Каков наилучший подход к перенаправлению старых страниц в Jekyll и GitHub Pages?

У меня есть блог на страницах github — jekyll

Каков наилучший способ решения миграции стратегии URL?

Я обнаружил, что лучшей практикой является создание htaccess таким образом

Redirect 301 /programovani/2010/04/git-co-to-je-a-co-s-tim/ /2010/04/05/git-co-to-je-a-co-s-tim.html

Но, похоже, это не работает с Github. Еще одно решение, которое я нашел, — создать задачу rake, которая будет генерировать страницы перенаправления. Но поскольку это html, он не может отправить заголовок 301, поэтому сканеры SE не распознают его как перенаправление.


person Mailo Světel    schedule 16.04.2012    source источник
comment
Это сработало для меня: help.github.com/articles/redirects-on-github -страницы   -  person Mike Cole    schedule 08.06.2014


Ответы (8)


Лучшее решение — использовать как <meta http-equiv="refresh", так и <link rel="canonical" href=.

Очень хорошо работает, Google Bot переиндексировал весь мой сайт по новым ссылкам, не теряя позиций. Также пользователи сразу перенаправляются на новые посты.

<meta http-equiv="refresh" content="0; url=http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/">
<link rel="canonical" href="http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/" />

Использование <meta http-equiv="refresh" будет перенаправлять каждого посетителя на новый пост. Что касается Google Bot, он обрабатывает <link rel="canonical" href= как перенаправление 301, в результате вы переиндексируете свои страницы, и это то, что вы хотите.

Весь процесс переноса моего блога с Wordpress на Octopress я описал здесь. http://konradpodgorski.com/blog/2013/10/21/how-i-migrated-my-blog-from-wordpress-to-octopress/#redirect-301-on-github-pages

person Konrad Podgórski    schedule 31.10.2013
comment
При переходе на страницы GitHub это сработало для меня: help.github.com/articles /перенаправляет-на-github-страницы. Похоже, он делает все, что вы упомянули. - person Mike Cole; 08.06.2014
comment
Означает ли эффект использования canonical, что Google переиндексирует страницы с нуля, или он перенесет оценку рейтинга на новую страницу? Можете ли вы уточнить, как этот подход влияет на рейтинг страницы? - person Yuri; 15.04.2015
comment
Не вызовет ли <meta http-equiv="refresh" бесконечный цикл перенаправления? Вот что я получаю, может я что-то не так делаю? - person Erik Berkun-Drevnig; 11.08.2015
comment
@ErikBerkun-Drevnig контент, показанный выше, добавляется на старую страницу и должен указывать на новую страницу. Таким образом, не должно быть бесконечного цикла. - person vossad01; 11.01.2017
comment
Если кому интересно: эти две строки должны быть включены в ваш блок <head>. - person stragu; 03.07.2018

Пробовали ли вы использовать плагин Jekyll Alias ​​Generator?

Вы помещаете URL-адреса псевдонимов в заголовок сообщения YAML:

---
  layout: post
  title: "My Post With Aliases"
  alias: [/first-alias/index.html, /second-alias/index.html]
---

Когда пользователь посещает один из URL-псевдонимов, он перенаправляется на основной URL-адрес через обновление метатега:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="refresh" content="0;url=/blog/my-post-with-aliases/" />
  </head>
</html>

См. также эту запись в блоге на эту тему.

person ms-ati    schedule 03.12.2012
comment
GitHub Pages не использует плагины - person tekknolagi; 30.12.2012
comment
@tekknolagi Возможно, я не понимаю GitHub Pages. Но если вы используете jekyll и просто публикуете статический сайт на Github, то это сработает, поскольку сгенерированные страницы будут включать метаобновления для старых URL-адресов? - person ms-ati; 03.01.2013
comment
это правильно, но GitHub не будет запускать Jekyll с плагинами, а просто будет обслуживать скомпилированный статический сайт - person tekknolagi; 03.01.2013
comment
Я закончил с чем-то вроде этого. Я генерирую страницы перенаправления локально с помощью задачи Rake и отправляю их на Github как статические страницы. - person Mailo Světel; 16.07.2013
comment
Я следовал этому подходу, и это было довольно легко. Я столкнулся с двумя проблемами: 1) плагин не запускался - мне пришлось установить safe: false в _config.yml 2) мне нужно было создать более 400 записей псевдонимов. Вместо того, чтобы создавать их вручную, я автоматизировал их с помощью скрипта Python: - person smholloway; 31.01.2014

перенаправление из плагина

https://github.com/jekyll/jekyll-redirect-from#redirect-to

Он поддерживается GitHub и упрощает его:

_config.yml

gems:
  - jekyll-redirect-from

a.md

---
permalink: /a
redirect_to: 'http://example.com'
---

как объяснено по адресу: https://help.github.com/articles/redirects-on-github-pages/

