Идеология формирования ЧПУ
Разрабатывая ЧПУ для CMS, я обращаю внимание на 3 основных аспекта:
- Зрительное восприятие URL человеком
- Восприятие и оценка URL поисковыми машинами
- Удобство использования URL для управления CMS
По первому аспекту идет тихая война между приверженцами календарного и иерархического способов. Причем война не особенно обоснованная, поскольку каждый из способов показывает свои преимущества в конкретных приложениях: первый хорош и удобен в блогах, второй соответственно в информационных системах, регулярно пополняемых материалом, не имеющим жесткой привязки к календарной дате.
Я совершенно искренне недоумевал, почему и в блогах нельзя использовать только 2-й способ - пишем site.com/blog/unikalnoe_nazvanie_materiala - и никаких проблем? Но у первого есть 2 неоспоримых преимущества: легко получать материалы за определенный временной промежуток, и очень легко формировать навигацию. Правда любой материал получает длинный адрес site.com/blog/year/month/day/some_else - выглядит не очень(например, как в этом блоге, построенном на InTerra), но зато очень удобно для пользователя - никто не мешает ему отсечь кусок урла в адресной строке и посмотреть, например, что автор писал за период site.com/blog/year/month/. Такой фокус трудновато проделать, если тот же календарный способ используется с формированием полного адреса в одном виртуальном каталоге - site.com/blog/year-month-day/some_else - не всякий пользователь догадается, что и как именно убрать из адреса, чтобы просмотреть интересующий его период. Однако при нормально построенной навигации такой подход мне представляется надуманным, как впрочем и разработчикам навигации сервиса Blogspot - в этом легко убедиться, посмотрев как устроена навигация по архивам публикаций любого пользователя за любой период.
В любом случае, исповедуя "человекопонятность", необходимо помнить что один взгляд на урл должен говорить читателю - где он находится, без догадок - /blog/ - значит блог, /shop/ - значит магазин. Причем цифры после /blog/ ясно говорят пользователю что это скорее всего дата, а вот после /shop/ должно стоять /anal_toys/ а уж вовсе не /86tge987yhf9h_/ - такой подход и parental control кстати облегчит :) В блоге или в разделе новостей корпоративной CMS оправданно будет сохранить двойную навигацию - как по хронологии, так и по тематическим разделам, в остальных навигационных блоках вполне досточно будет формировать ЧПУ используя реальную или виртуальную иерархическую структуру разделов.
Второй аспект тоже вызывает немало головной боли. Одни поисковики больше "любят" страницы с меньшим уровнем вложенности, другим это абсолютно равноапостольно. Дорвейщики этот факт знают и дабы не рисковать, генерируют дорвеи в которых все файлы контента находятся в корневой папке и имеют уникальные имена. Это дает быструю индексацию контента Гуглем и выдачу его в результатах поиска в кратчайшие сроки - до бана, если повезет, сутки-трое такой сайт проживет. Нас интересует другой момент - просто адекватная и быстрая индексация контента. К примеру, один мой недавний материал я опубликовал также на форуме searchengines.ru. Через 3 дня смотрим запрос по точному названию материала - есть выдача с форума (1-й уровень вложенности), есть даже с моего ЖЖ (1-й уровень, проиндексирована главная) - а на моем блоге индексация главной закрыта, и сама статья, находящаяся на 4-м уровне, ждет своей поры. Не принципиально, что я закрыл индексацию - обычно большой материал не бывает доступен с главной страницы - как правило есть 2-3 абзаца в анонсе и ссылка на постоянный адрес - а он может ждать своей очереди долго, и иногда, если кто-то успеет скопировать материал - то попадает в сапплиментал и прощай трафик.
Таким образом, у приверженцев длинных иерархических URL появляются противники с серъезными аргументами. Как с ними бороться - каждый решает по-своему, я пока не определился какую сторону принять, но проблема есть и решать её надо.
Принципы использования ЧПУ для управления навигацией с помощью mod_rewrite довольно просты - построение ЧПУ должно быть непротиворечивым и не входить в конфликт с первыми двумя аспектами по возможности.
Непротиворечивость реализовать просто, опять на примере используемой CMS - если после адреса сайта в строке цифра - это скорее всего календарный урл, скрипт проверяет и выводит публикацию, если она существует; если слово - это вероятно название раздела. Угу, я обновил Интерру до новой версии и оказалось что раздел Ajax недоступен - разработчик, недолго думая зарезервировал это слово, как служебное в новой версии, функция-обработчик теперь интерпретирует именно этот запрос по-другому, в результате мой сайт поломался (don't worry, я все починил)! А ведь в том же Wordpress-е уже дано пришли к простому решению - зарезервировать для служебных слов определенный префикс, и всего делов - wp-admin, wp-login и так далее, а если пользователь пытается создать раздел в корне сйта с таким же названием - мягко, но твердо наставить на путь истинный. Берем принцип на вооружение.
А вот с бесконфликтностью я думаю придется идти на хитрости. Первый аспект нам ничем не угрожает, а вот глубина вложенности материала создает определенные проблемы для своевременной индексации поисковиками. Как полумеру, я принял для себя такое решение: ссылки на свежие материалы блога с главной страницы формируются как site.com/quick_year_month_day_some_else.php - обработчик ловит служебное слово quick (на самом деле читаем абзац выше и придумываем своё слово правильно), выдает 301 и редиректит уже на "правильный" адрес. Но редиректит не сразу после публикации. а потом, через заданное время, например через пару месяцев, а до тех пор материал спокойно проживает по двум адресам, один из них будет в выдаче, второй видимо в сапплиментале - это не смертельно.
Засим закругляюсь, с удовольствием выслушаю мнения авторитетных товарищей