Сайт может открываться у владельца, но при этом поисковый робот получает ошибку, не видит часть страниц или считает ресурс временно недоступным. Для бизнеса это неприятная ситуация: внешне все выглядит спокойно, а органический трафик, индексация и видимость в поиске постепенно начинают страдать.
В этой статье разберем, почему так происходит, какие признаки проверить в первую очередь и как выстроить мониторинг, чтобы не узнавать о проблеме только из отчетов вебмастера или жалоб клиентов.
Почему поисковый робот может не видеть сайт
Поисковый робот заходит на сайт не из вашего браузера, не из вашей сети и не всегда по тому же маршруту, по которому сайт открывается у администратора. Поэтому фраза «у меня все работает» не закрывает диагностику.
Разные 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, время проверки, код ответа и то, повторяется ли проблема сейчас.
Что означают типовые симптомы
Робот получает 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, включите уведомления и периодически сверяйте события мониторинга с логами сервера. Так проще отделить единичную ошибку от системной проблемы и быстрее понять, что именно нужно исправлять.
Вывод
Если поисковый робот не видит сайт, а у владельца он открывается, причина часто находится не в одной странице, а в разнице условий: DNS, SSL, CDN, firewall, редиректы, robots.txt, серверные ошибки или неполный контент при коде 200.
Проверяйте сайт снаружи, смотрите не только браузер, но и HTTP-код, DNS, сертификат, служебные файлы и логи. После исправления настройте автоматический мониторинг: он не заменяет техническую диагностику, но помогает быстрее узнать, что сайт снова стал недоступен для пользователей или поисковых роботов.