Страницы, которые не отвечают

Что это

Страницы, которые не отвечают — это URL-адреса сайта, при обращении к которым сервер не возвращает никакого HTTP-ответа в разумное время или разрывает соединение до его завершения. В отличие от ошибки 404 (сервер ответил, но страница не найдена), здесь ответа нет вообще: соединение зависает, таймаутится или сбрасывается на уровне TCP. Краулер поисковика фиксирует такой URL как недоступный и не может получить содержимое страницы.

---

Почему это важно для SEO

Поисковые роботы — Googlebot и Яндекс.Бот — работают с ограниченным краулинговым бюджетом. Когда робот упирается в страницу, которая не отвечает, он тратит время ожидания впустую, а затем уходит ни с чем. Если таких URL много, бюджет исчерпывается раньше, чем будут обойдены важные страницы. Для крупного интернет-магазина с 50 000+ страниц даже 3-5% «молчащих» URL могут привести к тому, что новые карточки товаров неделями не появляются в индексе.

Яндекс учитывает доступность сайта при формировании ИКС и при расчёте частоты переобхода. Если робот систематически получает таймауты с одного домена, Яндекс снижает приоритет его краулинга — сайт начинают обходить реже. Google аналогично снижает краулинговую активность: в Google Search Console в разделе «Настройки» — «Сканирование» можно увидеть провалы на графике запросов. Зафиксированные сбои влияют и на Core Web Vitals — если страница не отвечает при реальных пользовательских визитах, это напрямую бьёт по показателю TTFB и метрике LCP.

---

Как проверить вручную

1. Screaming Frog SEO Spider — запустите краулинг сайта, после завершения отфильтруйте результаты по статусу: Response Code → No Response или Timeout. Инструмент покажет полный список URL без ответа с указанием типа сбоя (connection refused, timeout, reset).

1. Google Search Console — раздел «Индексирование» → «Страницы» → фильтр «Причина: ошибка сканирования». Здесь Google сам сообщает, какие URL не смог получить, и когда была последняя попытка.

1. Яндекс.Вебмастер — раздел «Индексирование» → «Статистика обходов» → вкладка «Ошибки». Ищите тип ошибки «Нет ответа от сервера» или «Превышен таймаут». Экспортируйте список в CSV для дальнейшего анализа.

1. cURL в терминале — быстрая ручная проверка конкретного URL:

curl -v --max-time 10 https://example.ru/problemnaya-stranitsa

Если соединение виснет до истечения 10 секунд — страница не отвечает. Флаг -v покажет, на каком этапе обрывается соединение.

---

Как исправить

Шаг 1. Определите причину. Таймаут может быть на уровне сервера (перегрузка, упавший воркер), приложения (зависший PHP-процесс, долгий запрос к БД) или сети (firewall блокирует краулер по IP). Проверьте логи сервера (/var/log/nginx/error.log, /var/log/apache2/error.log) в момент времени, когда зафиксирован сбой.

Шаг 2. Настройте таймауты на сервере. Пример для Nginx:

# nginx.conf
fastcgi_read_timeout 30s;
fastcgi_connect_timeout 10s;
proxy_read_timeout 30s;
keepalive_timeout 15s;

Шаг 3. Закройте проблемные URL от краулинга, пока чините. Добавьте в robots.txt:

Disallow: /problemnaya-kategoriya/

После устранения причины — уберите запрет.

Решения под популярные CMS:

• WordPress — установите плагин Query Monitor, чтобы найти тяжёлые запросы к БД. Включите объектный кеш (Redis/Memcached) через WP-config.
• 1C-Bitrix — в настройках главного модуля увеличьте BX_TIME_LIMIT и проверьте агенты Bitrix — зависший агент может блокировать поток обработки запросов.
• Tilda — страницы рендерятся на серверах Tilda, прямого доступа к конфигу нет. При систематических проблемах обращайтесь в поддержку; для внешних страниц используйте мониторинг через Яндекс.Вебмастер.
• Webflow — аналогично Tilda: инфраструктура управляется платформой. Проверьте кастомный код и встроенные скрипты — они могут блокировать рендер.

---

Типичные ошибки

1. Путают «нет ответа» с 404 или 500. Это разные проблемы с разными причинами. Страница без ответа — это сетевой или серверный сбой, а не логика приложения.

1. Игнорируют эпизодические таймауты. «Иногда зависает» — уже проблема. Краулер не перезванивает сразу: он запомнит URL как проблемный и снизит частоту обхода.

1. Блокируют IP поисковых роботов на firewall. Googlebot и Яндекс.Бот используют широкий диапазон IP. Блокировка по подозрению в нагрузке — типичная ошибка DevOps, которая обнуляет индексирование.

1. Не настраивают мониторинг доступности. Без внешнего uptime-мониторинга (Яндекс.Вебмастер, UptimeRobot) владелец узнаёт о проблеме через недели, когда позиции уже просели.

1. Исправляют URL, но не переподают в переобход. После устранения проблемы отправьте URL вручную: в GSC — «Проверить URL», в Яндекс.Вебмастере — «Переобход страниц».

---

Влияние на разные типы сайтов

Для интернет-магазинов проблема критична: карточки товаров и страницы категорий — это основной трафик. Если под нагрузкой в пиковое время (распродажи, праздники) сервер начинает давать таймауты, краулеры фиксируют массовые сбои именно тогда, когда коммерческие страницы важнее всего. PageSpeed Insights в этот момент покажет высокий TTFB, а данные Core Web Vitals в GSC ухудшатся.

Для контентных сайтов и медиа последствия проявляются медленнее, но накапливаются. Статьи с тысячами входящих ссылок, которые периодически не отвечают, теряют вес в глазах поисковика. SaaS-продуктам с закрытыми за авторизацией страницами таймауты на публичных лендингах особенно болезненны — это единственные страницы в индексе, и их недоступность сразу отражается на видимости. Для одностраничных лендингов один таймаут = потеря всего органического трафика на период сбоя.