В настоящее время:

firefox localhost:4000/a

перенаправит вас на example.com.

Плагин вступает во владение всякий раз, когда redirect_to определяется страницей.

Протестировано на страницах GitHub v64.

Примечание: в этой версии недавно была исправлена ​​серьезная ошибка, из-за которой для перенаправления ошибочно используется макет по умолчанию: https://github.com/jekyll/jekyll-redirect-from/pull/106

Метод макета вручную

Если вам не хочется использовать https://github.com/jekyll/jekyll-redirect-from его легко реализовать самостоятельно:

a.md

---
layout: 'redirect'
permalink: /a
redir_to: 'http://example.com'
sitemap: false
---

_layouts/redirect.html на основе перенаправления с HTML-страницы:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Redirecting...</title>
  {% comment %}
    Don't use 'redirect_to' to avoid conflict
    with the page redirection plugin: if that is defined
    it takes over.
  {% endcomment %}
  <link rel="canonical" href="{{ page.redir_to }}"/>
  <meta http-equiv="refresh" content="0;url={{ page.redir_to }}" />
</head>
<body>
  <h1>Redirecting...</h1>
  <a href="{{ page.redir_to }}">Click here if you are not redirected.<a>
  <script>location='{{ page.redir_to }}'</script>
</body>
</html>

Как и в этом примере, плагин redirect-from не генерирует ошибки 301, а только переадресацию meta + JavaScript.

Мы можем проверить, что происходит с:

curl localhost:4000/a
person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 25.04.2016

Это решение позволяет вам использовать настоящие HTTP-перенаправления через .htaccess, однако ничего, связанное с .htaccess, не будет работать на страницах GitHub, поскольку они не используют Apache.

По состоянию на май 2014 г. GitHub Pages поддерживает перенаправления, но в соответствии с документация jekyll-redirect-from Gem они по-прежнему основаны на HTTP-REFRESH (с использованием тегов <meta>), который требует полной загрузки страницы, прежде чем произойдет перенаправление.

Мне не нравится подход <meta>, поэтому я придумал решение для тех, кто хочет обеспечить реальную переадресацию HTTP 301 в файле .htaccess с помощью Apache, который обслуживает предварительно созданный сайт Jekyll:


Сначала добавьте .htaccess к свойству include в _config.yml

include: [.htaccess]

Затем создайте файл .htaccess и не забудьте включить в него вводную часть YAML. Эти тире важны, потому что теперь Jekyll будет анализировать файл с помощью Liquid, языка шаблонов Jekyll:

---
---
DirectoryIndex index.html

RewriteEngine On
RewriteBase /

...

Убедитесь, что ваши сообщения, требующие перенаправления, имеют два свойства, например:

---
permalink: /my-new-path/
original: blog/my/old/path.php
---

Теперь в .htaccess просто добавляем цикл:

{% for post in site.categories.post %}
  RewriteRule ^{{ post.original }} {{ post.permalink }} [R=301,L]
{% endfor %}

Это будет динамически генерировать .htaccess каждый раз, когда вы создаете сайт, а include в вашем файле конфигурации гарантирует, что .htaccess попадет в каталог _site.

RewriteRule ^blog/my/old/path.php /my-new-path/ [R=301,L]

Оттуда вы можете обслуживать _site с помощью Apache. Обычно я клонирую полный репозиторий Jekyll в каталог, отличный от webroot, тогда мой виртуальный хост представляет собой символическую ссылку на папку _site:

ln -s /path/to/my-blog/_site /var/www/vhosts/my-blog.com

Тада! Теперь Apache может обслуживать папку _site из вашего виртуального корня вместе с переадресацией на основе .htaccess, которая использует любой код ответа HTTP, который вы пожелаете!

Вы могли бы даже проявить фантазию и использовать свойство redirect во вступительной части каждого сообщения, чтобы указать, какой код перенаправления использовать в вашем цикле .htaccess.

person Chris Ruppel    schedule 26.06.2013
comment
Это кажется отличным! Но что, если есть несколько оригинальных (предыдущие ссылки теперь достигают 404) ссылок для поста? - person Sharath kumar; 21.06.2017
comment
Решение будет включать более сложную логику при создании файла .htaccess. Например, вы можете преобразовать YAML так, чтобы original был массивом, а не строкой. Затем вам нужен вложенный цикл, чтобы каждая запись original генерировала перенаправление на permalink. Возьмите этот код в качестве отправной точки и поэкспериментируйте сами! - person Chris Ruppel; 21.06.2017
comment
Спасибо. Я заставил его работать, как вы предложили. Я использовал этот метод для учебника. - person Sharath kumar; 21.06.2017
comment
поскольку это решение не работает на страницах GitHub, оно вообще не отвечает на вопрос. Количество нерелевантных ответов бесконечно, так зачем вообще это публиковать? - person Corey Goldberg; 27.04.2018
comment
@CoreyGoldberg в основном для того, чтобы дать таким людям, как вы, что-то, что они могут прокомментировать;) - person Chris Ruppel; 28.04.2018

