Шаблон чек-листа технического SEO-аудита

Аудит сканируемости и индексации

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

Robots и директивы сканирования

• ☐ Убедитесь, что robots.txt открывается на корневом домене и возвращает статус 200, а не 4xx/5xx.
• ☐ Проверьте, что ни одно правило Disallow не блокирует CSS, JavaScript или важные каталоги с контентом, нужные для рендеринга.
• ☐ Убедитесь, что staging- или dev-хосты заблокированы от продакшена, а сам продакшен не запрещён случайно для всего сайта (['Disallow: /']).
• ☐ Убедитесь, что в robots.txt указана действительная ссылка на sitemap.
• ☐ Проверьте meta robots и заголовки X-Robots-Tag на случайные noindex или nofollow на индексируемых страницах.
• ☐ Убедитесь, что страницы, которые вы хотите проиндексировать, не заблокированы в robots.txt (запрещённый URL не может прочитать собственный тег noindex).

XML-карты сайта

• ☐ Убедитесь, что sitemap содержит только канонические, индексируемые URL со статусом 200: никаких редиректов, noindex или заблокированных адресов.
• ☐ Убедитесь, что sitemap не превышает лимитов на файл (['50,000 URLs / 50 MB без сжатия']) и при необходимости использует sitemap-индекс.
• ☐ Проверьте, что URL используют абсолютные, согласованные https-пути, соответствующие предпочитаемому домену.
• ☐ Отправьте sitemap в Search Console и убедитесь, что он читается без ошибок.
• ☐ Сверьте число URL в sitemap с числом проиндексированных и исследуйте крупные расхождения.

Канонизация

• ☐ Убедитесь, что каждая индексируемая страница объявляет самоссылающийся canonical (абсолютный URL).
• ☐ Проверьте, что canonical-теги указывают на живые URL со статусом 200, а не на редиректы или 404.
• ☐ Проверьте на противоречивые сигналы (canonical против noindex, canonical против hreflang, canonical против sitemap).
• ☐ Убедитесь, что варианты с параметрами, фасетами, пагинацией и session-ID канонизируются корректно.
• ☐ Убедитесь, что канонической является только одна версия URL среди http/https, www/non-www и вариантов с завершающим слешем.

Покрытие индекса

• ☐ Просмотрите отчёт Индексирование страниц в Search Console и разберите каждую причину Не проиндексировано.
• ☐ Исследуйте Просканирована, но пока не проиндексирована и Обнаружена, но пока не проиндексирована на предмет проблем с качеством или краулинговым бюджетом.
• ☐ Устраните паттерны Дубль без выбранного пользователем канонического и Альтернативная страница с правильным canonical-тегом.
• ☐ Используйте «Проверку URL», чтобы подтвердить отрендеренный HTML, canonical и индексируемость ключевых шаблонов.
• ☐ Проверьте логи сервера или отчёт «Статистика сканирования» на всплески 4xx/5xx и расход краулинга впустую.
• ☐ Убедитесь, что важные страницы доступны через внутренние ссылки, а не только через sitemap.

Аудит архитектуры сайта и внутренней перелинковки

Обеспечьте, чтобы самые важные страницы были неглубокими, хорошо перелинкованными и получали внутренний вес ссылок.

Глубина сканирования и структура

• ☐ Запустите полное сканирование с главной страницы и зафиксируйте глубину кликов для каждого URL.
• ☐ Убедитесь, что приоритетные страницы лежат на небольшой глубине от главной (['3 клика или меньше']).
• ☐ Выявите глубокие страницы, погребённые за пагинацией, фильтрами или тонкими хаб-страницами, и при необходимости сделайте структуру более плоской.
• ☐ Убедитесь в логичной, согласованной иерархии URL, отражающей разделы сайта.
• ☐ Убедитесь, что основная навигация и футер открывают доступ к топ-категориям и ключевым коммерческим страницам.

Страницы-сироты и тупиковые страницы

• ☐ Сверьте данные сканирования с sitemap и данными аналитики/логов, чтобы найти страницы-сироты (URL без внутренних входящих ссылок).
• ☐ Добавьте контекстные внутренние ссылки, чтобы вернуть ценный осиротевший контент, или удалите либо перенаправьте малоценные сироты.
• ☐ Выявите тупиковые страницы с малым числом или отсутствием исходящих внутренних ссылок и добавьте релевантные ссылки.
• ☐ Убедитесь, что страницы с пагинацией и фильтрами всё ещё открывают пути сканирования к базовым элементам.

