Структура URL: полное руководство по адресам страниц, которые нельзя менять после запуска

Короткий ответ: URL — это первичный ключ страницы в поиске. Позиции, накопленные ссылки, история в Search Console, цитирования в AI-ответах — всё привязано к конкретному адресу. Меняете адрес — начинаете отношения с Google заново, даже при идеально настроенных редиректах. Поэтому решения из этого материала нужно принять до релиза, а не после.

За последние годы через наши аудиты прошли сотни сайтов с падением трафика. И примерно в каждом пятом случае корень оказывался не в контенте и не в ссылках, а в том, что кто-то однажды решил навести порядок в адресах. Порядок навели. Трафик уехал.

Этот материал — полное руководство по адресам: от анатомии URL до карты редиректов при переезде. С разбором того, как решают эти задачи Rozetka, Comfy, Prom и Makeup — не по учебнику, а по их фактическим адресам и robots.txt. И с нашими собственными граблями, на которые мы наступили в августе на своём же сайте.

Из чего состоит URL: анатомия адреса

Прежде чем спорить о дефисах и транслите, стоит договориться о словах. Возьмём реальный адрес и разберём его на части:

https://rozetka.com.ua/ua/maska-dlya-litsa/c4657310/producer=face-boom/?sort=cheap#reviews

Дальше в статье я буду использовать эти названия. Особенно важно различать сегмент пути и параметр: одно и то же значение фильтра, записанное этими двумя способами, ведёт себя в поиске совершенно по-разному.

Что Google требует формально, а что просто рекомендует

Требований у Google немного, и они скучные. Всё остальное — практика, которая помогает людям и роботам, но формальным правилом не является. Разделять эти вещи полезно: в спорах с разработчиком вы будете точно знать, где стандарт, а где ваше предпочтение.

Что обязательно

Соответствие стандарту. Google Search поддерживает URL по стандарту IETF STD 66. Зарезервированные символы должны быть процент-кодированы. Если разработчик засунул в адрес пробел, кавычку или квадратную скобку в сыром виде — вы за пределами стандарта, и дальше поведение непредсказуемо.

Фрагменты не меняют контент. Адреса вида example.com/#/catalog — типичная болезнь одностраничных приложений на старых фреймворках. Google такие маршруты как отдельные страницы не видит. Решение — History API, то есть настоящие пути вместо решётки.

Регистр имеет значение. В документации сказано прямо: URL чувствительны к регистру, /APPLE и /apple — разные страницы. Рекомендацией это не является — так устроен веб.

Что рекомендуется

Здесь Google даёт пары «хорошо / плохо», и процитировать их лучше точно:

Про дефис и подчёркивание объяснение техническое: для поисковика color_profile — одно слово, color-profile — два. Разница влияет на то, как система разбирает адрес на токены.

Google отдельно перечисляет параметры, которые чаще всего плодят дубли: метки реферера (ref=foo%2Cbar), идентификаторы сессий (sessionid=6EE2BF1AF6A3D705D5561B7C3564D9C2), сортировки (search_sort=relevance). Рекомендация — закрывать такие адреса в robots.txt.

Как это решают крупные украинские магазины: разбор реальных адресов

Теория — теорией, но интереснее посмотреть, что делают сайты, которые в этой выдаче живут годами. Я выгрузил по 120 самых трафиковых адресов у четырёх крупных украинских проектов и посмотрел, какие решения там приняты. Плюс прочитал их robots.txt, потому что без него картина неполная.

Rozetka: фильтры вынесены в путь, всё с параметрами закрыто

Самое интересное решение из четырёх. Смотрите на реальные адреса из топа:

https://rozetka.com.ua/kalkulyatory/c2560887/
https://rozetka.com.ua/ua/hammer-tel000844/p458511719/
https://rozetka.com.ua/maska-dlya-litsa/c4657310/producer=face-boom/
https://auto.rozetka.com.ua/ua/mini-azs/c4630082/razreshennie-gidkosti=benzin/
https://rozetka.com.ua/ua/producer/jysk/

Что здесь заложено:

• Слово плюс идентификатор. Категория — это /kalkulyatory/c2560887/: человекочитаемый слаг и технический ID с префиксом c (category). Товар — /hammer-tel000844/p458511719/, где p означает product. Такая схема позволяет менять название категории, не ломая маршрутизацию: система находит страницу по ID, а слаг работает на людей и на сниппет.
• Фильтр — это сегмент пути, а не параметр. producer=face-boom/ стоит в пути и заканчивается слэшем. Формально это выглядит как параметр, но синтаксически — часть пути.
• Слэш в конце всегда. Из 120 адресов — 120 со слэшем. Ноль исключений, то есть правило прошито на уровне платформы.
• Параметров в топе нет вообще. Ни одного адреса с ? среди самых трафиковых.

Последние два пункта объясняются их robots.txt, и вот тут становится по-настоящему интересно. Там стоит правило Disallow: /*?* — то есть закрыто вообще всё, где есть знак вопроса. Плюс отдельно закрыты */search/, */comparison/, */cabinet/*, */section/*/*/, метки gclid, utm_medium=rooms, yclid, tab=.

