Robots.txt и sitemap.xml помогают поисковому роботу работать с сайтом, но решают разные задачи. Robots.txt задаёт ограничения обхода. Sitemap перечисляет страницы, которые вы хотите предложить поисковику, обычно в их предпочтительных канонических версиях. Ни наличие этих файлов, ни добавление страницы в карту не гарантируют её появления в поиске.
Для владельца бизнеса важно проверить не сам факт «файлы настроены», а результат: нужные услуги и товары доступны роботу, служебные страницы обрабатываются по выбранным правилам, а карта не отправляет поисковик к дублям и удалённым адресам.
Обход и индексация — разные действия
Обход, или crawling, — робот запрашивает страницу и получает её содержимое. Индексация, или indexing, — поисковик обрабатывает полученные сведения и решает, включать ли страницу в свою поисковую базу. Найти адрес, посетить страницу и показывать её по запросу — три разных результата.
Отсюда главное ограничение robots.txt: запретить запрос страницы не означает удалить известный поисковику адрес. Google и Яндекс предупреждают, что URL, запрещённый для обхода, может участвовать в поиске. Например, поисковик может узнать адрес из ссылок, не прочитав саму страницу.
| Что требуется | Какой механизм нужен | Что он не решает |
|---|---|---|
| Ограничить посещение определённых путей роботом | Правила robots.txt | Не гарантируют исчезновения URL из поиска |
| Сообщить о предпочтительных страницах сайта | Sitemap | Не гарантирует обход, индексацию и позиции |
| Исключить доступную публичную страницу из индекса | Noindex в метатеге страницы или HTTP-заголовке | Не закрывает страницу от посетителей |
| Закрыть личные данные и внутренние документы | Авторизация и проверка прав доступа | Robots.txt и noindex не заменяют защиту данных |
Сначала определите нужный результат, затем выбирайте механизм. Формулировка «закрыть страницу» слишком неоднозначна для технического задания.
Для чего нужен robots.txt
Это обычный текстовый файл с правилами для роботов. Его размещают в корне сайта по пути /robots.txt. Правила относятся к тому протоколу, хосту и порту, на котором находится файл: основной сайт и поддомен требуют отдельной проверки.
В простом правиле User-agent указывает адресата, а Disallow — путь, обход которого запрещается. Allow позволяет задать исключение внутри запрещённого пути. Если путь не запрещён применимыми правилами, обход по умолчанию разрешён. Поэтому длинный файл с множеством запретов сам по себе не признак хорошей настройки.
У robots.txt есть практический смысл, когда сайт порождает множество малоценных для обхода адресов: технические варианты страниц, комбинации параметров или служебные разделы. Но перед запретом нужно понять, какие из этих страниц уже известны поиску и какие сведения робот должен прочитать на них.
Опасные ошибки:
- Запрет всего сайта после переноса с тестового окружения. Правило
Disallow: /запрещает обход всех путей для указанного робота. Оно может остаться на рабочем сайте после запуска. - Слишком широкий запрет. Ограничение раздела каталога может затронуть полезные посадочные страницы вместе со служебными вариантами.
- Блокировка нужных CSS и JavaScript. Если эти ресурсы важны для отображения и понимания страницы, робот получает неполную картину сайта.
- Ожидание защиты информации. Robots.txt доступен публично, а недобросовестный робот может игнорировать его правила. Личные кабинеты и документы защищают правами доступа.
Не копируйте чужой robots.txt целиком. Одинаковые названия разделов не означают одинаковое назначение страниц, а особенности отдельных поисковых роботов требуют проверки по их документации.
Почему noindex нельзя сочетать с запретом обхода без проверки
Noindex сообщает поисковику, что страницу не следует включать в индекс. Для HTML-страницы его задают в метатеге robots, для других типов ресурсов можно использовать HTTP-заголовок X-Robots-Tag: noindex.
Робот должен запросить страницу и прочитать эту инструкцию. Если тот же адрес запрещён в robots.txt, нельзя считать, что робот увидел noindex. Это особенно важно, когда служебная страница уже попала в поиск.
Для доступной публичной страницы, которую нужно исключить из поиска, оставляют возможность обхода и задают noindex. Для конфиденциальной страницы используют авторизацию. Если страница окончательно удалена, сервер должен возвращать корректный статус отсутствия, а не успешный ответ с текстом «ничего не найдено».
Что включать в sitemap.xml
Sitemap — машиночитаемая карта, а не меню для посетителя и не перечень всех адресов, которые когда-либо создавала CMS. В карту включают опубликованные страницы, которые должны участвовать в поиске: услуги, категории, товары, статьи и другие полезные страницы в их предпочтительных канонических версиях.
Канонический URL — выбранный основной адрес содержимого, доступного по нескольким адресам. Sitemap сообщает поисковику ваше предпочтение, но не заставляет его выбрать именно эту версию. Карта должна согласовываться с canonical, редиректами и внутренними ссылками. Подробный разбор этих механизмов — в статье о редиректах и canonical при изменении страниц.
Рабочее правило для обычной карты страниц: включать конечный доступный URL с успешным ответом сервера, без запрета обхода и noindex. Не включать туда:
- адреса, которые перенаправляют на другую страницу;
- удалённые страницы и страницы с ошибками сервера;
- закрытые кабинеты, корзины, результаты внутреннего поиска и другие служебные страницы, которые не предназначены для поисковой выдачи;
- дубли с параметрами, если основной версией выбрана страница без них;
- черновики и страницы, на которых установлен noindex.
Это согласование сигналов, а не утверждение, что поисковик технически не способен обработать любой другой URL. Когда sitemap предлагает страницу, а сама страница запрещает индексацию, карта не отменяет запрет.
Что проверить в самом файле
Адреса страниц внутри XML должны быть полными абсолютными URL с протоколом и основным доменом. Относительные пути для поля loc не подходят. Директива Sitemap в robots.txt тоже требует полного адреса файла: относительный путь к карте не следует считать корректной настройкой для Google. Другой способ сообщить о карте — добавить её в Google Search Console и Яндекс Вебмастер.
Поле lastmod, если оно используется, должно отражать реальное существенное изменение страницы. Не обновляйте его текущей датой при каждом построении карты, когда содержимое не менялось. Google использует это поле, когда его значения достоверны; поля priority и changefreq Google игнорирует. Они не дают владельцу сайта возможности назначить позиции или обязать робота приходить по расписанию.
Для большого каталога учитывают ограничения формата: один sitemap содержит не более 50 000 URL и занимает не более 50 МБ без сжатия. Если превышен любой предел, карту делят на несколько файлов; для их перечисления можно использовать индекс sitemap. Проверяют не только индекс, но и доступность вложенных карт.
Практичнее формировать карту из опубликованного содержимого CMS и обновлять её при изменении страниц. Ручной файл, который забывают исправить после удаления товара или смены адреса, постепенно перестаёт соответствовать сайту.
Учебный пример: каталог, поиск и личный кабинет
Предположим, у магазина есть категория светильников, сортировка этой категории, внутренний поиск и кабинет покупателя. Пути ниже сокращены для объяснения; это не готовые значения для XML-карты.
| Страница | Что требуется от поиска | Решение |
|---|---|---|
Категория /catalog/lights/ | Показывать полезную страницу категории | Разрешить обход и индексацию, включить основной адрес в sitemap |
Сортировка /catalog/lights/?sort=price | Не создавать отдельную поисковую страницу, если изменён только порядок товаров | Согласовать canonical с основной категорией; в sitemap оставить основной адрес |
Результаты /search/ | Дать посетителю искать товары, но не показывать служебные результаты в поисковиках | Задать noindex и сохранить доступ роботу для чтения инструкции; исключить из sitemap |
Кабинет /account/ | Ограничить доступ к данным покупателя | Требовать авторизацию; не включать личные страницы в sitemap |
Сортировка и полезная категория фильтра — не обязательно одно и то же. Если отдельная страница фильтра отвечает самостоятельному спросу и имеет нужное содержимое, её назначение определяют отдельно. Запрет «всех адресов с параметрами» может убрать из обхода и полезные страницы.
Как проверить настройку и принять работу
Попросите исполнителя показать проверку конкретных адресов: важной услуги или товара, страницы с параметром, служебной страницы и удалённого URL. Проверка только главной страницы не выявит ошибку правила внутри каталога.
- Проверить доступность файлов. Открыть robots.txt и sitemap без авторизации, проверить ответ сервера и содержимое. Вместо XML-карты не должна приходить HTML-страница ошибки. Вложенные карты тоже должны быть доступны роботу.
- Проверить правила на выбранных URL. В Яндекс Вебмастере использовать анализ robots.txt, в Search Console — отчёт о robots.txt и проверку конкретного URL. Зафиксировать, какой робот и какое правило проверялись.
- Сверить карту с состоянием страниц. Проверить конечный адрес, ответ сервера, canonical, noindex и разрешение обхода. В sitemap не должно быть старого домена, тестового окружения или служебных вариантов вместо основных страниц.
- Проверить обработку поисковиками. Посмотреть отчёты о sitemap и состояние важных URL. Успешное чтение карты означает, что файл принят к обработке; оно не доказывает индексацию всех перечисленных страниц.
- Повторить проверку после обработки изменений. Поисковик может использовать сохранённые сведения о файле и странице. Сразу после выпуска настройки и отражение результата в поисковых инструментах могут различаться.
В результате работы должны остаться понятные правила для типов страниц и подтверждение проверки: какие URL доступны, какие исключаются из индекса и почему. Если важная страница отсутствует в поиске при доступном обходе и корректной карте, причину ищут дальше — в состоянии страницы, дублях и качестве содержимого. Добавление её в sitemap ещё раз само по себе этого не исправляет.
Исправление противоречий между robots.txt, картой, canonical и ответами сервера относится к технической SEO-оптимизации сайта. После изменения каталога, запуска нового раздела или переезда URL эти правила стоит проверять снова в рамках технической поддержки сайтов. Для более широкой проверки используйте чек-лист технического аудита сайта.
