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

Сайт может работать идеально: быстро грузиться, красиво выглядеть, удобно оформленный код. Но если поисковые роботы не могут его прочитать — он практически не существует. Техническое SEO в веб-разработке — это не метафора и не «что-то для маркетологов». Это конкретные файлы, теги и метрики, которые либо помогают Google и Яндекс находить ваш контент, либо мешают.

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

1. Доступность для краулеров

Это база. Если роботу закрыт доступ — всё остальное бессмысленно.

robots.txt и XML-карта. Убедитесь, что в robots.txt нет строки Disallow: / на боевом сайте. Такое бывает: для тестовой площадки закрыли всё, а потом выкатили на прод с тем же файлом. Рядом с robots.txt должен лежать sitemap.xml — актуальный и автоматически генерируемый. Забыть отправить карту в Google Search Console — значит оставить её без работы.

Канонические теги. На каждой странице — свой само-ссылающийся <link rel="canonical" href="..." />. Это убирает проблему дублей: когда страница доступна по разным адресам с параметрами отслеживания, поисковик будет знать, какой вариант индексировать. Укажите канонический прямо на странице — так надёжнее.

2. Core Web Vitals и скорость

Это уже не только про SEO, но и про конверсию. Пользователи уходят со страницы, которая грузится дольше пары секунд. Поисковики это видят и понижают в выдаче.

Ключевых метрик три. Собрал их в таблицу — так нагляднее.

Largest Contentful Paint (LCP). Главный контент (заголовок, картинка, текст) должен появляться на экране не позже 2,5 секунды. Частая проблема — «тяжёлые» изображения в шапке. Используйте современные форматы .webp или .avif и не забывайте указывать высоту и ширину картинки — это тоже ускоряет рендер.

Interaction to Next Paint (INP). Это время отклика интерфейса. Если при клике страница подвисает — метрика плохая. Причина чаще всего в длинных JavaScript-задачах в главном потоке. Разбивайте скрипты на части, используйте requestIdleCallback — и тайминг уложится в 200 мс.

Cumulative Layout Shift (CLS). Когда страница «прыгает»: подгрузился баннер и сдвинул текст, или картинка без размеров «развернулась» уже после загрузки. Резервируйте место под динамические элементы, рекламу, изображения с ленивой загрузкой. Тогда CLS останется ниже 0.1.

3. Мета-теги и семантическая структура

Недостаточно просто отдать роботу HTML. Надо явно показать, где заголовок, где основной текст, а где подвал.

Title и description. Для каждого роута — свои уникальные <title> и <meta name="description">. Генерируйте их динамически на стороне сервера или в фронтенде при рендере. Однотипные заголовки на всех страницах — одна из причин, почему сайт не попадает в топ: поисковик не видит разницы между страницами.

Семантические теги. Ими пренебрегают чаще, чем хочется думать. А ведь <header>, <main>, <article>, <footer> — это не просто «данные теги». По ним поисковый робот понимает структуру документа. Проверьте, что на странице ровно один <main>, а <article> используется для постов, а не для всего подряд.

4. Как не забыть всё это

Техническое SEO нельзя делать один раз в квартал — оно ломается каждый раз, когда вы выкатываете новую версию. Один неаккуратный коммит — и весь сайт исчезает из индекса. Поэтому:

• проверяйте robots.txt и sitemap вручную перед каждым релизом;
• прогоняйте уровень Core Web Vitals до и после деплоя, чтобы поймать деградацию сразу;
• включите проверку уникальности title и description в автотесты;
• быстрый аудит страницы через панель разработчика — пять минут работы. Это дёшево по сравнению с месяцем восстановления трафика.

Добавьте этот список в описание пул-реквеста — и пусть каждый участник команды проходит по нему, прежде чем отправлять код в прод.

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