А теперь ключевое: при этом стоит Allow: */section/*/producer=*/. То есть фильтр по производителю — единственный, который они целенаправленно открыли для обхода. Но открыт он только в одиночном виде — сразу под разрешающим правилом идут два запрещающих:

Allow:    */section/*/producer=*/
Disallow: */section/*/producer=*;*/
Disallow: */section/*/producer=*,*/

Точка с запятой и запятая — это разделители, которыми платформа склеивает несколько значений фильтра в одном сегменте. Значит, «бренд» открыт, а «бренд + цена», «бренд + цвет», «бренд + что угодно ещё» — закрыты. Оговорка про формулировки: robots.txt управляет обходом, а не индексацией; закрытый в нём адрес теоретически может попасть в индекс по внешним ссылкам, но без содержимого. На практике для комбинаций фильтров этого достаточно.

Складываем два наблюдения — и получаем осознанную стратегию, а не случайность. Всё, что попадает в параметры, у Rozetka по определению не индексируется. Всё, что должно индексироваться, живёт в пути. А из десятков возможных фильтров для индекса выбран один — по бренду, потому что «маска для лица Face Boom» люди действительно ищут, а «маска для лица от 200 до 300 гривен, сортировка по цене» — нет.

Есть у них и слабое место, которое видно в тех же выгрузках:

https://rozetka.com.ua/ua/1162060/c1162060/razmer-131496=copy_xxxs_59ee2f126acdc/
https://rozetka.com.ua/ua/2577232/c2577232/producer=beking/

Здесь слаг потерялся, остался голый ID, а значение фильтра выглядит как внутренний технический ключ: copy_xxxs_59ee2f126acdc. Так выглядит адрес, сгенерированный системой без человеческого участия — ровно то, от чего предостерегает документация Google. Даже у лидера рынка такие места есть, и это полезно знать: идеальных структур не бывает, бывают продуманные в главном.

Comfy: фильтры в пути через двойное подчёркивание

https://comfy.ua/ua/smartfon/brand__apple__seriya_smartphone__apple-iphone-17/
https://comfy.ua/smartfon/brand__apple__seriya_smartphone__apple-iphone-17-pro-max/
https://comfy.ua/ua/podstavka-antivibracionnaja-savitel-m-jaki-lapki-otzyvy.html

Comfy пошла тем же путём — фильтры в URL как сегмент, а не параметр, — но реализовала это через двойное подчёркивание как разделитель полей: brand__apple__seriya_smartphone__apple-iphone-17.

Формально это ровно то, чего Google советует избегать: подчёркивание вместо дефиса. Внутри значений при этом используется дефис (apple-iphone-17-pro-max), а между полями — двойное подчёркивание. Логика читается: подчёркивание как служебный разделитель уровней, дефис как разделитель слов.

Работает ли это? Судя по тому, что именно эти адреса собирают трафик — да, работает. Но повторять я бы не советовал: Comfy может позволить себе идти против рекомендации за счёт авторитета домена, у нового сайта такого запаса нет.

Второе, что бросается в глаза — .html в адресах товаров и суффикс -otzyvy для страниц отзывов. Расширение .html — наследие старых CMS. Само по себе оно не вредит, но добавляет символов и намекает на технологию, которая может смениться. Если сегодня начинаете новый проект — расширение в адресе не нужно.

Третья деталь — транслитерация. kak-udalit-pyatna-na-ehkrane-noutbuka: «экране» превратилось в ehkrane. Это машинная транслитерация по стандарту, где «э» передаётся как eh. Читается тяжело. Ниже отдельно разберу, почему выбор таблицы транслита — не формальность.

Prom: заглавные буквы в адресах

https://prom.ua/ua/Avtozapravochnye-stantsii.html
https://prom.ua/Rozetki.html
https://prom.ua/ua/p2012211303-podarochnyj-nabor-noskov.html
https://prom.ua/m-6437202537981145948-smartfon-hammer-energy.html

Здесь два наблюдения. Первое: структура плоская. Из 120 адресов 48 имеют глубину один сегмент, 66 — два. Для маркетплейса с миллионами товаров это осознанное решение: не выстраивать глубокую иерархию, а держать всё близко к корню.

Второе: заглавные буквы в адресах — Avtozapravochnye-stantsii, Rozetki, Gorillas-market. Учитывая, что URL регистрозависимы, это лишний риск: любая ссылка, где кто-то напишет адрес строчными, ведёт на несуществующую страницу или на дубль. Prom с этим живёт, но для нового проекта правило простое — только нижний регистр, а вариант в другом регистре редиректить на канонический.

Идентификаторы вида m-6437202537981145948 — девятнадцать цифр — это уже за гранью разумного. Такой адрес невозможно ни прочитать, ни продиктовать.

Makeup: адреса без слов

https://makeup.com.ua/ua/brand/2321515/
https://makeup.com.ua/ua/brand/232525/
https://makeup.com.ua/brand/29143/

