Який найкращий підхід для переспрямування старих сторінок у Jekyll та GitHub Pages?


77

У мене є блог на сторінках 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 не розпізнають це як переспрямування.


2
Це спрацювало для мене: help.github.com/articles/redirects-on-github-pages
Mike Cole

Відповіді:


69

Найкраще рішення - використовувати обидва <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


5
При переході на сторінки GitHub це спрацювало для мене: help.github.com/articles/redirects-on-github-pages . Схоже, він робить все, про що ви згадали.
Mike Cole

Чи означає ефект від використання canonical, що Google переіндексує сторінки з нуля, або переносить рейтинг на нову сторінку? Чи можете ви пояснити, як такий підхід впливає на рейтинг сторінок?
Юрій

Чи не буде <meta http-equiv="refresh"причиною нескінченний цикл перенаправлення? Це те, що я отримую, можливо, я роблю щось не так?
Ерік Беркун-Древніг

3
@ ErikBerkun-Drevnig вміст, побачений вище, додається на "стару" сторінку і повинен вказувати на "нову" сторінку. Зроблено таким чином, не повинно бути нескінченного циклу.
vossad01

Якщо хтось цікавиться: ці два рядки слід включити у ваш <head>блок.
stragu

23

Ви пробували плагін 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>

Дивіться також цю публікацію в блозі на цю тему.


3
Сторінки GitHub не використовують плагіни
tekknolagi

@tekknolagi Можливо, я не розумію Сторінки GitHub. Але якщо ви використовуєте jekyll і просто публікуєте статичний сайт на Github, то це буде працювати, оскільки згенеровані сторінки включатимуть метаоновлення для старих URL-адрес?
ms-ati

це правильно, але GitHub не буде запускати Jekyll з плагінами, просто обслуговуйте скомпільований статичний сайт
tekknolagi

2
Я закінчив щось подібне. Я
генерую

Я дотримувався цього підходу, і це було досить просто. Я натрапила на два питання: 1) доданок не буде працювати - я повинен був набір safe: falseв _config.yml2) я буду мати , щоб створити більше 400 записів псевдонімів. Замість того, щоб обробляти
smholloway

11

redirect-from plugin

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

9

Це рішення дозволяє використовувати справжні перенаправлення 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]

З цього моменту ви самі повинні обслуговувати _siteApache. Я зазвичай клоную повний репо Jekyll у каталог, що не є веб-кореневим, тоді мій vhost є символічним посиланням на _siteпапку:

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

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

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


Це здається чудовим! Але що, якщо для публікації існує кілька оригінальних (попередні посилання зараз потрапляють на 404)?
Шарат Кумар,

2
Рішення передбачає складнішу частину логіки під час створення .htaccessфайлу. Наприклад, ви можете перетворити YAML таким чином, що originalце масив замість рядка. Тоді вам потрібен вкладений цикл, щоб кожен originalзапис генерував переспрямування на permalink. Візьміть цей код як вихідну точку та експериментуйте самі!
Кріс Руппель,

Дякую. Я змусив це працювати, як ти запропонував. Я використав цей метод для підручника.
Шарат Кумар,

2
оскільки це рішення не працює на сторінках GitHub, воно не відповідає на питання взагалі. Кількість нерелевантних відповідей нескінченна, то навіщо взагалі публікувати це?
Кори Голдберг,

@CoreyGoldberg здебільшого для того, щоб людям, як ти, щось коментувати;)
Кріс Руппель,

5

Найкращий варіант - уникнути змін URL-адрес взагалі, встановивши формат постійного посилання в _config.yml відповідно до вашого старого блогу.

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

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


2

Оскільки github не дозволяє переспрямувати 301 (що не дивно), вам доведеться приймати рішення між переходом до нової структури URL-адреси (і прийняттям пошукової машини) або залишенням URL-адрес такими, якими вони є. Я пропоную вам піти далі і зробити крок. Нехай чіпи пошукової системи падають там, де можуть. Якщо хтось потрапить за одним із ваших старих посилань через пошукову систему, він буде перенаправлений на нове місце. З часом пошукові системи заберуть ваші зміни.

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

User-agent: *
Disallow: /programovani/

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


SE мене турбує не те. Я отримую 404 за посиланнями з інших сайтів / форумів. Я зробив підроблені сторінки з нульовим часом оновлення, які будуть "перенаправляти" користувача. Я протестував його в інструментах для веб-майстрів, і схоже, сканер також цим задоволений. Але я не;)
Mailo Světel

Якщо ви все ще маєте проблеми з помилками 404, перешліть мені посилання на одну з них, і я подивлюсь і подивлюсь, чи можу я сказати, що відбувається.
Алан В. Сміт,

Зараз я вирішив це на підроблених сторінках. Одним із колишніх 404 був rooland.cz/programovani/2010/04/git-co-to-je-a-co-s-tim . Я генерую їх за допомогою цього git.io/UrlZaQ . Сценарій жахливий, але він робить те, що мені потрібно
Mailo Světel

1

Як зазначали інші, найкращим рішенням є збереження робочих URL-адрес або продублювання сторінок та вказівка канонічної URL-адреси.

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

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


Чи підтримувало б це більш складні переспрямування? Такі , як з одним доменом , якщо я хотів перенаправити посилання , як example.com/index.htmlна example.comчи example.com/some-post/index.htmlна example.com/some-post/.
Ерік Беркун-Древніг

1

Протягом останніх кількох місяців Джекілл переживав деякі основні оновлення, тож, можливо, це було неможливо, коли це питання було опубліковано спочатку ...

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

1
Атрибут постійного посилання просто вказує jekyll, що потрібно зробити для нової сформованої URL-адреси, але не передбачає жодних переспрямувань для старої структури постійного посилання, які могли існувати раніше.
Joel Glovier

Ви маєте на увазі переспрямування старих сторінок на старий сайт? Начебто сторінку переміщено вже втретє?
Ендрю
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.