Сайт может открываться у владельца, но при этом поисковый робот получает ошибку, не видит часть страниц или считает ресурс временно недоступным. Для бизнеса это неприятная ситуация: внешне все выглядит спокойно, а органический трафик, индексация и видимость в поиске постепенно начинают страдать.
В этой статье разберем, почему так происходит, какие признаки проверить в первую очередь и как выстроить мониторинг, чтобы не узнавать о проблеме только из отчетов вебмастера или жалоб клиентов.
Короткий ответ
Если Search Console или Яндекс Вебмастер сообщает, что робот не может получить страницу, сначала проверьте не весь сайт, а конкретный URL из отчета. Важно увидеть HTTP-код, цепочку редиректов, SSL, DNS-ответ, доступность `robots.txt` и наличие ключевого текста в HTML.
Для быстрой внешней проверки можно открыть инструмент проверки сайта и указать проблемный адрес. Если URL важен для заявок, рекламы или органического трафика, после ручной проверки добавьте его в мониторинг Web-Puls: так будет видно, повторяется ли сбой, сколько он длится и когда появился впервые.
Следующий шаг зависит от симптома. Ошибки 5xx и таймауты нужно сверять с логами хостинга или приложения, 403 и 429 - с CDN, firewall и антибот-правилами, а успешный код 200 без нужного контента - с шаблоном, CMS и загрузкой данных. Если проблема уже влияет на индексацию или заявки, отправьте URL и симптомы через форму поддержки: достаточно указать адрес, код ответа, время ошибки и что менялось перед сбоем.
Почему поисковый робот может не видеть сайт
Поисковый робот заходит на сайт не из вашего браузера, не из вашей сети и не всегда по тому же маршруту, по которому сайт открывается у администратора. Поэтому фраза «у меня все работает» не закрывает диагностику.
Разные DNS-ответы и кэш
Владелец сайта может видеть старый рабочий IP из локального кэша, а робот уже получает новый адрес, где сайт не настроен. Бывает и наоборот: у администратора проблема не повторяется, потому что его провайдер еще не обновил DNS, а часть внешних сетей уже видит ошибочную запись.
Проверьте не только браузер, но и DNS-записи домена: A, AAAA, CNAME, NS. Если сайт недавно переносили, меняли CDN или правили записи у регистратора, стоит проверить домен из нескольких внешних сетей.
Ошибка SSL или неполная цепочка сертификата
Браузер владельца иногда открывает сайт за счет сохраненных исключений, промежуточного кэша или привычного сценария. Робот же будет оценивать доступность строго: сертификат должен подходить к домену, не быть просроченным, иметь корректную цепочку и нормально работать на HTTPS-версии.
Если сайт открывается по HTTP, но ломается по HTTPS, проблема может затронуть не только пользователей, но и обход поисковыми системами.
Firewall, антибот-защита и CDN-правила
Защитные правила часто включают после всплеска спама, DDoS или подозрительных запросов. Если фильтр настроен слишком жестко, он может отдавать роботам 403, показывать проверку JavaScript, капчу или пустую страницу. Для человека сайт выглядит доступным, потому что его IP уже прошел проверку, а поисковый робот получает другой ответ.
Особенно внимательно проверьте правила WAF, блокировки по user-agent, географии, ASN, частоте запросов и заголовкам.
Неверные редиректы
Редирект с HTTP на HTTPS, с www на домен без www или со старого адреса на новый должен быть коротким и предсказуемым. Если цепочка редиректов слишком длинная, циклическая или ведет на страницу с ошибкой, робот может не получить полезный контент.
Типичный пример: главная страница открывается, а старые URL из поиска редиректят на промежуточный адрес, который уже удален или закрыт от индексации.
Страница отвечает 200, но фактически показывает ошибку
Иногда сервер возвращает код 200 OK, но внутри страницы виден текст «товар не найден», «ошибка подключения к базе» или пустой шаблон без основного контента. Для пользователя это выглядит как поломка, а для поискового робота такая страница тоже не является нормальным результатом.
Поэтому важно проверять не только HTTP-код, но и содержимое страницы: наличие заголовка, ключевого блока, текста карточки товара, формы или другого ожидаемого элемента.
Как быстро понять, что проблема реальная
Начните с проверки снаружи. Не используйте только свой ноутбук, офисную сеть и телефон, потому что они могут давать одинаково неполную картину.
- Откройте проблемный URL в режиме без кэша и с другого подключения.
- Проверьте HTTP-код ответа: 200, 301, 302, 403, 404, 429, 500, 502, 503 или 504.
- Проверьте HTTPS: срок действия сертификата, домены в сертификате и цепочку доверия.
- Посмотрите DNS-ответы у разных резолверов.
- Откройте `robots.txt` и убедитесь, что он доступен без серверной ошибки.
- Проверьте, не отдает ли сайт разные ответы обычному браузеру и роботам.
- Посмотрите серверные логи по конкретному времени и URL.
Если в Search Console или Яндекс Вебмастере появилась ошибка обхода, ее нужно сверить с фактическим ответом сервера. Важен не только текст предупреждения, но и URL, время проверки, код ответа и то, повторяется ли проблема сейчас.
Практические сценарии, где это видно
Вебмастер показывает ошибку обхода, а браузер открывает страницу
Так бывает после короткого сбоя хостинга, перегрузки PHP-FPM, ошибки базы данных или неудачного релиза. Владелец открывает страницу уже после восстановления и видит нормальный сайт, а робот в момент обхода получил 502, 503 или timeout.
Что делать: проверить время ошибки в панели вебмастера, найти тот же интервал в логах и добавить важный URL в регулярный мониторинг. Тогда следующий сбой будет виден не только постфактум в SEO-инструменте.
Робот получает 403, а человек видит сайт
Частая причина - защитный слой: CDN, WAF, антибот-модуль, ограничения по странам, ASN или user-agent. Для обычного браузера сайт открывается, потому что запрос выглядит привычно, а робот получает запрет, капчу или JavaScript-проверку.
Что делать: сравнить ответ обычного запроса и запроса с пользовательским агентом поискового робота, затем проверить правила безопасности. Отключать всю защиту не нужно: безопаснее найти конкретное правило, которое блокирует легитимный обход.
Страница отвечает 200, но потеряла оффер или форму
Для SEO и заявок опасен не только полный отказ сервера. Страница может отдавать 200 OK, но показывать пустой шаблон, старую заглушку, ошибку подключения к каталогу или экран без формы заявки. Робот получает страницу, но не видит полезного содержимого, а посетитель не может выполнить целевое действие.
Что делать: контролировать не только HTTP-код, но и обязательный текст: заголовок услуги, фрагмент оффера, кнопку, форму заявки или другой стабильный элемент. В Web-Puls такую проверку можно использовать как маркер, что страница не просто открылась, а сохранила рабочее содержимое.
Если по странице уже есть переходы, но заявок нет, добавьте в проверку не только статус ответа, но и целевое действие: оффер, кнопку, форму и контрольный текст рядом с ней. Для регулярного контроля можно добавить URL в мониторинг Web-Puls, а если нужно понять, почему посадочная не доводит посетителя до обращения, отправьте страницу через форму оценки задачи с кратким описанием симптомов.
Что означают типовые симптомы
Робот получает DNS-ошибку
Проверьте NS-записи, адресные записи, срок делегирования домена и настройки у DNS-провайдера. Если используются разные зоны для поддомена и основного домена, убедитесь, что все они обновлены.
Практический пример: сайт перенесли на новый хостинг, главная открывается у владельца, но `www`-версия осталась на старом IP. Часть роботов и пользователей попадает на старую площадку и видит ошибку.
Робот получает 403 Forbidden
Проверьте, не заблокированы ли поисковые роботы правилами безопасности. Ошибка 403 часто появляется после включения защиты от ботов, ограничения по странам или запрета неизвестных user-agent.
Не стоит просто отключать всю защиту. Лучше найти конкретное правило, посмотреть логи и разрешить легитимный обход без открытия лишних рисков.
Робот получает 429 Too Many Requests
Код 429 означает, что сервер или защитный слой считает запросы слишком частыми. Для API и личных кабинетов это может быть нормальной защитой, но для публичных страниц сайта слишком жесткий лимит мешает обходу.
Проверьте лимиты CDN, reverse proxy, CMS-плагинов и серверных модулей. Отдельно посмотрите, не срабатывает ли ограничение на все запросы с одного внешнего диапазона.
Робот получает 5xx
Коды 500, 502, 503 и 504 говорят о серверной проблеме, сбое приложения, прокси, upstream-сервера или таймауте. Даже если ошибка возникает не постоянно, она может мешать обходу важных страниц.
Здесь полезно разделить проверку: главная страница, карточка товара, страница категории, форма заявки, sitemap и robots.txt. Если ломается только один тип страниц, причина часто находится в шаблоне, модуле CMS или интеграции.
Робот видит пустую или неполную страницу
Так бывает, когда контент загружается только JavaScript-запросом, который блокируется, падает или требует авторизации. Еще один вариант - ошибка в шаблоне: код ответа 200, а основной блок не выводится.
Проверьте исходный HTML, результат рендера, загрузку CSS и JS, а также наличие важных элементов без пользовательских действий.
Практический чек-лист для владельца сайта
Для быстрой диагностики удобно идти от внешней доступности к внутренним причинам.
1. Проверить главный URL и несколько важных страниц
Не ограничивайтесь главной. Для интернет-магазина проверьте категорию, карточку товара, корзину и оформление заказа. Для сервисного сайта - страницу услуги, форму заявки, контакты и страницу входа, если она важна для клиентов.
2. Сравнить ответы с разных точек
Если сайт доступен из одной сети, но недоступен из другой, возможны проблемы DNS, CDN, геоблокировки или сетевого маршрута. В таком случае простой браузерный тест мало что показывает.
3. Проверить служебные URL
Откройте `robots.txt`, `sitemap.xml`, HTTPS-версию, www-версию и адрес без www. Ошибка на служебном файле может быть незаметна для посетителей, но важна для обхода сайта.
4. Посмотреть логи
В логах ищите коды ответа, user-agent, IP, URL и время. Если робот получает 403 или 5xx, а человек получает 200, причина почти всегда находится в правилах доступа, прокси, CDN, CMS или серверной нагрузке.
5. Убедиться, что проблема не возвращается
Разовая ручная проверка помогает найти текущий сбой, но не показывает, повторится ли он ночью, после обновления CMS или при росте нагрузки. Поэтому после исправления стоит настроить регулярную проверку.
Почему ручной проверки недостаточно
Ручная проверка отвечает только на вопрос «что происходит прямо сейчас у меня». Она не показывает короткие падения, региональные проблемы, ошибки SSL после продления, сбои DNS и ситуации, когда сайт отвечает кодом 200, но не содержит нужного контента.
Автоматический мониторинг решает эту задачу лучше: он регулярно обращается к сайту снаружи, фиксирует статус, время ответа и может отправить уведомление, если страница перестала открываться или начала отдавать ошибку.
Чтобы не проверять сайт вручную, можно настроить автоматический мониторинг в Web-Puls. Он помогает следить за доступностью сайта и быстрее заметить ситуацию, когда проблема видна снаружи, но еще не дошла до владельца через жалобы клиентов.
Что стоит мониторить для SEO и стабильности
Минимальный набор проверок для небольшого сайта:
- главная страница;
- важная посадочная страница;
- страница услуги или категории;
- форма заявки или страница корзины;
- HTTPS-доступность и SSL-сертификат;
- корректный HTTP-код;
- наличие ожидаемого текста на странице;
- время ответа сервера.
Если сайт зависит от CDN, внешнего API или отдельного backend-сервера, добавьте проверки для этих точек. Так будет проще понять, где именно возникла проблема: в домене, сертификате, приложении, прокси или сторонней интеграции.
Когда стоит подключить специалиста
Если ошибка связана с DNS, SSL, хостингом, CDN, firewall или серверными кодами 5xx, ее не всегда получится быстро разобрать без доступа к настройкам. Важно не менять все подряд, а последовательно проверить маршрут запроса и место, где ответ ломается.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls: https://web-puls.ru/support/. Если удобнее обсудить ситуацию другим способом, используйте контактную информацию: https://web-puls.ru/contacts/.
Как Web-Puls помогает заметить проблему быстрее
Web-Puls регулярно проверяет доступность сайта и помогает владельцу увидеть проблему до того, как она станет массовой. Это особенно полезно для ситуаций, где сбой возникает не на глазах у администратора: ночью, после обновления, при изменении DNS, при ошибке SSL или при нестабильной работе хостинга.
Оффер в таком сценарии простой: вы выбираете важные URL, а сервис регулярно проверяет их снаружи, сохраняет историю кода ответа и времени ответа, следит за SSL и помогает заметить пропажу ключевого текста на странице. Для SEO-страницы это может быть заголовок, фрагмент основного текста или ссылка на форму заявки; для коммерческой страницы - оффер, цена, кнопка или блок контактов.
Практический порядок действий:
- Проверьте проблемный URL через форму проверки на странице или в разделе проверки сайта.
- Если ошибка подтверждается или уже была в вебмастере, добавьте URL в мониторинг.
- Укажите ожидаемый код ответа и контрольный текст, который должен быть на странице.
- Включите уведомления и сверяйте события мониторинга с логами сервера, CDN или CMS.
- Если причина требует доступа к DNS, SSL, firewall или серверу, передайте собранные факты через форму поддержки.
Вывод
Если поисковый робот не видит сайт, а у владельца он открывается, причина часто находится не в одной странице, а в разнице условий: DNS, SSL, CDN, firewall, редиректы, robots.txt, серверные ошибки или неполный контент при коде 200.
Проверяйте сайт снаружи, смотрите не только браузер, но и HTTP-код, DNS, сертификат, служебные файлы и логи. После исправления настройте автоматический мониторинг: он не заменяет техническую диагностику, но помогает быстрее узнать, что сайт снова стал недоступен для пользователей или поисковых роботов.