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

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

что является лучшим способом, чтобы решить стратегию адрес миграции?

Я нашел лучшую практику в общем, это создать 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 head, поэтому искатели SE не распознают его как перенаправление.

8 65
github jekyll redirect github-pages http-status-code-301

8 ответов:

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

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

<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 бота, то он лечит <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

61

вы пробовали плагин генератора псевдонимов Jekyll?

вы помещаете 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>

см. также этот блог на эту тему.

21

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

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

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

во-первых, добавьте .htaccess до include в собственность _config.yml

include: [.htaccess]

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

---
---
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 в файле config гарантирует, что .htaccess превращает его в .

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

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

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

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

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

10

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

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

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

5

redirect-from pluginhttps://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 плагин не генерирует 301s, только meta + JavaScript перенаправляет.

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

curl localhost:4000/a
4

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

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

User-agent: *
Disallow: /programovani/

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

2

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

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

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

1

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

Джекилл поддерживает a

1