✓ 23 октября 2026 года Google обновил рекомендации по структуре URL. Изменение точечное, но практичное: документация теперь яснее объясняет, почему слова в адресе страницы лучше разделять дефисами, а не символами подчёркивания.
Google рекомендует по возможности использовать дефисы (-). Они явно обозначают границы слов и помогают пользователям и поисковым системам распознавать понятия в URL. Подчёркивания (_) исторически могут обозначать части одного составного термина — как в названиях функций в языках программирования. Поэтому они не рекомендуются как разделители слов.
Обновление не означает, что каждый существующий URL с подчёркиванием нужно срочно переименовать. Массовая смена адресов — это миграция: она требует редиректов, обновления внутренних ссылок, canonical и sitemap и может временно повлиять на обход и сигналы страниц. Сначала нужен аудит, затем расчёт пользы и риска.
Что именно обновил Google
В журнале изменений Search Central указано: 23 октября руководство по структуре URL обновили, чтобы уточнить правила разделения слов дефисами и подчёркиваниями. Причиной Google назвал синхронизацию документации с выпуском видеосерии The Non-Canonical Cabinet.
В актуальной рекомендации есть три важных тезиса:
- слова в URL желательно разделять;
- предпочтительный разделитель — дефис;
- подчёркивание и слитное написание не являются рекомендуемыми вариантами.
Пример рекомендуемой модели выглядит так: /summer-clothing/. Варианты /summer_clothing/ и /summerclothing/ менее ясно показывают границу между словами. Правило относится не только к сегментам пути: в официальном примере дефисы применены и в понятном имени параметра.
Google формулирует это как рекомендацию, а не как новое обязательное техническое требование. Страница с подчёркиванием не становится автоматически закрытой от сканирования или индексации. Но при проектировании новых адресов выбор теперь однозначен.
Почему дефис лучше подчёркивания
Хороший URL должен помогать понять страницу ещё до перехода. Дефис работает как визуальный пробел: technical-seo-audit легко читается как три слова. Подчёркивание часто воспринимается как часть имени одной сущности, а на мобильном устройстве может сливаться с линией ссылки.
Для поисковой системы это тоже вопрос интерпретации понятий. Google прямо пишет, что дефисы помогают пользователям и поисковым системам лучше определять концепты в адресе. Это не обещание роста позиций, а способ уменьшить неоднозначность.
Читаемость полезна и за пределами поиска. URL копируют в письма, мессенджеры, отчёты и рекламные кабинеты. Понятный адрес легче проверить вручную, сопоставить с разделом сайта и заметить ошибку в аналитике.
Это фактор ранжирования?
Из обновления нельзя делать вывод, что замена _ на - сама по себе повысит позиции. Google не объявлял новый алгоритм и не называл дефис самостоятельным сильным сигналом ранжирования. Речь идёт о лучшей практике структуры и интерпретации URL.
Практический эффект чаще косвенный:
- адрес понятнее пользователю;
- шаблоны URL становятся последовательными;
- снижается риск случайно создать разные варианты одного адреса;
- команде проще контролировать внутренние ссылки, canonical и sitemap;
- диагностика в логах и Search Console становится быстрее.
Поэтому оценивать работу нужно не вопросом «сколько позиций даст дефис», а вопросом «сделает ли изменение архитектуру понятнее без потери сигналов существующих страниц».
Нужно ли менять существующие URL
Для нового сайта, нового раздела или ещё не опубликованной страницы ответ простой: используйте строчные слова, разделённые дефисами. Для давно индексируемых страниц решение сложнее.
Не стоит запускать массовое переименование только ради косметики, если URL:
- стабильно индексируется и получает органический трафик;
- имеет внешние ссылки;
- корректно указан в canonical и sitemap;
- не создаёт дублей и не мешает управлению сайтом;
- используется в рекламе, аналитике, интеграциях или печатных материалах.
Смена такого адреса создаёт больше движущихся частей, чем сама рекомендация. Старый и новый URL некоторое время должны быть правильно связаны, Google должен обработать перенаправление, а все зависимые системы — обновиться.
Переименование оправдано, когда оно входит в более широкую миграцию, исправляет системную ошибку шаблона, устраняет дубли или упрощает действительно проблемную архитектуру. Это вывод для практики, а не требование Google менять уже работающие адреса.
Как безопасно провести миграцию URL
Если изменение всё же нужно, подготовьте точную карту соответствий «старый URL → новый URL». Один старый адрес должен вести на наиболее близкую новую страницу, а не на главную или общий раздел.
Минимальный план миграции:
- Зафиксировать список индексируемых URL, трафик, внешние ссылки и текущие canonical.
- Создать новые адреса с тем же содержанием и тем же поисковым намерением.
- Настроить постоянные серверные перенаправления со старых URL на новые.
- Заменить внутренние ссылки, чтобы они сразу вели на конечный адрес без цепочки редиректов.
- Установить self-canonical на каждой новой странице.
- Удалить старые URL из XML-sitemap и добавить новые.
- Обновить hreflang, структурированные данные, рекламные ссылки и события аналитики, если в них записаны абсолютные адреса.
- Проверить коды ответа, отсутствие циклов, цепочек и soft 404.
- Отправить актуальный sitemap в Search Console и наблюдать за индексированием.
Старые редиректы нельзя снимать сразу после того, как новый URL появился в индексе. Они нужны пользователям, поисковым роботам и внешним ссылкам, которые ещё обращаются к прежнему адресу.
Параметры, регистр и фильтры
Обновлённая страница напоминает и о других принципах. Google советует убирать ненужные параметры — те, которые не меняют содержание страницы. Избыточные комбинации фильтров могут создавать огромное число похожих URL, расходовать ресурсы обхода и усложнять консолидацию сигналов.
URL чувствительны к регистру. Для поисковой системы /Audit/ и /audit/ могут быть разными адресами. Если сервер показывает один контент по обоим вариантам, лучше привести пути к единому регистру и перенаправлять альтернативы.
Особого внимания требуют каталоги с сортировкой, пагинацией и составными фильтрами. Для каждой комбинации нужно определить роль: индексируемая посадочная страница, служебный вариант с canonical или URL, который не должен генерировать бесконечное пространство обхода. Универсального правила «закрыть все параметры» нет — решение зависит от ценности страницы и навигации сайта.
Для JavaScript-приложений Google рекомендует не использовать фрагменты после # для изменения индексируемого содержания. Фрагмент не является надёжной заменой отдельному crawlable URL. Страницы, которые должны появляться в поиске, должны иметь обычные адреса и доступные поисковому роботу ссылки.
Кириллица, транслитерация и языки
Google рекомендует использовать в URL слова на языке аудитории; допустимы и слова, переданные транслитерацией. Документация приводит примеры локализованных адресов, но отдельно напоминает о корректном percent-encoding символов вне безопасного ASCII-набора в атрибутах ссылок.
Для русскоязычного или казахоязычного сайта это оставляет архитектурный выбор: читаемая кириллица либо последовательная транслитерация. Важнее не смешивать подходы хаотично и не менять уже индексируемые адреса без необходимости. Внутри выбранного стандарта слова всё равно следует разделять дефисами.
Мультирегиональным сайтам Google советует использовать структуру, которая помогает геотаргетингу: например, отдельный домен страны или подкаталог языка/региона. Но один только сегмент /kz/ не доказывает локальную релевантность. Локальная версия должна содержать соответствующие язык, предложение, контакты и контент, а hreflang должен связывать реальные альтернативы.
Чек-лист аудита URL
Проверку удобно разделить на проектирование, индексирование и миграционные риски.
Проектирование
- слова разделены дефисами;
- пути короткие, понятные и написаны в одном регистре;
- структура отражает иерархию без лишней вложенности;
- параметры имеют понятное назначение и не размножаются без контроля;
- адреса не зависят от сессий, внутренних идентификаторов пользователя и фрагментов
#.
Индексирование
- индексируемая страница отвечает HTTP 200;
- canonical указывает на выбранный основной URL;
- внутренние ссылки ведут на canonical без редиректа;
- в sitemap присутствуют только канонические индексируемые URL;
- варианты регистра, слеша и параметров не создают самостоятельные дубли;
- robots.txt не блокирует ресурсы и страницы, которые Google должен обработать.
Перед изменением
- выгружены страницы с кликами и показами из Search Console;
- учтены внешние ссылки и рекламные кампании;
- подготовлена карта перенаправлений один к одному;
- проверены hreflang и структурированные данные;
- определены контрольные метрики и период мониторинга.
После запуска сравнивайте не только число проиндексированных новых URL. Следите за ошибками обхода, выбранными Google canonical, кликами по группам страниц и попаданием старых адресов в отчёты. URL Inspection помогает проверять отдельные критические страницы, а отчёты Search Console — видеть системную динамику.
Главный вывод обновления Google прост: для новых адресов используйте дефисы. Но для существующего сайта правильная реакция — не глобальный поиск и замена, а технический аудит и управляемая миграция только там, где она действительно улучшает архитектуру.
Если нужно проверить шаблоны URL, дубли, canonical, параметры и план переноса без потери органического трафика, закажите техническую SEO-оптимизацию сайта.
Источники
- Latest Google Search documentation updates — Google Search Central, обновление от 23 октября 2026 года.
- URL Structure Best Practices for Google Search — рекомендации по дефисам, параметрам, регистру и локализованным URL.
- How to specify a canonical URL with rel=canonical and other methods — методы консолидации дублей.
- Understand the JavaScript SEO basics — crawlable links и ограничения URL fragments.
- Get started with Search Console — мониторинг и диагностика в Search Console.
Оставьте отзыв