SEO — работа над тем, чтобы поисковые системы могли обнаружить, обработать и правильно представить полезные публичные страницы. QA проверяет технические условия и договорённости продукта: доступность материалов, корректность метаданных, адресов и переходов. Это особенно важно после смены CMS, маршрутизации или способа рендеринга.
Зелёный SEO-аудит не гарантирует индексацию, место в выдаче и трафик. Поисковая система принимает собственные решения. Результат QA — доказательство того, что релиз не создаёт известных технических препятствий и страницы соответствуют согласованным правилам.
Как страница попадает в поиск
Полезно различать обнаружение URL, обход, обработку содержимого и индексацию. Страница может существовать, но не иметь доступных внутренних ссылок. Робот может знать адрес, но получать ошибку. Наконец, доступный документ может быть исключён из индекса или выбран как дубликат другого.
Поэтому вопрос «почему статьи нет в поиске» нельзя решить проверкой одного meta-тега. Сначала установите, какая именно стадия вызывает сомнение, а затем собирайте подтверждения через HTTP, содержимое страницы и инструменты поисковой системы.
Title и description
Title задаёт название документа и помогает понять его назначение во вкладке и поиске. Проверьте соответствие содержимому, язык, отсутствие шаблонных заглушек и нежелательных дублей между разными статьями. После клиентского перехода название должно обновляться вместе со страницей.
Meta description кратко описывает материал. Google может использовать его для сниппета, но может сформировать текст иначе. Не устанавливайте универсальный критерий «строго N символов»: фактическое отображение зависит от поисковой системы и контекста. Лучше проверить смысл, отсутствие обрезанного шаблона, HTML-мусора и чужого описания.
Что действительно делают robots-правила
Meta robots и HTTP-заголовок X-Robots-Tag могут управлять индексацией. Для публичной статьи неожиданный noindex после релиза — серьёзный сигнал. Проверьте одновременно HTML и заголовки: ограничение может добавляться инфраструктурой, даже если CMS показывает правильную настройку.
Robots.txt регулирует обход и не служит надёжной защитой приватных данных. Заблокированный URL всё ещё может появиться в выдаче без содержимого. Кроме того, если робот не может обойти страницу, он может не увидеть её noindex. Для закрытого контента нужны механизмы доступа, а не надежда на поведение робота.
Canonical и дубли
Canonical — указание предпочтительного адреса для одинаковых или очень похожих страниц. Это сигнал для поисковой системы, а не обязательная команда. Ошибка шаблона, который у всех статей указывает canonical на главную, может повредить обнаружению самостоятельных материалов.
Проверьте домен, протокол, путь и согласованность с редиректами, sitemap и внутренними ссылками. Для разных языковых версий правила отдельно обсуждают с SEO-специалистом: перевод не следует автоматически объявлять дубликатом оригинала. Случайное наследование адреса тестового стенда — типовой релизный дефект.
HTTP-ответы и переходы
Существующая публичная страница должна отдавать предусмотренный успешный ответ. Несуществующая статья не должна маскироваться под полезный документ с кодом 200 и текстом «ничего не найдено». Такое поведение называют soft 404, и оно затрудняет понимание состояния ресурса.
Проверьте постоянные перенаправления после смены адреса, отсутствие циклов, длинных цепочек и случайного перехода всех удалённых страниц на главную. Код и целевой адрес должны соответствовать миграционному плану. Открытие страницы в браузере не показывает, сколько промежуточных ответов пришлось пройти.
Содержимое, рендеринг и ссылки
Сравните исходный HTML, итоговый DOM и видимый материал. Если текст появляется только после JavaScript, проверьте, что процесс рендеринга не зависит от входа, запрещённых ресурсов или действия, которое поисковый робот не обязан выполнять.
Контрольные точки — заголовок материала, основное содержимое, доступные ссылки на связанные страницы и изображения с подходящими текстовыми альтернативами. Проверяйте переход по прямому адресу, а не только навигацию из уже загруженного приложения. Клиентский переход может скрыть ошибку серверной маршрутизации.
Практический пример: релиз базы знаний
Пусть команда переносит статьи на новый домен. Для каждой выбранной статьи известны новый адрес, старый адрес и ожидание публичной индексации.
- 1.Откройте новый URL без авторизации и изучите HTTP-ответ. Ожидается доступная статья, корректный статус и отсутствие случайного noindex в HTML и заголовках.
- 2.Сравните title, description и canonical с карточкой CMS. Ожидаются данные именно этой статьи и рабочий адрес нового домена.
- 3.Откройте старый URL. Ожидается предусмотренный постоянный redirect прямо на соответствующую новую статью.
- 4.Проверьте robots.txt, sitemap и внутреннюю ссылку из раздела. Ожидается согласованная политика: публичный материал не исключён случайным правилом стенда.
- 5.После публикации используйте доступный команде URL Inspection в Search Console. Ожидается возможность оценить обработку конкретного адреса; появление в выдаче не обещается к определённой минуте.
Как искать проблему инструментами
Network показывает статусы, redirect и X-Robots-Tag; просмотр исходного ответа — серверный HTML; Elements — DOM после выполнения скриптов. Сканер удобен для массового поиска дублей и неправильных ссылок, но отдельный адрес всё равно нужно воспроизвести вручную.
В отчёте указывайте точный URL, тип страницы, окружение, фактическое значение и согласованное ожидание. Формулировка «canonical ведёт на staging» проверяема; «SEO плохое» не даёт разработчику конкретного действия.
Типичные ошибки и выводы
Ошибки — считать robots.txt защитой, требовать индексацию сразу после релиза и проверять только главную. Ещё одна — переносить настройки тестового стенда на production без проверки итоговых ответов.
Минимальный SEO-набор QA покрывает HTTP, обнаружение ссылок, метаданные, ограничения и адреса. Он помогает предотвратить техническую потерю публичных страниц и даёт SEO-специалисту качественные данные для дальнейшей диагностики.