Technical SEO Audit Guide: How to Boost Website Performance in 2025

 

Что такое технический SEO-аудит?

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

Когда вы проводите технический SEO-аудит, вы проверяете, оптимизирован ли ваш сайт для поисковых систем.

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

Проблема не в аудите. Проблема в порядке.

Это руководство построено на одном принципе: серьезность определяет последовательность. Вы узнаете, что проверять, что исправлять в первую очередь и (что не менее важно) что безопасно игнорировать.

Примечание по объему: Это руководство рассчитано на сайты до 500 страниц, которыми управляют один-два человека, с использованием бесплатных или условно-бесплатных инструментов. Если у вас крупный сайт или сайт с большим количеством Java Script, некоторые рекомендации придется адаптировать.

 

Фильтр серьёзности: ваша модель триажа

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

Используйте эту трехуровневую модель во всех последующих разделах:

Уровень	Категория	Действие
Уровень 1	Блокирующие факторы ранжирования	Исправить немедленно: они активно подавляют видимость
Уровень 2	Неэффективность сканирования	Исправьте этот спринт: эти ограничивают охват без жесткой блокировки
Уровень 3	Флаги низкого приоритета	Запланируйте или проигнорируйте: это редко влияет на рейтинг для небольших сайтов

Если инструмент помечает что-то, и вы не можете отнести это к Уровню 1 или Уровню 2, это относится к Уровню 3, пока не доказано обратное.

 

Предварительная настройка аудита: инструменты и база

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

Бесплатный стек для этого аудита:

• Google Search Console — Прежде всего проверьте право собственности на ресурс; это ваша основа для данных об индексации и производительности.
• Google Page Speed Insights — полевые данные для Core Web Vitals; аккаунт не требуется
• Screaming Frog SEO Spider (бесплатная версия) — обходит до 500 URL; достаточно для большинства небольших сайтов
• Chrome Dev Tools — нулевая установка, встроено в браузер; используйте для рендеринга и диагностики сети
• Ahrefs Webmaster Tools (бесплатный тариф) — данные об обратных ссылках и базовый аудит сайта без платной подписки

Если ваш сайт превышает 500 страниц, приоритезируйте URL с самым высоким трафиком и конверсией для сканирования Screaming Frog. Не пытайтесь аудитировать всё сразу.

Рекомендуемые статьи: Google Search Console: Полное руководство на 2026 год

 

Домен, DNS и безопасность

Это категория аудита, которую пропускают все конкуренты. Она относится к Уровень 1 — не потому, что эти проблемы распространены, а потому, что когда они есть, они блокируют всё остальное. Сломанный SSL-сертификат или неправильно настроенный редирект на уровне домена могут незаметно подавить весь ваш сайт, даже не оценив ни одного фрагмента контента.

Большинство владельцев сайтов сразу переходят к ключевым словам и контенту. Этот раздел — о фундаменте, на котором они стоят.

Проверьте их по порядку:

 

1. Работает ли ваш сайт по HTTPS?

Когда вы посещаете веб-сайт, ваш браузер и сервер постоянно обмениваются информацией. HTTPS — это защищённая версия этого соединения, она шифрует данные, чтобы их нельзя было перехватить. HTTP (без S) — это старая незашифрованная версия.

Вы можете узнать, какой протокол использует ваш сайт, посмотрев на адресную строку браузера. Значок замка означает, что HTTPS активен. Предупреждение "Не защищено" означает, что это не так, и это заметят как Google, так и ваши посетители.

Почему это важно для SEO: Google подтвердил HTTPS как сигнал ранжирования. На практике браузеры, такие как Chrome, активно предупреждают посетителей о небезопасных сайтах. Если какая-либо страница вашего сайта все еще загружается по HTTP, исправьте это в первую очередь.

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

 

2. Имеет ли ваш домен постоянный адрес?

Технически ваш сайт доступен по двум разным адресам: www.yourdomain.com и yourdomain.com (без www). Для браузера это два разных места. Для Google они могут выглядеть как два отдельных сайта, публикующих одинаковый контент.

Это называется Конфликт www и без www , и это одна из самых распространенных проблем на уровне домена на небольших сайтах.

После настройки любой, кто вводит любую из версий, попадет на одно и то же место, и Google будет рассматривать ваш сайт как единое целое, а не как два дубликата.

