Для региональных поддоменов обычно указывают self-canonical: каждая локальная страница с самостоятельной ценностью ссылается в rel="canonical" на собственный URL. Например, страница spb.example.ru/services/ должна считать канонической именно spb.example.ru/services/, а не аналогичную страницу на основном домене.
Canonical на основной домен нужен только тогда, когда региональная версия не должна участвовать в поиске отдельно и фактически является дублем. В статье разберём, как выбрать схему канонизации, настроить теги по шаблонам, согласовать их с региональными сигналами и проверить внедрение, не исключив нужные поддомены из выдачи.
Как canonical работает в структуре региональных поддоменов
Атрибут rel="canonical" сообщает поисковой системе, какой URL владелец сайта считает основной версией страницы среди одинаковых или очень похожих адресов. Сигналы дублей могут объединяться вокруг канонического URL, а альтернативные адреса — реже показываться в результатах поиска.
Canonical — не директива с гарантированным исполнением. Поисковая система учитывает тег вместе с редиректами, внутренними ссылками, sitemap, доступностью страниц и другими техническими сигналами. Если выбранный адрес противоречит остальной структуре сайта, робот может определить другой канонический URL.
Для мультирегионального проекта последствия особенно важны. Если страницы московского, петербургского и казанского поддоменов канонизированы на основной домен, поисковая система получает сигнал, что локальные версии не требуется рассматривать как самостоятельные документы. Это противоречит задаче продвижения поддоменов в соответствующих регионах.
Наличие похожих описаний само по себе не означает, что все региональные URL следует объединить. Поисковая ценность локальной страницы определяется не только текстом, но и назначением: условиями работы в городе, адресами, контактами, ассортиментом, сроками, зонами обслуживания и другими сведениями, влияющими на выбор пользователя.
Как выбрать каноническую схему
Решение зависит от роли региональных страниц. Сначала нужно определить, должны ли пользователи находить каждый поддомен в поиске по локальным запросам.
| Сценарий | Рекомендуемая настройка | Что произойдёт |
|---|---|---|
| Поддомен предназначен для отдельного региона и должен получать поисковый трафик | Self-canonical на каждой индексируемой странице | Локальный URL сохраняет возможность участвовать в поиске самостоятельно |
| Региональный URL создан технически, но не имеет отдельной поисковой задачи | Canonical на основную версию либо редирект, если страница не нужна пользователю | Сигналы концентрируются на выбранном основном URL |
| На поддоменах есть локальные разделы, но часть материалов общая | Self-canonical для региональных страниц, единый canonical для точных копий общих материалов | Коммерческие страницы остаются локальными, служебные дубли объединяются |
| Один товар или услуга доступны по нескольким URL внутри поддомена | Canonical на основной URL этого же регионального поддомена | Параметрические и навигационные дубли не конкурируют с целевой страницей |
| Региональная версия закрывается | Постраничные редиректы на наиболее близкие актуальные страницы | Пользователи и роботы сразу переходят на действующие URL |
Типовая рабочая схема выглядит так: example.ru/catalog/ ссылается на себя, spb.example.ru/catalog/ — на себя, а kazan.example.ru/catalog/ — на себя. Правило должно распространяться на все индексируемые страницы поддоменов, а не только на главные.
Канонизация на основной домен оправдана, если региональные копии появились из-за архитектуры, сессионных параметров, переключателя города или ошибки маршрутизации и не должны ранжироваться. Если URL больше не нужен ни поисковому роботу, ни посетителю, постоянный редирект обычно даёт более однозначный сигнал, чем canonical.