Из 120 трафиковых адресов 90 содержат числовой идентификатор, и у страниц брендов адрес состоит буквально из слова brand и номера. Ни названия бренда, ни категории.

Это ровно тот антипример, который Google приводит в документации. Работает ли сайт? Работает, трафик есть. Но представьте: вы копируете такую ссылку в мессенджер, и человек на той стороне видит makeup.com.ua/ua/brand/232525/. Ни одного сигнала о том, что внутри. Кликабельность такой ссылки в письме, в сниппете, в чате заведомо ниже, чем у /ua/brand/estee-lauder/.

Сводная таблица решений

Общее у всех четырёх: языковая версия вынесена в сегмент пути, а не в поддомен и не в параметр. Для украинского рынка это де-факто стандарт, и спорить с ним на новом проекте смысла нет.

Транслит или кириллица: что выбрать украинскому сайту

Это первый спор, который случается почти на каждом проекте. Разработчику проще отдать кириллицу — CMS так умеет из коробки. Клиенту кириллица кажется понятнее. Формально Google работает и с тем, и с другим.

Но в документации Google рекомендует именно закодированный вариант вместо нелатиницы в открытом виде. Причина в том, что кириллический адрес живёт красиво ровно до первого копирования. В адресной строке браузера вы видите /маска-для-обличчя/. Стоит скопировать ссылку и вставить в письмо, в мессенджер, в рекламный кабинет, в отчёт — и там окажется /%D0%BC%D0%B0%D1%81%D0%BA%D0%B0-%D0%B4%D0%BB%D1%8F-%D0%BE%D0%B1%D0%BB%D0%B8%D1%87%D1%87%D1%8F/. Из тридцати символов получается сто с лишним.

Практическая разница выглядит так:

Для украинского проекта есть отдельный фактор, о котором вспоминают поздно. Если сайт многоязычный, кириллица заставляет держать разные наборы правил для украинской и русской версий, и любая ошибка в передаче «і», «ї», «є» рождает новый адрес. Мы на своём сайте держим латинские слаги на всех трёх языках: /razrabotka-sajtov/, /rozrobka-saytiv/, /website-development/. Каждый адрес на языке своей аудитории, и при этом любой из них можно продиктовать по телефону.

Какую таблицу транслитерации брать

Если выбрали транслит, следующий вопрос — по какой системе. Вариантов много, и они дают разный результат для одного и того же слова. В Украине есть официальный стандарт — постановление Кабмина №55 от 27 января 2010 года, по которому оформляются загранпаспорта и географические названия. Проблемные буквы там передаются так:

Практический вывод не в том, чтобы слепо взять этот стандарт для всех слаг. Он оптимизирован под паспорта, а не под чтение в поиске: Koriukivka человеку читать сложнее, чем koryukivka. Вывод в другом: таблица должна быть одна на весь сайт и должна быть зафиксирована в коде. Худшее, что может случиться — половина адресов сгенерирована одним транслитератором, половина другим, и в структуре одновременно живут /kharkiv/ и /harkov/.

И отдельно: не смешивайте украинскую и русскую транслитерацию в одной версии сайта. Ошибка вида ehkrane для «экране», которую видно у Comfy, рождается именно из машинной таблицы, применённой без разбора.

Длина URL: сколько символов и почему это снова стало важно

Раньше на длину смотрели как на вкусовщину. В 2026-м появились данные, из-за которых стоит смотреть внимательнее.

Semrush в январе 2026-го разобрал 5 миллионов URL, процитированных ChatGPT Search и Google AI Mode, — 378 тысяч цитирований в анализе — и посмотрел, что у этих страниц общего. По длине слага картина такая: больше всего цитирований (около 87 тысяч) собрали адреса со слагом в 21–25 символов, следом идут короткие, 6–10 символов. Рабочий диапазон — примерно 17–40 символов.

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

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

Для обычных страниц это неактуально. Но для магазина, где пользователь может накрутить восемь фильтров подряд, а система сложит их в один адрес, — вполне реальный сценарий отказа. Причём отвалится не самый терпимый компонент, а самый строгий: если у вас NGINX перед приложением, потолок будет 4 096 независимо от того, что умеет браузер.

Практический ориентир для страницы, которую вы продвигаете: слаг 20–40 символов, весь адрес в пределах 75–100. Не потому что дальше штраф, а потому что дальше он перестаёт помещаться в сниппет, в письмо и в голову.

Восемь адресов одной страницы: как рождаются дубли на ровном месте

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

Возьмите любую страницу своего сайта. Скорее всего, она доступна как минимум по восьми адресам:

Каждый вариант, который отдаёт код 200 без канонической ссылки на основной, — отдельная страница в глазах поисковика. Вес размазывается, в отчётах появляются дубли, а в AI-ответ попадает не тот адрес, который вы продвигали.

Проверяется это за пять минут из терминала:

curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" http://site.com/catalog
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://www.site.com/catalog
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://site.com/Catalog/

