Robots.txt и sitemap.xml: как настроить и проверить сайт

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

Robots.txt — это инструкция для обхода, а не замок

Файл robots.txt лежит в корне домена: например, https://example.ru/robots.txt. В нём владелец сайта задаёт правила для роботов: какие каталоги можно обходить, какие URL лучше не тратить на сканирование, где находится Sitemap. Яндекс указывает, что файл должен быть доступен по HTTP-коду 200, называться именно robots.txt, находиться в корне и иметь размер не больше 500 КБ. Это базовые условия, а не декоративные рекомендации.

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

Если страницу нельзя показывать в поиске, я сначала выбираю другой механизм: авторизацию, удаление файла, HTTP-заголовок или noindex там, где робот должен зайти и прочитать директиву. Запрет в robots.txt не должен блокировать доступ к странице, для которой поисковику нужно увидеть noindex.

Что происходит с URL, закрытым в robots.txt

На практике URL может остаться известным поисковой системе по ссылкам, Sitemap или истории обхода. Сам контент робот не прочитает, но адрес иногда всё равно появится в результатах. Это неприятный сценарий для фильтров каталога, технических страниц и дублей: владелец думает, что «спрятал» URL, а в выдаче остаётся пустая карточка без описания.

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

Как настроить robots.txt без опасных запретов?

Начинайте с карты типов страниц

Перед редактированием я делю сайт на четыре группы. Первая — страницы, которые должны индексироваться: главная, услуги, статьи, рубрики, кейсы и полезные посадочные. Вторая — служебные URL: поиск по сайту, личный кабинет, корзина, формы и технические обработчики. Третья — дубли с параметрами и сортировками. Четвёртая — страницы, которые нужно исключить из поиска по отдельной причине, например тестовый раздел.

У каждой группы свой способ обращения. Важные страницы открыты и включены в Sitemap. Служебные маршруты можно закрыть от обхода. Дубли лучше лечить canonical, редиректом или настройкой CMS, а не составлять бесконечный список запретов. Так правила остаются короткими и понятными, а новый раздел не ломается после обновления сайта.

Базовый шаблон для сайта услуг

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

