Как проверить robots.txt после переезда сайта

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

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

Что именно меняется при переезде

Правила robots.txt действуют для конкретного протокола, хоста и порта. Файл для https://example.ru/ не следует автоматически считать правилом для http://example.ru/ или https://www.example.ru/, поэтому проверьте все версии, на которые могут попасть робот и пользователь.

На новом сайте часто меняются:

• пути к каталогу, поиску, фильтрам и личному кабинету;
• адрес sitemap.xml;
• расположение CSS, JavaScript и изображений;
• правила CMS, прокси или CDN;
• основной домен и редиректы между версиями с www и без него.

Сохраните исходное состояние до переключения

До смены DNS откройте https://example.ru/robots.txt и сохраните тело ответа вместе с HTTP-заголовками. Отдельно запишите, какие URL должны быть доступны, а какие действительно следует закрыть от обхода.

Минимальная матрица проверки:

| Тип URL | Ожидаемый результат | |---|---| | Главная, категории, товары или услуги | обход разрешён | | CSS, JavaScript и важные изображения | доступны для корректного рендеринга | | Внутренний поиск и бесконечные фильтры | правило соответствует SEO-плану | | Админка и технические разделы | закрыты от обхода, но защищены не только robots.txt | | Sitemap | указан актуальный абсолютный адрес |

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

Как получить файл со старого и нового сервера

Если домен ещё не переключён, достаточно сохранить старый ответ и затем повторить запрос после выкладки. Проверяйте обычным GET, а не только HEAD: важны и код ответа, и фактическое тело файла.

curl -sS -D old-headers.txt -o old-robots.txt https://example.ru/robots.txt
curl -sS -D new-headers.txt -o new-robots.txt https://example.ru/robots.txt
diff -u old-robots.txt new-robots.txt

Когда новый сервер доступен по отдельному IP, запрос можно направить на него до смены DNS, сохранив исходное имя хоста:

curl -sS --resolve example.ru:443:NEW_SERVER_IP \
  -D new-headers.txt -o new-robots.txt \
  https://example.ru/robots.txt

Так сервер получает правильный Host, а TLS проверяется для рабочего домена.

На какие расхождения смотреть в первую очередь

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

Строка Disallow: / у общей группы User-agent: * уместна на закрытом стенде, но опасна на production. Проверьте, не приехала ли она вместе с конфигурацией тестовой среды.

Старые пути в новых правилах

Запрет /search/ бесполезен, если новая CMS использует /catalog/filter/. Обратная ошибка тоже возможна: старый закрытый путь после переезда становится адресом публичного раздела.

Неверный Sitemap

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

Заблокированные ресурсы страницы

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

Разные группы роботов

Сравните правила для User-agent: * и отдельных роботов. Общая группа может выглядеть правильно, пока специальная секция сохраняет старый запрет или разрешение.

Проверьте правила на реальных URL

Текстовый diff показывает изменение строк, но не отвечает, как правило сработает для конкретного адреса. Возьмите URL из каждой важной группы и проверьте их в анализаторах robots.txt Яндекс Вебмастера и Google Search Console.

Для каждого URL зафиксируйте три вещи:

1. какой робот проверяется;
2. какое правило должно победить;
3. совпал ли результат инструмента с ожиданием.

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

Что проверить после переключения DNS

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

Затем повторите матрицу URL в инструментах поисковых систем: один успешный запрос ещё не подтверждает корректность всех правил.

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

Как не пропустить повторную поломку

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

Web-Puls может регулярно проверять публичный URL и помочь быстрее заметить, что robots.txt перестал открываться или неожиданно изменился. Это не заменяет проверку логики правил в Вебмастере, но закрывает риск тихого технического сбоя после релиза.

Чек-лист перед завершением переезда

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

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