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

Где должен находиться robots.txt

Он обязан находиться в корне хоста, как /robots.txt, в виде обычного текста UTF-8. Он применяется ровно к одной комбинации схемы, хоста и порта, так что https://example.com/robots.txt не управляет ничем на https://shop.example.com и ничем на http-версии того же хоста. Каждый поддомен, который нужно контролировать, требует собственного файла.

Код состояния, который возвращает файл, важен не меньше его содержимого. 404 читается как "ограничений нет, обходите все", что является вполне допустимым состоянием. Повторяющийся 5xx читается как временный сбой, и Google может приостановить обход хоста, а не считать, что ему по-прежнему разрешено продолжать. 403 для этой цели ведет себя как ошибка сервера. Если robots.txt ненадежен, обход становится ненадежным вместе с ним.

Синтаксис в пяти строках

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent открывает группу. Disallow блокирует префикс пути, Allow вырезает исключение из блокировки, * совпадает с любой последовательностью символов, а $ закрепляет конец URL. Sitemap не зависит ни от одной группы и принимает абсолютный URL. Формат стандартизирован как RFC 9309, так что описанное здесь поведение не специфично для конкретного вендора.

Что происходит на самом деле, решают два правила разрешения. Краулер использует только самую конкретную группу, называющую именно его, и полностью игнорирует группу *, как только группа называет его напрямую. Внутри этой группы побеждает самое длинное совпадающее правило, а при равенстве побеждает Allow.

Ошибки, блокирующие весь сайт

• Disallow: /, оставшийся от деплоя staging. Один символ - и заблокирован весь сайт целиком. Попадает в прод точно так же, как noindex staging: файл конфигурации, продвинутый вместе с релизом.
• Блокировка CSS и JavaScript. Google отрисовывает страницы, поэтому заблокированный каталог ресурсов может заставить страницу выглядеть сломанной для краулера, хотя для вас она выглядит нормально.
• Ожидание, что robots.txt уберет страницу из поиска. Он не может. Заблокированный URL все еще может быть указан по внешним ссылкам, обычно без сниппета, и поскольку краулер не может его получить, noindex на этой странице никогда не увидят. Чтобы убрать страницу, разрешите обход и отдавайте noindex.
• Использование noindex: как директивы внутри robots.txt. Она никогда не была частью стандарта, и Google перестал ее соблюдать 1 сентября 2019 года. Сегодня она молча игнорируется.
• Добавление группы для именованного бота с ожиданием, что правила wildcard все еще применяются. Не применяются. Как только появляется User-agent: Googlebot, Googlebot читает именно эту группу и ничего больше, так что каждое общее правило приходится повторять в ней.
• Пустая строка внутри группы. Пустая строка завершает группу, так что правила после нее не принадлежат никому до следующей строки User-agent.
• Перечисление приватных путей. Файл публичен. Указание в нем /internal-admin/ публикует местоположение того, что вы пытаетесь скрыть.

Как проверить отдельный путь

Получите файл и сначала прочитайте группу, применимую именно к вам:

curl -s https://example.com/robots.txt

Затем вручную примените правило самого длинного совпадения к интересующему пути. С Disallow: /blog/ и Allow: /blog/public/ URL /blog/public/post разрешен, потому что совпадающее правило Allow длиннее. Для ресурса, которым вы владеете, отчет robots.txt в Search Console показывает полученный файл, время последнего получения и любые ошибки разбора, что является самым быстрым способом подтвердить, что краулер читает именно то, что вы думаете.

Убедитесь, что файл доступен отовсюду

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

Способ это увидеть - запросить файл откуда-то, что не является вашим офисом. Направьте бесплатный инструмент HTTP-проверки на https://example.com/robots.txt и прочитайте код состояния, возвращаемый из точек проверки в разных странах. 200 везде - здоровый ответ; 200 дома и 403 из трех регионов - это уже находка. Чтобы проверить, блокируют ли правила конкретную страницу, бесплатный тестер robots.txt проверяет URL по группе для всех краулеров и сообщает, указан ли он в карте сайта. Robots.txt существует отдельно от страницы, поэтому опция Indexability в HTTP-мониторе HostTracker его не считывает: она следит за тегами noindex и canonical на самой странице, а запланированный обход, в бета-версии, сверяет каждую обойденную страницу с robots.txt. SEO-мониторинг объясняет, что из этого что покрывает.