На мой взгляд, намного удобнее и человечнее выглядят ссылки вида /dvizhok/chpu.html, чем ссылка с параметрами вида /index.php?category=21&content=74. Плюс к читаемости ЧПУ добавляется бонус в виде лучшего ранжирования страницы поисковыми системами. Поисковики, при прочих равных, отдадут предпочтение странице, в адресе которой будут слова, заданные в поисковом запросе. Они давно научились правильно понимать транслит, поэтому нет никакого смысла включать в URL кириллицу.

В предыдущих билдах была использована схема генерации ссылок на материалы с использованием в ссылке ключевого слова и идентификатора. Например, старый адрес статьи в этом блоге выглядел так: http://savagenoname.windowsfaq.ru/testirovanie-proizvoditelnosti_item180.html

При использовании такой ссылки есть две небольшие, но заметные проблемы:

• при чтении ссылки не понятно к какой категории относится материал;
• в тексте ссылки есть посторонний, как с точки зрения человека, так и с точки зрения поисковой системы, служебный идентификатор (_item180).

Такая ссылка была намного лучше и правильнее со всех точек зрения по отношению к ссылке вида /index.php?category=21&content=74, но всё равно далека от идеала. В нынешнем билде успешно решены обе проблемы. Теперь в ссылке на материалы и категории отсутствуют служебные идентификаторы, и все ссылки на материалы, входящие в категории, включают название категории, в которой они опубликованы. Новый адрес статьи из этого блога выглядит так: http://savagenoname.windowsfaq.ru/dvizhok/testirovanie-proizvoditelnosti.html

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

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

Для решения этой проблемы часто можно встретить рекомендацию использовать редиректы через код ответа сервера 301, т.е. автоматическое перенаправление со старого адреса опубликованных материалов на новые. Эта рекомендация достаточно опасна, ибо поисковики относятся к массовым редиректам примерно так же, как и к массовым ошибкам 404. Вполне вероятно, что сайт будет полностью исключён из индекса для последующей полной переиндексации. Причём, после переиндексации материалы сайта моугт потерять "вес" в глазах поисковой системы и их положение в выдаче будет ниже, чем было до смены структуры ссылок.

В некоторых случаях невозможно написать одно-два правила для автоматической переадресации со старого адреса статьи на новый. Например, если раньше материалы публиковались в папке /articles/, а после реструктуризации были перемещены в папку /content/, то написание правила для mod_rewrite не представляет труда. Но если раньше материалы имели адреса вида /index.php?category=21&content=74, а новые адреса стали вида /dvizhok/chpu.html, то правилом уже не ограничиться и придётся писать скрипты, которые будут искать новый адрес статьи по их старым идентификаторам. И это ещё не самый сложный пример. Достаточно часто при смене движка структура сайта меняется настолько сильно, что переадресацию настроить невозможно.

Что же предлагает GlassCubeServer для безболезненного изменения структуры давно работающего сайта или при миграции с других движков?

Сначала рассмотрим возможности переадресации.

Движок предлагает простое создание правил переадресации со старых адресов на новые. Переадресация возможна через код ответа сервера 301, 302 (документ перемещён постоянно или временно) или без уведомления о переадресации. Если выбрать второй вариант без уведомления, то один и тот же материал будет доступен и по старому адресу и по новому. С одной стороны, это полностью решает описанные выше проблемы. Но появляется другой нежелательный эффект: одна и та же статья теперь доступна по двум адресам:
по старому http://savagenoname.windowsfaq.ru/testirovanie-proizvoditelnosti_item180.html
и новому http://savagenoname.windowsfaq.ru/dvizhok/testirovanie-proizvoditelnosti.html

Это намного меньшая проблема, чем массовый редирект через 301 код ответа сервера или 404-я ошибка при переходе с поисковой системы, но, тем не менее, проблема. Она решается достаточно просто: каждое обращение посетителя или поисковой системы по старой ссылке движком протоколируется и ведётся учёт количества срабатывания правил переадресации. В интерфейсе GlassCubeServer можно видеть количество срабатываний кажого правила. Таким образом, если одновременно предстоит сменить адреса у большого количества материалов, то сначала генерируется список правил для переадресации без кода ответа сервера, а затем постепенно тип каждого правила изменяется на переадресацию через 301 код ответа сервера. Для посетителей работа всех этих алгоритмов остаётся незаметна: они как переходили из поисковой выдачи на определённый материал, так и продолжают. А поисковые системы, постепенно получая 301-й редирект начинают медленно "вымывать" из индекса старые ссылки на материалы, заменяя их новыми. Это исключает выпадение сайта из индекса, потерю посещаемости и другие неприятности, вызываемые массовыми редиректами или 404 ошибками. Это же решение сохраняет работоспособность всех ссылок на домен, которые были размещены на других сайтах за годы работы. Так называемая "ссылочная масса" после миграции на GlassCubeServer будет работать как и раньше.

Как выполнить безболезненную миграцию с другого движка на GlassCubeServer с изменением адресов всех опубликованных материалов?

GlassCubeServer для подготовки миграции предлагает воспользоваться небольшим поисковым роботом, который пройдёт по всему старому сайту, соберёт с него все ссылки и описания доступных по ним страниц. После миграции можно будет сформировать аналогичный описанному выше список правил переадресации и постепенно, в течение, например, года, заменить в индексах поисковых систем все старые ссылки на материалы новыми. Использование робота позволяет найти на старом сайте все ссылки на один материал, а не только наиболее заметные. Например, часто можно наблюдать ситуацию, когда веб-мастер учитывает только основной путь по сайту от главной страницы до какого-либо материала во вложенной категории. Но на практике поисковые роботы находят один и тот же материал совершенно разными путями. Например, через тэги, через архив анонсов, карту сайта и так далее. Использование при подготовке к миграции робота позволяет учесть все страницы старого сайта, все ссылки. После миграции ни поисковые системы, ни люди не будут получать 404-х ошибок.

Более того, в интерфейсе сервера в реальном времени можно наблюдать за активностью на сайте и сразу же при появлении красной строки с 404-й ошибкой создать правило переадресации парой кликов мыши. Запланирована к реализаци возможность анализа накопленных логов для быстрой "работы над ошибками".