Robots.txt и Sitemap.xml: грамотная настройка сайта

robots.txt и Sitemap.xml являются важными файлами технической SEO-инфраструктуры. Первый управляет доступом поисковых роботов к определённым URL, а второй сообщает поисковым системам, какие канонические страницы владелец сайта считает значимыми.

Эти файлы часто воспринимаются как инструменты прямого управления поисковой выдачей. В результате в robots.txt пытаются запрещать индексацию, а в Sitemap добавляют все существующие адреса, включая редиректы, ошибки и параметры фильтров.

На самом деле файлы решают более узкие задачи. robots.txt регулирует сканирование, но не является надёжным способом удаления HTML-страницы из поиска. Sitemap помогает обнаруживать URL и передаёт дополнительные сведения, но не гарантирует обход, индексацию или высокие позиции.

Чем отличаются сканирование и индексация

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

Сканирование

Поисковый робот запрашивает URL, получает ответ сервера, загружает HTML и необходимые ресурсы. Именно доступом робота к URL управляет robots.txt.

Индексация

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

Страница может быть:

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

Google и Яндекс предупреждают, что URL, закрытый в robots.txt, всё ещё может появляться в поиске, если робот узнает о нём из других источников. Чтобы поисковая система увидела noindex, страница должна оставаться доступной для сканирования.

Что такое robots.txt

robots.txt — обычный текстовый файл с правилами для поисковых и других автоматизированных роботов.

Он размещается в корне конкретного протокола и хоста:

https://example.ru/robots.txt

Файл по адресу:

https://example.ru/folder/robots.txt

не управляет обходом сайта.

У поддомена должен быть собственный файл:

https://shop.example.ru/robots.txt

Правила основного домена автоматически на поддомен не распространяются. Отчёт Search Console также рассматривает отдельные хосты и протоколы как самостоятельные источники правил.

Когда robots.txt действительно нужен

Небольшому сайту без технических разделов может быть достаточно файла, который разрешает обход и указывает Sitemap.

robots.txt особенно полезен, если необходимо:

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

Google описывает основное назначение файла как управление трафиком сканеров и предотвращение лишней нагрузки, а не как средство скрытия страниц из поиска.

Требования к robots.txt

Для корректной обработки файл должен:

• называться robots.txt;
• быть текстовым;
• находиться в корне хоста;
• быть доступным поисковым роботам;
• содержать понятные правила без HTML-разметки;
• не превышать ограничения поисковых систем;
• использовать корректные пути;
• соответствовать фактической структуре сайта.

Яндекс указывает ограничение размера файла в 500 КБ и рекомендует ответ сервера 200 OK.

Структура robots.txt

Правила объединяются в группы. Каждая группа начинается с директивы User-agent, после которой указываются ограничения и исключения.

User-agent: *
Disallow: /manager/
Disallow: /search/
Sitemap: https://example.ru/sitemap.xml

Значение * означает, что группа предназначена для всех роботов, которые поддерживают стандарт и для которых не создано более точное правило.

Директива User-agent

User-agent определяет робота, для которого действуют следующие правила.

Общее правило:

User-agent: *

Отдельная группа для Googlebot:

User-agent: Googlebot
Disallow: /technical/

Отдельная группа для Яндекса:

User-agent: Yandex
Disallow: /technical/

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

Директива Disallow

Disallow запрещает указанному роботу запрашивать URL, соответствующие пути.

Закрытие каталога:

Disallow: /manager/

Закрытие отдельного файла:

Disallow: /technical/report.php

Полный запрет обхода:

User-agent: *
Disallow: /

Последний вариант допустим для закрытой тестовой среды только как дополнительная мера. Для настоящей защиты staging-сайта следует использовать авторизацию, VPN или ограничение по сети. Файл robots.txt доступен публично и соблюдается только добросовестными роботами.

Пустой Disallow

Пустое значение означает отсутствие запрета:

