Что адрес решает, а что нет
У URL три работы, и только одна из них связана с поиском напрямую.
Первая — быть уникальным идентификатором документа. Именно по адресу поисковая система различает страницы, и именно здесь возникает большинство проблем: один и тот же документ, доступный по трём вариантам написания, превращается в три записи в базе.
Вторая — сообщать человеку, куда ведёт ссылка. Адрес виден в строке браузера, в мессенджере, в письме, в сниппете выдачи. Осмысленный путь снижает неопределённость до клика.
Третья, самая слабая, — передавать смысл поисковой системе. Слово в адресе учитывается, но его вес несопоставим с весом заголовка H1 и текста. Разница между /catalog/item-4471/ и /catalog/nozh-kuhonnyy/ для ранжирования куда меньше, чем принято думать.
Порядок приоритетов из этого выводится сам: сначала уникальность, потом читаемость, и только потом слова.
Из чего складывается адрес
Разбор по частям нужен, чтобы понимать, какая из них создаёт проблемы.
| Часть | Пример | Что с ней делать |
|---|---|---|
| Протокол | https:// | Один вариант на сайт, второй переадресуется |
| Хост | example.com | Выбрать с www или без и придерживаться |
| Путь | /catalog/knives/ | Отражает раздел, а не рекламную формулировку |
| Слаг | kitchen-knife | Короткий, латиницей, слова через дефис |
| Параметры | ?sort=price&utm_source=... | Не должны создавать новых документов |
| Якорь | #reviews | Для поиска не существует, отдельного адреса не образует |
Первые две строки — источник самых дорогих дублей, потому что они удваивают весь сайт целиком. Четыре комбинации протокола и хоста дают четыре копии каждой страницы, и при неверной настройке все четыре доступны одновременно.
Строка с параметрами отвечает за вторую по массовости проблему: метки рекламных кампаний и сортировки плодят адреса тысячами. Что с ними делать — в разборе дублирующегося контента.
Правила, которые действительно имеют значение
Их немного, и все они про стабильность, а не про красоту.
Один документ — один адрес. Все остальные варианты отвечают постоянной переадресацией. Это единственное правило, нарушение которого стоит дорого всегда.
Адрес не меняется без причины. Каждая смена — это переадресация, потеря части внешних ссылок и период, в течение которого система переиндексирует раздел. Адрес, привязанный к дате публикации или к текущему названию акции, ломается предсказуемо.
Путь повторяет навигацию, а не рекламную структуру. Если пользователь пришёл в раздел через два меню, адрес логично отражает эти два уровня. Расхождение между путём в адресе и путём по ссылкам сбивает и людей, и разбор структуры.
Слова разделяются дефисом, регистр только нижний. Подчёркивание и слитное написание читаются хуже, а заглавные буквы на части серверов создают отдельный документ.
Никаких идентификаторов сессии в пути. Каждый посетитель получает свой набор адресов, и робот тоже — раздел разрастается до бесконечности.
Вложенность в этот список не входит намеренно. Число сегментов адреса и расстояние до главной в кликах — разные величины, и на обход влияет второе. Механика разобрана в индексации и в перелинковке.
Как собирают слаг
Слаг — последний сегмент адреса, тот самый, который пишут вручную. Правила его сборки короткие и почти все выведены из требования стабильности.
Берут название страницы, отбрасывают служебные слова, оставляют два-четыре значимых. /blog/kak-nastroit-redirekt-na-servere-nginx-poshagovaya-instrukciya/ не лучше, чем /blog/nginx-redirect/, — вторая версия короче, читается в переписке и не ломается при смене заголовка.
Из слага исключают всё, что меняется: год, номер версии, слово «новый», название текущей акции. Дата в адресе особенно коварна — она превращает актуализацию материала в выбор между устаревшим адресом и переадресацией.
Транслитерацию делают по одному правилу на весь сайт. Смешение схем даёт schi в одном разделе и shchi в другом, и потом никто не может вспомнить, какой вариант где.
Числовой идентификатор в адресе не преступление. Для каталога с постоянно меняющимися названиями /catalog/4471-kitchen-knife/ устойчивее чистого текстового слага: смена названия товара не требует переезда. Компромисс осознанный — часть читаемости меняется на неизменность адреса.
Как проверить адреса на сайте
Три варианта написания одного адреса проверяются тремя запросами. Ответы читаются вместе, а не по отдельности.
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' 'https://example.com/catalog/page'
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' 'https://example.com/catalog/page/'
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' 'https://example.com/Catalog/Page/'
Что означают сочетания:
- Одна строка
200без адреса переадресации, две строки301с одним и тем же целевым адресом — правильная настройка. Есть один канонический вариант, остальные ведут к нему. - Все три строки
200— на сайте три копии каждой страницы. Число документов в индексе при этом раздувается втрое, а бюджет обхода тратится на одно и то же. 301, ведущий на адрес, который сам отвечает301— цепочка переадресаций. Работает, но теряет часть сигналов и замедляет обход; разбор — в материале про 301-редирект.302вместо301— временная переадресация там, где нужна постоянная. Система вправе оставить в индексе исходный адрес.
Флаг -o /dev/null выбрасывает тело ответа, -w печатает только код и адрес переадресации. Проверять достаточно нескольких типовых страниц из разных шаблонов — товар, категория, статья: настройки для них часто различаются. Массово то же самое собирается краулером.
В индексе страниц втрое больше, чем на сайте. Почти всегда варианты одного адреса: со слешем и без, с www и без, с параметрами сортировки. Проверьте коды ответа для всех вариантов и настройте переадресацию на один; то, что убрать нельзя, закройте каноническим адресом.
Ссылки из рассылок и рекламы ведут на адреса с метками, и они попали в поиск. Параметры отслеживания создали копии страниц. Метки убирать не нужно — нужен самоссылающийся canonical на каждой странице, тогда варианты с параметрами склеятся с базовым адресом.
После переезда на новую структуру трафик не вернулся к прежнему уровню. Часть переадресаций могла вести не на соответствующую страницу, а на главную или в раздел. Сверьте список старых адресов с целевыми попарно — потери концентрируются там, где соответствие потерялось.
Один и тот же товар открывается по двум путям из разных категорий. Структура допускает несколько маршрутов к одному документу. Выберите один основной путь, остальные закройте canonical, а навигацию оставьте как есть — людям она нужна.
Когда менять адреса, а когда не трогать
Смена адресов — операция с гарантированными потерями и негарантированной выгодой. Это делает её решением по остаточному принципу.
Менять оправданно, когда старая структура мешает работать: адреса содержат идентификаторы сессий, разделы физически не разделены, один документ доступен десятком путей, система адресации не позволяет добавить новый раздел без конфликта. Здесь смена решает конкретную задачу, а не улучшает вид.
Не менять — когда единственная причина в том, что адреса выглядят некрасиво или не содержат ключевых слов. Выигрыш в этом случае лежит в области самого слабого из трёх факторов, а потери реальны: часть внешних ссылок ведёт на старые адреса, и не каждая из них переживёт переадресацию.
Отдельная граница — размер сайта. На каталоге в десятки тысяч адресов ручная сверка соответствий невозможна, а автоматическая даёт ошибки в тех самых нетиповых случаях, которые приносят трафик. Перед такой операцией имеет смысл выгрузить страницы, дающие показы, из панели вебмастера и проверить соответствия хотя бы для них.
И ещё одно ограничение: структура адресов не лечит содержание. Аккуратные пути на страницах, которые никому не отвечают, остаются аккуратными путями. Соответствие структуры реальному спросу проверяется по семантическому ядру, а не по виду URL.
Спорное место
Читаемый адрес — та часть работы, которую видно сразу и которую легко защитить перед заказчиком. /catalog/kitchen-knives/ выглядит профессионально, /index.php?cat=17 — нет. Разница очевидна на слайде.
Но эффект от неё меньше, чем эффект от одной правильно настроенной переадресации между вариантами со слешем и без. Первое заметно человеку, второе — поисковой системе. Между «адреса красивые» и «адрес у каждой страницы ровно один» приоритет всегда у второго, хотя рассказать о нём труднее.
Признание, которое из этого следует, неприятное. В большинстве проектов, где переделывали структуру адресов ради читаемости, тот же ресурс, потраченный на устранение дублей и на содержание страниц, дал бы больше. Разница в том, что переделка структуры видна в отчёте, а отсутствие дублей — нет.
Частые вопросы
Нужен ли слеш в конце адреса?
Влияют ли ключевые слова в адресе на позиции?
Можно ли использовать кириллицу в адресах?
Насколько глубокой может быть вложенность?
Стоит ли менять адреса ради красоты?