Как проверить: Введите оба варианта вашего домена в браузер и посмотрите, что происходит в адресной строке. Если один чисто перенаправляет на другой, всё в порядке. Если оба загружаются независимо (показывая одинаковый контент), у вас проблема с дублирующимся контентом, которую нужно исправить. Вы также можете использовать redirect-checker.org чтобы подтвердить, что редирект — это настоящий 301, а не более мягкий временный редирект.

3. Видны ли ваши тестовые или промежуточные сайты для Google?

Когда разработчики создают или обновляют сайт, они обычно сначала работают над отдельной версией сайта, часто по адресу типа staging.yourdomain.com или dev.yourdomain.com. Это называется тестовая среда или тестовый поддомен. Он предназначен быть невидимым для публики.

Проблема: если никто явно не скажет Google держаться подальше, Googlebot найдёт и просканирует это. Теперь у Google есть две версии вашего сайта (рабочая и тестовая) с идентичным контентом. Это путает индексацию и тратит бюджет сканирования на страницы, которые никогда не должны появляться в результатах поиска.

 

4. Действителен ли ваш SSL-сертификат и актуален ли он?

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

Когда срок действия SSL-сертификата истекает, браузеры показывают посетителям полноэкранное предупреждение: "Ваше соединение не защищено." Большинство людей сразу уходят. Недействительный SSL-сертификат может блокировать пользователей, подрывать доверие, создавать предупреждения браузера, может навредить сканированию/опыту страницы, и замок исчезает.

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

Редирект — это инструкция, которая отправляет посетителя (или поискового робота) с одного URL на другой. Один редирект — это нормально, например, перенаправление с http:// на https:// или с www на без www. Проблемы начинаются, когда редиректы накладываются друг на друга.

Цепочки перенаправлений происходит, когда одно перенаправление ведет к другому, прежде чем наконец достичь цели. Например: посетитель переходит на страницу A, которая перенаправляет на страницу B, которая перенаправляет на страницу C — фактическую страницу. Каждый дополнительный переход увеличивает время загрузки и повышает вероятность того, что краулер Google сдастся, не дойдя до конечного пункта. Такие цепочки часто возникают незаметно после миграции сайта, смены домена или обновления HTTPS, которое не было полностью очищено.

Циклические перенаправления более серьёзны. Это когда редирект указывает на страницу, которая перенаправляет саму на себя: Страница A перенаправляет на Страницу B, которая перенаправляет обратно на Страницу A. Ни пользователи, ни краулеры не могут никуда попасть. Браузер покажет ошибку, а Google не сможет проиндексировать ни одну из страниц. Это исправление первого уровня.

 

Аудит индексации

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

 

1. Файл robots.txt — привратник

У каждого сайта есть (или должен быть) файл по адресу yourdomain.com/robots.txt. Это обычный текстовый файл, который сообщает поисковым роботам, какие страницы им разрешено сканировать, а какие следует пропустить. Введите этот URL прямо в браузере, чтобы увидеть свой.

Самые разрушительные ошибки здесь не экзотические, они случайные. Три самых распространённых:

• Блокировка всего сайта — одна строка (Disallow: /) говорит всем сканерам полностью держаться подальше. Это может произойти, когда разработчик устанавливает ее во время сборки и забывает удалить перед запуском.
• Блокировка CSS или Java Script файлов — Google нужно загрузить стили и скрипты вашего сайта, чтобы понять, как выглядят и ведут себя ваши страницы. Заблокируйте их, и Google может отображать ваши страницы неправильно или вообще не отображать.
• Оставление старых правил — staging-era инструкции, которые имели смысл во время разработки, часто случайно переносятся в продакшн, незаметно ограничивая доступ к страницам, которые должны быть проиндексированы.

Если заметите что-то из этого, помечайте как уровень 1 и исправляйте перед продолжением.

Чтобы узнать больше о robot.txt, посмотрите это видео от Google Search Central: 

 

2. Ваша XML-карта сайта — дорожная карта

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

Пока вы там, ищите три конкретные проблемы:

