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

Перед запуском сайта техническое SEO проверяют по пяти направлениям: поисковик может обойти сайт, понимает, какие страницы индексировать, видит содержимое без JavaScript, получает быстрые страницы и корректные метаданные. Большинство ошибок запуска — забытый запрет индексации со стенда, отсутствие редиректов со старых адресов и пустой HTML — исправляются за день, если проверить их заранее.

Ниже — чек-лист, которым мы пользуемся перед каждым релизом сайта.

Почему техническое SEO проверяют до запуска?

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

Что чаще всего ломается при запуске:

• на продакшен переезжает robots.txt или метатег noindex с тестового стенда;
• старые адреса отдают 404 вместо постоянного редиректа на новые;
• страницы рендерятся только в браузере, и робот видит пустой шаблон;
• у всех страниц одинаковые заголовки и описания;
• карта сайта не создана или содержит несуществующие адреса.

Как проверить, что сайт доступен для обхода и индексации?

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

Минимальный robots.txt для продакшена:

User-agent: *
Disallow: /admin/
Disallow: /account/
Disallow: /cart

Sitemap: https://example.com/sitemap.xml

Что проверить:

1. robots.txt не закрывает весь сайт и ссылается на карту сайта.
2. Карта сайта содержит только канонические страницы с кодом 200, у каждой — дата изменения.
3. Несуществующие страницы отдают код 404, а не 200 с текстом «не найдено».
4. Старые адреса перенаправляются постоянным редиректом 301 на новые, без цепочек.
5. У каждой страницы есть canonical, а у многоязычного сайта — hreflang для всех версий.
6. На продакшене нет noindex, а на тестовом стенде — есть, плюс закрытие паролем.

Как проверить, что робот видит содержимое?

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

Решение — серверный рендеринг или статическая генерация. Почему это важно и как устроено, мы подробно разбирали в статье SSR в Nuxt и SEO, а выбор между фреймворками — в статье Nuxt или Next.js.

Дополнительно проверьте:

• ссылки в меню, пагинации и карточках — настоящие <a href>, а не кнопки с обработчиком клика;
• у изображений заполнен alt;
• на странице один заголовок H1, структура H2–H3 отражает содержание.

Фото: Unsplash

Какие метаданные и разметку нужно заполнить?

Для каждой страницы нужно заполнить уникальные title и description, метатеги Open Graph для соцсетей и мессенджеров и структурированные данные schema.org там, где они уместны: организация, статьи, товары, частые вопросы.

Элемент	Что проверить	Типичная ошибка
title	Уникальный, до 60 символов, ключевая фраза в начале	Одинаковый на всех страницах
description	Уникальный, до 160 символов, отвечает на запрос	Пустой или скопированный из текста
Open Graph	Заголовок, описание, картинка 1200×630	Нет картинки — превью в мессенджерах пустое
canonical	Абсолютный адрес основной версии страницы	Указывает на главную с каждой страницы
hreflang	Все языковые версии ссылаются друг на друга	Ссылка на несуществующую версию
Структурированные данные	Проходят проверку валидатора	Разметка не совпадает с видимым текстом

Пример разметки статьи блога в формате JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Техническое SEO перед запуском сайта: чек-лист",
  "datePublished": "2026-11-11T10:00:00+00:00",
  "author": { "@type": "Organization", "name": "Nordex" }
}

Что проверить по скорости и мобильной версии?

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

Быстрые проверки перед запуском:

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

Инструменты для проверки

Lighthouse и PageSpeed Insights показывают лабораторные и полевые данные о скорости. Google Search Console и Яндекс Вебмастер стоит подключить до запуска: там видны ошибки индексации, проблемы мобильной версии и отчёты о скорости на реальных пользователях.

Что сделать в первые недели после запуска?

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

План на первые недели:

1. Отправить карту сайта в Google Search Console и Яндекс Вебмастер.
2. Проверить отчёты об ошибках сканирования и исключённых страницах.
3. Сравнить трафик по ключевым страницам с периодом до переезда.
4. Выгрузить 404 из логов сервера и добавить недостающие редиректы.
5. Проверить, как страницы выглядят в выдаче и в превью мессенджеров.

Коротко

• Проверьте robots.txt, карту сайта, коды ответов, редиректы, canonical и hreflang до запуска.
• Основной текст и ссылки должны быть в HTML-ответе сервера, а не появляться после JavaScript.
• У каждой страницы — уникальные title и description, Open Graph и уместная разметка schema.org.
• Проверьте Core Web Vitals и мобильную версию на ключевых шаблонах.
• Подключите панели вебмастеров заранее и следите за ошибками в первые недели.