Основные принципы формирования URI (перевод)
За последние несколько лет я проявляю всё большее интереса к юзабилити и веб-дизайну. Одной из областей, которую, как мне кажется, часто забывают, когда дело доходит до проектирования сайта является дизайн (отображение) URI на этом сайте. Современные CMS позволяют в той или иной степени формировать индивидуальный URI, но по умолчанию эта опция не используется, и в процессе проектирования эта задача часто находится последней в очереди.
Ясность и понятность адреса страницы (URI) - важная составляющая юзабилити сайта. Подавляющее большинство пользователей используют URI для навигации по сети Интернет (у меня есть знакомая секретарша, которая до сих пор серфит, кликая по баннерам - прим. пер.) и важно сделать эту навигацию максимально простой и понятной.
Во-первых, я хотел бы говорить о руководящих принципах, лежащих в основе дизайна URI, то есть поговорить о практической реализации этих принципов.
Примечание: Первоначально я написал эту статью, используя термин "URL", но так как термин "URL" признан устаревшим, то везде в тексте он заменён на "URI". (дополнительная информация от W3C) .
Принципы
Во-первых, давайте взглянем на некоторые общие принципы проектирования URI.
URI должен представлять объект, однозначно и постоянно
Базовым постулатом URI является то, что это представление собой объекта данных в Интернете. URI должен быть уникальным, один URI - один объект данных.
Хотя такая цель ставилась всегда, бывают случаи, кгода этого невозможно достичь средствами CMS, и один объект доступен по 2 и более разным адресам. Для исправления ситуации были придуманы теги Canonical в заголовке страницы, указывающие на "правильный" уникальный адрес, дабы сократить количество "дублированного" контента в индексах поисковых систем. И хотя это еще не окончательное решение проблемы дублирования, поисковики настоятельно рекомендуют использовать их при проектировании (подробнее см. на SEOmoz).
URI объекта (документа) должен быть постоянным - это свидетельствует о продуманной информационной архитектуре сайта, о тщательной планировке. Может прийти время, когда вы сочтете необходимым модернизировать свою CMS и изменить структуру URI - в этом случае стоит помнить о необходимости HTTP 301 moved permanently редиректа на новый адрес. Этот редирект укажет браузерам и поисковикам на смену адреса объекта и позволит сохранить Page Rank старого документа по новому адресу.
По возможности используйте ЧПУ
Использование ЧПУ должно быть основным мотивирующим фактором при проектировании URI - адрес должен создаваться прежде всего в расчете на конечного пользователя. SEO-факторы и простота разработки должны быть на втором месте.
Один из способов сохранить URI удобным является делать его коротким и осмысленным. Это означает использование минимума символов при сохранении удобства пользования им. Таким образом, адрес /about будет лучше чем /about-acme-corp-page. Стремление сократить не должно идти в ущерб удобству пользования - например /a2 еще короче чем /about, но это сокращение не даёт никаких видимых преимуществ и сбивает с толку посетителей.
И наоборот - использование сократителей ссылок приветствуется при обмене адресами - например при публикации их в Твиттере или на Фейсбуке. Хорошо, если есть возможность самостоятельно формировать содержание сокращенного URI для SEO целей - Bit.ly хорошо подходит для этой цели, для Wordpress можно использовать PrettyLink Pro или Short Url plugin.
URI не должен быть основан на малозначимой или не имеющей отношения к контенту информации. Типичным примером этого является использование в URI ID записи базы данных, под которым сохранена запись - например, шариковая ручка отображена по адресу /products/23. Пользователю без разницы, что запись товара в базе равна номеру 23, а вот URI типа /products/pen смотрелось бы гораздо уместнее. Однако часто возникает соблазн использования в URI именно идентификаторов вместо наименований (отдельный случай - проверка уникальности прим. мои), так как это упрощает работу с бэкендом CMS при разработке, одновременно ухудшая читаемость адреса при использовании веб-приложения.
Очень легко проверить дружественность URI - попробовать продиктовать его вслух, например по телефону:
моё резюме по адресу сайт точка ру слэш био
или
моё резюме по адресу сайт точка ру слэш вэ бэ бэ двадцать девять дубль-вэ
Последовательность
Структура URI должна быть последовательна - то есть раз избранный формат должен использоваться во всех разделах сайта. Использование продуманной структуры только в некоторых разделах сайта оставляет впечатление от сайта как от непродуманного и недоделанного. Если вы улучшаете структуру URI на работающем сайте, изменяете - не забудьте про 301-й редирект для пользователей, заходящих по старым ссылкам, как уже упоминалось выше.
"Hackable" URI
URI, относящиеся к последовательным записям, должны быть формировтаься таким образом, чтобы пользователь мог понять их структуру и вызывать произвольные документы, самостоятельно вводя адрес в адресную строку.
Например, если /events/2010/01 показывает ежемесячный календарь с событиями, с января 2010 года, то:
- /events/2009/01 должны показать календарь событий Январь 2009
- /events/2010 должны показать события в течение всего 2010 года
- /events/2010/01/21 должны показывать события на 21 января 2010
Ключевые слова
URI должен содержать слова, которые явно содержатся на странице и являются ключевыми. Таким образом, если URI для записи в блоге с длинным заголовком, тот в URI желательно размещать слова из заголовка (и не забудьте научиться создавать правильные заголовки! прим. моё). Например, если пост озаглавлен "Моя поездка в Best Buy за картами памяти", то URI может быть /posts/2010/07/02/trip-best-buy-memory-cards или нечто подобное. Эта же методика, по-видимому, является хорошим фактором улучшения SEO-характеристик веб-приложения.
Технические детали
Мы рассмотрели некоторые руководящие принципы, лежащие в дизайн URI. Теперь давайте посмотрим на некоторые технические реализации этих принципов.
Никаких свидетельств о серверной технологии
URI не должен содержать .html, .htm, .aspx или другие расширения файлов, предназначенные только для отображения базовой технологии. Конечного потребителя мало заботит, что ваш сайт был написан на ASP.NET (.aspx), ColdFusion (.cfm), или использует Server Side Includes (.shtml) - по крайней мере, большинству конечных пользователей это мало интересно. Такая бесполезная информация в адресе - это лишняя работа при наборе адреса и лишняя возможность совершить ошибку в наборе.
Единственное исключение из этого правила является добавление URI с расширениями типа .atom, .rss, или .json, которые необходимо явно указывать для указания формата данных, или в случае обработки заголовков страницы директивами сервера, например Accept HTTP.
без WWW
Префикс www - лишний в адресе, он не несет никакой полезной информации (gopher мёртв, детка!).
Однако многие пользователи по привычке набирают адреса сайтов с www перед доменным именем - такие запросы тоже желательно перенаправлять с помощью 301 редиректа на адрес домена без www.
Формат URI
URI должны быть в следующем формате:
domain.com/[key information]/[name]/?[modifiers].
/[key information]/ - это не идентификатор объекта, а его общий признак, это может быть названием категории (например "статьи", "комментарии"), названием глобальной родительской категории (например, "технологии") или более общий признак, такой, как дата.
Количество уровней /[key information]/ должно стремиться к минимуму, чтобы избежать чрезмерной вложенности, насколько это возможно.
В конце концов, URI должен формироваться по убыванию иерархии.
Например: домен → тип → категория → название.
Пример: http://domain.com/posts/servers/nginx-ubuntu-10.04.
В случае использования адресов, содержащих дату, формат должен следовать нисходящей иерархии:
год → месяц → день.
Пример: http://domain.com/news/tech/2007/11/05/google-announces-android.
(прим.: Это несколько не соответствует предыдущему замечанию об уровнях вложенности, целых 3 уровня для даты - перебор! Я стараюсь использовать дату в URI в таком формате /2007-11-05/).
Для включения вашего сайта в список новостных партнеров Google придется при проектировании учитывать требования Goggle к формату URI.
Все строчные
Все символы должны быть в нижнем регистре. Попробуйте ввести вручную URI со смешанным регистром без ошибок с первого раза - это малореально!
Если вы переделываете движок работающего сайта, URI которого содержали символы в разных регистрах - то позаботьтесь добавить в обработчик ЧПУ модуль, перенаправляющий все такие запросы на URI в нижнем регистре.
Команды в URI
В некоторых CMS встречаются команды серверу, передаваемые серверу методом GET - такие как show, delete, edit. Недеструктивные команды (которые не изменяют объект, типа команды выдачи печатной версии например) можно передавать в URI, все прочие рекомендовано передавать только с помощью метода POST.
Не мучайте сервер!
URI, содерждащие текст. например заголовок статьи, могут содержать различные типографские символы, не подходящие для использования в адресной строке, их необходимо преобразовывать:
- Символы в верхнем регистре преобразуем в нижний регистр
- Умляуты преобразуем в близкие по написанию символы (å в а)
- Пробелы (в т.ч. множественные) преобразовываем в дефис
- Нечитаемые символы (!, @ # $,%, ^, И, * и т.д.) заменяем дефисом
- Длинный дефис — заменяем коротким дефисом же!
- наверное, какие-то еще правила есть - но забыл!
Не забываем про URLencode перед выводом символов в URI (зачем это - читаем в Вики).
Источник - статья Guidelines for URI Design, перевести которую мне захотелось после очередного просмотра своей заметки Идеология формирования ЧПУ 3-летней давности. С вами были автор перевода kikaha и Булко Тимофей с TimNet.ru в качестве приглашённой звезды, вдохновляла на перевод консультация юриста бесплатно - так что спать будем спокойно и при своих :)