• Страницы, возвращающие ошибки 4xx — это битые URL из вашей карты сайта, ведущие Google в тупик.
• URL без индексации, включённые в карту сайта — страница не может быть одновременно "пожалуйста, индексируйте это" (карта сайта) и "не индексируйте это" (тег noindex); одна инструкция победит, а конфликт тратит бюджет сканирования.
• Важные страницы полностью отсутствуют — если ключевая страница отсутствует в вашей карте сайта, Google может всё равно её найти, но вы оставляете обнаружение на волю случая.

 

3. Бюджет сканирования — актуален только в масштабе

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

Это становится актуальным, когда ваш сайт автоматически генерирует большое количество низкоценных или почти дублирующихся URL. Частые причины: комбинации фильтров и сортировки на страницах товаров, ID сессий, добавленные в URL, или пагинация, уходящая в сотни почти идентичных страниц.

Если при сканировании Screaming Frog количество страниц значительно превышает реальное количество контента, изучите шаблоны URL, прежде чем считать их все намеренными. Возможно, у вас ловушка сканирования, генерирующая тысячи URL, которые расходуют бюджет сканирования, не принося пользы для ранжирования.

 

Аудит индексации

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

Проверка оператора site:

Поищите site:yourdomain.com в Google. Количество результатов даст вам примерное количество проиндексированных страниц. Резкое несоответствие между этим числом и фактическим количеством страниц указывает на проблему с индексацией.

Аудит Noindex

Случайные теги noindex — самый распространённый самонанесённый блокиратор ранжирования. Запустите Screaming Frog и отфильтруйте страницы, возвращающие директиву noindex. Сверьте со страницами, которые вы ожидаете увидеть в выдаче. Noindex на вашей главной или ключевых посадочных страницах — это авария первого уровня.

Логика канонических тегов

Канонический тег — это небольшой фрагмент кода в заголовке страницы, который сообщает Google: "Это официальная версия этой страницы." Он существует потому, что один и тот же контент часто может быть доступен по нескольким разным URL-адресам: с косой чертой в конце или без нее, с добавленными параметрами отслеживания или через версии HTTP и HTTPS. Без канонического тега Google приходится угадывать, какой URL является "настоящим". Иногда он угадывает неправильно.

Тег выглядит так в HTML страницы:

<link rel="canonical" href="https://www.yourdomain.com/your-page/" />

Есть два правильных использования:

• Самореферентный канонический — страница ссылается сама на себя, подтверждая, что это основная версия. Это стандартная настройка для большинства страниц и просто говорит Google "этот URL правильный, индексируйте его."
• Консолидация канонических — дубликат или почти дубликат страницы указывает на предпочтительную версию. Например, если yourdomain.com/page?ref=email и yourdomain.com/page показывают идентичный контент, URL с параметром должен иметь каноническую ссылку, указывающую на чистую версию.

Проблемы начинаются, когда канонические теги указывают не туда. Три самые вредные ошибки:

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

Параметр и дублирование слэша в конце

/page, /page/ и /page?ref=email могут рассматриваться Googlebot как отдельные URL. Убедитесь, что ваш сервер или CMS обрабатывает их единообразно, или используйте канонические теги для их объединения.

 

Технические сигналы на странице

Это структурные элементы (отличающиеся от копирайтинга), которые влияют на то, как Google парсит и представляет ваши страницы.

 

Заголовки и мета-описания

Заголовки страниц должны быть не длиннее 60 символов, чтобы избежать обрезания в выдаче. Мета-описания — до 155 символов. В Screaming Frog отфильтруйте отчёт Page Titles по записям, помеченным как "слишком длинные" или "отсутствуют." Они не приведут к падению позиций, но обрезанные заголовки снижают кликабельность.\

 

Иерархия заголовков

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

 

Битые внутренние ссылки

Каждая внутренняя 404 ошибка тратит краулинговый бюджет и создает тупик для передачи ссылочного веса. Screaming Frog находит их в разделе Response Codes → 4xx. Исправьте, обновив ссылку или настроив редирект с битой ссылки.

 

Альтернативный текст изображения

Альтернативный текст — это сигнал для сканирования, а не только функция доступности. Изображения без альтернативного текста невидимы для текстового анализа Googlebot. В Screaming Frog проверьте отчёт Images на наличие отсутствующих атрибутов alt у изображений, несущих смысловую нагрузку.

 

Основные веб-показатели (стандарты 2025)

