Диагностика сайта: от симптома к причине

Диагностика сайта по-врачебному: от симптома — тормоза, падение трафика, письма в спаме, недоступность, предупреждения браузера — к реальной причине.

Инфраструктура · Опубликовано: 8 октября 2026 г. · 5 мин чтения · Дмитрий Орлов

Диагностику сайта никто не проводит просто так. Всё начинается с жалобы: «сайт тормозит», «трафик упал вдвое», «клиенты пишут, что счета попадают в спам», «Chrome показывает предупреждение». Жалоба — это симптом, а у одного симптома бывает пять совершенно разных причин. Хорошая диагностика идёт от симптома к короткому списку подозреваемых, проверяет каждого измерением и только потом что-то меняет.

Ниже — пять жалоб, которые мы слышим чаще всего, их обычные причины и способы подтвердить диагноз.

«Сайт тормозит»

Сначала уточните: тормозит у кого и в какой момент? За этой фразой прячутся три разные проблемы.

• Сервер долго отвечает. Время до первого байта больше 800 мс значит, что HTML генерируется медленно: нет кеша страниц, тяжёлые запросы к базе, перегруженный хостинг. Медленные все страницы, даже крошечные.
• Страница тяжёлая. Первый байт приходит быстро, но главная картинка весит 2 МБ, шрифты и скрипты блокируют отрисовку, и LCP уходит за 2,5 с. Типично для лендингов.
• Повторные визиты тоже медленные. Статика отдаётся без Cache-Control, и браузер на каждой странице заново качает те же CSS и JS. Подробнее — в статье про HTTP-кеширование.

Заодно проверьте сжатие (HTML и скрипты без gzip или Brotli) и HTTP/2. Цепочка редиректов на каждой внутренней ссылке добавляет лишний круг до сервера.

«Упал трафик»

Отделите резкое падение от медленного сползания. Резкое падение после релиза почти всегда имеет техническую причину:

• на прод уехал robots.txt со стейджинга с Disallow: / — проверьте, что на самом деле написано в robots.txt;
• noindex попал в шаблоны, которые должны индексироваться: карточки товаров, категории, статьи;
• canonical указывает на другой хост, на HTTP или на главную — разберитесь с каноническими адресами;
• после переезда старые URL отдают 404 вместо 301 на новый адрес;
• под нагрузкой сайт начал отвечать роботам Яндекса и Google ошибками 5xx.

Медленное сползание за несколько месяцев обычно не техническое: конкуренты, контент, изменения алгоритмов. Внешняя диагностика его не объяснит, но за минуты исключит технические причины.

«Письма уходят в спам»

Почту с вашего домена оценивают по DNS-записям, которые к самому сайту отношения не имеют, — поэтому о них и забывают.

1. SPF перечисляет серверы, которым разрешено отправлять почту от имени домена. Если записи нет или появилась вторая v=spf1, проверка ломается.
2. DKIM подписывает письма; настраивается у почтового провайдера.
3. DMARC говорит получателю, что делать с письмами, не прошедшими проверку. Без него крупные почтовики всё чаще считают письма подозрительными.
4. Репутация. Если домен или его IP попали в DNS-блоклист, не помогут даже идеальные записи. Отчёт показывает результат проверки по DNS-блоклистам.

Подробности и примеры записей — в статье об аутентификации почты.

«Сайт недоступен»

Прежде чем ругать хостинг, исключите всё, у чего есть срок годности:

• TLS-сертификат. Автопродление ломается тихо: поменяли DNS, добавили правило файрвола, кончилось место на диске. В один день браузеры показывают ошибку на весь экран.
• Домен. Просроченная карта или старая почта у регистратора — и домен перестаёт резолвиться.
• DNS. Переехали NS-серверы, удалили запись, опечатка в A-записи.

Всё это видно снаружи за дни и недели до проблемы — см. статью о сроках действия. Если ничего из этого не подходит, а сервер отвечает 5xx или не отвечает вовсе, причина на сервере: логи, ресурсы, последний деплой.

«Браузер показывает предупреждение»

• «Не защищено» в адресной строке — страница или форма загружены по HTTP, либо HTTPS-страница тянет скрипты и картинки по HTTP. Это смешанный контент.
• Ошибка сертификата на весь экран — истёк срок, не совпадает имя хоста или не хватает промежуточного сертификата. Последнее коварно: десктопный Chrome часто достраивает цепочку сам, а Android и API-клиенты падают. Проверьте цепочку сертификатов.
• «Сайт может быть опасен» — домен попал в списки безопасного просмотра, обычно после взлома. Это инцидент безопасности, а не ошибка настройки.

Как провести диагностику с SiteScan

Проверка снаружи закрывает большинство подозреваемых разом: время ответа и вес страниц, сжатие и кеширование, robots.txt, noindex и canonical, битые ссылки, сроки сертификата и домена, SPF, DMARC и блоклисты. Чего она не видит — это логи сервера и данные Яндекс Вебмастера и Search Console, поэтому сочетайте одно с другим.

Запустите проверку проблемного сайта, откройте категорию, которая соответствует симптому, и начните с критичных и серьёзных находок. После исправления пересканируйте: диагноз считается снятым, когда причина пропала из отчёта, а не когда кажется, что всё починили.