На заре интернета все сайты по сути представляли собой набор текстовых документов. Каждая страница сайта фактически была отдельным файлом. Чтобы на каждой странице было навигационное меню сайта, его приходилось вносить во все такие файлы. Когда таких страниц было 2-3, то проблем не возникало. Но представьте, что у вас крупный информационный ресурс (по тем меркам — страниц на 100), и вам нужно добавить в навигационное меню еще одну ссылку.

Чтобы решить эту проблему, разработчики начали подключать к своим сайтам простенькие скрипты, которые позволяли отделить типовые элементы на странице от уникальных. Такие скрипты были прототипами современных CMS.

Ссылки в веб-скриптах

Так был заложен принцип формирования ссылок, и с тех пор он принципиально не менялся: ссылка на страницу скрипта состоит из пути к скрипту и набора параметров, позволяющих скрипту вывести необходимую информацию. Выглядит это примерно так:

http://example.com/index.php?section=news&article=12

Чем сложнее скрипт, тем больше параметров нужно, чтобы правильно идентифицировать страницу. Так, сайт, целиком и полностью состоящий из текстовых (статических) страниц, может обойтись одним параметром, в то время как интернет-магазину со сложной системой поиска и фильтрации товаров может потребоваться с десяток параметров.

Структура URL

Давайте на минутку отвлечемся и рассмотрим структуру URL детальнее. Рассмотрим все составляющие URL на примере:

http://vasya:[email protected]:8080/files/new.php?title=Untitled&cat=web#form

В этом примере присутствуют все возможные составляющие URL, в том числе и необязательные. Первым идет протокол или схема (в нашем примере это протокол http). В контексте браузера этот параметр определяет, каким именно образом браузер будет обращаться к серверу, содержащему запрашиваемый ресурс.

Далее идут два параметра: логин и пароль, указанные через двоеточие. В нашем примере это vasya и 123 соответственно. Эти два параметра являются необязательными и чаще используются с протоколом ftp.

За логином и паролем следует хост и порт. Хостом может быть как доменное имя, так и IP-адрес (у нас хостом является доменное имя example.com). Порт является необязательным (у нас указан порт 8080). Если он отсутствует, браузер использует стандартный для выбранного протокола порт (для протокола http это 80).

Далее идет путь к ресурсу на сервере (у нас это /files/new.php). Этот путь передается браузером непосредственно серверу при составлении запроса. Обычно структура путей организована на основе файловой системы, поэтому она напоминает адрес файла.

После пути к ресурсу URL может содержать один или несколько GET-параметров. Эти параметры отделены от пути к ресурсу знаком вопроса и представляют собой набор пар «ключ = значение», разделенных символом &. В нашем примере есть два параметра, title и cat, со значениями Untitled и web соответственно.

Последней возможной составляющей URL является якорь. Якорь отделен от остального URL символом решетки # (у нас значение якоря — form). Он не передается на сервер, а используется браузером для автоматического перехода к специфическому элементу на странице, полученной в результате запроса.

Оптимизация ссылок

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

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

http://example.com/index.php?section=news

Вместо нее мы в атрибуте href всех ссылкох на раздел новостей пишем /news, а когда получаем от браузера запрос к этому пути, отправляем пользователю содержимое исходного адреса. Естественно, чем больше параметров содержится в исходном URL, тем сложнее будет и преобразованный URL.

Проблемы оптимизированных ссылок

В теории все относительно просто и понятно, но реальность такова, что в современном интернете оптимизацией ссылок принято заниматься программистам, в связи с чем такая оптимизация порой приносит больше вреда, чем пользы. К примеру, попробуйте догадаться, куда именно будут вести следующие ссылки (я опустил доменные имена):

/office-phones/c80029/21101=2752/
/tainstvennye-sovpadeniya/park-gorkogo-perioda-studiya-artemiya-lebedeva-431255/431255-5122105/
/computer/noutbuki-netbuki/872-859-884-33338-1860-9873-33359-9855-28269-911-27788/

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

Суть проблемы наглядно Суть проблемы наглядно

Давайте попробуем составить правила корректной оптимизации ссылок. Будем это делать на примере абстрактного интернет-магазина.

Правила оптимизации ссылок

Правило 1. Ссылки должны выглядеть, как путь к файлу

Каждый пользователь интернета работал с файлами на компьютере, поэтому концепция файлов и папок — отличная отправная точка для формирования ссылок. Поэтому, первое правило — оптимизированные ссылки должны выглядеть, как ссылки на реальные файлы. Как будто CMS и не существует вовсе. Ссылка может вести только на файл. Если имя файла в ссылке не указано, предполагается index.html:

/about.html
/news/

Правило 2. Одна страница — одна ссылка

В случае использования описанной выше схемы, у нас существует три ссылки на раздел новостей: /news, /news/ и /news/index.html. Это плохо с точки зрения поисковой оптимизации.

Второе правило — на каждую страницу должна быть только одна ссылка, все остальные варианты записи должны перенаправлять пользователя на канонический путь. Если вы ввели в адресной строке ссылку на папку, то слеш в конце пути (если его нет) должен быть добавлен автоматически. Второе правило часто не соблюдает CMS Joomla. В этой CMS на одну страницу может существовать 5-6 разных ссылок.

Правило 3. Голые цифры в ссылках неуместны

Допустим, новостей в нашем интернет-магазине поднакопилось достаточно много. Так много, что понадобилась постраничная разбивка страницы со списком новостей. Страница index.html становится первой страницей списка. Но как назвать следующую страницу? Третье правило — избегайте цифр в адресах. Никто не любит голые цифры. Любая цифра должна иметь понятный пользователю контекст. Допустим, ссылка на вторую страницу новостей может быть /news/page-2.html, контекстом здесь выступает слово page и тот факт, что мы находимся на странице списка новостей. Не забудьте сделать перенаправление /news/page-1.html на страницу /news/index.html, согласно второму правилу.

Ссылка на полный текст новости может выглядеть так: /news/novinki-nashego-internet-magazina.html. Использование транслитерированного названия страницы в адресе этой страницы выполняет сразу несколько задач: во-первых, пользователь может быстро соориентироваться о содержании страницы, не переходя на нее. А во-вторых, при поиске по ключевым словам, поисковики учитывают не только содержимое, но и адрес страницы.

Правило 4. Числовые идентификаторы нужно заменять текстовыми

Часто встречаются ссылки вида /news/42-interesnaya-novost.html. В ней число 42 — уникальный числовой идентификатор новости, по которому осуществляется поиск в базе данных. Таких ссылок быть не должно. Для поиска новости в БД достаточно транслитерированного заголовка. Естественно, нужен механизм, гарантирующий уникальность этого параметра. Четвертое правило — все числовые идентификаторы нужно заменять текстовыми. Такие идентификаторы часто называют алиасами или слагами (второй термин в широкий обиход ввела CMS Wordpress).

Правило 5. Для передачи равноценных параметров нужно использовать GET-параметры

Переходим к каталогу товаров. В нашем интернет-магазине есть страница со списком категорий товаров, страница со списком товаров в категории, а также страница одного товара. Список категорий расположен на главной странице сайта, с его адресом вопросов не возникает. Допустим, у нас есть категория "футболки". Адрес страницы этой категории /futbolki/. На странице категории есть фильтр по цвету, размеру и бренду футболок. Все эти параметры равноценны, может быть указана любая комбинация значений этих параметров. Пятое правило — для передачи набора равноценных параметров должны использоваться GET-параметры. Фильтр не относится к иерархии файлов в нашей файловой системе, он позволяет выводить их в произвольном порядке по заданному набору параметров. Аналогичным образом обстоит дело и с поиском. Допустим, нас интересуют футболки черного цвета в размере M производства бренда CoolBrand:

/futbolki/?color=black&size=M&brand=CoolBrand

Неужели кому-то кажется, что такой вариант хуже, чем /futbolki/1124-1345-2451/?

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

/futbolki/coolbrand-classic.html

Правило 6. Адрес страницы всегда должен заканчиваться расширением

Давайте поговорим про расширение в URL. Строго говоря, в нем нет необходимости. Но расширение помогает пользователю идентифицировать ссылку, точно так же как сделать это помогает префикс www перед доменным именем, ведь технически он давно не нужен. Кроме того, в такую схему формирования URL отлично вписываются разнообразные API для сторонних сайтов:

/futbolki/coolbrand-classic.json
/goryachie-predlozheniya/index.rss

Шестое правило — адрес страницы всегда должен заканчиваться расширением, явным (coolbrand-classic.html в случае со страницей товара) или неявным (index.html на странице списка товаров категории).

Еще раз списком

  1. Оптимизированные ссылки должны выглядеть как ссылки на реальные файлы.
  2. На каждую страницу должна быть только одна ссылка, все остальные варианты записи должны перенаправлять пользователя на канонический путь.
  3. Избегайте цифр в адресах.
  4. Все числовые идентификаторы нужно заменять текстовыми.
  5. Для передачи набора равноценных параметров должны использоваться GET параметры.
  6. Адрес страницы всегда должен заканчиваться расширением, явным или неявным.

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