Лучший вариант — полностью избежать изменений URL-адреса, установив формат постоянной ссылки в _config.yml в соответствии с вашим старым блогом.

Помимо этого, наиболее полным решением является создание страниц перенаправления, но оно не обязательно стоит затраченных усилий. В итоге я просто сделал свою страницу 404 немного более дружелюбной, добавив javascript для угадывания правильного нового URL-адреса. Он ничего не делает для поиска, но реальные пользователи могут попасть на страницу, которую они искали, и в остальной части кода нет устаревших вещей, которые нужно поддерживать.

http://tqcblog.com/2012/11/14/custom-404-page-for-a-github-pages-jekyll-blog/

person Tom Clarkson    schedule 15.11.2012

Поскольку github не разрешает переадресацию 301 (что неудивительно), вам придется принять решение между переходом на новую структуру URL-адресов (и попаданием в поисковую систему) или оставлением URL-адресов такими, какие они есть. Я предлагаю вам идти вперед и сделать ход. Пусть чипы поисковых систем падают, где они могут. Если кто-то нажмет на одну из ваших старых ссылок через поисковую систему, он будет перенаправлен на новое место. Со временем поисковые системы подхватят ваши изменения.

Чтобы облегчить ситуацию, вы можете создать карту сайта где вы перечисляете только свои новые страницы, а не старые. Это должно ускорить замену старых URL на новые. Кроме того, если все ваши старые URL-адреса находятся в вашем каталоге /programovani, вы также можете использовать файл robots.txt. чтобы сообщить будущим сканированиям, что они должны игнорировать этот каталог. Например:

User-agent: *
Disallow: /programovani/

Поисковым системам потребуется некоторое время, чтобы догнать изменения. Это не имеет большого значения. Пока старые URL-адреса все еще существуют и перенаправляют реальных людей на активные страницы, все будет в порядке.

person Alan W. Smith    schedule 19.04.2012
comment
SE меня не беспокоит. Я получаю 404 по ссылкам с других сайтов/форумов. Я сделал поддельные страницы с нулевым временем обновления, которые будут перенаправлять пользователя. Я протестировал его в инструментах для веб-мастеров, и, похоже, краулер тоже им доволен. Но я нет ;) - person Mailo Světel; 20.04.2012
comment
Если у вас все еще есть проблемы с ошибкой 404, дайте мне ссылку на одну из них, и я посмотрю и посмотрю, смогу ли я сказать, что происходит. - person Alan W. Smith; 20.04.2012
comment
Прямо сейчас я решил это с помощью поддельных страниц. Одним из первых 404 был rooland.cz/programovani/2010/04/git-co-to-je-a-co-s-tim . Я генерирую их с помощью этого git.io/UrlZaQ . Скрипт ужасный, но он делает то, что мне нужно - person Mailo Světel; 20.04.2012

Как уже упоминалось, лучшим решением является сохранение рабочих URL-адресов или дублирование страниц и указание канонический URL.

Поскольку страницы github не поддерживают настоящие перенаправления, я решил настроить rerouter на Heroku для возврата 301 (постоянный ) перенаправляет со старого домена моего сайта на новый. Подробности я описал здесь:

http://joey.aghion.com/simple-301-redirects/

person Joey    schedule 16.07.2013
comment
Будет ли это поддерживать более сложные перенаправления? Например, с одним доменом, если я хочу перенаправить такие ссылки, как example.com/index.html на example.com или example.com/some-post/index.html на example.com/some-post/. - person Erik Berkun-Drevnig; 11.08.2015

За последние несколько месяцев Jekyll претерпел несколько серьезных обновлений, поэтому, возможно, это было невозможно, когда этот вопрос был изначально опубликован...

Jekyll поддерживает атрибут permalink в вступительной части YAML ваших сообщений в блоге. Вы можете указать URL-адрес, который должен иметь ваш пост, и Jekyll будет использовать его (вместо имени файла) при создании вашего сайта.

---
title: My special blog post
permalink: /programovani/2010/04/git-co-to-je-a-co-s-tim
---
My blog post markdown content
person Andrew    schedule 25.09.2013
comment
Атрибут постоянной ссылки просто сообщает jekyll, что делать с новым сгенерированным URL-адресом, но не предоставляет ничего в виде перенаправлений для старой структуры постоянной ссылки, которая могла бы существовать ранее. - person Joel Glovier; 05.12.2013
comment
Вы имеете в виду редиректы старых страниц на старом сайте? Как будто это третий раз, когда страница была перемещена? - person Andrew; 05.12.2013