Техническое SEO: чек-лист проверки сайта и релиза

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

Перед релизом проверьте тестовую среду; после выпуска повторите проверки на рабочем домене. Запреты тестового сайта не должны случайно перейти на публичные страницы, а доступ к тестовой среде не следует защищать только robots.txt.

Запрет обхода не равен исключению из поиска. Чтобы прочитать noindex или canonical, робот должен получить страницу. Дополнительные пояснения: robots.txt и sitemap.xml.

Google не даёт общего обещания, что 410 удалит страницу быстрее 404. Редирект 302 тоже нельзя описывать как автоматическое обнуление всех сигналов. Проверяйте конечные адреса, циклы и лишние переходы.

Сначала сравните содержание. Метки перехода могут давать дубль; пагинация или полезный фильтр могут содержать другой набор товаров. Решение о canonical, индексации или ограничении обхода принимают по задаче, а не по наличию вопросительного знака в URL.

Учебный пример: сортировка той же категории и отдельная подборка для конкретного применения внешне обе используют параметры. Первой может подойти канонизация дубля, второй — самостоятельная страница с понятной ценностью. Сначала проверьте спрос, ассортимент и содержание.

Сравните исходный и отрисованный HTML, особенно на JavaScript-сайте. Важный текст не должен пропадать из-за недоступного API, обязательного входа или ошибки скрипта. Откройте маршрут напрямую и через навигацию.

На телефоне проверьте чтение, меню, таблицы и форму. Основное содержание не должно теряться при адаптации. Google использует мобильную версию для индексирования; не выдавайте это за автоматически идентичное устройство систем каждого другого поисковика.

Проверьте HTTPS, сертификат и загрузку ресурсов. Защита приватных данных требует отдельной проверки доступа — одного сертификата недостаточно.

Используйте лабораторные измерения для диагностики, полевые — для оценки реальных посещений. Хорошие пороги Core Web Vitals на 75-м процентиле: LCP не больше 2,5 секунды, INP не больше 200 мс, CLS не больше 0,1. Подробный порядок — диагностика скорости.

Не откладывайте изображение первого экрана без причины, резервируйте место динамическим элементам, проверяйте тяжёлые задачи JavaScript. После оптимизации повторите ключевые действия: быстрый интерфейс с неработающей формой не проходит приёмку.

Проверьте существующие данные темы и плагинов. Организация, автор, товар, цена и отзывы должны соответствовать видимым сведениям. Валидный JSON не доказывает истинность значения.

Поддержка типа Schema.org и доступность поисковой функции — разные проверки. Например, FAQPage можно описать в словаре, но FAQ rich results Google прекращены в мае 2026 года. Для отдельных типов используйте текущие требования и живую проверку страницы. Подробнее — структурированные данные.

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

В задаче разработчику укажите URL, наблюдаемое поведение, ожидаемый результат и контроль после исправления. Например: «при прямом открытии несуществующего маршрута сервер возвращает 200; нужен корректный ответ отсутствующей страницы, при этом существующие маршруты должны сохранить доступность».

После изменения повторите выборку и массовую проверку затронутого шаблона. Периодичность полного аудита зависит от частоты релизов и риска; фиксированный квартальный срок не заменяет проверку после существенного изменения.