Вес ссылок и анкорный текст

• ☐ Составьте карту числа внутренних входящих ссылок и отметьте ценные страницы, которым их не хватает.
• ☐ Сократите число ссылок на малоценные URL (вход, корзина, служебные страницы), размывающих вес.
• ☐ Используйте описательный, разнообразный, релевантный по ключам анкорный текст вместо общего нажмите здесь.
• ☐ Убедитесь, что важные внутренние ссылки — это сканируемые элементы <a href>, а не только JavaScript-обработчики кликов.
• ☐ Исправьте внутренние ссылки, проходящие через редиректы или ведущие на 404, чтобы вес передавался напрямую.

Хлебные крошки и хаб-страницы

• ☐ Внедрите навигацию «хлебные крошки» на глубоких шаблонах и разметьте её структурированными данными BreadcrumbList.
• ☐ Убедитесь, что ссылки в «хлебных крошках» — настоящие анкоры и отражают реальную иерархию сайта.
• ☐ Создайте или усильте хаб/категорийные страницы, ведущие к связанному кластерному контенту.
• ☐ Убедитесь, что модули связанного и контекстного контента перелинковывают тематически близкие страницы между собой.

Аудит Core Web Vitals и производительности

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

Полевые данные и диагностика

• ☐ Просмотрите отчёт Core Web Vitals в Search Console и отметьте группы URL, не проходящие на мобильных и десктопе.
• ☐ Отдавайте приоритет полевым (реальных пользователей) данным над лабораторными оценками; лабораторные инструменты — только для воспроизведения и отладки.
• ☐ Убедитесь в целях: LCP не более ['2.5s'], INP не более ['200ms'], CLS не более ['0.1'] на 75-м процентиле.
• ☐ Аудитируйте репрезентативные шаблоны (главная, категория, товар/статья), а не только главную страницу.

Largest Contentful Paint (LCP)

• ☐ Определите LCP-элемент на каждом ключевом шаблоне и убедитесь, что он загружается рано.
• ☐ Делайте preload LCP-изображения или шрифта и избегайте lazy-load для медиа над сгибом.
• ☐ Отдавайте hero-изображения в современных форматах с правильными размерами и адаптивным srcset.
• ☐ Сократите время ответа сервера (TTFB) через кеширование и CDN.

Interaction to Next Paint (INP)

• ☐ Разбивайте длинные JavaScript-задачи и откладывайте некритичные скрипты.
• ☐ Минимизируйте работу основного потока от сторонних тегов, A/B-инструментов и чат-виджетов.
• ☐ Удалите неиспользуемый JavaScript и CSS и разделяйте крупные бандлы на части.
• ☐ Тестируйте реальные взаимодействия (тапы, открытие меню, ввод в формы) на мобильном устройстве среднего класса.

Cumulative Layout Shift (CLS)

• ☐ Задавайте явные ширину и высоту (или aspect-ratio) для изображений, видео и встраиваний.
• ☐ Резервируйте место для рекламы, баннеров и динамически вставляемого контента.
• ☐ Делайте preload веб-шрифтов и используйте font-display, чтобы ограничить сдвиги от замены текста.
• ☐ Избегайте вставки контента над существующим контентом после загрузки.

Доставка, кеширование и мобильные

• ☐ Устраните CSS/JS, блокирующие рендеринг, и встраивайте инлайн только критический CSS.
• ☐ Включите сжатие текста (gzip/Brotli) и долгоживущие заголовки кеша для статических ресурсов.
• ☐ Убедитесь, что HTTP/2 или HTTP/3 и CDN отдают ресурсы близко к пользователям.
• ☐ Убедитесь, что мобильный макет адаптивный, а цели для тапа и размеры шрифтов пригодны для касания.
• ☐ Перетестируйте после каждого исправления и наблюдайте за полевыми данными в течение полного окна сбора, прежде чем объявлять успех.

Аудит структурированных данных и расширенных результатов

Проверьте, что ваша schema-разметка точна, пригодна и получает расширенные результаты, на которые имеет право.

Покрытие schema и выбор типов

