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

Технические проблемы редко бьют по трафику без предупреждения. До просадки обычно уже видны сигналы в Search Console, индексации, robots.txt, sitemap.xml или в том, как Google обходит страницы.

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

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

Достаточно ли 20 минут в неделю?

Если говорить без прикрас, нет. За 20 минут не делают полный технический аудит, не разбирают сложные конфликты canonical, не тестируют все шаблоны и не проходят весь сайт вручную.

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

В одну неделю такой обзор подтвердит, что сайт работает стабильно. В другую — поможет вовремя заметить проблемы с noindex, rel canonical, mobile-first indexing, sitemap.xml или резкий рост технических ошибок в Search Console.

В этот формат не входит полная проверка шаблонов, лог-файлов, JS-рендеринга, всех связок hreflang и canonical или детальный анализ причин падения. Это короткий контрольный обзор, который помогает понять, где нужен более глубокий разбор.

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

1. Обзор Search Console (минуты 0–10)

Лучшая точка старта — Google Search Console . Это первое место, где видно, как Google реально видит сайт: что индексирует, что исключает, что сканирует, а где уже есть проблемы.

За эти 10 минут не нужно пытаться сделать полный SEO-аудит. Задача проще: быстро отловить аномалии, которые не похожи на обычное недельное колебание.

Начните с раздела Обзор

Обзор Google Search Console с ключевыми показателями эффективности и состояния сайта

На этом этапе смотрите на крупные изменения, а не на мелкие движения по отдельным запросам. Если есть резкая просадка кликов, показов или покрытия, это уже повод не откладывать разбор.

  • Проверьте, нет ли резкого падения кликов и показов в эффективности. Не каждая просадка означает техническую проблему, но резкое изменение без очевидной причины — это сигнал.
  • Обратите внимание, не появились ли новые сбои в индексации после релиза, миграции, редизайна или правок шаблонов.
  • Если сайт использует микроразметку и structured data для товаров, статей, breadcrumbs, видео или других элементов, просмотрите также отчёты rich results, если они доступны.

Если Search Console у вас ещё не доведена до ума, отдельно посмотрите материал как правильно настроить Google Search Console .

Затем перейдите к разделу индексации

Отчёт об индексации страниц в Search Console с ошибками и исключёнными URL

Далее откройте page indexing report — отчёт об индексации страниц. Это один из самых полезных отчётов для еженедельной технической проверки, потому что именно здесь видно, как Google ведёт себя с URL на уровне индексации.

Смотрите не только на сам факт ошибок, но и на их динамику. Больше всего внимания обычно требуют такие причины:

  • резкий рост страниц с noindex;
  • страницы, заблокированные через robots txt, хотя они должны быть в поиске;
  • всплеск soft 404 или других нетипичных исключений;
  • конфликты canonical, когда Google выбирает не ту каноническую страницу;
  • увеличение группы дублированных URL без чётко выбранного canonical.

Не каждый исключённый URL — это ошибка. Но если вы видите нетипичный рост проблемных статусов, это уже не мелкая флуктуация, а повод разбираться глубже. Логику канонизации Google отдельно объясняет в документации о canonical URL и rel canonical . Если нужно лучше понять общую логику индексации, полезно держать под рукой и материал как проиндексировать сайт в поисковых системах .

Просмотрите раздел Файлы Sitemap

Раздел Sitemap в Search Console со статусами карт сайта и датой последнего чтения

Здесь важно не просто убедиться, что sitemap xml добавлена. Проверьте, читал ли Google карту недавно, нет ли ошибок обработки и соответствует ли структура sitemap актуальной архитектуре сайта.

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

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

Проверка ручных мер и выборочная проверка URL

Раздел Manual Actions в Google Search Console для проверки ручных санкций

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

В конце этого блока откройте URL Inspection Google для 1–2 критически важных страниц: главной, ключевой категории, услуги или страницы, которая приносит заявки. Посмотрите, индексируется ли URL, когда он в последний раз сканировался, какой canonical выбрал Google и не противоречит ли он вашему rel canonical.

Если подозреваете проблему со сканированием, дополнительно загляните в Crawl Stats Report в настройках Search Console. Он полезен, когда нужно быстро проверить, не просели ли запросы Googlebot, не выросло ли среднее время ответа сервера и нет ли всплесков 5xx-ошибок после изменений на сайте.

2. Проверьте robots.txt (минуты 11–12)

Файл robots.txt — один из самых простых технических элементов, но именно он регулярно становится причиной неприятных историй после релизов, миграций или работ на staging-среде.