User-agent: *
Disallow: /search/
Disallow: /admin/
Disallow: /login/
Disallow: /cart/
Disallow: /*?sort=
Disallow: /*?filter=
Allow: /blog/
Allow: /services/

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

Я не копирую этот блок на сайт вслепую. Если у MetaRise поиск работает по другому пути, запрет /search/ ничего не сделает. Если фильтр формирует полезные индексируемые страницы, его закрывать нельзя. Комментарии в файле допустимы, но кириллицу в путях и доменных именах нужно кодировать корректно. Сам файл сохраняем в UTF-8 и проверяем снаружи, а не только в редакторе CMS.

Какие директивы нужны сайту?

User-agent, Disallow и Allow

User-agent задаёт, для какого робота действует блок правил. Звёздочка означает всех роботов. Disallow запрещает обход указанного пути, а Allow разрешает более узкий путь, когда он пересекается с закрытым каталогом. В простом сайте лучше не писать десятки отдельных User-agent-блоков без причины: так легче получить конфликт правил.

Регулярно встречаю ошибку, когда разработчик закрывает каталог изображений, CSS или JavaScript вместе с админкой. Если эти файлы нужны для понимания страницы, запрет ухудшит рендеринг и оценку шаблона. Закрываем не тип файла сам по себе, а реально ненужный маршрут.

Sitemap и Clean-param

Строка Sitemap: сообщает роботу полный URL файла карты сайта. Она не открывает страницы автоматически и не заменяет отправку файла в Яндекс.Вебмастер или Google Search Console. Я размещаю строку в robots.txt даже при наличии панели: это ещё один понятный сигнал для обходчика.

В Яндексе может использоваться Clean-param для параметров, которые не меняют содержание страницы, например рекламной метки. Но я не применяю его как универсальную кнопку «убрать дубли». Сначала выясняю, какие параметры меняют контент, какие только отслеживают кампанию, а какие создают настоящие фильтры.

Директива Crawl-delay не является надёжным общим решением для всех поисковиков. Если сервер выдерживает 2–3 запроса в секунду, не надо искусственно замедлять обход и ждать более позднего обнаружения обновлений. При нагрузке лучше смотреть логи, кэш, лимиты и ответы сервера.

Почему sitemap.xml не заменяет перелинковку?

Карта сайта сообщает о приоритетных URL

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

Есть существенная оговорка: наличие URL в Sitemap не означает гарантированный показ в поиске. Страница должна быть доступна, отвечать нужным HTTP-кодом, иметь качественное содержание, не конфликтовать с canonical и быть связана с остальным сайтом. Sitemap — список приоритетных адресов, не приказ проиндексировать всё.

Что включать и что исключать

Я включаю в карту только канонические URL, которые хочу видеть в поиске. Это статьи, рубрики, услуги, кейсы и полезные коммерческие страницы. Не включаю 301, 404, 410, страницы с noindex, дубли параметров, внутренний поиск, черновики, фильтры без самостоятельной ценности и тестовые адреса.

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

Как собрать sitemap.xml для реального сайта?

Один файл или индекс из нескольких файлов

Для небольшого сайта услуг часто хватает одного XML-файла. Ограничение протокола — 50 000 URL или 50 МБ в несжатом виде для одного Sitemap. Если проект больше, создают несколько файлов и Sitemap Index. Важно не количество страниц в базе, а число URL, которые вы реально хотите показывать в поиске.

Для MetaRise я бы разделил карту после роста библиотеки на логические файлы: статьи, рубрики, услуги и кейсы. Это облегчит диагностику в Search Console и Яндекс.Вебмастере. Сейчас важнее не дробить ради вида, а вычистить из карты дубли и проверить HTTP-ответ каждого URL.

Пошаговая сборка карты сайта

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

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://metarise.ru/blog/optimizacziya-i-indeksacziya/robots-txt-sitemap</loc>
<lastmod>2026-10-21</lastmod>
</url>
</urlset>

Как проверить robots.txt и sitemap.xml?

Проверка robots.txt за 15 минут

1. Откройте файл по адресу https://домен.ru/robots.txt.
2. Проверьте HTTP 200, отсутствие циклического редиректа и размер до 500 КБ для требований Яндекса.
3. Найдите строку Sitemap и убедитесь, что путь ведёт на фактический XML-файл.
4. Проверьте важные URL: статья, рубрика, услуга, главная. Они не должны случайно попадать под Disallow.
5. Проверьте закрытые маршруты: поиск, админка, параметры сортировки и тестовые разделы.

Для Яндекса использую инструмент проверки robots.txt в Вебмастере. Для Google смотрю URL Inspection и отчёт Sitemaps в Search Console. Одной проверки синтаксиса мало: файл может быть написан корректно, но закрывать не тот путь из-за особенностей CMS.

Проверка Sitemap через данные индексации

1. Откройте Sitemap и убедитесь, что XML отдаётся без HTML-обёртки и серверных ошибок.
2. Проверьте, что URL абсолютные, на HTTPS и относятся к тому же домену.
3. Сверьте несколько страниц из Sitemap с их canonical, кодом ответа и robots meta.
4. Отправьте файл в Яндекс.Вебмастер и Google Search Console.
5. Через 7–14 дней сравните число отправленных, известных и проиндексированных URL. Не ждите, что каждый адрес появится автоматически.

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

Какие ошибки чаще всего ломают индексацию?

Запрет всего сайта одной строкой

Самая дорогая ошибка выглядит коротко: Disallow: /. Её иногда оставляют после разработки, миграции или тестового запуска. В результате робот не может нормально обойти статьи и услуги, а команда месяц обсуждает падение показов, не открывая robots.txt. Проверяйте файл после каждого переноса домена и перед публикацией новой версии сайта.

Вторая ошибка — закрыть CSS, JavaScript или изображения, которые нужны поисковику для понимания страницы. Третья — запретить `/blog/` вместе с внутренним поиском, потому что правило написано слишком широко. В CMS с похожими путями лучше использовать точные каталоги и тестировать несколько реальных URL.

Грязный Sitemap и конфликт canonical

Типичная карта сайта содержит 301-адреса, дубли со слэшем и без слэша, URL с UTM, страницы фильтров и материалы, закрытые noindex. Поисковику приходится выбирать между противоречивыми сигналами. Если в Sitemap указан один адрес, canonical говорит о втором, а внутренние ссылки ведут на третий, индексация становится менее предсказуемой.

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

Что меняется после исправления файлов?

Пример: сайт услуг и страницы после редизайна

В одном из кейсов MetaRise по услугам юриста в Москве трафик вырос с 10 до 400 посетителей в день, а заявки — с 0 до 15 в неделю за 4 месяца. В работе были информационные статьи, описания программ и результатов услуг, а также перелинковка на целевые страницы. Robots.txt и Sitemap не были единственной причиной результата, но без доступных и согласованных URL эти изменения сложнее обнаружить и оценить.

Другой пример — сайт строительства домов: было около 50 посетителей в день и позиции примерно в ТОП-20, стало около 1200 посетителей в день и ТОП-3 за 3 месяца. В кейсе указаны устранение дублей, тексты с LSI, микроразметка и улучшение пользовательского опыта. Такие цифры — данные, опубликованные MetaRise на коммерческой странице, а не независимое исследование. Их правильный смысл: техническая чистота работает вместе со структурой, контентом и коммерческими факторами.

Почему нельзя обещать результат только настройкой Sitemap

Robots.txt и Sitemap не поднимают страницу в топ автоматически. Они убирают часть технической неопределённости: робот понимает, что обходить, а владелец видит, какие адреса считает важными. Дальше нужны релевантный контент, экспертность, нормальная скорость, удобная мобильная версия, понятные услуги и внутренние ссылки.

Яндекс описывает качество через ЭПОС: экспертность, полезность, оригинальность и содержательность. Для статьи о технических файлах это означает не просто дать шаблон, а объяснить последствия директив, показать проверку и честно разделить примерную практику с гарантированным правилом.

После технических изменений я не делаю вывод по одному графику показов. Сначала фиксирую дату внедрения, список изменённых URL и версию файлов. Затем смотрю обход робота, ошибки сервера, количество известных страниц и переходы на целевые разделы. Такой журнал занимает 10–15 минут в неделю, но помогает понять, что именно повлияло на результат: новая статья, редирект, обновление Sitemap или изменение структуры.

Если на сайте есть региональные версии, поддомены или несколько языков, проверка становится строже. В Sitemap должны быть адреса нужного домена, а в robots.txt — правила именно для этой версии сайта. Нельзя отправить карту staging-домена в панель production-сайта и ждать корректной статистики. Путаются протокол, www, зеркало и окружение — путаются и выводы.

Отдельно проверьте мобильную версию и страницы, которые формируются JavaScript. Робот должен получить доступ к основному HTML и ресурсам, необходимым для понимания содержания. Если важный текст появляется только после клика или запроса браузера, одной строки в Sitemap будет недостаточно.

Как связать robots.txt, sitemap и canonical?

Три сигнала должны говорить об одном URL

Представьте страницу статьи с четырьмя вариантами адреса: HTTP, HTTPS, со слэшем и без слэша, плюс UTM. В Sitemap попадает HTTPS-версия со слэшем. Canonical указывает адрес без слэша. Внутренние ссылки ведут на HTTP. Robots.txt закрывает один из вариантов. Технически сайт продолжает работать, но поисковику приходится разбирать противоречия.

Нужна простая система. Внутри сайта все ссылки ведут на один канонический URL. Sitemap содержит только его. Canonical повторяет его. HTTP и дубль со слэшем перенаправляются на него. Robots.txt не блокирует страницу, на которой нужно прочитать canonical или noindex. Эта схема легче поддерживается и после смены CMS.

Мини-чеклист перед публикацией

• URL статьи отдаёт 200 OK.
• Внутренняя ссылка ведёт на тот же адрес, что и canonical.
• Статья не закрыта robots.txt и не содержит случайный noindex.
• Канонический URL включён в Sitemap.
• URL рубрики и статьи связаны breadcrumbs и контекстными ссылками.
• Дата lastmod меняется только после реального обновления.

Для расширенного аудита я связываю эту проверку с проверкой индексации сайта, SEO-структурой сайта и SEO-аудитом. Если проблема связана с архитектурой, пригодится материал о семантическом ядре: карта URL должна отражать спрос, а не только устройство CMS.

Какие вопросы задают перед настройкой?

Что делать владельцу сайта дальше?

План проверки на один рабочий день

1. Сохранить текущие версии robots.txt и Sitemap перед изменениями.
2. Собрать список важных URL: главная, услуги, рубрики, статьи, кейсы.
3. Проверить каждый URL на 200, canonical, noindex и доступность обхода.
4. Удалить из Sitemap 301, 404, дубли и страницы, которые не нужны в поиске.
5. Добавить чистую строку Sitemap в robots.txt.
6. Отправить файл в Яндекс.Вебмастер и Google Search Console.
7. Через 7–14 дней сравнить статусы, а через 4–8 недель оценить показы, клики и заявки.

Когда лучше подключить специалиста

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

Я могу проверить связку robots.txt, Sitemap, canonical, HTTP-коды, внутреннюю перелинковку и реальные страницы в индексе. Если нужна не разовая проверка, а системное SEO-продвижение сайта частным специалистом, на странице MetaRise есть примеры проектов, сроки от 2–5 месяцев и бюджеты от 40 000–50 000 ₽ для отдельных задач. Конкретный план и стоимость зависят от количества страниц, региона, конкуренции и состояния сайта.