• ☐ Проведите инвентаризацию: какие шаблоны имеют структурированные данные, а каким пригодным шаблонам их не хватает.
• ☐ Сопоставьте каждую страницу с подходящими типами (['Article, Product, FAQPage, BreadcrumbList, Organization, LocalBusiness']).
• ☐ Отдавайте приоритет JSON-LD в коде страницы и держите один согласованный формат разметки на страницу.
• ☐ Внедрите сущность Organization или уровня сайта с логотипом и профилями sameAs, где это уместно.

Правила точности и пригодности

• ☐ Убедитесь, что размеченный контент виден пользователям на странице: никаких скрытых данных или только в разметке.
• ☐ Включите все обязательные свойства для каждого типа и добавьте рекомендуемые, чтобы усилить пригодность.
• ☐ Убедитесь, что значения правдивы и актуальны (цена, наличие, рейтинги, даты) и отражают контент страницы.
• ☐ Используйте разметку review/rating только для настоящих отзывов на странице и следуйте действующим правилам о самовосхвалении.
• ☐ Убедитесь, что ссылки на сущности и ID согласованы между связанными блоками разметки.

Валидация и тестирование

• ☐ Прогоните каждый ключевой шаблон через Rich Results Test и валидатор schema.
• ☐ Исправьте все сообщённые ошибки и устраните предупреждения, блокирующие улучшения.
• ☐ Тестируйте отрендеренный HTML, поскольку часть разметки вставляется через JavaScript после загрузки.
• ☐ Выборочно проверяйте несколько реальных URL на шаблон, а не только один пример.

Мониторинг и поддержка

• ☐ Отслеживайте каждый тип расширенного результата в отчётах Улучшения в Search Console на новые ошибки.
• ☐ Настройте оповещения или регулярную проверку после изменений шаблона, CMS или плагинов.
• ☐ Повторно валидируйте, когда меняются рекомендации или функция признаётся устаревшей.
• ☐ Ведите журнал того, какие шаблоны выдают какие типы schema и кто за них отвечает.

Аудит международного SEO

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

Реализация hreflang

• ☐ Убедитесь, что каждая страница в языковом/региональном наборе ссылается на все альтернативы, включая самоссылающийся hreflang.
• ☐ Проверьте, что обратные теги двунаправленны: каждая альтернатива ссылается на остальные (никаких односторонних ссылок).
• ☐ Используйте действительные коды языка и опциональные коды региона (['en, en-GB, es-MX']) в формате ISO.
• ☐ Включите тег x-default для глобального фолбека или селектора языка.
• ☐ Выберите один метод доставки (HTML head, HTTP-заголовок или sitemap) и применяйте его последовательно.
• ☐ Направляйте hreflang-URL на живые, индексируемые, канонические страницы со статусом 200 — никогда на редиректы или noindex-страницы.

Взаимодействие canonical и индексации

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

Геотаргетинг и структура URL

• ☐ Убедитесь в чёткой, масштабируемой структуре для языков/регионов (ccTLD, поддомен или подкаталог) и применяйте её последовательно.
• ☐ Установите таргетинг по стране там, где уместно, и согласуйте его со стратегией URL.
• ☐ Избегайте авторедиректов на основе IP, блокирующих краулеров или запирающих пользователей в неправильной версии; предпочитайте языковой баннер или селектор.
• ☐ Локализуйте контент осмысленно (валюта, единицы, контактные данные, орфография), а не дублируйте один язык.

Валидация

• ☐ Просканируйте сайт с включённой отчётностью hreflang и устраните отсутствующие или битые обратные теги.
• ☐ Используйте «Проверку URL», чтобы подтвердить, как обнаруживаются альтернативы.
• ☐ Выборочно проверьте несколько локалей на корректный рендеринг, индексируемость и отдачу.
• ☐ Проведите повторный аудит после добавления новых локалей или шаблонов.

Аудит миграции / редизайна сайта

Защитите позиции и трафик до, во время и после миграции или редизайна, проверив редиректы и паритет.

Подготовка перед запуском

• ☐ Просканируйте живой сайт и в качестве базовой линии экспортируйте полный перечень индексируемых URL, заголовков, метаданных и кодов статуса.
• ☐ Зафиксируйте базовые показатели: топ органических целевых страниц, позиции, трафик, конверсии и покрытие индекса.
• ☐ Убедитесь, что staging-сайт заблокирован от индексации и защищён (авторизация или IP-allowlist), но убедитесь, что директивы будут сняты при запуске.
• ☐ Постройте полную карту редиректов от каждого старого URL к ближайшему новому эквиваленту.
• ☐ Подготовьте новые XML-sitemap, robots.txt и ресурсы аналитики/Search Console для новой структуры.