Core Web Vitals — это три метрики, которые Google использует для оценки того, как страница ощущается при использовании. Не просто загружается ли она, а загружается ли быстро, реагирует ли мгновенно и остается ли визуально стабильной во время загрузки. Они являются частью оценки качества страницы Google и отображаются напрямую в Page Speed Insights и Google Search Console.

Сейчас есть три метрики. Если в вашем аудите где-то упоминается First Input Delay (FID), забудьте о нём — FID был официально заменён на INP 12 марта 2024 года.

 

INP: Отзывчива ли ваша страница, когда люди нажимают?

INP расшифровывается как Interaction to Next Paint. Он измеряет, насколько быстро страница визуально реагирует после действия пользователя: нажатия кнопки, открытия меню, ввода в поле. Если между действием и реакцией страницы есть заметная задержка, это плохой показатель INP.

Пороги:

• Хорошо = менее 200 мс
• Требует улучшения = 200–500 мс
• Плохо = более 500 мс

Источник: Скриншот: Взаимодействие до следующей отрисовки (INP)

Самые частые причины на небольших сайтах: слишком много Java Script, работающего в фоне, сторонние скрипты (чат-виджеты, аналитика, рекламные теги), конкурирующие за внимание браузера, и медленные ответы сервера.

 

LCP: Загружается ли основной контент быстро?

LCP расшифровывается как Largest Contentful Paint. Он измеряет, сколько времени требуется для полной загрузки самого большого видимого элемента на странице: обычно это изображение-герой, крупный заголовок или избранное фото. Это способ Google спросить: @"Насколько быстро страница кажется работоспособной?@"

Порог: Хорошо = менее 2,5 секунд

Источник: Скриншот: Largest Contentful Paint (LCP)

Самые распространенные причины медленного LCP: изображения-герои, которые не были сжаты, CSS или Java Script, блокирующие рендеринг страницы, и медленный хостинг или время ответа сервера.

 

CLS: Остаётся ли страница неподвижной во время загрузки?

CLS расшифровывается как Cumulative Layout Shift. Он измеряет, насколько страница визуально прыгает при загрузке. Вы сталкивались с плохим показателем CLS: хотите нажать на что-то, а в последнюю секунду загружается изображение выше, сдвигая всё вниз, и вы нажимаете не туда.

Порог: Хорошо = менее 0.1

Источник: Скриншот: Cumulative Layout Shift (CLS)

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

 

Как проверить все три

Перейти к Page Speed Insights и вводите свои самые важные страницы по одной:

• Ваша домашняя страница
• Страница вашего основного продукта или услуги
• Ваша самая посещаемая целевая страница

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

В GSC также есть специальный отчет Core Web Vitals (в разделе «Опыт»), который группирует ваши URL по статусу:

• Хорошо
• Требует улучшения
• Плохо

И показывает, какой конкретный показатель не работает на каких страницах.

Вот как это выглядит при аудите с помощью Google Page Speed:

Вы даже можете увидеть больше деталей о вашей оценке производительности.

 

Структура сайта и внутренняя перелинковка

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

 

Аудит глубины сканирования

Любая важная страница, находящаяся на расстоянии более трех кликов от главной, фактически погребена. В Screaming Frog проверьте столбец Crawl Depth. Страницы на глубине 4+ следует либо продвинуть в навигации, либо связать с более авторитетных страниц.

 

Страницы-сироты

Страница-сирота — это страница, на которую нет внутренних ссылок. Googlebot может найти её через карту сайта, но без внутренних ссылок она не получает вес и сигнализирует о низкой важности. Сверьте URL-адреса из вашей карты сайта с отчётом о входящих ссылках в Screaming Frog.

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

Цепочки и циклы перенаправлений

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

 

Мобильные устройства и структурированные данные

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

Google завершил переход на мобильно-ориентированное индексирование в июле 2024 года. Все сайты теперь сканируются и индексируются с помощью Googlebot Smartphone. Проверьте отчет о мобильной удобстве на наличие ошибок: текст слишком мелкий для чтения, кликабельные элементы расположены слишком близко друг к другу, контент шире экрана. Любые ошибки здесь Уровень 2 как минимум.

 

Структурированные данные

