Sitemap, robots.txt и canonical: как не запутать поискового робота

Три технических элемента часто сваливают в один список «для SEO», хотя они решают разные задачи.

• robots.txt подсказывает, какие URL робот может обходить.
• Sitemap перечисляет канонические страницы, которые владелец хочет показать поисковику.
• rel="canonical" помогает выбрать предпочтительную версию среди дублей или очень похожих URL.

Когда сигналы согласованы, всё выглядит скучно и предсказуемо. Когда они спорят друг с другом, начинаются странные статусы: адрес есть в sitemap, но закрыт от обхода; страница разрешена, но её canonical ведёт в другой раздел; внутренние ссылки указывают на URL, который затем перенаправляет.

Разберём каждый инструмент без ритуалов и лишних директив.

Что на самом деле делает robots.txt

Файл robots.txt находится в корне хоста, например:

https://example.ru/robots.txt

Он регулирует доступ роботов к URL этого конкретного протокола и хоста. Главная практическая задача — не тратить ресурсы обхода на бесконечные фильтры, служебные параметры, внутренний поиск или технические разделы.

Минимальный открытый вариант:

User-agent: *
Allow: /

Sitemap: https://example.ru/sitemap.xml

Правила нужно писать под реальную архитектуру, а не копировать из чужого сайта. Случайный Disallow: / закроет обход всего проекта. А слишком широкая маска может вместе с фильтрами закрыть полезные категории.

Чего robots.txt не делает

Google прямо указывает: файл не предназначен для удаления страницы из поиска. Если URL уже известен из внешних ссылок, в выдаче теоретически может остаться сам адрес без содержимого. Чтобы запретить индексирование документа, используют noindex или ограничивают доступ авторизацией.

Есть важная ловушка: если одновременно закрыть URL в robots и поставить на странице noindex, робот может не получить HTML и не увидеть запрет индексирования.

Что обычно закрывают

Решение зависит от сайта, но кандидаты выглядят так:

• результаты внутреннего поиска;
• корзина, оформление заказа и личный кабинет;
• технические параметры сортировки;
• служебные файлы и панели;
• бесконечные комбинации фильтров без самостоятельного спроса.

CSS и JavaScript, необходимые для отрисовки публичной страницы, закрывать обычно не следует: поисковику важно увидеть документ в состоянии, близком к пользовательскому.

Что сообщает sitemap

Sitemap — не приказ «проиндексировать всё». Это список URL и дополнительная информация, помогающая поисковику находить страницы.

В обычной XML-карте размещают:

• канонические адреса;
• страницы с кодом 200;
• документы, разрешённые к индексации;
• только те URL, которые действительно должны участвовать в поиске.

Редиректы, 404, noindex, тестовые адреса и параметрические дубли в карту не включают.

Пример:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.ru/uslugi/</loc>
    <lastmod>2026-07-20</lastmod>
  </url>
</urlset>

Как использовать lastmod

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

Sitemap не заменяет навигацию

Google обычно может обнаружить страницы через нормальные внутренние ссылки. Карта особенно полезна новому сайту, крупному проекту, сложной структуре или ресурсу с большим числом медиа. Но если важная страница находится только в XML и ниоткуда не связана с остальным сайтом, проблему архитектуры sitemap не исправит.

Что делает rel="canonical"

Canonical указывает предпочтительный URL для дубля или почти одинаковых страниц:

<link rel="canonical" href="https://example.ru/uslugi/seo/" />

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

Где canonical действительно полезен

• UTM и другие аналитические параметры;
• варианты сортировки, не меняющие основную сущность страницы;
• доступность одного материала по нескольким техническим URL;
• печатная и обычная версия;
• унификация адресов со слешем или без него, если сервер не делает редирект.

На канонической странице часто ставят ссылку на саму себя. Это уменьшает двусмысленность, когда к URL добавляют параметры.

Где canonical используют неправильно

Все услуги канонизированы на главную. Так владелец фактически просит считать отдельные документы версиями главной.

Canonical ведёт на 301 или 404. Предпочтительная версия должна быть рабочей конечной страницей.

В sitemap один URL, в canonical другой. Поисковик получает конфликт.

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

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

Сигналы должны смотреть в одну сторону

Для важной страницы проверьте цепочку:

1. сервер отдаёт 200;
2. URL разрешён к обходу;
3. meta robots допускает индексирование;
4. canonical указывает на этот же конечный адрес;
5. адрес находится в sitemap;
6. внутренние ссылки ведут сразу на него;
7. альтернативные версии перенаправляют или согласованно канонизированы;
8. содержимое соответствует назначению URL.

Самая частая ошибка — проверять каждый элемент отдельно. Валидный robots, валидный XML и существующий canonical ещё не означают, что вся система согласована.

Типовые схемы для разных ситуаций

Публичная каноническая страница

• 200 OK;
• доступна в robots;
• index, follow или отсутствие запрета;
• self-canonical;
• присутствует в sitemap;
• получает внутренние ссылки.

Старый URL после переезда

• постоянный редирект одним шагом на новый адрес;
• отсутствует в sitemap;
• внутренние ссылки заменены;
• новый URL отвечает 200 и канонизирован на себя.

Техническая страница, которую не нужно показывать

• доступна роботу, если требуется увидеть noindex;
• имеет noindex;
• отсутствует в sitemap;
• не получает массовых внутренних ссылок как важный раздел.

Удалённая страница без замены

• возвращает 404 или 410;
• удалена из sitemap и навигации;
• не перенаправляется на нерелевантную главную.

Как проверять после изменений

Не ограничивайтесь просмотром файла в редакторе.

• запросите заголовки через curl -I;
• откройте исходный HTML и найдите canonical и meta robots;
• проверьте конечный URL после всех редиректов;
• убедитесь, что sitemap отдаётся с кодом 200 и валиден;
• сравните URL из sitemap с каноническими адресами;
• проверьте нужный адрес инструментом поисковой системы;
• посмотрите, какой canonical выбрал сам поисковик.

Если сайт генерируется из шаблонов, прогоните проверку сразу по всему списку. Ручной просмотр пяти страниц не ловит ошибку, которая появилась только в одном шаблоне категории.

Минимум без магии

Для небольшого сайта не нужен многокилометровый robots с десятками директив. Нужна понятная архитектура:

• один основной домен;
• чистые конечные URL;
• аккуратная карта;
• осознанные запреты;
• согласованный canonical;
• нормальные внутренние ссылки.

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

Источники и документы

1. Google: robots.txt
2. Google: обзор файлов Sitemap
3. Google: создание и отправка Sitemap
4. Google: canonical URLs
5. Google: noindex
6. Яндекс: robots.txt
7. Яндекс: Sitemap
8. Яндекс: canonical