User-agent: *
Disallow:

Для полностью открытого сайта можно также использовать:

User-agent: *
Allow: /
Sitemap: https://example.ru/sitemap.xml

При отсутствии robots.txt поисковые роботы обычно считают сайт открытым для обхода, но наличие файла упрощает указание Sitemap и контроль конфигурации.

Директива Allow

Allow разрешает обход конкретного пути внутри более широкого запрещённого раздела.

User-agent: *
Disallow: /assets/private/
Allow: /assets/private/public.css

Использовать Allow следует только при реальной необходимости. Чрезмерно сложная комбинация разрешений и запретов быстро превращает файл в головоломку, автор которой уже через месяц также вынужден решать её заново.

Символы * и $

Поисковые системы поддерживают шаблоны путей.

Звёздочка

Символ * обозначает произвольную последовательность символов.

Disallow: /*?sort=

Такое правило может закрыть URL, содержащие параметр сортировки.

Знак доллара

Символ $ обозначает конец URL.

Disallow: /*.pdf$

Правило закрывает URL, заканчивающиеся на .pdf.

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

Директива Sitemap

В robots.txt можно указать один или несколько файлов Sitemap:

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

Используются абсолютные URL с протоколом и доменом.

Яндекс рассматривает Sitemap как межсекционную директиву: она применяется независимо от расположения внутри файла. Тем не менее практичнее помещать все ссылки на карты в конце, чтобы файл было проще читать и обслуживать.

Директива Clean-param

Clean-param является директивой Яндекса. Она сообщает, что определённые параметры URL не изменяют основное содержимое страницы.

Пример:

User-agent: Yandex
Clean-param: utm_source&utm_medium&utm_campaign

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

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

Нужно ли использовать Crawl-delay

В старых шаблонах часто встречается:

Crawl-delay: 5

Для актуальной настройки эта директива обычно не нужна. Яндекс перестал учитывать Crawl-delay 22 февраля 2018 года и предлагает изменять скорость обхода через Яндекс Вебмастер.

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

Если робот создаёт нагрузку, сначала необходимо:

• проверить серверные логи;
• убедиться, что User-Agent не подделан;
• найти бесконечные URL;
• исправить фильтры и параметры;
• ускорить ответы сервера;
• ограничить действительно лишние разделы;
• использовать настройки скорости обхода в панели поисковой системы;
• при перегрузке корректно возвращать 429 или временный 503.

Нужно ли использовать Host

В старых шаблонах для Яндекса встречается:

Host: example.ru

В актуальной документации Яндекса среди поддерживаемых директив перечислены User-agent, Disallow, Allow, Sitemap и Clean-param. На Host как на способ выбора главного зеркала полагаться не следует. Основной домен задаётся постоянными редиректами, canonical, внутренними ссылками и настройками переезда в панели вебмастера.

Комментарии в robots.txt

Комментарии начинаются с символа #:

# Закрываем внутренний поиск
Disallow: /search/

Комментарии полезны для объяснения нестандартных правил, но не должны содержать:

• пароли;
• адреса скрытых панелей;
• названия резервных копий;
• внутренние IP;
• технические секреты;
• данные сотрудников.

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

Точный список зависит от CMS и архитектуры. Возможные кандидаты:

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

Закрывать путь следует не потому, что он «обычно закрывается», а после проверки его содержимого, ссылок, canonical, статуса индексации и роли в пользовательском сценарии.

Что не следует закрывать без проверки

CSS и JavaScript

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

Изображения

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

Страницы пагинации

Они помогают поисковому роботу находить материалы глубже первой страницы списка. Закрытие пагинации допустимо только после проектирования другого доступного пути к каждому документу.

Категории и рубрики

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

URL с noindex

Если URL необходимо удалить из поиска через noindex, робот должен иметь возможность загрузить страницу и увидеть директиву.

Sitemap.xml

Файл карты должен быть доступен поисковым роботам и возвращать 200 OK. Яндекс прямо указывает запрет Sitemap в robots.txt как одну из причин невозможности обработки карты. Отдельно закрывать Sitemap «от индексации» не требуется: XML-файл не является обычной поисковой страницей и может отображаться в отчёте как исключённый документ без ущерба для обработки.

Robots.txt не защищает конфиденциальные данные

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

Для защиты используются:

• авторизация;
• сетевые ограничения;
• VPN;
• права доступа;
• удаление файла из web-root;
• защищённое хранилище;
• временные подписанные URL.

Добавление строки:

Disallow: /backups/database.sql

не защищает базу, а любезно публикует путь к ней. Иногда служебный файл превращается в каталог подарков для злоумышленника с удивительной эффективностью.

Как выбрать инструмент для конкретной задачи

Базовый robots.txt для корпоративного сайта

User-agent: *
Disallow: /manager/
Disallow: /search/
Sitemap: https://example.ru/sitemap.xml

Это только отправная точка. Пути административной панели и поиска должны соответствовать реальному проекту.

Пример robots.txt для блога

User-agent: *
Disallow: /manager/
Disallow: /search/
Disallow: /*?sort=
Sitemap: https://example.ru/sitemap.xml

Не следует автоматически запрещать:

• рубрики;
• страницы авторов;
• теги;
• архивы;
• пагинацию.

Сначала нужно определить, имеют ли эти страницы самостоятельную ценность или создают дубли.

Пример robots.txt для интернет-магазина

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*?view=
Sitemap: https://example.ru/sitemap-index.xml

Фильтры нельзя закрывать одним универсальным шаблоном, пока не определены индексируемые посадочные комбинации. Часть фильтров может привлекать целевой спрос и должна оставаться доступной.

Что такое Sitemap.xml

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

Sitemap особенно полезен, если сайт:

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

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

Sitemap не заменяет внутренние ссылки

Страница, присутствующая только в Sitemap, остаётся слабо связанной с архитектурой сайта.

Карта не заменяет:

• основное меню;
• рубрики;
• категории;
• хлебные крошки;
• связанные материалы;
• контекстные ссылки;
• пагинацию.

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

Поддерживаемые форматы Sitemap

XML

Наиболее универсальный формат, позволяющий передавать URL, дату изменения и расширенные данные.

TXT

Простой текстовый файл, содержащий по одному абсолютному URL в каждой строке.

https://example.ru/
https://example.ru/services/
https://example.ru/services/audit.html

Индекс Sitemap

Файл, который содержит ссылки на отдельные карты:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <sitemap>
        <loc>https://example.ru/sitemap-pages.xml</loc>
        <lastmod>2026-08-01</lastmod>
    </sitemap>
    <sitemap>
        <loc>https://example.ru/sitemap-blog.xml</loc>
        <lastmod>2026-08-01</lastmod>
    </sitemap>
</sitemapindex>

Ограничения Sitemap

Один файл Sitemap может содержать не более 50 000 URL и иметь размер не более 50 МБ в несжатом виде. При превышении лимита карту разделяют и объединяют через файл индекса. Эти ограничения указывают и Google, и Яндекс.

Файл можно сжимать в формате .gz, но ограничения оцениваются для несжатого содержимого.

Базовая структура Sitemap.xml

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

Элемент loc

<loc> содержит полный канонический URL.

Правильно:

<loc>https://example.ru/services/audit.html</loc>

Неправильно:

<loc>/services/audit.html</loc>

Google рекомендует использовать абсолютные адреса и включать предпочтительные канонические версии страниц.

Элемент lastmod

<lastmod> сообщает дату последнего существенного изменения страницы.

Существенным изменением может быть:

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

Не следует менять lastmod из-за:

• текущей даты в футере;
• обновления счётчика просмотров;
• перегенерации Sitemap;
• случайного сохранения документа;
• изменения сессионного блока.

Google может учитывать lastmod, если значение регулярно оказывается точным и проверяемым. Если генератор ежедневно ставит всем URL текущую дату, поисковая система перестаёт получать полезный сигнал.

Элементы changefreq и priority

Протокол Sitemap допускает:

<changefreq>weekly</changefreq>
<priority>0.8</priority>

Google официально игнорирует оба значения. Поэтому установка всем коммерческим страницам приоритета 1.0 не заставит Google срочно поставить их в очередь и отложить остальные дела цивилизации.

Яндекс документирует поддержку этих элементов, однако значения должны отражать реальную относительную важность и частоту изменений. Для совместимой и компактной карты можно ограничиться loc и достоверным lastmod.

Какие URL включать в Sitemap

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

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

Google рекомендует включать URL, которые владелец хочет видеть в результатах поиска, и использовать предпочтительные канонические адреса.

Какие URL не следует включать

• страницы с noindex;
• URL, закрытые в robots.txt;
• редиректы;
• ошибки 404 и 410;
• страницы с кодом 5xx;
• дубли;
• неканонические варианты;
• UTM-метки;
• служебные параметры;
• корзину;
• личный кабинет;
• оформление заказа;
• результаты внутреннего поиска;
• тестовые страницы;
• пустые фильтры;
• технические файлы;
• страницы другого домена.

Нужно ли включать пагинацию в Sitemap

Универсального требования нет. Главная задача Sitemap — перечислить канонические страницы, предназначенные для поиска.

Если страницы пагинации:

• имеют самостоятельные URL;
• разрешены для индексации;
• имеют self-canonical;
• содержат отдельные наборы материалов;
• важны для обнаружения документов;

их можно включить.

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

Нужно ли включать фильтры

В Sitemap добавляются только заранее отобранные индексируемые фильтры, которые:

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

Технические фильтры и сортировки в карту не добавляются.

Sitemap для изображений

XML Sitemap может содержать сведения об изображениях, особенно если они:

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

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

Sitemap для языковых версий

В XML-карту можно добавлять связи между языковыми и региональными версиями страниц.

При этом необходимо обеспечить:

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

Как разделить Sitemap большого сайта

Удобно создавать карты по типам содержимого:

• sitemap-pages.xml;
• sitemap-services.xml;
• sitemap-blog.xml;
• sitemap-products.xml;
• sitemap-categories.xml;
• sitemap-images.xml.

Преимущества разделения:

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

Связь robots.txt и Sitemap.xml

Правильная схема выглядит так:

1. В robots.txt ограничиваются технические URL.
2. В Sitemap перечисляются канонические индексируемые страницы.
3. Адрес Sitemap указывается в robots.txt.
4. Карта также отправляется в панели поисковых систем.
5. Файлы не противоречат друг другу.

Если URL одновременно находится в Sitemap и закрыт в robots.txt, владелец посылает два противоположных сигнала: «эта страница важна» и «не загружайте её».

Типичные противоречия

Автоматическая генерация Sitemap

Для динамического сайта карту лучше генерировать автоматически на основе данных CMS.

Генератор должен:

• выбирать только опубликованные документы;
• проверять доступность для индексации;
• использовать канонический URL;
• исключать удалённые документы;
• исключать технические шаблоны;
• учитывать язык и домен;
• выводить достоверный lastmod;
• разделять большие карты;
• правильно экранировать XML;
• возвращать код 200;
• использовать UTF-8;
• обновляться после публикации и удаления страниц.

Почему статическая карта быстро устаревает

Ручной файл подходит только для небольшого стабильного сайта.

После изменений в нём могут оставаться:

• удалённые страницы;
• старые URL;
• редиректы;
• неактуальные даты;
• тестовые документы;
• страницы noindex;
• неверный домен.

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

Проверка robots.txt

Откройте файл в браузере

Проверьте:

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

Используйте отчёт Search Console

Отчёт о файлах robots.txt показывает найденные файлы, дату проверки, размер, предупреждения и ошибки обработки. В экстренной ситуации из отчёта можно запросить повторное сканирование файла.

Используйте Яндекс Вебмастер

В Яндекс Вебмастере можно проверить синтаксис и доступность URL с учётом правил файла.

Проверьте важные страницы вручную

Минимальный набор:

• главная;
• основные услуги;
• разделы;
• статьи;
• карточки товаров;
• изображения;
• CSS;
• JavaScript;
• страницы пагинации.

Проверка Sitemap.xml

Откройте файл

Он должен:

• открываться без авторизации;
• возвращать код 200;
• быть валидным XML или TXT;
• содержать текущий домен;
• не иметь битых символов;
• не превышать ограничения;
• не быть закрытым в robots.txt.

Отправьте карту в Search Console

Отчёт Sitemap показывает, удалось ли получить карту и обработать перечисленные URL.

Добавьте карту в Яндекс Вебмастер

Яндекс позволяет проверить Sitemap специальным анализатором и добавить её в раздел файлов карт сайта.

Сравните карту с обходом сайта

Краулер помогает найти:

• URL в Sitemap без внутренних ссылок;
• страницы сайта, отсутствующие в Sitemap;
• редиректы;
• ошибки;
• noindex;
• неканонические адреса;
• различия HTTP и HTTPS;
• дубли www;
• неверные даты.

Проверка кодов ответа

Что делать после изменения robots.txt

1. Проверить синтаксис.
2. Проверить несколько важных URL.
3. Опубликовать файл.
4. Убедиться в ответе сервера.
5. Проверить отчёт Search Console.
6. Проверить Яндекс Вебмастер.
7. Проанализировать серверные логи.
8. Проверить отчёты индексации после повторного обхода.

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

Что делать после изменения Sitemap

1. Перегенерировать карту.
2. Проверить XML.
3. Проверить количество URL.
4. Проверить даты lastmod.
5. Проверить отсутствие noindex и редиректов.
6. Отправить карту в панели поисковых систем.
7. Проверить результат обработки.
8. Сравнить карту с фактическим сайтом.

Типичные ошибки robots.txt

Случайный полный запрет

User-agent: *
Disallow: /

Часто попадает на рабочий сайт из тестовой среды.

Использование robots.txt для удаления страницы

Робот не сможет увидеть noindex, а URL может остаться в поиске без описания.

Закрытие CSS и JavaScript

Поисковая система не может корректно отобразить и оценить страницу.

Слишком широкие шаблоны

Запрет параметра случайно затрагивает полезные URL.

Копирование файла другой CMS

В конфигурации появляются несуществующие каталоги, а реальные служебные пути остаются открытыми.

Использование Crawl-delay

Директива сохраняется из старых инструкций, хотя Яндекс её больше не учитывает.

Публикация секретных путей

Файл используется как список резервных копий и административных каталогов.

Разные правила без причины

Google и Яндекс получают разные версии сайта, хотя технической необходимости нет.

Отсутствие контроля после релиза

Новый раздел случайно попадает под существующий шаблон запрета.

Типичные ошибки Sitemap.xml

Включение всех URL CMS

В карту попадают архивы, метки, поиск, авторы, вложения и технические страницы.

Редиректы

Карта должна указывать непосредственно на конечные канонические страницы.

Страницы noindex

Одновременно сообщается, что URL важен и не должен находиться в поиске.

Неверный домен

После переноса генератор продолжает использовать старый адрес.

Недостоверный lastmod

Дата всех страниц обновляется при каждом запуске cron.

Приоритет 1.0 для всех URL

Относительная шкала теряет смысл, а Google всё равно игнорирует значение.

Закрытие Sitemap в robots.txt

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

Отсутствие XML-экранирования

Параметр с символом & делает XML невалидным, если символ не преобразован в &.

Необновляемый статический файл

Новые страницы не добавляются, удалённые продолжают присутствовать.

Отсутствие контроля лимита

Генератор создаёт один огромный файл вместо индекса и отдельных карт.

Практический алгоритм настройки

Шаг 1. Соберите все типы URL

Разделите их на:

• индексируемые;
• доступные, но noindex;
• закрытые от обхода;
• перенаправляемые;
• удалённые;
• защищённые авторизацией.

Шаг 2. Определите канонические версии

Утвердите:

• HTTPS;
• www или без www;
• правило слэшей;
• регистр;
• формат параметров;
• языковые версии.

Шаг 3. Составьте robots.txt

Закройте только те URL, обход которых действительно не нужен.

Шаг 4. Создайте Sitemap

Добавьте канонические индексируемые страницы с кодом 200.

Шаг 5. Согласуйте файлы

Ни один URL карты не должен противоречить robots.txt, noindex или canonical.

Шаг 6. Проверьте шаблоны

Убедитесь, что новые страницы автоматически получают правильный статус.

Шаг 7. Отправьте карты

Добавьте Sitemap в Google Search Console и Яндекс Вебмастер.

Шаг 8. Проверьте логи

Посмотрите, какие URL реально запрашивают роботы.

Шаг 9. Настройте мониторинг

Контролируйте:

• доступность служебных файлов;
• изменение размера;
• ошибки XML;
• появление редиректов;
• URL noindex в Sitemap;
• случайный Disallow: /;
• изменение домена;
• рост количества страниц.

Чек-лист robots.txt

• Файл находится в корне хоста.
• Имя написано как robots.txt.
• Файл доступен без авторизации.
• Содержимое является обычным текстом.
• Нет случайного Disallow: /.
• Основные страницы разрешены.
• CSS и JavaScript не заблокированы без причины.
• Изображения не закрыты случайно.
• Пагинация проверена отдельно.
• Фильтры разделены на полезные и технические.
• Правила соответствуют текущей CMS.
• Crawl-delay не используется как универсальное решение.
• Старый Host не заменяет редиректы и canonical.
• Секретные пути не опубликованы.
• Указан абсолютный URL Sitemap.
• Все шаблоны путей протестированы.
• Файл проверен в Google Search Console.
• Файл проверен в Яндекс Вебмастере.
• После изменения изучены серверные логи.

Чек-лист Sitemap.xml

• Файл доступен поисковым роботам.
• Сервер возвращает код 200.
• Используется UTF-8.
• XML корректно сформирован.
• Применяются абсолютные URL.
• Указан текущий домен.
• Включены только индексируемые страницы.
• Все URL являются каноническими.
• В карте нет редиректов.
• В карте нет 404 и 5xx.
• В карте нет noindex.
• В карте нет закрытых URL.
• UTM-метки исключены.
• Служебные параметры исключены.
• lastmod отражает реальные изменения.
• Размер не превышает 50 МБ.
• Количество URL не превышает 50 000.
• Большие карты разделены индексом.
• Sitemap указан в robots.txt.
• Sitemap отправлен в панели поисковых систем.
• Карта сравнивается с результатами краулера.
• Генератор обновляется после публикации и удаления страниц.

Вывод

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

robots.txt не является надёжным инструментом удаления HTML-страницы из поиска. Для этого используются noindex, авторизация, коды ответа, перенаправления или удаление содержимого в зависимости от задачи.

В Sitemap следует включать только страницы с кодом 200, предназначенные для индексации и соответствующие каноническим URL. Редиректы, ошибки, служебные параметры, страницы noindex и закрытые разделы в карте не нужны.

Поля priority и changefreq не ускоряют Google, а значение lastmod полезно только при достоверном обновлении. Яндекс больше не учитывает Crawl-delay, поэтому старые шаблоны требуют пересмотра.

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