Schema-разметка не гарантирует расширенные результаты, но делает ваш контент читаемым для машин. Для большинства небольших сайтов наиболее ценными типами схем являются: Article, FAQ, Breadcrumb и Local Business (если это актуально для местоположения). Проверьте свою реализацию с помощью Тест Rich Results от Google.

Помечайте ошибки структурированных данных как Уровень 2. Помечайте предупреждения структурированных данных как Уровень 3. Они не мешают появлению расширенных результатов.

 

Проверьте исправление

Большинство руководств заканчиваются на "fix this." Вот где они вас подводят.

Каждое исправление требует шага подтверждения, прежде чем двигаться дальше.

Тип исправления	Метод проверки	Сроки
Индексация / удален noindex	Проверка URL в GSC → Запрос индексации	От дней до недель
Улучшения Core Web Vitals	Повторный запуск Page Speed Insights + отчет CWV в GSC	Задержка данных поля на 28 дней
Ошибки сканирования устранены	Повторный обход Screaming Frog; сравнить с базовым уровнем	Немедленно
Добавлены структурированные данные	Повторный тест Rich Results	Мгновенная проверка

Google переоценивает некоторые сигналы быстро (индексация на уровне URL) и другие медленно (данные CWV отражают скользящее 28-дневное окно реальных взаимодействий пользователей).

 

Когда следует проводить SEO-аудит?

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

 

Когда проводить повторный аудит

Технический SEO-аудит — это не разовая задача. Проведите полный аудит:

• При запуске нового веб-сайта — установите чистую базовую линию до накопления трафика
• Каждые 6 месяцев в рамках стандартного обслуживания
• После любой крупной миграции сайта (новая CMS, новый домен, новая структура URL)
• После значительного падения в выдаче что не объясняется изменениями контента
• После добавления новых разделов сайта или шаблонов которые могут привести к новым шаблонам сканирования

Между аудитами держите отчеты Coverage и Core Web Vitals в GSC открытыми как пассивный слой мониторинга.

 

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

Используйте это после завершения каждого раздела. Каждый пункт соответствует разделу выше.

 

Заключение

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

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

Техническое SEO поддерживает сканируемость, индексацию, производительность и пользовательский опыт, что может улучшить видимость в поиске в сочетании с качественным контентом. Регулярные аудиты (каждые 6-12 месяцев) необходимы для снижения рисков и использования новых возможностей.

Будьте впереди всех и подписаться на нашу рассылку для последних тенденций и инсайтов индустрии.

 

Часто задаваемые вопросы

 

В чем разница между проблемой сканирования и проблемой индексации?

Сканируемость означает, может ли Googlebot получить доступ к странице и прочитать ее (она заблокирована на уровне сети или robots). Индексация означает, решил ли Google включить эту страницу в свой поисковый индекс. Страница может быть сканируемой, но все равно исключена из индекса из-за тега noindex, сигнала дублированного контента или канонического тега, указывающего на другой URL. Анализируйте их отдельно: сначала сканируемость, затем индексацию.

 

Влияют ли цепочки редиректов на ранжирование?

Google заявил, что 301-редиректы не теряют Page Rank. Практический риск цепочек перенаправлений — это задержка (каждый переход увеличивает время загрузки) и повышенная вероятность того, что Googlebot прервет цепочку до полного разрешения, особенно на медленных серверах. Сокращайте цепочки до одного перехода как меру эффективности сканирования, а не потому, что каждый переход "теряет" вес.

 

Мой инструмент аудита выявил 200+ проблем. С чего мне вообще начать?

Начните с чек-листа первого уровня в этом руководстве: принудительное использование HTTPS, валидность SSL, случайные теги noindex и циклы перенаправлений. Это проблемы, которые с наибольшей вероятностью прямо сейчас подавляют видимость. Игнорируйте всё, что не относится к первому или второму уровню, пока они не будут решены. Чистый, доступный для сканирования и индексации сайт с приемлемыми Core Web Vitals превзойдет технически "идеальный" сайт с нерешенными блокирующими проблемами.

 

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

Каждые шесть месяцев в рамках стандартного обслуживания. Кроме того, проводите целенаправленный аудит после любого переноса сайта, значительного изменения платформы или необъяснимого падения позиций. Между аудитами отчёты Coverage и Core Web Vitals в GSC дают достаточно пассивных сигналов, чтобы заметить новые проблемы до их накопления.