Здесь важно помнить главное: robots txt управляет сканированием, но не гарантирует исключение страницы из индекса. Если страницу нужно не показывать в поиске, для этого обычно нужны noindex, правильные статус-коды или ограничение доступа, а не только блокировка через robots.txt.

Еженедельная проверка занимает минуту-две:

  • откройте файл на живом сайте и убедитесь, что он отдается корректно;
  • проверьте, не появилась ли случайная директива вроде Disallow: /;
  • посмотрите, не заблокированы ли важные каталоги, CSS, JS или служебные ресурсы, нужные для рендеринга;
  • убедитесь, что путь к sitemap актуален.

Особенно внимательно смотрите на robots.txt после обновлений CMS, доработок шаблонов, переноса сайта или работ, которые выполнялись ещё на этапе разработки сайта .

Если хотите отдельно освежить логику этого файла, посмотрите материал robots.txt: что это и зачем он нужен .

User-agent: *

Disallow: /

Такой директивы на живом сайте быть не должно, если вы не блокируете весь ресурс сознательно.

3. Проверьте скорость сайта и Core Web Vitals (минуты 13–15)

В этом блоке не нужно делать полный профайлинг фронтенда. Задача проще — понять, не стало ли сайту хуже за последнюю неделю и нет ли очевидной просадки в page experience Google.

Core Web Vitals — это набор метрик реального пользовательского опыта. Для еженедельного контроля достаточно быстро сверять общий тренд, а если видите ухудшение — уже точечно запускать PageSpeed Insights или Lighthouse для нужных URL.

Скрин ниже иллюстрирует сам принцип быстрой проверки: сначала смотрите общую динамику, потом — шаблоны страниц, где просадка заметнее всего. Для SEO-оценки ориентироваться стоит прежде всего на Core Web Vitals и PageSpeed Insights .

Пример отчёта для быстрой оценки скорости сайта и изменений в производительности страниц

Если у вас есть внутренний дашборд в GA4 или Looker Studio, удобно сравнивать последнюю неделю с предыдущей. Но для SEO-оценки не стоит опираться только на общий отчёт по скорости: смотрите на шаблоны, мобильные страницы и реальные URL, которые дают трафик и заявки.

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

Что проверять быстро:

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

Если видите просадку, прогоняйте 2–3 ключевых URL через PageSpeed Insights и Lighthouse, а не пытайтесь объяснить всё только общей цифрой.

Детальные рекомендации по скорости страниц и проблемным URL после проверки производительности

4. Посмотрите результаты поиска (минуты 15–18)

Ни один инструмент не заменит живой просмотр SERP. Даже если у вас есть трекеры позиций, раз в неделю стоит своими руками посмотреть, что реально видит пользователь в выдаче.

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

Пример ручной проверки поисковой выдачи Google для контроля SERP и технических сигналов страницы

На что смотреть:

  • ранжируется ли правильная страница, а не дубль или второстепенный URL;
  • не сломались ли title, description или favicon;
  • не попала ли в SERP страница, которая должна была быть закрыта через noindex или canonical;
  • корректно ли работает hreflang на мультиязычном сайте, если у вас есть несколько языковых версий;
  • не исчезли ли rich results там, где у вас реализована микроразметка.

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

Для мультиязычных сайтов полезно время от времени сверять и hreflang , особенно после запуска новых языковых версий или изменений в шаблонах. А если есть подозрение, что rich results исчезли из-за разметки, проверьте соответствующие страницы через документацию Google по structured data и Rich Results Test . Это быстрый способ понять, видит ли Google вашу микроразметку вообще и не появились ли технические ошибки после изменений в шаблоне.

5. Визуально проверьте сайт (минуты 19–20)

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

Начинайте с мобильной версии, а затем коротко смотрите desktop. Из-за mobile-first indexing именно мобильный рендер имеет первостепенное значение для поиска.

Быстро пройдитесь по главной, ключевой категории, странице услуги и одной-двум статьям блога. Вас интересуют не мелкие стилистические нюансы, а вещи, которые реально могут повлиять на индексацию или конверсию:

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

После этого откройте исходный код одной-двух страниц и проверьте базовые сигналы: title, meta robots, rel canonical, hreflang, JSON-LD или другую микроразметку. Это простое действие, но оно часто помогает заметить то, чего не видно при поверхностном просмотре шаблона.

Инструменты разработчика > Просмотр исходного кода страницы

Вывод

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

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

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