Чек-лист SEO-оптимизации сайта перед запуском

Запуск нового сайта — это всегда точка невозврата. Первое сканирование поисковым роботом, первая индексация, первое впечатление алгоритмов Google и Яндекса о том, что перед ними за ресурс. Если на этом этапе допущены технические ошибки, сайт может месяцами «выкарабкиваться» из последствий: терять позиции, которые никогда не занимал, попадать в фильтры за дублированный контент или просто оставаться невидимым для поисковых систем при формально работающем интерфейсе.

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

Эта статья пригодится, если вы:

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

Почему технический аудит обязателен именно перед запуском, а не после

Первая мысль, которая часто возникает у владельцев бизнеса: «Запустим сайт, а потом уже займёмся SEO». Логика понятна — хочется быстрее показать продукт клиентам, а оптимизация кажется второстепенной задачей, которую можно докрутить позже. На практике это одна из самых дорогих ошибок в цифровом маркетинге, и вот почему.

Первое сканирование формирует первое впечатление поисковой системы о сайте. Google и Яндекс индексируют сайт не мгновенно и не одним проходом — они постепенно строят карту ресурса, оценивают его структуру, скорость, качество контента и техническое состояние. Если в момент первого сканирования робот натыкается на десятки битых ссылок, дублирующиеся страницы без канонических тегов или закрытый через robots.txt раздел с ключевым контентом, это закладывается в базовую оценку сайта. Изменить её потом можно, но это займёт недели и месяцы переиндексации — тогда как исправить ошибки до запуска можно за пару дней.

Технический долг накапливается и переносится на контент. Если сайт технически нездоров — со временем на него наслаиваются статьи в блоге, новые страницы каталога, лендинги под рекламные кампании. Каждая новая страница наследует те же проблемы: неправильную структуру заголовков, отсутствие микроразметки, медленную загрузку. В результате через год технический долг приходится разгребать не на 10 страницах, а на 500, и стоимость исправления вырастает в разы.

Часть ошибок физически невозможно исправить «по-тихому» после индексации. Например, если сайт индексируется одновременно на https://site.ru и https://www.site.ru, или на версиях с завершающим слэшем и без него, поисковики какое-то время воспринимают их как разные сайты и распределяют между ними вес ссылок и трафик. Склеить зеркала можно, но это требует настройки редиректов, ожидания переиндексации и — часто — временной просадки позиций.

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

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

1. Индексация: robots.txt, sitemap.xml, канонические теги

Это фундамент. Если поисковая система не может корректно просканировать и проиндексировать сайт, всё остальное — скорость, контент, микроразметка — не имеет значения, потому что до пользователя сайт просто не дойдёт через органический поиск.

Что проверять в robots.txt

Файл robots.txt находится по адресу site.ru/robots.txt и указывает поисковым роботам, какие разделы сканировать, а какие — нет. Типичная ошибка при переносе сайта с тестового домена на боевой — забыть снять директиву Disallow: /, которая полностью закрывает сайт от индексации. Проверить это нужно вручную, открыв файл в браузере, а не полагаться на память разработчика.

Что смотреть конкретно:

