SEO-чек-лист перед запуском сайта: что проверить

Запуск сайта редко срывается из-за одного большого дефекта. Чаще неприятности складываются из мелочей: на тестовом домене забыли noindex, старые адреса ведут в 404, форма отправляет заявку, но цель не фиксируется, а мобильная версия отличается от той, которую согласовали на широком экране.

Этот чек-лист нужен не для формальной галочки «SEO сделано». Его задача — в день запуска сохранить управляемость: поисковый робот получает правильную версию страниц, пользователь не упирается в сломанный сценарий, а команда видит, что происходит с трафиком и заявками.

До проверки зафиксируйте границы релиза

Сначала составьте список того, что действительно выходит в продакшен:

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

Без такого реестра проверка быстро превращается в случайные переходы по меню. Удобнее работать с таблицей: URL, назначение, ожидаемый код ответа, canonical, статус индексации, ответственный и результат проверки.

1. Домен, HTTPS и ответы сервера

У сайта должна быть одна основная версия адреса. Варианты с http, https, www и без www не должны жить как четыре самостоятельных сайта.

Проверьте:

сертификат действует и корректно покрывает домен;
все альтернативные версии ведут одним постоянным редиректом на основную;
внутренние ссылки сразу используют конечные HTTPS-адреса;
важные страницы отвечают 200 OK;
удалённые страницы возвращают настоящий 404 или 410, а не мягкую страницу ошибки с кодом 200;
сервер не выдаёт случайные 403, 429 или 5xx;
редиректы не образуют цепочки и циклы.

Один переход старого URL на новый — нормальная миграция. Путь HTTP → HTTPS → новый раздел → слеш на конце уже создаёт лишнюю работу и для пользователя, и для робота.

2. Управление индексированием

На тестовых копиях обычно ставят запрет индексации. Перед релизом его надо снять только с публичного сайта, не открывая при этом staging.

Проверьте три места:

robots.txt;
<meta name="robots"> в HTML;
HTTP-заголовок X-Robots-Tag.

Важно понимать разницу: robots.txt управляет обходом URL, а noindex — возможностью хранить документ в поисковом индексе. Запрещённый в robots URL робот может не обойти и, следовательно, не увидеть метатег. Для публичных страниц не должно быть случайного сочетания запретов.

Отдельно составьте список страниц, которые действительно не нужны в поиске: служебные результаты, технические формы, корзина, личный кабинет, политика обработки данных или дубли с параметрами. Не закрывайте весь раздел только потому, что в нём нашлась одна техническая страница.

3. Canonical и единая версия URL

Карта проверки домена, индексирования, canonical и аналитики — Технические сигналы должны указывать на одну и ту же основную версию каждого URL.

Для каждой индексируемой страницы нужен согласованный набор сигналов:

страница открывается по тому URL, который заявлен основным;
rel="canonical" указывает на этот же канонический адрес;
этот адрес находится в sitemap;
внутренние ссылки ведут на него же;
альтернативные версии либо редиректят, либо корректно канонизированы.

Самоссылочный canonical не является обязательным волшебным тегом, но помогает явно зафиксировать предпочитаемую версию. Он особенно полезен, если сайт получает URL с UTM-метками, фильтрами и другими параметрами.

Не ставьте canonical со всех похожих услуг на главную: так вы сообщите поисковику, что отдельные страницы не являются самостоятельными.

4. Sitemap и обнаруживаемость страниц

В XML-карту включают только канонические URL, которые:

отвечают 200;
разрешены к индексации;
не являются редиректами;
действительно нужны в поиске.

Файл должен открываться без авторизации и ошибок, а путь к нему — быть указан в robots.txt и добавлен в панели поисковых систем. lastmod меняют после содержательной правки конкретной страницы, а не при каждой сборке всего проекта.

Однако sitemap не заменяет обычные ссылки. Важная страница должна быть достижима из меню, раздела, хлебных крошек или тематических материалов. Если URL существует только в XML, структура сайта остаётся слабой.

