Ne v kontakte Antisocial programmer's blog

Изменение структуры URL при переезде на Acrylamid

Изменение структуры URL при переезде на Acrylamid

    blog     migration     acrylamid     url     seo

Продолжу рассказ о приключениях, связанных с уходом с Drupal на Acrylamid. Как и обещал, на этот раз речь пойдет о смене структуры адресов страниц моего блога.

Напомню еще раз о задачах, которые я перед собой поставил:

  • Сделать более-менее вменяемые URL постов. Например, транслитерированный кошмар вроде /blog/aleks/ispolzuem-svn-v-upravlenii-saitom-chast-pervaya-teoreticheskie-soobrazheniya превратить в более вменяемое /2008/Use-SVN-website-governance-Part-one-theoretical-considerations.html.
  • Скорректировать все внутренние ссылки на посты, чтобы они указывали на правильные адреса постов. Попутно — все внутренние ссылки, картинки и тому подобное с полными адресами виде http://nevkontakte.(com|org.ru)/whatever позаменять на просто /whatever, чтобы обезопасить себя от проблем в случае смены домена или, например, перехода на https.
  • Организовать редиректы со старых адресов постов на новые для поисковиков и внешних ссылок.

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

  1. Внешние ссылки на посты по старым адресам не должны быть сломаны.
  2. При запросе старого адреса страницы поисковики должны получать редирект 301 на новый адрес, чтобы они могли корректно переиндексировать сайт.
  3. В будущем, как настоящий гик, я хочу захостить блог на GitHub Pages, раз уж он у меня полностью статический.

Единственная сложность — GitHub Pages не предусматривает никакой возможности задать 301-й редирект для определенного адреса. Поэтому, решение состоит из двух шагов:

  1. Сгенерировать .htaccess с редиректами для поисковиков, и дождаться переиндексации, оставаясь на старом хостинге, который работает на Apache.
  2. Так же сгенерировать набор страничек-заглушек с перенаправлением через <meta http-equiv="refresh">, которые будут служить для перенаправления пользователей после переезда на GitHub.

Имея адреса новых и старых страниц сделать это не так уж и сложно:

  1. Код генерации .htaccess. На выходе — длинный-длинный .htaccess, с правилами для mod_rewrite.
  2. Код генерации заглушек для GH Pages. Результат работы — по адресу старой странички генерируется почти пустой HTML документ, содержащий в себе лишь meta redirect на нужный адрес с нулевой задержкой.

Есть один лайф-хак, связанный с таким решением. Если хостинг не поддерживает “умных” средств передачи файлов типа rsync, можно сэкономить кучу времени, не загружая на сервер заглушки для гитхаба — их работу сделает .htaccess.

P.S. Ruined Conflict — Treason (Destruction Remix)

blog comments powered by Disqus