Пошаговая настройка canonical на поддоменах
- Составьте карту типов страниц. Разделите URL на локальные коммерческие страницы, общие информационные материалы, карточки, листинги, страницы фильтров, служебные адреса и параметры. Одно правило для всех URL часто приводит к ошибкам.
- Определите индексируемые версии. Для каждого шаблона зафиксируйте основной протокол, поддомен, вариант со слешем или без него, регистр символов и допустимые параметры. Канонический адрес должен соответствовать фактической структуре сайта.
- Назначьте self-canonical целевым локальным страницам. В секции head страницы должен формироваться тег вида <link rel="canonical" href="https://spb.example.ru/services/">. В CMS лучше генерировать URL автоматически из утверждённого шаблона, а не заполнять вручную.
- Объедините технические дубли внутри каждого хоста. Адреса с метками аналитики, сортировками и необязательными параметрами могут ссылаться на чистую версию той же региональной страницы, если содержимое по существу не меняется.
- Отдельно обработайте общие материалы. Если одна статья полностью копируется на всех поддоменах и локальные версии не нужны в поиске, допустим canonical на исходную публикацию. Однако такое решение нельзя автоматически переносить на категории, услуги и другие посадочные страницы.
- Согласуйте остальные сигналы. Внутренние ссылки и XML-карты должны вести на канонические адреса. Неканонические URL не следует массово добавлять в sitemap или использовать в навигации.
- Проверьте шаблоны и исключения. Тестировать нужно главную, категории, карточки, пагинацию, фильтры, информационные страницы и URL с параметрами на каждом поддомене.
Предпочтительны абсолютные URL с протоколом и хостом. Такой формат снижает риск ошибки при переносе шаблона между поддоменами. Каноническая страница должна отвечать кодом 200, быть доступна для обхода и не содержать запрет на индексацию.
Цепочка canonical нежелательна. Если URL A ссылается на B, а B — на C, настройку лучше упростить и сразу указывать C. Не следует выбирать в качестве канонического адреса редирект, страницу ошибки или URL, который сам канонизирован на другой документ.
Как согласовать canonical с региональными сигналами
Canonical решает задачу выбора основной версии среди дублей, но не подтверждает принадлежность страницы конкретному городу. Региональность формируется совокупностью структуры сайта, содержания, контактов, внутренних ссылок и данных, доступных поисковым системам.
На локальной странице полезно размещать только достоверные сведения: фактический адрес подразделения, телефон, территорию обслуживания, доступные способы получения товара или услуги, сроки и условия работы. Простая замена названия города в одинаковом тексте не создаёт полноценной региональной версии.
Переключатель региона должен вести на соответствующие страницы поддоменов, а не всегда на их главные. Например, переход с услуги на московском хосте должен открывать аналогичную услугу на петербургском хосте, если такой URL существует. Это улучшает пользовательский маршрут и делает связь версий понятнее для роботов.
XML-карта каждого поддомена должна содержать индексируемые канонические URL этого поддомена. Внутренние ссылки также следует формировать без лишних параметров и промежуточных редиректов. Если проект использует несколько поисковых систем, нужно учитывать, что способы определения региона и интерпретация сигналов могут различаться.
Canonical не исправляет слабую мультирегиональную архитектуру. До технической настройки важно решить, какие города требуют отдельных посадочных страниц, чем версии отличаются и как пользователь переключается между ними. Подробнее об архитектуре, контенте и региональных факторах — в материале о продвижении сайта по регионам.
Ошибки, из-за которых локальные страницы выпадают из поиска
- Все поддомены ссылаются на основной домен. Такая настройка фактически сообщает, что региональные версии являются дублями. Она не подходит, если поддомены должны продвигаться отдельно.
- Canonical всегда ведёт на главную поддомена. Категории, услуги и карточки должны ссылаться на соответствующий основной URL, а не на страницу другого типа.
- Одинаковый canonical жёстко прописан в шаблоне. После копирования темы или запуска нового региона тег может продолжить вести на старый хост.
- Канонический URL закрыт от индексации. Сочетание canonical с noindex, блокировкой обхода или недоступной страницей создаёт конфликтующие сигналы.
- Внутренние ссылки ведут на неканонические адреса. Поисковый робот видит расхождение между тегом и фактической структурой навигации.
- В sitemap включены параметры и дубли. Карта сайта должна подтверждать выбранные основные URL, а не перечислять все технически доступные варианты.
- Canonical используют вместо редиректа при переезде. Если старый URL окончательно заменён новым, перенаправление обычно понятнее для пользователя и робота.
- Региональные страницы отличаются только названием города. Self-canonical сохраняет URL отдельным, но не делает малополезный шаблон качественной посадочной страницей.
Особенно опасны массовые ошибки генерации: неверный протокол, чужой поддомен, отсутствие слеша или попадание параметров в canonical. Один дефект шаблона способен затронуть тысячи адресов, поэтому проверять нужно не только исходный код отдельных страниц, но и выборку URL разных типов.

Чек-лист проверки после внедрения
- На каждой целевой региональной странице присутствует один тег rel="canonical".
- Self-canonical содержит точный URL текущей страницы с правильным протоколом, хостом и форматом пути.
- Канонический адрес отвечает кодом 200 и не перенаправляет пользователя.
- Страница не закрыта метатегом robots или заголовком X-Robots-Tag с директивой noindex.
- Основные разделы доступны для обхода и не заблокированы правилами robots.txt.
- Внутренние ссылки ведут на канонические URL без лишних параметров.
- В XML-картах перечислены только выбранные индексируемые версии.
- Региональные коммерческие страницы не канонизированы случайно на основной домен или другой город.
- Страницы с параметрами, фильтрами и сортировками обработаны по отдельным правилам.
- В панелях для вебмастеров выбранный поисковой системой canonical совпадает с указанным владельцем сайта либо расхождение исследовано.
Проверку стоит повторять после изменений в CMS, шаблонах, маршрутизации, HTTPS, структуре каталога и механике выбора города. Для крупных проектов полезен регулярный технический обход, который фиксирует canonical на другой хост, несколько тегов, циклы, цепочки и недоступные целевые URL.
Частые вопросы
Нужно ли ставить canonical с регионального поддомена на основной домен?
Нет, если поддомен должен ранжироваться в своём регионе. В таком случае локальной странице нужен self-canonical. Ссылка на основной домен уместна для дубля, который не должен участвовать в поиске отдельно.
Могут ли похожие региональные страницы ссылаться каждая на себя?
Да. Сходство структуры и части текста не требует обязательного объединения URL, если страницы решают разные локальные задачи и содержат полезные региональные сведения.
Что выбрать для ненужного регионального URL: canonical или редирект?
Если URL больше не должен открываться как самостоятельная страница, обычно применяют постоянный постраничный редирект. Canonical подходит, когда дубль остаётся доступным пользователю, но в поиске предпочтительна другая версия.
Нужно ли добавлять canonical на каждую страницу поддомена?
Для индексируемых страниц self-canonical является безопасной и понятной практикой. Исключения определяются отдельно для дублей, параметрических URL и материалов, у которых выбрана единая основная версия.
Поможет ли canonical, если на поддоменах одинаковый контент?
Canonical поможет объединить дубли, но тогда региональные копии могут не участвовать в поиске самостоятельно. Если требуется локальное продвижение, следует развивать полезность региональных страниц, а не маскировать проблему техническим тегом.
Если структура охватывает много городов и шаблонов, до массового внедрения стоит провести выборочный технический аудит. Специалисты Granat могут оценить архитектуру регионального проекта, логику канонизации и согласованность поисковых сигналов.