Маппинг редиректов

• ☐ Используйте постоянные редиректы 301 для изменённых URL и избегайте 302 для постоянных перемещений.
• ☐ Маппируйте старые URL один-к-одному на релевантные новые страницы; избегайте массовых редиректов на главную.
• ☐ Устраните цепочки и петли редиректов, чтобы каждый старый URL разрешался за один шаг.
• ☐ Сохраните или мигрируйте hreflang, canonical и структурированные данные на новые URL.
• ☐ Учтите устаревшие параметры, медиафайлы и любые URL с внешними обратными ссылками.

Паритет контента и технический

• ☐ Проверьте, что заголовки, метаописания, заголовки, тело контента и изображения перенесены или улучшены.
• ☐ Убедитесь, что внутренние ссылки ведут на новые URL напрямую, а не через редиректы.
• ☐ Проверьте, что canonical-теги, структурированные данные и hreflang правильны на новых шаблонах.
• ☐ Сравните Core Web Vitals и ключевую скорость страницы до и после, чтобы поймать регрессии.

Валидация во время и после запуска

• ☐ На запуске снимите staging-блокировки noindex/robots и убедитесь, что продакшен-сайт сканируем.
• ☐ Отправьте новые sitemap и используйте «Проверку URL», чтобы запросить индексацию приоритетных страниц.
• ☐ Повторно просканируйте новый сайт, чтобы подтвердить, что редиректы разрешаются, нет критических 404 и ни один шаблон не выдаёт непреднамеренный noindex.
• ☐ Ежедневно следите за покрытием индекса, статистикой сканирования, позициями и трафиком в первые недели и остерегайтесь устойчивых падений.
• ☐ Держите редиректы долгосрочно и исправляйте любые вновь обнаруженные битые пути.

Как часто следует проводить технический SEO-аудит?

Для большинства сайтов хорошо работает комплексный технический аудит ежеквартально в паре с непрерывным мониторингом в промежутках. Крупные, часто меняющиеся сайты (большие e-commerce или новостные издания) выигрывают от ежемесячных глубоких погружений, тогда как малые стабильные сайты часто могут ждать полгода. Помимо графика, всегда запускайте соответствующий модуль аудита после любого крупного события: миграции, редизайна, смены CMS или обновления шаблона, ведь именно тогда появляются технические проблемы.

В чём разница между аудитом и постоянным мониторингом?

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

Являются ли Core Web Vitals фактором ранжирования?

Да. Core Web Vitals являются частью сигналов удобства страницы Google и могут влиять на позиции, особенно как решающий фактор между страницами схожей релевантности и качества. Они не волшебная палочка (релевантный, полезный контент остаётся доминирующим фактором), поэтому относитесь к Core Web Vitals как к значимому сигналу пользовательского опыта и ранжирования, который стоит сделать правильно, а не как к замене качества контента и общего здоровья сайта.

Рендерит ли Google JavaScript и почему это важно для аудита?

Google может рендерить JavaScript, но рендеринг происходит вторым проходом после начального сканирования и зависит от того, сканируемы ли ресурсы. Если критический контент, внутренние ссылки, canonical или структурированные данные появляются только после выполнения клиентского JavaScript, их могут обнаружить поздно или пропустить, если скрипты заблокированы или дают сбой. Во время аудита всегда проверяйте отрендеренный DOM в дополнение к сырому HTML и убедитесь, что ваш robots.txt разрешает JavaScript и CSS, нужные для рендеринга.

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

Приоритизируйте всё, что блокирует сканирование или индексацию важных страниц: случайные теги noindex, слишком широкие правила disallow в robots.txt, битые или противоречивые canonical, ошибки сервера (5xx) и цепочки или петли редиректов. Они могут полностью убрать страницы из поиска, поэтому перевешивают косметические исправления. Убрав блокеры сканирования и индексации, продвигайтесь по серьёзности через архитектуру сайта, Core Web Vitals, структурированные данные и международные вопросы.

Через сколько после исправления проблем я увижу результаты?

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