• нет ли строки Disallow: / или Disallow: /* без исключений — это полностью блокирует индексацию;
• закрыты ли от индексации служебные разделы: админ-панель, страницы поиска по сайту, корзина, личный кабинет, страницы фильтров с параметрами (?sort=, ?filter=);
• указана ли директива Sitemap: со ссылкой на актуальный sitemap.xml;
• если сайт мультиязычный или мультирегиональный — не блокируются ли случайно языковые версии.

Проверить, как робот интерпретирует файл, можно через Google Search Console → «Файлы Sitemap» и инструмент «robots.txt Tester» (доступен через старую версию Search Console по прямой ссылке, либо через сторонние валидаторы вроде technicalseo.com/tools/robots-txt). Для Яндекса — раздел «Индексирование» → «robots.txt» в Яндекс.Вебмастере, который показывает, какие правила распознаёт именно Яндекс (у него местами своя логика обработки директив, отличная от Google).

Что проверять в sitemap.xml

Карта сайта — это список URL, которые вы явно предлагаете поисковику проиндексировать. Частая ошибка — генерировать sitemap.xml автоматически на CMS, не проверяя, что реально в него попадает.

Чек-лист по sitemap.xml:

• файл доступен по адресу site.ru/sitemap.xml и открывается без ошибок 404 или 500;
• в карте сайта нет URL, которые ведут на 404, редиректы или закрыты в robots.txt — такие несостыковки Google Search Console помечает как «ошибки» в разделе «Файлы Sitemap»;
• в sitemap.xml нет служебных, технических или неканонических страниц — только те URL, которые вы хотите видеть в поиске;
• если сайт большой (от нескольких тысяч страниц), sitemap разбит на несколько файлов с sitemap-index, поскольку один файл не должен превышать 50 000 URL;
• у каждой записи указана актуальная дата lastmod — это помогает поисковику приоритизировать пересканирование изменённых страниц.

После публикации sitemap.xml нужно вручную добавить его в Google Search Console (раздел «Файлы Sitemap» → вставить URL) и в Яндекс.Вебмастер (раздел «Индексирование» → «Файлы Sitemap»). Без этого шага поисковики, конечно, всё равно найдут сайт, но процесс индексации будет медленнее.

Канонические теги (rel="canonical")

Канонический тег указывает поисковику, какая версия страницы «главная», если существует несколько похожих или идентичных URL. Это критично для сайтов с фильтрами каталога, пагинацией, UTM-метками в ссылках и версиями для печати.

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

• на каждой странице сайта есть тег <link rel="canonical" href="..."> в <head>, и он указывает на правильный, предпочитаемый URL;
• канонические теги не образуют цепочек и не противоречат друг другу (страница А ссылается на Б как каноническую, а Б — обратно на А);
• на страницах с параметрами (например, site.ru/catalog?sort=price) канонический тег указывает на чистый URL без параметров: site.ru/catalog;
• HTTP и HTTPS версии, версии с www и без него не конкурируют между собой — обычно это решается через 301-редирект на единственную предпочитаемую версию плюс канонический тег для подстраховки.

Проверить, как Google трактует канонический URL конкретной страницы, можно через инструмент «Проверка URL» в Google Search Console — он покажет, какой адрес Google выбрал как канонический «по факту» (google-selected canonical), и это не всегда совпадает с тем, что указано в коде. Если расхождение есть — это сигнал, что нужно разбираться, почему поисковик не доверяет вашему тегу.

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

Скорость загрузки — это и прямой фактор ранжирования, и фактор поведенческий: медленный сайт увеличивает процент отказов, что дополнительно ухудшает позиции. С 2021 года Google официально использует Core Web Vitals как часть алгоритма ранжирования Page Experience.

Три метрики Core Web Vitals

LCP (Largest Contentful Paint) — время отрисовки самого крупного видимого элемента на экране (обычно это главное изображение или заголовок). Норма — до 2,5 секунд. От 2,5 до 4 секунд — «требует улучшения», больше 4 секунд — «плохо».

INP (Interaction to Next Paint) — время отклика интерфейса на действие пользователя (клик, тап, нажатие клавиши); с марта 2024 года эта метрика заменила устаревший FID в отчётах Google. Норма — до 200 миллисекунд.

CLS (Cumulative Layout Shift) — показатель визуальной стабильности: насколько сильно «прыгают» элементы на странице во время загрузки (классический пример — кнопка съезжает вниз, потому что над ней подгрузилась картинка без заданных размеров). Норма — до 0,1.

Чем проверять

PageSpeed Insights (pagespeed.web.dev) — основной инструмент. Он показывает данные из двух источников: Lab Data (лабораторное тестирование конкретно в момент проверки) и, если у сайта достаточно трафика, Field Data из CrUX (Chrome User Experience Report) — реальные данные с устройств пользователей за последние 28 дней. Для SEO важнее именно Field Data, потому что это то, на что реально ориентируется алгоритм ранжирования. Проверять нужно отдельно мобильную и десктопную версии — разница между ними часто существенная.

Google Search Console → «Основные интернет-показатели» — показывает, сколько URL на сайте попадает в категории «хорошо», «нужно улучшить» и «плохо» по всем трём метрикам, сгруппированных по типу страниц. Это удобно для сайтов с сотнями страниц: не нужно проверять каждую вручную.

Lighthouse (встроен в Chrome DevTools, вкладка Lighthouse) — даёт детальный отчёт с конкретными рекомендациями: какие изображения не оптимизированы, какие скрипты блокируют рендеринг, какие шрифты грузятся без font-display: swap.

WebPageTest.org — для более глубокой диагностики: показывает waterfall-диаграмму загрузки всех ресурсов, помогает найти конкретный скрипт или запрос, который тормозит страницу.

Что чаще всего проверяют и что нужно исправить до запуска

• изображения сжаты и отдаются в современных форматах (WebP или AVIF), а не в исходном PNG/JPEG «как есть» из фотобанка;
• у изображений заданы атрибуты width и height (или aspect-ratio в CSS), чтобы браузер резервировал место и не «прыгал» макет при подгрузке — это напрямую влияет на CLS;
• используется lazy loading (loading="lazy") для изображений ниже первого экрана;
• шрифты подключены с font-display: swap, чтобы текст не «исчезал» во время загрузки шрифта (Flash of Invisible Text);
• сторонние скрипты (виджеты чатов, аналитика, рекламные пиксели) подключены асинхронно (async/defer) и не блокируют рендеринг основного контента;
• включено сжатие Gzip или Brotli на сервере;
• настроено кэширование статических ресурсов через заголовки Cache-Control.

3. Мета-теги и заголовки H1–H6

Это базовый уровень on-page SEO, но именно здесь чаще всего встречаются массовые технические ошибки — особенно на сайтах, собранных на конструкторах или без участия SEO-специалиста в разработке.

Title и description

• у каждой страницы сайта уникальный <title> — дубли тайтлов на разных страницах — одна из самых частых находок при аудите каталогов и блогов;
• title укладывается примерно в 50–60 символов (точнее — в 580–600 пикселей в выдаче Google), иначе он обрезается в сниппете;
• meta description уникален для каждой страницы и умещается в 150–160 символов; хотя description не входит в прямые факторы ранжирования, он напрямую влияет на CTR в выдаче;
• на страницах нет пустых или дефолтных тайтлов вроде «Untitled» или «Home» — это типично для страниц, добавленных «на скорую руку» перед запуском.

Проверить title и description по всему сайту массово можно через Google Search Console → «Страницы», но она не покажет дубли напрямую — для этого удобнее краулер (например, Screaming Frog SEO Spider в бесплатной версии до 500 URL), который выгружает все title и description в таблицу и подсвечивает дубли и превышения длины.

Структура заголовков H1–H6

• на странице ровно один <h1> — это правило, которое до сих пор массово нарушается на сайтах, где H1 используется как «просто крупный текст» в дизайне, без понимания SEO-роли тега;
• заголовки идут по иерархии без пропуска уровней (после H2 не должно резко идти H4 в обход H3) — это влияет и на SEO, и на доступность сайта для скринридеров;
• в заголовках используются ключевые слова естественно, без переспама — заголовок должен быть в первую очередь понятен человеку;
• H1 не дублирует дословно title страницы — они могут пересекаться по смыслу, но лучше, если это не идентичный текст.

Проверить структуру заголовков быстро можно через расширение для браузера HeadingsMap (доступно для Chrome и Firefox) — оно строит визуальное дерево заголовков страницы, и любые пропуски уровней или лишние H1 сразу видны.

4. Микроразметка Schema.org

Микроразметка не влияет на позиции напрямую, но напрямую влияет на CTR и на то, получит ли сайт расширенные сниппеты в выдаче (рейтинг со звёздами, FAQ-блоки, хлебные крошки, карточки товаров с ценой). Для коммерческих сайтов это один из самых недооценённых пунктов чек-листа.

Что стоит внедрить в зависимости от типа сайта:

• Organization / LocalBusiness — базовая разметка компании: название, логотип, контакты, адрес, часы работы (обязательна для сайтов с физическим присутствием — салонов, клиник, магазинов);
• BreadcrumbList — хлебные крошки, которые Google часто показывает прямо в сниппете вместо URL;
• Product — для карточек товаров: цена, наличие, рейтинг (именно этот тип разметки отвечает за звёздочки рейтинга в выдаче);
• Article / BlogPosting — для статей блога: автор, дата публикации, дата обновления;
• FAQPage — для страниц с блоком вопрос-ответ, что может дать расширенный сниппет с раскрывающимися вопросами прямо в выдаче;
• Review / AggregateRating — для отзывов, но здесь важно не нарушать правила Google: разметка должна отражать реальные отзывы, размещённые на странице, а не быть «нарисованной» искусственно — за это можно получить ручные санкции.

Проверять корректность разметки нужно через Rich Results Test (search.google.com/test/rich-results) — он показывает, какие типы расширенных результатов Google может показать по этой странице и есть ли ошибки в структуре данных. Второй обязательный инструмент — Schema Markup Validator (validator.schema.org), который проверяет разметку на соответствие самой спецификации Schema.org, а не только требованиям Google. После запуска стоит также следить за разделом Google Search Console → «Улучшения», где показываются ошибки и предупреждения по внедрённым типам разметки в динамике по всему сайту.

5. Мобильная адаптивность

Google с 2019 года использует mobile-first индексацию для всех сайтов — это значит, что для ранжирования оценивается именно мобильная версия сайта, даже если основной трафик у бизнеса идёт с десктопа. Если мобильная версия хуже десктопной по контенту или функциональности, сайт теряет в позициях для всех устройств, а не только для мобильных.

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

• сайт использует адаптивную (responsive) вёрстку, а не отдельный поддомен m.site.ru — Google рекомендует именно единый responsive-подход как наиболее устойчивый к техническим ошибкам;
• на мобильной версии присутствует весь контент, что и на десктопной — частая ошибка при вёрстке «под скорость» — скрывать часть текста или блоков на мобильных, что технически означает потерю этого контента для индексации;
• размер кликабельных элементов (кнопок, ссылок) достаточен для тапа пальцем, а расстояние между ними не провоцирует случайные нажатия;
• шрифт читаем без необходимости масштабировать страницу (минимум 16px для основного текста);
• в <head> указан корректный <meta name="viewport" content="width=device-width, initial-scale=1">;
• нет горизонтальной прокрутки из-за элементов, которые не вписываются в ширину экрана.

Проверить это можно через Google Search Console → «Удобство для мобильных» — раздел показывает конкретные URL с проблемами и типы ошибок (текст слишком мелкий, элементы расположены слишком близко и так далее). Ручную проверку конкретной страницы стоит делать через Chrome DevTools → Device Toolbar (иконка устройства в инструментах разработчика), протестировав несколько разрешений экрана — от компактных смартфонов до планшетов.

6. Битые ссылки и редиректы

Битые ссылки — это не только потеря пользовательского опыта, но и потеря «ссылочного веса» внутри сайта: если внутренняя ссылка ведёт на страницу с ошибкой 404, вес, который вы могли бы передать этой странице, просто теряется.

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

• на сайте нет внутренних ссылок, ведущих на страницы с кодом ответа 404;
• при переносе или переименовании страниц настроены 301-редиректы (постоянные) со старых URL на новые — использование временного редиректа 302 в этом случае ошибка, поскольку он не передаёт ссылочный вес полноценно;
• нет цепочек редиректов (когда URL А редиректит на Б, а Б — на В) — каждый лишний «прыжок» замедляет загрузку и снижает эффективность передачи веса; правильно — редиректить сразу со старого адреса на конечный;
• внешние ссылки на партнёрские и справочные ресурсы тоже периодически проверяются на актуальность — ссылка на «умерший» внешний ресурс не критична для SEO, но портит впечатление у пользователя;
• если сайт менял домен или структуру URL, есть карта соответствия старых и новых адресов — без неё редиректы настраиваются наугад и часть страниц теряется.

Для полного сканирования сайта на битые ссылки стандартный инструмент — Screaming Frog SEO Spider: краулер обходит весь сайт по внутренним ссылкам и составляет список всех кодов ответа (200, 301, 302, 404, 500), показывая, с каких страниц идёт ссылка на проблемный URL. Бесплатная версия ограничена 500 URL, чего обычно достаточно для сайта среднего бизнеса; для крупных каталогов нужна платная версия или облачные альтернативы вроде Sitebulb или Ahrefs Site Audit. Дополнительно раздел Google Search Console → «Страницы» → «Не проиндексировано» показывает, какие URL Google пытался просканировать и получил ошибку — это удобно, чтобы увидеть проблему глазами самого поисковика, а не только краулера.

7. Дублирующийся контент

Дубли — одна из самых недооценённых технических проблем, потому что визуально сайт выглядит нормально: пользователь не видит разницы между site.ru/tovar и site.ru/tovar/, а поисковик — видит две разные страницы с одинаковым контентом.

Технические источники дублей, которые нужно проверить:

• www и без www — site.ru и www.site.ru не должны индексироваться параллельно; должен быть настроен 301-редирект на единственную предпочитаемую версию;
• http и https — после подключения SSL-сертификата старая http-версия должна редиректить на https, а не оставаться доступной параллельно;
• слэш в конце URL и без него — site.ru/catalog и site.ru/catalog/ технически два разных адреса для поисковика, если не настроена унификация;
• страницы с UTM-метками и параметрами сортировки/фильтрации — site.ru/catalog?utm_source=... или ?sort=price создают технически бесконечное количество вариаций одной и той же страницы, если не закрыты через canonical или robots.txt;
• версии для печати и дублирующие шаблоны, которые часто генерируются автоматически некоторыми CMS;
• идентичные описания товаров, скопированные с сайта производителя — это не техническая, а контентная проблема, но встречается почти на каждом втором интернет-магазине и требует отдельного внимания при аудите.

Проверить дубли можно через оператор site: в поиске Google (site:site.ru "точная фраза из текста") — если фраза встречается на нескольких URL, это сигнал для проверки. Более системно — через Google Search Console → «Страницы» → «Дублирующаяся страница без выбранной канонической» — этот отчёт напрямую показывает, какие URL Google считает дублями и не может сам выбрать, какой из них канонический. Для Яндекса аналогичная информация доступна в Яндекс.Вебмастере → «Индексирование» → «Страницы в поиске», где можно отследить исключённые из индекса дубли.

Типичные ошибки, которые совершают даже опытные разработчики

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

Забытый Disallow: / после переноса с тестового сервера. Это, наверное, самая частая и самая обидная ошибка: на staging-окружении сайт специально закрывают от индексации, чтобы черновик не попал в выдачу, а после переноса на боевой домен забывают снять запрет. Сайт может провисеть закрытым от поиска неделями, прежде чем кто-то заметит проблему через падение органического трафика в аналитике.

SSL-сертификат подключён, но старая http-версия не редиректит. Формально сайт «на https», но поисковик по-прежнему видит и индексирует старую версию, из-за чего вес и трафик распределяются между двумя копиями сайта.

Sitemap.xml генерируется автоматически и не проверяется вручную. Многие CMS создают карту сайта «из коробки», включая туда служебные страницы, черновики или страницы с ошибками — разработчик считает задачу выполненной по факту наличия файла, не проверяя его содержимое.

H1 используется как элемент дизайна, а не как SEO-тег. Дизайнер или верстальщик присваивает тег <h1> любому крупному заголовку на странице просто потому, что он визуально самый большой, из-за чего на странице оказывается три-четыре H1 подряд.

Изображения без атрибута alt и без сжатия. Даже на сайтах с в целом хорошей технической базой этот пункт часто выпадает из процесса — картинки заливаются «как есть» из макета в Figma, без оптимизации веса и текстовых описаний.

Микроразметка скопирована с чужого сайта и не адаптирована. Готовые шаблоны разметки Schema.org берут с других ресурсов и вставляют без изменения — в результате структурированные данные ссылаются на чужую компанию, чужой рейтинг или несуществующие товары, что при проверке через Rich Results Test выдаёт ошибки несоответствия.

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

Редиректы настраиваются точечно, без общей стратегии. Каждая проблема чинится по факту обнаружения — сначала редирект A→B, потом, когда меняется структура, добавляется B→C, и через полгода на сайте цепочки из трёх-четырёх редиректов, о существовании которых никто уже не помнит.

Что делать, если сайт уже запущен, а чек-лист не проходили

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

Шаг 1. Снять полную техническую картину. Прогнать сайт через краулер (Screaming Frog или аналог) и одновременно выгрузить данные из Google Search Console и Яндекс.Вебмастера — раздел индексации, основные интернет-показатели, удобство для мобильных, отчёты по дублям. Это даёт объективную картину, а не догадки.

Шаг 2. Приоритизировать находки по влиянию, а не по количеству. Условно, 40 неоптимизированных изображений — это не так критично, как открытый в robots.txt раздел с тысячей страниц, которые не должны индексироваться. Начинать нужно с проблем, которые блокируют индексацию или создают дубли, — это фундаментальный уровень, без которого остальная оптимизация не имеет смысла.

Шаг 3. Исправлять индексацию и дубли в первую очередь. Настроить недостающие редиректы, канонические теги, поправить robots.txt и sitemap.xml. После этого через Google Search Console стоит запросить повторное сканирование ключевых страниц («Проверка URL» → «Запросить индексирование»), чтобы ускорить переоценку сайта поисковиком.

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

Шаг 5. Заняться скоростью, микроразметкой и контентными дублями. Это следующий слой оптимизации после фундаментальных технических исправлений — он влияет не столько на факт индексации, сколько на позиции в конкурентной выдаче и на CTR.

Шаг 6. Внедрить регулярный мониторинг, а не разовую проверку. Технический аудит — это не разовое мероприятие «сделали и забыли». Раз в квартал стоит повторять базовую проверку по этому же чек-листу, особенно после любых крупных изменений на сайте — редизайна, переноса на новую CMS, добавления нового раздела каталога.

Отдельно про разницу между Google Search Console и Яндекс.Вебмастер

Для российского и СНГ-рынка важно держать в фокусе оба инструмента, а не только Google Search Console, — и не потому что «так положено», а потому что у Яндекса своя логика индексации и свои требования, которые местами прямо противоречат рекомендациям Google.

Например, Яндекс исторически чувствительнее к техническим дублям и к скорости именно мобильной загрузки в регионах с не самым быстрым интернетом. В Яндекс.Вебмастере стоит регулярно проверять раздел «Диагностика» → «Важные страницы», где можно отслеживать состояние конкретных ключевых URL (главная, страницы услуг, ключевые товарные категории) и получать уведомления, если с ними что-то произошло — страница перестала отвечать, изменился код ответа сервера, вырос вес страницы. Это особенно полезно для бизнеса, где основной трафик и клиенты приходят именно из Яндекса, а не Google.

Второе отличие — Яндекс своеобразно обрабатывает региональность. Если бизнес работает в нескольких городах или регионах, стоит явно указать регион сайта или конкретных страниц через Яндекс.Вебмастер → «Информация о сайте» → «Регион», иначе поисковик может неверно определить геопривязку и показывать сайт не той аудитории, которой он реально адресован. У Google похожий механизм называется geo-targeting и настраивается иначе — если сайт мультирегиональный, для Google важнее использовать корректную структуру URL по регионам (поддомены или подпапки) в сочетании с hreflang-разметкой, если речь о разных языковых версиях.

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

Итоговый чек-лист

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

Индексация

• robots.txt не блокирует сайт целиком, служебные разделы закрыты корректно
• sitemap.xml актуален, доступен, без ошибочных URL, добавлен в Search Console и Вебмастер
• канонические теги на всех страницах указывают на верный URL, без цепочек и противоречий

Скорость и Core Web Vitals

• LCP до 2,5 сек, INP до 200 мс, CLS до 0,1 — проверено в PageSpeed Insights по Field Data
• изображения сжаты, в WebP/AVIF, с заданными width/height, с lazy loading
• шрифты с font-display: swap, сторонние скрипты асинхронны, включено кэширование и сжатие

Мета-теги и заголовки

• уникальные title (50–60 символов) и description (150–160 символов) на каждой странице
• один H1 на странице, иерархия заголовков без пропусков уровней

Микроразметка

• внедрены Organization/LocalBusiness, BreadcrumbList и релевантные типы (Product, Article, FAQPage)
• разметка проходит проверку в Rich Results Test и Schema Markup Validator без ошибок

Мобильная адаптивность

• responsive-вёрстка без потери контента на мобильной версии
• проверено удобство для мобильных в Search Console, нет ошибок по размеру шрифта и кликабельных зон

Битые ссылки и редиректы

• нет внутренних ссылок на 404, нет цепочек редиректов
• все перенесённые страницы имеют 301-редирект, проверено краулером

Дубли

• унифицированы www/без www, http/https, слэш в конце URL
• параметры фильтрации и UTM-метки закрыты от индексации или канонизированы
• отчёт о дублях в Search Console и Вебмастере пуст или объяснён

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

Не готовы делать это самостоятельно?

Технический SEO-аудит требует внимания к деталям и опыта работы с десятками разных CMS и конфигураций серверов — пропущенная строка в robots.txt или неверно настроенный редирект стоят месяцев потерянного трафика. Если вы запускаете новый сайт или подозреваете, что с текущим что-то не так, но не хотите проходить весь чек-лист вручную, — мы в G-land проводим бесплатный технический аудит сайта: проверим индексацию, скорость, микроразметку, мобильную версию и дубли, и пришлём конкретный список того, что нужно исправить, с приоритетами. Напишите нам в Telegram @gland_studio — разберём ваш сайт и покажем, с чего начать.