URL-адрес страницы — это первое, что фиксирует поисковый краулер, и один из заметных факторов восприятия страницы пользователем. Правильно построенный URL ускоряет индексацию, упрощает интерпретацию контента и положительно сказывается на CTR в выдаче. В материале — техническое устройство URL, правила построения slug, спор о кириллице и транслите, обработка параметров и шаги по корректной смене адресов на работающем сайте, что особенно важно при продвижении сайтов с устоявшейся структурой каталога.
Что такое URL и как он устроен
URL (Uniform Resource Locator, унифицированный указатель ресурса) обозначает полный адрес ресурса в сети. Стандартный URL состоит из протокола, хоста, пути и опциональных параметров: https://example.by/catalog/shoes/?color=black разбирается на части https:// (протокол), example.by (хост), /catalog/shoes/ (путь), ?color=black (строка запроса). У каждой части свои правила оформления и свои особенности обработки поисковыми системами.
Путь (path) — самая управляемая часть URL с точки зрения SEO. Именно в нём задаётся структура каталога, slug страницы (читаемая текстовая часть) и иерархия разделов. Продуманный путь сообщает и пользователю, и краулеру содержание страницы ещё до её загрузки: /catalog/zhenskaya-obuv/krossovki/nike-air-max/ читается без открытия документа.
Строка запроса (query string) после знака ? используется для передачи параметров: UTM-меток (Urchin Tracking Module, параметры отслеживания источников), фильтров каталога, сортировки, идентификаторов сессии. С точки зрения SEO это самая проблемная часть URL: каждое уникальное сочетание параметров формально считается отдельным URL, что создаёт риск дублей и неконтролируемого роста индекса. Правила обработки параметров — отдельная тема, разобранная ниже в соответствующем разделе.
ЧПУ — человекопонятный URL
ЧПУ (Человекопонятный URL, в терминах WordPress — permalink, постоянная ссылка) задаёт читаемый адрес страницы, который описывает её содержание словами на естественном языке. Противоположность ЧПУ — технические URL вида /index.php?id=1234&cat=56 или /page?p=a8f3d: они валидны для сервера, но непонятны человеку и не несут SEO-сигнала о содержании. Современные CMS (Content Management System, системы управления контентом) генерируют ЧПУ по умолчанию, но переход с технических URL на ЧПУ на старых проектах остаётся типовой задачей при SEO-аудите.
ЧПУ работает на трёх уровнях. Первый — улучшение CTR (Click-Through Rate, кликабельность) в выдаче: пользователь видит читаемый адрес в сниппете и доверяет ссылке больше, чем технической строке. Второй — слабый, но измеряемый сигнал ранжирования: ключевое слово в URL входит в оценку релевантности страницы запросу. Третий — упрощение работы с сайтом: разработчики, контент-менеджеры и SEO-специалисты быстрее ориентируются в структуре проекта по понятным адресам.
Ключ в URL даёт небольшой, но измеряемый прирост по релевантности. По разным оценкам — порядка нескольких процентов кликов в выдаче на длинном хвосте запросов; в коммерческих нишах эффект сильнее за счёт уточнения по локали и категории.
Двенадцать правил построения URL под SEO
Правила сформулированы по итогам аудитов и переезда сотен сайтов с проблемными URL-структурами. Часть правил жёсткие (нарушение явно вредит индексации), часть — рекомендательные (правильное оформление даёт небольшой плюс в восприятии). Применяются эти правила и при создании структуры нового сайта, и при оценке существующих адресов в техническом аудите.
При проектировании структуры URL стоит зафиксировать единый стандарт в проектной документации: длина, формат разделителя, регистр, обработка параметров. Это даёт стабильную картину для разработчиков и аналитиков на годы вперёд. Любое отклонение от стандарта обычно стоит дороже, чем его соблюдение с самого начала.
- Латиница в slug. Применяется транслит (transliteration) русских букв в латиницу по стандартным правилам: ё→yo, щ→shch, ц→c, ч→ch, ш→sh, й→y, мягкий и твёрдый знаки опускаются. Это снимает проблемы с копированием URL, отображением в браузерах и работой с внешними сервисами.
- Только нижний регистр. URL чувствителен к регистру:
/Catalog/Shoes/и/catalog/shoes/технически считаются разными адресами. Использование одного регистра (обычно нижнего) снимает риск дублей. - Дефис как разделитель. Слова в slug разделяются дефисом:
zhenskaya-obuv, неzhenskaya_obuvи неzhenskayaobuv. Google официально рекомендует дефис; подчёркивание интерпретируется как часть одного токена. - Длина в разумных пределах. Slug страницы умещается в 3–5 слов; полный URL — до 100–120 символов. Длинные URL технически валидны, но плохо читаются в выдаче, обрезаются в почтовых клиентах и хуже распространяются в соцсетях.
- Ключевое слово в slug. В slug страницы попадает основной ключ или его читаемая форма: для страницы «Купить кроссовки Nike Air Max» slug =
nike-air-maxилиkrossovki-nike-air-max. Переспам ключами в URL запрещён:kupit-krossovki-nike-air-max-deshevo-minsk— слишком длинный, недостоверный сигнал. - Иерархия отражает структуру. Адрес
/catalog/zhenskaya-obuv/krossovki/явно показывает уровень вложенности: каталог → раздел → подраздел. Глубина пути не должна превышать 4–5 уровней; для большинства проектов оптимально 2–3. - Слэш в конце — выбор и фиксация. Адреса
/pageи/page/технически различаются. Выбирается один формат (чаще с слэшем для разделов и без — для конкретных страниц) и выдерживается на всём сайте, второй вариант отдаёт 301-редирект. - Без даты публикации в URL. Адреса вида
/blog/2024/03/12/title/старят страницу: пользователь видит дату в URL и не идёт на «старый» материал, даже если контент актуален. Дата хранится в метаданных, не в адресе. - Без расширения файла. Современные URL не содержат
.html,.php,.aspx. Расширение указывает на конкретный движок и привязывает URL к технологии — при смене стека все адреса меняются. - Без идентификаторов из базы. URL
/product/12345/— это плохо: идентификатор не несёт смысла, плохо запоминается, не помогает с CTR. Лучше/product/nike-air-max-256/, где сохранён читаемый slug и числовой ID (если он нужен для уникальности). - Без стоп-слов в slug. Слова «и», «в», «на», «для» в slug обычно опускают:
kak-sdelat-saytx, неkak-sdelat-saytx-pravilno-dlya-biznesa-v-belarusi. Стоп-слова не добавляют SEO-веса и удлиняют адрес. - Транслитерация прилагательных «-ый». Прилагательные с окончанием «-ый» транслитерируются как
-yy:dlinnyy,minimal-nyy. Частая ошибка — писатьdlinniyилиdlinny: окончание теряет грамматический сигнал и хуже распознаётся в качестве слова.
Контрольный вопрос при проектировании URL — может ли человек, видя только адрес, понять, что на странице. Если ответ положительный, slug построен корректно. Если адрес выглядит как технический мусор или избыточный набор ключей — нужна правка структуры.
Кириллица или транслит в URL
Спор о выборе между кириллицей и транслитом в URL продолжается уже больше десяти лет. Современные браузеры корректно отображают кириллицу в адресной строке, поисковые системы Google и Яндекс одинаково индексируют оба варианта. Тем не менее в подавляющем большинстве случаев применяется транслит.
Технически кириллический URL вида example.by/каталог/обувь/ передаётся по сети в виде punycode-кодировки: example.by/%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/%D0%BE%D0%B1%D1%83%D0%B2%D1%8C/. В адресной строке браузера пользователь видит кириллицу; при копировании ссылки в Telegram, WhatsApp, Discord — может появиться громоздкая punycode-строка, которая отпугивает. По нашему опыту, кириллический URL даёт на 10–15% меньше переходов из мессенджеров по сравнению с латинским slug при прочих равных.
| Аспект | Латиница (транслит) | Кириллица |
|---|---|---|
| Индексация в Google и Яндексе | Полностью поддерживается | Полностью поддерживается |
| Отображение в браузере | Без преобразований | Без преобразований (для пользователя) |
| Передача в мессенджерах | Сохраняется кириллица | Часто превращается в punycode |
| Копирование в офисные документы | Без потерь | Может ломаться при ручном копировании |
| Длина итогового URL | Стандартная | На 30–50% длиннее из-за кодирования |
| Совместимость со старыми сервисами | Универсальная | Иногда ломается на устаревших платформах |
| Психологическое восприятие | Привычно для веба | Воспринимается локально и доверительно |
Рекомендация для большинства бизнес-сайтов — транслит. Кириллический URL имеет смысл только для информационных проектов и блогов с локальной аудиторией, где читатели приходят преимущественно из поиска и не пересылают ссылки в мессенджеры.
Параметры, UTM и фильтры в URL
Параметры в URL — самый частый источник проблем с индексацией. Каждое уникальное сочетание параметров создаёт формально отдельный URL, и без правильной настройки в индексе появляются тысячи дублей одной страницы с разными метками. Это перегружает краулинговый бюджет и размывает сигналы ранжирования.
Параметры делятся на четыре типа по их влиянию на контент страницы: трекинговые (UTM, gclid, fbclid) — не меняют контент; фильтрационные (color, size, price_from) — меняют выборку товаров; пагинационные (page, offset) — меняют видимый блок; сортировочные (sort, order) — меняют порядок. Для каждого типа применяется отдельная стратегия обработки.
Трекинговые параметры. UTM-метки, метки Google Ads (gclid), Facebook (fbclid) и аналогичные приходят с рекламных кампаний. Контент страницы при этом одинаковый; URL отличается только меткой. Стандартная обработка — rel="canonical" на чистый URL без меток: example.by/landing/. Это передаёт сигналы ранжирования на канонический адрес и не размывает их.
Фильтрационные параметры в каталоге. URL вида /catalog/shoes/?color=black&size=42 формально открывает уникальную выборку. Стратегия: только определённые комбинации параметров открыты к индексации (например, фильтр по цвету для частотных цветов), остальные закрываются через rel="canonical" на родительскую категорию. Альтернатива — генерация ЧПУ для приоритетных фильтров: /catalog/shoes/black/ вместо параметризованного URL.
Пагинация и сортировка. Пагинация (?page=2, ?page=3) с 2019 года рекомендуется индексировать как самостоятельные страницы — каждая каноникалит сама на себя. Сортировка (?sort=price) не создаёт нового контента, только меняет порядок — закрывается каноникалом на чистый URL.
# robots.txt: пример обработки параметров
User-agent: *
Disallow: /*?utm_
Disallow: /*?gclid=
Disallow: /*?fbclid=
Disallow: /*?sort=
Disallow: /*?order=
Allow: /*?page=
# В HTML страниц с трекинговыми метками
<link rel="canonical" href="https://example.by/landing/" />Изменение URL работающего сайта
Смена адресов на работающем сайте — операция с высокими рисками. По нашему опыту, около 30% случаев таких миграций сопровождаются временной просадкой органического трафика на 15–40% длительностью 2–6 недель, даже при корректной настройке 301-редиректов. Без 301 потеря может стать постоянной.
Базовый процесс смены URL включает шесть обязательных шагов: подготовка карты редиректов, тестирование на staging-окружении, ночной деплой в технологическое окно, настройка 301-редиректов на серверном уровне, обновление внутренних ссылок и sitemap.xml, мониторинг индексации и позиций в течение 2–3 месяцев после миграции.
- Карта редиректов. Готовится в виде таблицы «старый URL — новый URL» на постраничной основе. Для крупных каталогов карта строится автоматически по шаблону трансформации, для уникальных страниц — вручную. Обязательно проверяется покрытие: каждая обнаруженная в Search Console и Яндекс Вебмастере страница должна иметь свой целевой URL.
- Тестирование на staging. Карта применяется на тестовом окружении, проверяется через curl или httpstatus.io: каждая старая страница отдаёт 301 на правильный новый URL. Цепочки 301→301→200 устраняются объединением правил.
- Деплой в технологическое окно. Миграция проводится в низкий сезон или ночное время, чтобы минимизировать пользовательский ущерб. Параллельно с деплоем фиксируются метрики: позиции по ключевым запросам, объём органического трафика, индексация.
- 301-редиректы на серверном уровне. Конфигурация Apache/Nginx загружается до запуска нового кода. Код ответа должен быть именно 301 (302 не передаёт ссылочный вес). Проверка обязательна через curl сразу после деплоя.
- Обновление внутренних ссылок и sitemap.xml. Все ссылки внутри сайта приводятся к новым URL. Sitemap.xml пересобирается с новыми адресами и отправляется в Search Console и Яндекс Вебмастер. Параллельно подаётся запрос на ускоренный обход через инструменты вебмастера.
- Мониторинг 2–3 месяца. Отслеживается динамика позиций, индексация новых URL, обработка 301-редиректов краулерами. Первая неделя — частые проверки, далее — еженедельные. Полная стабилизация индекса занимает 6–12 недель.
Параллельно со сменой URL стоит запустить контекстную рекламу на ключевые страницы — это компенсирует временную просадку органического трафика и сохраняет конверсии на период стабилизации индекса. По нашему опыту, такая комбинация снижает финансовые риски миграции до приемлемого уровня.
Типичные ошибки при работе с URL
Ошибки в URL делятся на структурные (плохо спроектированная архитектура каталога), технические (некорректная обработка регистра, слэша, параметров) и процессные (смена URL без подготовки и редиректов). Структурные обычно требуют переезда; технические закрываются конфигурацией сервера; процессные — чек-листом миграции.
| Ошибка | Чем плоха | Как исправить |
|---|---|---|
| Подчёркивание вместо дефиса | Краулер воспринимает zhenskaya_obuv как один токен; ключи в slug не разделяются | Заменить на дефис; 301-редирект со старого формата на новый |
| Регистрозависимые URL | Один контент по нескольким URL; дубли в индексе | Серверная нормализация в нижний регистр; 301 со старых регистров |
| Несогласованный слэш в конце | Версии с и без слэша индексируются параллельно; ссылочный вес делится | Зафиксировать один формат; 301 с альтернативного |
| UTM-метки без canonical | Тысячи URL с одинаковым контентом; перегрузка краулингового бюджета | rel="canonical" на чистый URL; запрет в robots.txt |
| Пагинация с canonical на первую страницу | Страницы 2+ выпадают из индекса; контент с глубоких страниц теряется | Каждая страница пагинации каноникалит сама на себя |
| Идентификатор из базы в URL | Адрес не несёт смысла; плохо запоминается; не помогает CTR | Добавить slug с читаемым названием рядом с ID |
| Кириллица + транслит вперемешку | Часть страниц на кириллице, часть на латинице; нет единства | Выбрать один стандарт; переезд на единый формат через 301 |
| Глубина пути 6+ уровней | Краулер реже доходит до глубоких страниц; снижается приоритет | Упрощение структуры до 3–4 уровней; перенос в логичную родительскую категорию |
| Расширение .html / .php в адресе | Привязка к конкретной технологии; URL ломается при смене стека | Серверная нормализация: page.html отдаёт 301 на page/ |
Особенности SEO работы с URL для бизнеса в Беларуси
Региональная специфика проявляется в трёх плоскостях: выбор между кириллицей и транслитом для русскоязычного контента (актуальная задача в РБ с её доминированием русского как языка деловой коммуникации), специфика геопривязки страниц в Яндексе при наличии городов в URL, требования к индексации платёжных страниц с ЕРИП-интеграцией. По актуальным данным StatCounter, Google занимает 65–75% поиска в Беларуси, Яндекс — 25–30%; для обеих систем правила построения URL одинаковые, но привязка к региону работает по-разному.
Раскрутка сайтов в Беларуси с правильной URL-структурой даёт ощутимое преимущество в локальной выдаче. Особенно это касается коммерческих ниш с региональной привязкой: услуги, b2b-сегмент, ритейл с филиальной сетью по городам РБ.
Выбор языка slug для русскоязычной аудитории РБ. Для большинства бизнес-сайтов рекомендуется транслит латиницей: он универсален, не ломается в мессенджерах и привычен для технической команды. Кириллический slug имеет смысл для информационных порталов и медиа, где аудитория преимущественно белорусскоязычная или русскоязычная и где материал распространяется через поисковый трафик, а не через прямые ссылки в чатах.
Геопривязка через URL. Если у бизнеса есть филиалы в нескольких городах, типовая структура URL: example.by/minsk/uslugi/, example.by/gomel/uslugi/, example.by/brest/uslugi/. Города распределения по убыванию населения: Минск, Гомель, Могилёв, Витебск, Гродно, Брест. Каждый городской раздел получает свою геопривязку в Яндекс Вебмастере и собственную семантику в контенте — иначе адрес работает как декорация без реального эффекта.
Платёжные страницы с ЕРИП. Страницы оформления заказа с интеграцией ЕРИП (единое расчётное и информационное пространство — белорусская система платежей) и приёма карт БЕЛКАРТ обычно закрываются от индексации через robots.txt и noindex: они содержат только функциональную часть и не несут ценности для поиска. URL платёжных страниц при этом может быть техническим: /checkout/payment/ или аналогичным.
SEO-продвижение и контекстная реклама в Cropas
Команда Cropas проектирует URL-структуру белорусских сайтов с прицелом на долгосрочное продвижение: единый стандарт slug, корректная обработка параметров, проработанная иерархия каталога. SEO-продвижение в Беларуси с правильной URL-архитектурой ускоряет индексацию и снижает технические риски при росте проекта.
В случае смены адресов на работающем сайте проводится постраничная проработка карты редиректов, тестирование на staging-окружении, мониторинг позиций после миграции. Подробнее об услуге контекстной рекламы как компенсирующего канала на период стабилизации индекса — на странице направления.
Часто задаваемые вопросы
Влияет ли длина URL на ранжирование?
Длина URL — слабый сигнал ранжирования. Прямого штрафа за длинный URL нет, но косвенные эффекты заметны: длинные URL хуже умещаются в сниппет, обрезаются в почтовых клиентах, плохо распространяются в соцсетях. По нашему опыту, оптимальная длина — 60–100 символов; всё, что больше 120, заметно теряет в CTR. Конкретные слова в slug важнее, чем общее число символов.
Что лучше для slug — дефис или подчёркивание?
Однозначно дефис. Google официально рекомендует использовать дефис как разделитель слов в slug; подчёркивание интерпретируется как часть одного токена, и слова не различаются как отдельные сигналы ранжирования. Это давняя позиция, не менявшаяся с середины 2000-х. Для нового проекта только дефис; на существующих сайтах с подчёркиванием — переезд через 301 на дефис при ближайшей возможности.
Как организовать процесс смены URL, если параллельно идёт SEO-продвижение?
Из общего бюджета SEO-продвижения на месяц миграции выделяется отдельная статья на технические работы (обычно 30–40% месячного объёма): аудит, карта редиректов, тестирование, мониторинг. Параллельно контент-маркетинг и линкбилдинг приостанавливаются на 4–6 недель — нет смысла наращивать сигналы на адреса, которые меняются. Контекстная реклама, наоборот, активизируется: компенсирует возможную просадку органического трафика на период стабилизации индекса.
Что делать, если на сайте уже есть кириллические URL?
Если кириллица работает технически и не создаёт проблем — оставить. Переезд с кириллицы на транслит — серьёзная операция, требующая постраничного 301-редиректа со всех старых адресов на новые. Без явных проблем (плохая индексация, низкий CTR из мессенджеров, технические ошибки на старых сервисах) переезд не окупается. Если же планируется большой запуск или редизайн — можно совместить с переходом на латиницу.
Как объяснить руководству, что нужны редиректы при смене URL?
На презентации показывают три цифры: текущий объём органического трафика на старые адреса (через Search Console и Яндекс Вебмастер); прогноз потери трафика без редиректов (обычно 80–95% в первые недели); прогноз потери с корректными редиректами (10–30% временно, восстановление за 2–3 месяца). В деньгах это считается через средний чек и конверсию из поискового канала. Окупаемость работы по редиректам — обычно несколько недель.
Можно ли использовать кириллицу в slug, если домен в .by зоне?
Технически можно. Доменная зона .by латинская, но slug страницы и зона домена — две разные части URL. Кириллический slug в .by-домене работает точно так же, как в любой другой зоне. Решение принимается по общим аргументам — универсальность транслита против локального восприятия кириллицы, а не по принадлежности доменной зоны.
Как минимизировать риски при переезде на новую URL-структуру?
Базовый чек-лист: подготовить полную карту редиректов с покрытием всех индексируемых URL; провести миграцию в технологическое окно или низкий сезон; настроить 301-редиректы на серверном уровне до запуска нового кода; обновить sitemap.xml и подать в Search Console и Яндекс Вебмастер; обновить все внутренние ссылки на новые URL; запустить контекстную рекламу на ключевые посадки для компенсации временной просадки; вести мониторинг позиций и индексации 2–3 месяца. Окно стабилизации индекса — 6–12 недель; в течение этого периода раскрутка сайтов опирается преимущественно на платный трафик.
Что делать с URL, если у бизнеса несколько филиалов в Беларуси?
Стандартная схема — городской подкаталог: example.by/minsk/, example.by/gomel/, example.by/mogilev/. В каждом подкаталоге уникальный контент с привязкой к городу: телефоны, адреса, прайс, графики работы. Такая структура поддерживает продвижение сайтов с филиальной сетью без раздувания доменной структуры. В Яндекс Вебмастере каждый раздел получает геопривязку к соответствующему региону. Если у филиалов сильно разный ассортимент или прайс — альтернатива в виде поддоменов (minsk.example.by), но это требует независимого продвижения каждого хоста.