Все три должны показать 301 и один и тот же целевой адрес. Если хоть один отдаёт 200 — у вас дубль. Если показывает 302 — вы сообщаете поисковику, что переезд временный, и сигналы переносятся хуже.

Отдельная засада — цепочки. Когда http://www.site.com/Catalog редиректит на https://www.site.com/Catalog, тот на https://site.com/Catalog, а тот уже на https://site.com/catalog/ — это три прыжка вместо одного. Google прямо предупреждает, что длинные цепочки редиректов негативно влияют на краулинг: каждый прыжок — отдельный запрос. Правильно — один редирект сразу на финальный адрес.

Глубина вложенности: сколько уровней допустимо

Второй вопрос после «какие слова в адресе» — «сколько сегментов». Здесь есть два ограничения: техническое и поведенческое.

Техническое связано с краулингом. Google считает бюджет обхода критичным для сайтов от миллиона уникальных страниц при обновлении раз в неделю или примерно от 10 тысяч страниц при ежедневных изменениях. Если ваш сайт меньше — про бюджет можно не думать. Если больше — каждая лишняя ступень иерархии, каждый лишний дубль и каждая цепочка редиректов съедают обход, который мог бы достаться товарам.

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

При этом глубина пути в адресе и глубина кликов — разные вещи, которые часто путают. У Rozetka распределение адресов по глубине пути такое: 3 сегмента — 18 адресов из 120, 4 сегмента — 56, 5 сегментов — 38. То есть большинство трафиковых страниц лежат на четвёртом-пятом уровне пути. Но кликами они достижимы гораздо быстрее, потому что на них ведут ссылки с главной, из меню, из блоков перелинковки.

Вывод: длина пути в адресе — вопрос понятности, а не ранжирования. Не стоит выстраивать /catalog/electronics/computers/laptops/gaming/asus/rog-strix/ ради иерархии. Но и плющить всё в один уровень, как Prom, стоит только если у вас маркетплейс с миллионами позиций и своя логика навигации.

Фильтры и фасетная навигация: где магазины теряют больше всего

Фасетная навигация умеет создавать десятки тысяч адресов из ничего. Считается легко: 10 брендов × 6 размеров × 8 цветов × 4 сортировки × 20 страниц пагинации — это 38 400 адресов на одну категорию. Все они отдают код 200, все содержат почти одинаковый контент, и все конкурируют между собой.

В рекомендациях Google для e-commerce есть несколько конкретных правил:

• Формат /t-shirt?color=green вместо /t-shirt?green — значение всегда с именем параметра.
• Не дублировать один и тот же параметр в адресе.
• Не пускать в URL временные параметры: сессии, метки времени, фильтры вроде «рядом со мной».
• Варианты товара — либо сегментом пути /t-shirt/green, либо параметром /t-shirt?color=green; для необязательных параметров канонической считается версия без параметра.
• Пустые категории закрывать noindex или отдавать 404.
• Каждая страница пагинации должна иметь свой уникальный адрес. Google отдельно отмечает, что больше всего ошибок в структуре URL приходится именно на пагинацию.

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

«Вы создаете фильтр — в первую очередь у вас должны быть товары под этот фильтр. То есть под созданный фильтр должен быть создан уникальный контент».

И дальше он объясняет, откуда берётся уникальность у разных типов бизнеса:

«У интернет-магазина уникальным контентом являются карточки товаров — это их уникальный контент. Если же вы сайт услуг, то вашим уникальным контентом является чётко прописанная услуга под выбранные запросы».

Это рабочий критерий, который экономит месяцы. Прежде чем открывать комбинацию фильтров для индексации, ответьте на три вопроса: есть ли под неё товары, есть ли под неё спрос в семантике, будет ли выдача по ней отличаться от родительской категории. Если хотя бы один ответ «нет» — адрес создавать не нужно.

Три способа обращаться с фильтрами

Схема Rozetka — это первый и второй подход одновременно: всё с вопросительным знаком закрыто в robots.txt, а из фильтров в путь вынесен и открыт для индекса ровно один — по производителю. Такая жёсткость выглядит грубо, но именно она объясняет, почему в топе их адресов нет ни одного мусорного.

Пагинация: где чаще всего ломается структура

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

Что должно быть: у каждой страницы списка — свой уникальный адрес (/catalog/page/2/ или /catalog/?page=2), собственный rel="canonical" на саму себя, а не на первую страницу, и осмысленный title, отличающийся от первой страницы.

Что часто встречается вместо этого:

• Canonical со всех страниц на первую. Логика «первая страница главная» кажется разумной, но так вы сообщаете поисковику, что товары со второй и дальше страниц ему не нужны. На больших каталогах это прямой путь к тому, что половина ассортимента не попадает в индекс.
• Бесконечная прокрутка без адресов. Товары подгружаются скриптом, адрес не меняется, у страницы 40 никогда не будет своего URL. Решение — подгрузка с параллельным обновлением адреса через History API и работающие ссылки пагинации в разметке.
• Дублирующий текст категории на всех страницах. Описание категории на 2000 знаков, повторённое на всех 30 страницах пагинации, — это 30 почти одинаковых документов. Текст оставляют только на первой.
• Комбинация пагинации с фильтрами и сортировками. /catalog/?page=7&sort=price&color=red — самый плодовитый генератор мусора из всех.

