Проверка сканерами. Интерпретация данных
Почти любой SEO-сканер после проверки сайта выдаёт десятки «критических ошибок».
На практике часть из них действительно важна. Но часть — ложные срабатывания, особенности методологии или просто отсутствие понимания контекста.
Разберём несколько примеров на реальном сайте.
Как и все, для сбора первичных данных я тоже использую внешние сканеры. Но почти каждый раз значительная часть «ошибок» после ручной проверки оказывается совсем не тем, чем кажется в отчёте.
1. «Страницы-сироты» (на которые никто не ведёт)
Сканер:
На сайте есть страницы, на которые нет внутренних ссылок.
Проверяю. Ссылки есть:
- В анонсе на главной блога
- В блоке «Читайте также» в других статьях
- Плюс ручные ссылки по тексту
Почему сканер их не увидел?
Не потому что сайт тормозит. А потому что у сканера своя логика.
Он может:
- Игнорировать ссылки в определённых блоках (например, «похожие статьи»)
- Иметь лимит на количество ссылок со страницы
- Не считать ссылкой то, что не вписано в его шаблон «идеального сайта»
Вывод:
Ссылки есть. Сканер их просто не заметил. Некоторые сканеры также плохо обрабатывают динамически формируемые блоки и JS-элементы. Проблема не в сайте, а в алгоритме проверки. Сканер работает по своим правилам. Он может игнорировать определённые блоки, обрезать количество ссылок или просто не туда смотреть. Сайт здесь ни при чём.
2. «Ошибка 404 на HTTP-версии»
Сканер пишет:
http://b2btext.ru/ возвращает 404. Это ошибка. Нужен редирект на HTTPS.
Смотрю в заголовки: Strict-Transport-Security: max-age=31536000; includeSubDomains
Это HSTS. Браузер запоминает, что сайт — только HTTPS, на целый год.
Для большинства пользователей браузер после первого посещения автоматически использует HTTPS благодаря HSTS.
Сканеры, которые не понимают HSTS, видят 404 и паникуют.
Вывод:
Да, формально редиректа с http://b2btext.ru на HTTPS нет. HSTS снижает практическую значимость отсутствия HTTP→HTTPS редиректа для пользователей. Сканер, который игнорирует HSTS, увидит 404 и поднимет панику. На практике проблема не существует.
«Редирект c WWW не настроен»
Сканер:
Перенаправление не настроено.
Редирект — предпочтительный способ склейки, но не единственный. При rel=canonical поисковики понимают основной вариант. Ошибки нет, просто подход чуть менее строгий. Сканер же подаёт это как «критическую ошибку», хотя на деле сайт индексируется нормально.
Сканер же настаивает на «единственно верном» варианте с 301 редиректом.
Вывод:
Попытка подать один из подходов как единственно допустимый.
3. «Сайт недоступен из разных регионов»
Проблема 1: Fail2ban (не мой случай)
Иногда бывает, что SEO-сканер пишет «сайт недоступен» или «ошибка соединения». И одна из причин — Fail2ban.
Если на сервере настроен Fail2ban для веб-логов, он может временно заблокировать IP сканера, который слишком агрессивно стучится в несуществующие страницы или генерирует много 404. С точки зрения сканера — сайт «упал». А по факту — сработала защита.
Но в моём случае это не так.
На данном сайте количество потенциально уязвимых точек минимально, поэтому Fail2ban для веб-логов отдельно не использовался.
Однако если вы используете CMS (WordPress, Bitrix, OpenCart) и заметили, что сканеры периодически «теряют» ваш сайт — проверьте настройки Fail2ban. Возможно, он просто отлавливает их как ботов.
А я пошел дальше — у меня другая история.
Проблема 2: Таймаут у одного провайдера из 25
Мониторинг с 25 точек по Москве и регионам (Владивосток, Иркутск, Екатеринбург, Воронеж и др.).
Результат:
- 24 точки — сайт открылся. Время ответа: от 0,03 до 0,2 секунды.
- 1 точка (Москва, юго-восток) — таймаут, сервис не ответил за 8 секунд.
Что это значит на самом деле
Сервер один и тот же для всех точек.
Если бы он лежал — не работали бы все 25 точек.
Что там происходит — непонятно. Картина выскакивает регулярно. По виду — маршрутизатор на стыке сетей одного из магистральных.
Вывод
«Недоступен в регионе» в отчёте сканера — не равно «сайт не работает».
Проблема одной точки замера, а не вашего хостинга. Хотя, хостинга тоже.
Проверяйте сами: если сайт летает из 24 точек из 25 — проблема не у вас.
Проблема 3: Сканер не понимает HSTS
«Код ответа сервера — 404. Не успешный запрос»
Сканер пишет:
http://b2btext.ru → 404 Not Found. Не успешный запрос.
А сам же выше в этом отчёте пишет:
SSL-сертификат есть, сайт доступен по HTTPS.
Вопрос: зачем вы вообще проверяете HTTP, если у вас включён HSTS?
Это ровно тот же кейс, что выше. Сканер не понимает HSTS и выдаёт «ошибку».
Проблема 4
Meta-Tag: не запрещает индексацию. Robots.txt: не запрещает индексацию.
То есть: «Доступа нет, но индексация разрешена». Логики ноль.
Почему так:
Бот ходит на http://, получает 404 и делает вывод «сайт недоступен». Хотя на https:// всё работает.
Ещё один пример непонимания контекста.
4. «Разные конечные URL»
Сканер проверил варианты домена:
| URL | Итоговый URL |
|---|---|
| http://b2btext.ru/ | 404 |
| https://b2btext.ru/ | 200 |
| http://www.b2btext.ru/ | 301 → 200 |
| https://www.b2btext.ru/ | 200 |
И выдал:
В некоторых случаях переадресация происходит на разные конечные URL. Рекомендуется сделать единый вариант.
Обратите внимание: https://b2btext.ru/ и https://www.b2btext.ru/ — это разные URL. Сайт доступен и с www, и без.
У меня прописан rel=canonical, который указывает поисковикам, какой вариант основной. Это современный и гибкий подход, который понимают Яндекс и Google.
rel=canonical помогает поисковым системам понять предпочтительный URL, хотя классическим вариантом всё же считается 301-редирект.
Вывод:
Сканер трактует свой шаблон «единственно верного» варианта. Но в реальности работает и так. Сканер преувеличивает важность склейки. Ошибки нет, но предпочтительный метод — 301.
5. «Отсутствует Content-Security-Policy»
Сканер по безопасности выдал оценку A, но написал:
Missing header: Content-Security-Policy. Это защита от XSS.
У меня подключены шрифты с cdnjs.cloudflare.com и скрипты Метрики. Чтобы прописать строгий CSP и ничего не сломать, нужно изрядно повозиться.
CSP — это хорошо. Но не критично для сайта-визитки, где нет платежей и личных кабинетов. Для небольшого информационного сайта отсутствие CSP не является критическим риском, хотя наличие политики безопасности считается хорошей практикой.
Вывод:
Сканер находит «идеальный» вариант, но не учитывает, что ресурсы разработчика не бесконечны. Правка не даст реального выигрыша, а времени съест много.
6. «Микроразметка Open Graph не найдена»
Сканер:
Open Graph не найдена.
Вопрос: а она вам нужна? Вы продвигаетесь через соцсети? Если нет — это не ошибка, а просто отсутствие ненужного функционала.
Сканер же пишет как «недочёт».
Вывод:
Open Graph не имеет значения для SEO. Если вы не продвигаете сайт в соцсетях, его отсутствие — не ошибка, а осознанный выбор.
Вывод (как я это вижу)
Сканеры SEO-аудита — инструмент, а не истина.
Большинство из них либо слишком пристрастны (как и должен работать аудитор), либо преследуют свои коммерческие интересы (как аудитор работать не должен).
Они полезны, чтобы заметить очевидное: битые ссылки, отсутствие robots.txt, дубли мета-тегов.
Но они не умеют: понимать HSTS, учитывать блокировки безопасности, отличать реальную ошибку от ложного срабатывания, оценивать, стоит ли вообще что-то исправлять.
Поэтому любую выгрузку сканера обрабатываем вручную.
P.S.
В этой статье я использовал реальные выгрузки с моего сайта. Если вы узнали в «сканере» свой любимый сервис — не расстраивайтесь. Он всё равно лучше, чем ничего. Просто не верьте ему на 100%. Данный сайт разумеется не является идеалом и примером технической и SEO-оптимизации. Это просто баланс необходимых инструментов для конкретных задач, без лишнего перфекционизма.
P.P.S.
Аудит заказывать надо. Но читать их — с холодной головой и знанием матчасти.