Для локального бизнеса в этот же реестр добавьте карточки Яндекс.Бизнеса, 2ГИС и других справочников. Название, телефон, адрес или зона обслуживания должны совпадать с сайтом; подробная последовательность собрана на странице про локальное SEO.

5. Метаданные и содержимое

Просмотрите не только исходники шаблонов, но и готовый HTML на боевом домене.

Для каждой ключевой страницы проверьте:

один понятный H1;
осмысленный title, который описывает конкретную страницу;
description без механического перечисления ключей;
язык документа и кодировку;
корректный viewport;
видимый основной текст;
уникальную задачу относительно соседних URL;
информативные alt у смысловых изображений;
пустой alt="" у декоративных изображений;
отсутствие заглушек, тестовых цен, lorem ipsum и внутренних комментариев.

Не пытайтесь сделать все заголовки «уникальными» перестановкой одних и тех же слов. Сначала убедитесь, что сами страницы решают разные задачи.

6. Мобильная версия

Google использует мобильную версию контента для индексирования и ранжирования. Поэтому мобильная проверка — не уменьшенная копия десктопной приёмки.

Пройдите основные сценарии на реальном телефоне:

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

Проверьте несколько ширин, а не одну картинку из эмулятора.

7. Скорость и стабильность интерфейса

Перед запуском важно не «выбить сто баллов», а убрать реальные препятствия.

Смотрите:

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

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

8. Формы, аналитика и заявки

Сайт может прекрасно индексироваться и при этом терять обращения. Протестируйте каждую форму от начала до конца.

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

Сделайте тест с мобильного интернета и другим браузером. Запись «форма работает у разработчика» не заменяет проверку боевого маршрута.

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

9. Структурированные данные и социальные превью

Разметка Schema.org должна описывать то, что реально видно на странице. Проверьте синтаксис и смысл:

организация и сайт — с актуальными контактами;
хлебные крошки — с реальными URL;
статья — с фактическими автором и датами;
услуга — без вымышленных рейтингов и отзывов;
FAQ — только если вопросы и ответы действительно опубликованы.

Для Open Graph и карточек мессенджеров нужны корректные title, description, URL и изображение. Это не прямой механизм индексации, но плохое превью снижает доверие к ссылке.

10. Миграция со старого сайта

Если меняются URL, подготовьте карту соответствий до переключения домена.

каждому ценному старому URL назначен максимально близкий новый;
редирект ведёт сразу на конечную страницу;
удалённые материалы не отправляются массово на главную;
старые внутренние ссылки заменены;
новый sitemap содержит только новые канонические URL;
старые адреса проверены после запуска;
аналитика и панели вебмастеров продолжают собирать данные.

Сохраните старый sitemap и выгрузку посещаемых страниц. Они помогут найти URL, которые не попали в новую навигацию.

Первые 72 часа после запуска

Мониторинг сайта в первые дни после запуска — После релиза контролируют доступность, обход поисковыми роботами и реальные конверсии, а не только внешний вид страниц.

В день релиза работа не заканчивается. Нужен короткий период наблюдения.

Сразу после переключения: проверить главную, ключевые услуги, формы, robots, sitemap, canonical и редиректы.

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

Через два-три дня: проверить статусы важных URL в панелях, неожиданные 404, выбранные canonical и первые данные производительности.

Не отправляйте все страницы на переобход каждый час. Если базовая конфигурация верна, sitemap и внутренние ссылки дадут поисковику устойчивый маршрут.

Короткий критерий готовности

Сайт готов к запуску, когда команда может ответить на три вопроса:

Какая версия каждого важного URL является основной?
Может ли пользователь выполнить целевое действие без препятствий?
Увидим ли мы ошибку, если после запуска что-то перестанет работать?

Если ответы подтверждены тестами, релиз становится контролируемым. Когда сайт большой или переживает миграцию, полезно провести технический SEO-аудит до переключения, а не разбирать потерянные страницы после него.

Источники и документы

Готовите новый сайт или миграцию? Проверим релизный контур до переключения домена и зафиксируем результат по каждому URL.