В браузере сайт открывается, а технический аудит получает 403. Это не доказывает отсутствие контента или noindex. Сначала установите различие запросов: IP, User-Agent, cookies, частота и правила WAF. Ответ инструмента и доступность для поискового робота — отдельные наблюдения.
403 ограничивает выводы аудита, а не доказывает отсутствие текста
Ошибка доступа ограничивает выводы аудита. Не интерпретируйте неполученный HTML как отсутствующий title или H1. Согласуйте допустимый режим диагностики с владельцем защиты, сохраняя необходимые ограничения сайта.
Ответ 403 сообщает отказ доступа; без полученного документа нельзя оценивать его метатеги как фактически отсутствующие. Официальная документация.
Если инструмент не получил документ, его проверка метатегов не состоялась. В отчёте нужен статус недоступности, а не список «нет title, H1 и canonical». Успешный вход владельца тоже имеет ограничения: он может быть авторизован, иметь разрешённый IP или проходить challenge. Начните с гостевого браузера в новом сеансе. Сохраните точный URL и время. Разделите доступ обычного человека, вашего аудитора и настоящего поискового робота. Эти клиенты могут обслуживаться разными правилами, поэтому один результат не переносится на всех автоматически.
Сравните запросы браузера и инструмента
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| Гостевой браузер | Обычный клиент | Записать ответ | Не использовать сессию админа |
| Обходчик аудита | Другой IP или agent | Сверить WAF лог | Найти правило |
| Много запросов | Ограничение частоты | Снизить темп | Не отключать защиту |
| Строка Googlebot | Не проверенная личность | Не доверять имени | Отдельная проверка подлинности |
Сопоставьте IP источника, User-Agent, наличие cookies, метод, частоту и порядок запросов. Не публикуйте чувствительные значения; достаточно безопасных признаков для владельца защиты. Проверяйте документ GET, а не успешный favicon или API. Если браузер проходит JavaScriptchallenge, простой HTTP клиент может получать 403 без выполнения этой проверки. Убедитесь, что адрес не перенаправляет на защищённый поддомен. Важно найти конкретное различие, а не предполагать, что аудит «сломал сайт» или что каждый 403 означает запрет поискового обхода.
Какие данные нужны владельцу WAF
Передайте URL, время, статус, request id и безопасные признаки клиента владельцу WAF. Сравните гостевой браузерный GET и запрос инструмента по журналам. Не публикуйте cookies, токены или внутренние правила защиты.
Передайте владельцу WAF адрес, время с часовым поясом, статус, request ID и ограниченную информацию о клиенте. Попросите сопоставить событие с правилом: репутация IP, частота, бот-защита, география или другой подтверждённый критерий. Текст страницы блокировки может подсказывать причину, но окончательное объяснение требует конфигурации или журнала. Не отправляйте полный HAR с cookies без очистки. Если логов нет, отметьте границу и проведите согласованный минимальный опыт. Такой запрос хостингу полезнее требования отключить всю защиту на основании одного неуспешного обхода.
Учебный отказ после увеличения частоты
Учебный WAF ограничивает частые обращения нового клиента. Первый GET проходит, последующие получают 403. Сравнение с тихим браузером не доказывает различие HTML; сначала проверяется событие защиты и согласованная частота.
Учебный сервер пропускает первый запрос нового клиента, а после серии отвечает 403. Сравните один медленный запрос и ограниченную серию при тех же остальных условиях. Не усиливайте нагрузку на рабочий сайт, чтобы добиться отказа. Если частота подтверждена как причина, уменьшите параллельность и интервал по согласованной политике. Затем повторите исходный контроль. Такой опыт отличает доступ клиента от качества HTML. Если уже первый запрос запрещён, гипотеза только о лимите частоты недостаточна: проверьте IP, challenge и другие правила.
Настройте узкий разрешённый диагностический режим
Исправьте подтверждённое ложное срабатывание либо настройте разрешённый диагностический доступ с узким охватом. После изменения повторите тот же запрос и убедитесь, что защита остальных сценариев сохраняется.
Для нужного инструмента настройте предусмотренное разрешение с ограниченной областью и понятным владельцем, если политика сайта это допускает. Не доверяйте произвольной строке User-Agent как удостоверению личности. Не отключайте защиту всех маршрутов ради одного публичного аудита. Если инструмент не подходит архитектуре challenge, выберите разрешённый механизм получения данных или сообщите ограничение. После изменения проверьте один разрешённый публичный URL и один сценарий, который защита должна по-прежнему ограничивать. Исключение должно быть управляемым и не превращаться в общий открытый проход.
Googlebot требует проверки подлинности отдельно
Поддельный User-Agent Googlebot не подтверждает настоящий Googlebot и не обосновывает общее разрешение. Отключение WAF целиком не является необходимым решением одного 403.
Настоящие обращения Google проверяются предусмотренными способами, включая официальные сведения о сетях или DNS-проверку по актуальной документации. Простая подмена User-Agent не подтверждает их происхождение. Проверка запросов Google описана отдельно. Если поисковый инструмент получает страницу, а ваш аудит 403, это два конкретных наблюдения, не противоречащие друг другу. Сохраните даты и условия. Не делайте вывод о поисковом трафике по отказу стороннего инструмента: его доступ полезен диагностике, но не заменяет подтверждённые данные настоящего обхода.
Приёмка доступа и сохранения защиты
Повторите тот же проверочный запрос после согласованной правки и подтвердите получение нужного HTML, а не 200 от заглушки. Только затем интерпретируйте метатеги и содержимое. Проверьте сохранение других правил защиты и отсутствие доступа к приватным маршрутам. В отчёте назовите подтверждённое правило отказа, область исключения и оставшиеся ограничения. Если получение всё ещё невозможно, результатом остаётся недоступная проверка с причиной, а не ложный список SEO-дефектов. Состояние поискового доступа и классификацию индекса добавляйте отдельными источниками с собственными датами.
Критерии завершения проверки
Проверочный запрос получает предусмотренный доступ, причина отказа подтверждена журналом или правилом. Результат аудита интерпретируется только после получения содержимого; поисковый доступ проверяется отдельно.
- Гостевой браузер: Не использовать сессию админа. Зафиксируйте фактический результат и адрес проверенного сценария.
- Обходчик аудита: Найти правило. Зафиксируйте фактический результат и адрес проверенного сценария.
- Много запросов: Не отключать защиту. Зафиксируйте фактический результат и адрес проверенного сценария.
- Строка Googlebot: Отдельная проверка подлинности. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Как провести SEO аудит сайта: пошаговое руководство и HTTP статус-коды: полный справочник (200, 301, 404, 500...). Отдельные проверки сайта собраны на странице технического аудита reChecker.