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

Что должен делать robots.txt для бизнеса? Давать поисковым роботам правила обхода. RFC 9309 отделяет эти правила от авторизации.

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

Такие решения согласует владелец раздела. Ответственность за ошибки остаётся у людей, даже если файл подготовил агент.

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

Для публичной страницы с noindex робот должен прочитать само правило. Если путь закрыт в robots.txt, Google его не увидит.

Личные данные ради noindex не открывают. Их защищают авторизацией, а поведение поиска проверяют отдельной задачей.

Как избежать противоречия между robots.txt и sitemap? Хранить назначение разделов в одном месте. Иначе одна правка закроет страницу, а другая продолжит приглашать робота её обойти.

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

У нас общий список служебных зон используется в robots.txt и при сборке sitemap. Это устройство машины на vibecoding.ru, а не замер клиентского проекта.

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

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

Общий список ещё не гарантирует согласованное поведение. На нашем сайте 7 октября запрет /payment захватывал публичный /payments, который присутствовал в sitemap.

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

У vibecoding.ru витрина открыта для обхода, а app.vibecoding.ru закрыт целиком. Один шаблон «запретить всё» для обоих хостов закрыл бы и витрину.

В наших тестах отдельно заданы основной хост, кабинет и снятый учебный хост. Локальный адрес кабинета тоже получает его закрытые правила.

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

Ответ 200 принимают вместе с содержимым. Страница ошибки или форма входа под этим кодом не становится файлом правил.

У нас оба публичных адреса robots.txt вернули 200 и текст правил 7 октября. Это подтверждает ответы этих адресов, а не состояние всех страниц сайта.

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

Правила для ИИ-агентов задают границы работы. Для этого файла граница конкретна: агент предлагает изменения, а назначение разделов утверждает руководитель.

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

Строка «Disallow есть» слишком слаба для приёмки. В Google более конкретное разрешение может выиграть у общего запрета.

Именная группа Googlebot тоже требует своего сценария. Она не наследует общую группу со звёздочкой: нужен разбор результата для робота, а не поиск строки в файле.

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

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

Кто принимает результат? Инженер сверяет протокол с назначением разделов. Обязанности руководителя разработки и агентов здесь разделены: машина проверяет, человек решает, что публиковать.

Протокол содержит хост, адрес, ожидание и фактический ответ. Формулировка «всё зелёное» не показывает, проверяли ли вообще кабинет.

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

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

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

Принятая правка и поисковый результат имеют разные сроки. Загрузка sitemap сама по себе не гарантирует индексирования: это отдельно оговорено в документации Google.

Что включить в заказ разработчику? Перечень хостов, согласованную карту разделов и доказательства её исполнения. Тогда результат можно принять по адресам, даже если код написал агент.

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

Для постоянного потока изменений эту работу можно включить в подписку на разработку. На 7 октября тариф «Один проект» стоит 250 000 ₽ в месяц, один поток работы.

Разовая настройка файла не требует месячной подписки. Она уместна, когда у сайта есть очередь доработок и кому-то нужно вести их дальше.

Если в компании некому согласовать такую приёмку, следующий шаг: тест для руководителя. Он помогает разобрать работу отдела с агентами, но не сканирует robots.txt.

Своего клиентского кейса этой услуги у нас нет. Пример статьи: машина агентов на vibecoding.ru; перечисленные проверки можно использовать как предмет обсуждения с вашей разработкой.

1. Согласуйте назначение разделов до правки robots.txt.

2. Разделяйте обход, исключение из поиска и защиту данных.

3. Сверяйте robots.txt и sitemap с одной картой сайта по каждому хосту.

4. Принимайте протокол с адресами и результатами, затем проверяйте боевой ответ.

5. Каждое найденное расхождение превращайте в проверку следующего выпуска.