Проверка robots.txt перед запуском сайта: чек-лист, который спасает трафик

Почему именно robots.txt — частая причина катастрофы после запуска

Сайт почти всегда сначала собирают на тестовом домене или поддомене, и на этом этапе разработчики намеренно закрывают его от индексации — правильно, потому что незавершённый сайт не должен попасть в выдачу раньше времени. Типичный способ — строка Disallow: / в robots.txt, которая запрещает роботу заходить куда бы то ни было на сайте. Проблема начинается в момент переноса сайта на боевой домен: если файл robots.txt переносится вместе с остальными файлами автоматически, без отдельной проверки, этот запрет переезжает вместе с сайтом и продолжает действовать уже на реальном адресе, который должен собирать трафик. Внешне всё выглядит нормально — сайт открывается в браузере, работает, — но робот на него принципиально не заходит, и без специальной проверки эта проблема может оставаться незамеченной неделями, потому что стандартные метрики вроде «сайт работает» её не показывают. Такой сценарий стоит держать в голове ещё на этапе постановки задачи на разработку сайта — проверку robots.txt разумно закладывать в чек-лист запуска заранее, а не вспоминать о ней постфактум.

Чек-лист из пяти проверок перед запуском

1. Открыть robots.txt по прямому адресу боевого домена. Не в файлах проекта, не в панели разработки — именно по адресу site.ru/robots.txt, как его увидит поисковик. Иногда файл, который редактировали на тестовом сервере, физически не попадает на боевой из-за особенностей деплоя, и по факту на новом адресе висит старая версия или файл вовсе отсутствует.
2. Убедиться, что нет полного запрета Disallow: / в блоке User-agent: *. Это первое, что нужно проверить визуально, — одна строка, которая перечёркивает всю дальнейшую работу над сайтом.
3. Проверить, что важные разделы не закрыты по ошибке. Каталог товаров, статьи блога, посадочные страницы должны быть открыты. Легко перепутать похожие пути и случайно закрыть директивой не только служебный раздел, но и соседний с ним рабочий — например, если тестовая версия использовала общий префикс URL.
4. Проверить актуальность директивы Sitemap. Адрес в строке Sitemap: должен указывать на боевой домен, а не на тестовый — при переносе такие адреса иногда остаются от старой конфигурации и продолжают вести на уже недоступный сервер.
5. Проверить, нет ли конфликта между robots.txt и noindex в коде страниц. Если разработчики использовали мета-тег noindex для служебных страниц на этапе тестирования и он остался в шаблоне, а сама страница при этом закрыта Disallow — робот не увидит тег и решение может сработать не так, как задумано на конкретной странице.

Инструмент проверки в панели вебмастера — не полагайтесь на чтение файла глазами

Визуальная проверка полезна для быстрого просмотра, но синтаксис robots.txt достаточно тонкий, чтобы ошибку не заметить: лишний пробел, неверный порядок Allow и Disallow, опечатка в пути. И в Google Search Console, и в Яндекс.Вебмастере есть встроенный инструмент проверки robots.txt: он показывает, как именно поисковик интерпретирует текущий файл, и позволяет протестировать конкретный URL — доступен он для сканирования или нет, согласно действующим правилам. Это надёжнее любого визуального осмотра, потому что инструмент использует ту же логику разбора файла, что и реальный робот, а не человеческое чтение построчно, которое легко пропускает конфликтующие правила в разных блоках.

Что делать, если проблему нашли уже после запуска

Порядок действий здесь стандартный, но важна скорость. Сначала — исправить сам файл, убрать лишний запрет. Дальше не стоит просто ждать: нужно отправить сайт на переобход через инструмент «Проверка URL» в Google Search Console и «Переобход страниц» в Яндекс.Вебмастере — по главной странице как минимум, чтобы ускорить первый повторный визит робота. Затем стоит убедиться, что sitemap.xml актуален и содержит все страницы сайта, и переотправить его через панель вебмастера — это даёт роботу полный список того, что нужно обойти заново. По опыту устранения подобных ситуаций, робот обычно возвращается на сайт в течение 1-3 дней после ручного запроса переобхода, но полная переиндексация всех страниц сайта, если их много, может занять от одной до нескольких недель — то есть даже быстрое исправление не отменяет заметный провал в трафике сразу после инцидента, просто сокращает его длительность по сравнению со сценарием, где проблему находят случайно спустя месяц.

Как эта проблема остаётся незамеченной так долго

Есть конкретная причина, почему подобные ошибки не находят сразу: сайт полностью функционален для живых посетителей — он открывается, работает, формы отправляются. Ничего в обычном использовании не сигнализирует о проблеме. А стандартные метрики вроде счётчика Яндекс.Метрики или Google Analytics в этой ситуации показывают ноль или почти ноль органического трафика, но это легко списать на «сайт же только что запустили, трафик ещё не набрался» — вполне логичное на первый взгляд объяснение, которое в реальности маскирует техническую поломку. Разница между «трафика пока нет, потому что сайт молодой» и «трафика нет, потому что робот на сайт не заходит» видна только при целевой проверке — либо через инструмент проверки robots.txt, либо через отчёт об индексации в панели вебмастера, где в первом случае со временем страницы будут появляться, а во втором — обход не начнётся вообще, пока не снимут технический барьер. Регулярный контроль этих показателей стоит вести как часть веб-аналитики сайта, а не проверять только один раз при запуске.

Частые ошибки при переносе сайта, помимо robots.txt

Хотя тема материала — именно robots.txt, на практике эта проблема редко приходит одна: при переносе сайта на боевой домен вместе с ней часто всплывают смежные технические огрехи, которые стоит проверить в том же заходе. Мета-тег noindex, оставленный в шаблоне на этапе разработки, — та же логика ошибки, только на уровне отдельной страницы, а не всего сайта сразу. Устаревший или отсутствующий sitemap.xml — файл могли просто забыть создать заново под боевой домен. Неправильные канонические ссылки, всё ещё указывающие на тестовый поддомен, — тоже частый спутник спешного переноса. Комплексная проверка перед запуском, которая закрывает все эти пункты разом, а не только robots.txt, разобрана в материале про SEO-аудит сайта.

Когда стоит делать эту проверку, помимо самого запуска

Не только при первом запуске сайта риск возникает повторно. Любая миграция на новый движок или новый хостинг несёт те же риски — файлы конфигурации переносятся целиком, и вместе с ними может переехать тестовая версия robots.txt. Смена темы оформления на WordPress или обновление конструктора тоже иногда затрагивает файл, если он генерировался автоматически через плагин, а не лежал статично в корне. Разумная практика — включить проверку robots.txt в стандартный чек-лист после любого крупного технического изменения сайта, а не считать её разовой задачей, актуальной только в момент самого первого запуска.

FAQ

Готовый robots.txt для WordPress

Базовый набор правил: закрываем служебные каталоги, оставляем открытым ajax-обработчик и указываем карту сайта.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /?s=
Disallow: /*?replytocom
Allow: /wp-content/uploads/

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