UTM, gclid и другие метки: как аналитика плодит дубли

Отдельный класс адресов, о которых при проектировании структуры не думают вообще, потому что их создаёт не разработчик, а маркетолог.

Любая ссылка с меткой — ?utm_source=facebook&utm_medium=cpc&utm_campaign=autumn — технически новый адрес. Пока такие ссылки живут только в рекламе, беды нет. Проблема начинается, когда их кто-то опубликовал: партнёр поставил ссылку с меткой на своём сайте, блогер вставил в пост, менеджер отправил клиенту, а тот запостил в сообщество. Теперь у страницы появился внешний дубль, который поисковик обошёл и проиндексировал.

Как с этим живут крупные магазины — видно по их robots.txt. Rozetka закрывает /*gclid=*, /*utm_medium=rooms*, yclid, и вдобавок всё подряд через Disallow: /*?*. Comfy закрывает *utm_*, *?gclid=*, *?yclid=*, а также store_id и city_id — параметры выбора магазина и города, которые иначе умножили бы каталог на количество городов.

Минимальный набор для любого коммерческого сайта:

• rel="canonical" на чистый адрес со всех страниц с метками — это основной механизм.
• Закрытие меток в robots.txt — как страховка от лишнего расхода обхода.
• Проверка в Search Console: отчёт «Страницы» покажет, попали ли адреса с метками в индекс.

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

Страницы под города: самая дорогая ошибка в структуре

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

«Когда ко мне приходит клиент и говорит: я занимаюсь документацией, и у меня там для Барнаула одна страница, для Абакана другая, а по факту они ничем друг от друга не отличаются, кроме названия города — это дубли и мусор».

Механика тут такая. Проблема не в том, что в адресе есть город. Проблема в том, что за адресом нет ничего своего. У магазина уникальность обеспечивают карточки товаров — на разных фильтрах выводятся разные товары. У сайта услуг такого источника нет, его нужно создавать руками.

Николай про эту стратегию высказывается недвусмысленно:

«Я являюсь противником стратегии, когда на одну страницу услуг создаётся вот сколько городов, столько копий. Эта стратегия позволяет иногда обманывать индекс, иногда по низкой частоте получается пролезть, но Google уже это всё склеивает».

При этом в том же разборе он показывает клиента, у которого получилось: сервис по ремонту стиральных машин, где страницы разведены не по городам, а по маркам. У каждой марки свои коды ошибок, свои типичные поломки, свой блок вопросов и ответов. /remont-indesit/ и /remont-bosch/ действительно разные страницы, потому что у машин разные кнопки и разные неисправности:

«У разных стиральных машин чаще всего реально разные поломки, и для каждой страницы собраны разные вопросы и под них подобраны разные ответы. Даже коды ошибок».

Рабочий вариант, который мы видели в проектах: разводить страницы не по географии, а по товару или услуге, а региональность закрывать отдельным слоем. В магазине детских товаров в Молдове, например, рост дала не нарезка по городам, а новые подкатегории — коляски, кроватки, манежи, — каждая со своим ассортиментом и своим спросом.

Если региональные страницы всё-таки нужны — а для сервисного бизнеса они часто действительно нужны, — минимальный набор различий выглядит так: свой адрес и телефон, свои цены или сроки выезда, свои отзывы клиентов из этого города, своя карта, свой список выполненных работ. Если ничего из этого нет, страница не выживет, каким бы правильным ни был её адрес.

URL и AI-поиск: что изменилось в 2026

Раньше адрес был вопросом гигиены. Сейчас у него появилась вторая функция — быть цитируемым.

Когда ChatGPT, Perplexity или Google AI Mode формируют ответ, они показывают источники. Пользователь видит ваш адрес, и решение кликать или нет принимается за долю секунды по тому, что в этом адресе написано. Адрес вида makeup.com.ua/ua/brand/232525/ не сообщает ничего. Адрес /struktura-url/ сообщает всё.

Данные из уже упомянутого исследования Semrush по 5 миллионам процитированных URL дают ещё несколько ориентиров помимо длины слага. На процитированных страницах систематически встречается структурированная разметка: Organization — у 25% страниц, процитированных ChatGPT, и 34% в Google AI Mode; Article — 20% и 26%; Breadcrumb — 15% и 20%. Open Graph присутствует у 40–60% процитированных страниц.

Разметка Breadcrumb здесь важна именно в контексте адресов: она описывает поисковику ту же иерархию, что заложена в путь URL. Если путь говорит одно (/blog/razrabotka/struktura-url/), а хлебные крошки другое, вы сами создаёте себе разночтение. Согласованность пути, хлебных крошек и разметки — это одна работа, а не три.

Ещё раз честно: корреляция не равна причине. Никакая правка адреса не заставит модель вас процитировать. Но набор признаков «короткий осмысленный адрес + согласованные крошки + разметка» описывает страницу, которую делали осознанно, и такие страницы цитируют чаще.

Многоязычность в адресах

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

Google называет допустимыми два подхода — отдельный домен на страну (example.de) и подпапку (example.com/de/). Третий вариант, поддомен (de.example.com), формально работает, но означает, что авторитет вы строите почти с нуля для каждой версии.

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

Дальше начинается место, где ошибаются почти все. Слаги внутри языковых версий должны быть локализованы, а не скопированы. Если у вас украинская версия лежит по адресу /ua/razrabotka-sajtov/, то есть с русским слагом в украинской папке, вы получаете адрес, который не читается ни одной аудиторией. Правильно — /ua/rozrobka-saytiv/.

И каждая версия должна ссылаться на остальные через hreflang, включая саму себя, плюс x-default для версии по умолчанию. Без этого поисковик может показать украинцу английскую версию, а иностранцу — украинскую.

Насколько это масштабируется, видно по нашему проекту финансовой платформы: 44 языковые локали, 10 681 проверенный адрес в кэше карты сайта и 57 070 hreflang-альтернатов без единого некорректного значения. При таком количестве связок адреса перестают быть вопросом вкуса — любая нестабильность в правилах генерации слага множится на сорок четыре версии.

Кейс: что даёт перевод фильтров из параметров в путь

Чтобы предыдущие разделы не выглядели теорией — пример из нашей практики.

Ювелирный интернет-магазин. Исходное состояние: фильтры отдавали динамические адреса с параметрами, а мета-теги при применении фильтра не менялись вовсе — какой бы фильтр человек ни выбрал, title и description оставались от родительской категории. Плюс общий технический фон: больше 9 700 ошибок и 3 128 страниц без H1.

Что сделали с адресами: перевели фильтры из параметров в человекочитаемый вид и задали уникальные мета-теги для страниц фильтров. Это позволило вернуть трафик по запросам вида «золотые серьги 585 пробы» — тем самым комбинациям «металл + проба + тип изделия», которые люди действительно ищут.

Результат за год, с декабря 2024 по декабрь 2025: показы в поиске выросли со 169 526 до 960 936 — в 5,6 раза, клики по товарным сниппетам с 1 400 до 7 800, органический трафик с 45 000 до 51 900 визитов, ROAS с 2,8 до 5,1.

Обратите внимание на пропорцию: показы выросли в разы, трафик — на 16%. Так и выглядит открытие длинного хвоста через адреса: много запросов, у каждого небольшая частотность и высокая точность намерения.

Когда URL всё-таки надо менять: карта редиректов

Иногда переделывать адреса действительно нужно: переезд с конструктора, смена CMS, слияние двух сайтов, локализация слагов под языковые версии. Тогда работает один принцип — карта.

Джон Мюллер из Google на вопрос о ключах успешной миграции отвечает буквально: самое важное — отслеживать отдельные URL, чтобы иметь чёткую карту старых и новых адресов. Второе по важности — внутренняя перелинковка: забытые ссылки в меню и подвале, ведущие на старые адреса, замедляют переиндексацию сильнее, чем что-либо ещё. Там же он напоминает про rel canonical, про который при переезде забывают систематически.

И правило, которое нарушают чаще всего: редиректить страницу можно только на существенно похожий контент. Если подходящей страницы нет — честный 404 лучше, чем редирект на главную. Массовый редирект всего подряд на главную Google расценивает как soft 404: вы теряете и старую страницу, и время на выяснение, почему ничего не переносится.

Порядок работ при смене адресов

1. Собрать полный список старых адресов. Четыре источника, и все нужны: выгрузка из Search Console (что реально в индексе), sitemap.xml (что вы считаете своими страницами), логи сервера за 3–6 месяцев (что реально запрашивают, включая страницы, о которых вы забыли), краулер вроде Screaming Frog (что связано внутренними ссылками). Пересечение этих четырёх списков всегда шире, чем ожидаешь.
2. Построить таблицу «старый → новый». Три колонки: старый адрес, новый адрес, тип соответствия (точное / близкое / нет аналога).
3. Отдельно решить, что делать со страницами без аналога. Если у страницы был трафик и ссылки — стоит создать замену. Если нет — 410 или 404, но не редирект на главную.
4. Настроить 301 — сразу на финальный адрес. Без промежуточных прыжков, даже если так проще написать правило.
5. Обновить внутренние ссылки. В меню, подвале, текстах статей, в разметке хлебных крошек, в sitemap. Внутренние ссылки должны вести на новые адреса напрямую, а не через редирект.
6. Отправить новый sitemap и оставить старый доступным несколько недель — так Google быстрее увидит соответствия.
7. Проверить фактические ответы сервера по всей таблице. Не конфиг — именно ответы.
8. Наблюдать 4–8 недель за отчётами Search Console: ошибки 404, страницы с редиректами, покрытие.

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

Наш случай: как два слоя редиректов увели пять языковых адресов не туда

Пример из собственной практики, чтобы это не выглядело теорией. Мы прошли ровно такую миграцию на seoquick.com.ua и наступили на грабли, которые стоит описать подробно.

Что мы меняли и зачем

Достался нам этот сюжет по наследству: украинская и английская версии сайта много лет жили по русским слагам. Украинец, попавший на /ua/zakazat-zvonok/, видел в адресе русское слово; англоязычный на /en/raskrutka-v-youtube/ — тоже. Язык контента один, язык адреса другой — ровно та ошибка локализации, о которой шла речь выше.

В июне 2026-го мы это исправили: сгенерировали карту редиректов со старых русско-слаговых адресов на локализованные. Русская версия слаги не меняла, поэтому для неё редиректов нет. Блог, подкасты, вебинары и инструменты не трогали вовсе — там слаги не менялись, а значит, и рисковать было незачем.

Файл правил выглядит так (формат Cloudflare Pages: откуда, куда, код):

# ===== UA — услуги =====
/ua/kontekstnaya-reklama/            /ua/kontekstna-reklama/         301
/ua/poiskovoe-prodvizhenie/          /ua/poshukove-prosuvannya/      301
/ua/texnicheskij-audit/              /ua/tekhnichnyy-audyt/          301
/ua/website-audit/                   /ua/audyt-saytu/                301
/ua/schedule-event/                  /ua/zabronyuvaty-zustrich/      301

# ===== EN — услуги =====
/en/poiskovoe-prodvizhenie/          /en/seo-services/               301
/en/razrabotka-sajtov/               /en/website-development/        301

Обратите внимание на две вещи, которые мы заложили осознанно. Первая: английские слаги — это не транслит, а перевод. /en/razrabotka-sajtov/ стало /en/website-development/, а не /en/razrabotka-sajtov/. Второе: /en/kontekstnaya-reklama/ стало /en/performance-marketing/ — то есть на английском рынке услуга называется иначе, и адрес это отражает. Механический перевод слага дал бы /en/contextual-advertising/, чего никто не ищет.

Где сломалось

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

Причина оказалась в том, что на нашей инфраструктуре редиректы живут в двух местах одновременно. Есть файл правил, который вы видели выше, и есть обработчик запросов на уровне функций Cloudflare Pages, где прописаны точные соответствия. И обработчик срабатывает раньше файла: если точное правило нашлось там, до файла с масками запрос уже не доходит.

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

Что я забрал из этой истории

Первое и главное: карта редиректов должна включать не только пары «старый → новый», но и то, каким механизмом каждая пара обрабатывается. Если слоёв больше одного — а на любом современном хостинге с CDN, edge-функциями и правилами на уровне платформы их обычно больше одного, — то проверять надо не конфиг, а фактический ответ по каждому адресу.

Второе: проверка должна быть автоматической и регулярной, а не разовой после релиза. Простейший вариант — список адресов и цикл, который дёргает каждый и сравнивает с ожидаемым результатом:

while read -r from to; do
  real=$(curl -sI -o /dev/null -w "%{redirect_url}" "https://site.com$from")
  [ "$real" = "https://site.com$to" ] || echo "MISMATCH: $from -> $real (ожидали $to)"
done < redirects.tsv

Третье, менее очевидное: языковые редиректы опаснее обычных, потому что ломаются тихо. Битая ссылка даёт 404, и её видно в Search Console на следующий день. А редирект на страницу другого языка отдаёт честный код 200 — с точки зрения любого технического мониторинга всё в порядке. Заметить это можно только двумя способами: глазами или по поведенческим метрикам конкретных страниц.

Как проверить свой сайт: инструменты и команды

Аудит адресов не требует дорогих инструментов. Вот набор проверок, который закрывает 90% проблем.

Проверка канонизации хоста и слэша

for u in "http://site.com/catalog" "http://www.site.com/catalog" \
         "https://www.site.com/catalog" "https://site.com/catalog" \
         "https://site.com/Catalog/"; do
  printf "%-45s %s\n" "$u" "$(curl -sI -o /dev/null -w '%{http_code} -> %{redirect_url}' "$u")"
done

Ожидаемый результат: везде 301 и один и тот же финальный адрес.

Поиск цепочек редиректов

curl -sIL -w "%{url_effective} %{http_code} (прыжков: %{num_redirects})\n" \
  -o /dev/null https://site.com/staraya-stranica

Если прыжков больше одного — правило нужно переписать так, чтобы вело сразу на финальный адрес.

Что смотреть в Search Console

• Отчёт «Страницы» → «Не проиндексированы». Категории «Страница с переадресацией», «Копия: Google выбрал другую каноническую страницу», «Обнаружена, не проиндексирована» — все три указывают на проблемы с адресами.
• Инструмент проверки URL. Показывает, какой адрес Google считает каноническим — и это далеко не всегда тот, который вы указали.
• Отчёт по статистике сканирования. Если большая доля запросов приходится на редиректы и 404 — обход тратится не туда.

Краулер

Screaming Frog в бесплатной версии обходит до 500 адресов — этого хватает для сайта услуг. Что смотреть в первую очередь: коды ответов (вкладка Response Codes), цепочки (отчёт Redirect Chains), несовпадения canonical, дубли title как косвенный признак дублей страниц, адреса с параметрами.

Быстрая альтернатива без установки — наш онлайн-аудит страниц: он показывает коды ответов, редиректы, канонические ссылки и дубли по конкретным адресам.

Симптом → причина → как чинить

Чек-лист перед релизом

Всё, что выше, сводится к списку решений, которые принимают один раз — до того, как первая страница попала в индекс.

Канонизация:

• Выбран один вариант хоста (с www или без) — остальные отдают 301.
• Весь сайт на https, http редиректит одним прыжком.
• Выбран вариант со слэшем в конце или без — единообразно по всему сайту.
• Адреса в другом регистре редиректят на нижний.
• На каждой странице есть rel="canonical" на саму себя.

Слаги:

• Латиница, нижний регистр, слова через дефис.
• Одна таблица транслитерации, зафиксированная в коде.
• Длина слага в пределах 20–40 символов.
• Слаг на языке своей версии сайта, а не транслит с русского.
• Служебных идентификаторов в адресе нет — либо есть, но рядом со словом.

Каталог и фильтры:

• Фильтры отдают ?ключ=значение, а не ?значение.
• Сессии, метки времени и служебные фильтры в адрес не попадают.
• Для комбинаций без товаров и без спроса адреса не создаются.
• Открыты для индекса только фильтры, под которые есть спрос в семантике.
• Пустые категории отдают 404 или закрыты noindex.
• У каждой страницы пагинации свой адрес и свой canonical на себя.

Языки:

• Языковые версии в подпапках, слаги локализованы.
• hreflang проставлен во все стороны, включая саму страницу и x-default.
• Проверено, что языковая версия не редиректит на другой язык.

Если это переезд:

• Есть таблица «старый → новый», собранная из четырёх источников.
• Все редиректы — 301 и без промежуточных прыжков.
• Внутренние ссылки обновлены на новые адреса.
• Карта проверена по фактическим ответам сервера, а не по конфигу.
• Учтены все слои обработки редиректов, если их больше одного.

Если сайт уже запущен и вы не уверены, что с адресами всё в порядке, начните с онлайн-аудита или закажите технический аудит — мы как раз ищем такие вещи. А если новый сайт только планируется, эти решения дешевле принять на этапе разработки, пока ни одна страница ещё не проиндексирована.

Частые вопросы

Влияет ли ключевое слово в URL на позиции?

Слабо. Как самостоятельный фактор ранжирования это давно почти ничего не весит. Но ключ в адресе помогает пользователю понять, куда он попадёт, иногда подсвечивается в сниппете и лучше выглядит в списке источников AI-ответа. То есть работает на кликабельность, а не на позицию.

Что лучше — со слэшем в конце или без?

Google относится к обоим вариантам одинаково, важно только выбрать один и держаться его. Rozetka и Makeup ставят слэш всегда, Prom почти никогда — обе стратегии рабочие. Единственное, чего делать нельзя, — отдавать код 200 по обоим вариантам одновременно.

Нужно ли убирать даты из адресов блога?

Если статьи регулярно обновляются — да, дата в адресе работает против вас: материал 2023 года выглядит устаревшим даже после переписывания. Но менять адреса ради одного этого стоит только вместе с другой запланированной переработкой, а не отдельной операцией: риск переезда всегда выше выгоды от косметики.

Что будет с позициями, если поменять адрес одной страницы?

При корректном 301 страница обычно возвращается на прежние позиции, но не мгновенно: Google должен переобойти старый адрес, увидеть редирект и перенести сигналы. На небольшом сайте это дни, на крупном — недели. Проблемы начинаются, когда редирект настроен цепочкой через два-три промежуточных адреса, когда внутренние ссылки продолжают вести на старый URL или когда новая страница по содержанию заметно отличается от старой.

Можно ли использовать кириллицу в домене, а не только в пути?

Технически да, кириллические домены работают через punycode. Практически — те же проблемы, что и с кириллицей в пути, только серьёзнее: домен фигурирует в почте, в визитках, в договорах. Для бизнеса, который планирует расти за пределы одной языковой аудитории, латинский домен безопаснее.

Сколько уровней вложенности допустимо?

Жёсткого лимита нет. У Rozetka большинство трафиковых адресов лежат на четвёртом-пятом уровне пути, и это не мешает. Важнее не длина пути, а количество кликов от главной до страницы: ключевые коммерческие страницы должны быть достижимы примерно за три перехода. Если для этого нужна перелинковка в обход иерархии — значит, нужна перелинковка.

Что делать со старыми адресами, для которых нет нового аналога?

Если у страницы был трафик и внешние ссылки — лучше создать замену по смыслу и редиректить на неё. Если страница была служебной или временной — отдавайте 404 или 410. Редирект всего подряд на главную Google считает мягкой ошибкой, и это худший из вариантов: вы и страницу теряете, и сигнал о переезде не передаёте.