Как я делаю SEO аудит сайта: полный пайплайн

TL;DR

Аудит сайта я делаю сам, руками, через собственные скрипты и инструменты – нейросеть в этом процессе участвует только в двух узких местах: помогает писать код скриптов сбора данных и сводит мои разрозненные заметки в читаемый черновик отчёта. Весь анализ, интерпретация метрик и решение, что критично, а что подождёт, – моя работа. Дальше по шагам: разведка, три обязательных блока для любого сайта, углублённая проверка, волна дополнительных проверок под конкретный тип бизнеса и финальная сборка отчёта.

После прошлого поста в моем телеграмм (подписывайтесь кстати) у меня начали спрашивать: а точно ли аудит я делаю сам, руками, а не запускаю какой-то автоматический сценарий и просто копирую результат себе в отчёт? Вопрос закономерный – про автоматизацию в SEO сейчас говорят на каждом углу, и слово «аудит» стало ассоциироваться с кнопкой «запустить» и пятиминутным ожиданием. У меня всё устроено иначе, и раз возник вопрос, разберу процесс по шагам целиком – с названиями скриптов, логикой и тем, что реально получаю на выходе на каждом этапе.

Сразу закрою тему нейросети, потому что вопрос именно в этом. Использую её в двух точках. Первая – при написании самих Python-скриптов, которые собирают данные: код пишется быстрее, если черновой вариант накидывает модель, а я его правлю и адаптирую под конкретную задачу. Вторая точка – в самом конце, когда у меня на руках десятки заметок, цифр и наблюдений, собранных вручную по ходу работы. Это каша из мыслей, поток сознания, который нужно превратить в читаемый отчёт – вот тут помощник сводит текст в структуру, а я проверяю каждый факт и правлю формулировки. Сам анализ сайта, выбор, что проверять глубже, приоритизация находок – всё это делаю я, глазами и головой, глядя в цифры, которые выдают мои инструменты.

Дальше распишу по шагам, из чего состоит мой аудит. Название скриптов даю, сам код – нет, это, простите, мой рабочий инструмент, который меня кормит. Можно попробовать собрать похожий пайплайн самостоятельно, но без опыта в анализе конкретный набор скриптов и сырые цифры дадут мало пользы  Цифры без интерпретации это просто цифры.

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

Шаг 0. Разведка

Первый шаг любого аудита – понять, с чем я вообще работаю. Без этого этапа можно потратить полдня на глубокую проверку структурированных данных на сайте, где нет даже нормального robots.txt.

Цель разведки – собрать фактуру и решить, какие дополнительные проверки на шаге 3 вообще запускать. Если сайт не локальный бизнес, зачем гонять проверки? Если у сайта нет блога, зачем анализировать каннибализацию ключевых слов?

Вот что я прогоняю на этом этапе и зачем:

Скрипт / инструмент	Что смотрю	Что получаю
sitemap_discovery	Есть ли sitemap.xml, robots.txt, сколько карт и какого типа	Понимание, закрыты ли важные разделы сайта от индексации в robots, есть ли sitemapindex (карта карт для крупных сайтов)
render_page –mode auto –json	HTML-код, тип рендеринга, извлечённый текст, дата публикации	SPA (сайт, который собирается прямо в браузере пользователя, а не отдаётся готовым HTML) или классический SSR; обрезан ли текст – сигнал, что нужно проверить через curl
curl по массиву адресов (/about, /pricing, /blog, /contacts и заведомо несуществующий адрес)	Коды ответа, заголовки, время до первого байта, редиректы	200 на живых страницах, 404 на несуществующей, корректный редирект с http на https, включено ли сжатие и кэширование
adv_crawl с лимитом в несколько сотен страниц	title, meta, h1, статус, редиректы по выборке страниц	Распределение статусов ответов, дубли title и meta, страницы без h1, несовпадение canonical
adv_urls	Структура путей и параметров	Разбивка по разделам сайта, UTM-мусор в индексе, локализация, потенциальная каннибализация
yandex_webmaster_list_hosts	Добавлен ли сайт в Яндекс.Вебмастер	Если нет – первая рекомендация в отчёт: зарегистрировать
yandex_metrika_list_counters	Установлен ли счётчик Метрики	Если да – дальше тяну оттуда топ страниц и трафик для текстовой аналитики
поисковый запрос по домену с исключением самого домена	Внешние упоминания, конкуренты	Кто пишет о сайте, кто конкурирует за внимание в выдаче

На выходе из этого шага у меня заметка с базовыми сигналами о сайте – что это за проект, какая CMS, есть ли явные технические проблемы на поверхности, куда смотреть глубже. Часто уже здесь видно направление: если curl показывает, что половина сайта отдаёт 404 на реально существующие страницы – заметка превращается в приоритет номер один для отчёта.

Шаг 1. Ядро: технический аудит, контент и структурированные данные

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

Технический аудит

Здесь смотрю на всё, что мешает поисковым роботам нормально обходить и понимать сайт. Использую те же render_page и sitemap_discovery с предыдущего шага, плюс adv_urls и проверку безопасности URL. Если на разведке уже был быстрый краул – подтягиваю его результаты, чтобы не гонять запросы повторно.

Анализирую доступность страниц для сканирования – закрыты ли важные разделы в robots.txt или через тег noindex. Проверяю индексируемость: совпадают ли canonical-ссылки с реальным адресом страницы, нет ли дублей контента, нет ли тонких страниц (страницы которые поисковики считаю ненужными) с минимумом текста. Смотрю на защитные заголовки сервера, структуру URL и логику редиректов, адаптивность под мобильные устройства, потенциал по скорости загрузки, зависимость контента от JavaScript-рендеринга и поддержку IndexNow (протокол быстрого уведомления поисковиков об изменениях на сайте).

На выходе получаю оценку по каждой категории – прошел сайт проверку или нет, общий технический балл от 0 до 100 и список находок, разложенных по приоритету: критично, высокий, средний, низкий.

Чаще всего технические проблемы прячутся не в очевидных местах типа robots.txt, а в мелочах: canonical, который указывает на несуществующую версию страницы после смены домена, или редирект-цепочка из трёх-четырёх прыжков там, где должен быть один прямой переход.

Контент и E-E-A-T

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

Оцениваю по модели E-E-A-T (Experience, Expertise, Authoritativeness, Trust – опыт автора, экспертность, авторитетность источника и доверие к сайту), с весами: опыт – 20%, экспертность – 25%, авторитетность – 25%, доверие – 30%.

Смотрю на объём текста в привязке к типу страницы (карточка товара и статья в блоге требуют разного объёма), читаемость, признаки текста, написанного нейросетью без правки, YMYL-сигналы (Your Money Your Life – страницы, которые влияют на деньги или здоровье человека, для них требования жёстче: наличие юридических реквизитов, дисклеймеров), и потенциал цитируемости текста в ответах ИИ-сервисов.

На выходе – контентный балл, разбивка по E-E-A-T, оценка готовности к цитированию и флаги там, где текст тонкий, филлерный (набор слов без пользы) или написан по шаблонным AI паттернам без редактуры.

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

Третий блок – разметка schema.org (стандарт очень актуален в 2026. Он помогает поисковикам и AI понимать структуру страницы: где цена, где отзыв, где автор).

Смотрю на валидность JSON-LD и microdata, наличие устаревших типов разметки – FAQPage и HowTo, например, поисковики уже не показывают в расширенных сниппетах, хотя формально разметка ещё валидна. Проверяю обязательные поля и то, какие возможности разметки сайт вообще не использует, хотя мог бы.

На выходе – разбор по блокам разметки и сразу пишу готовые фрагменты JSON-LD, которые можно сразу отдать разработчику для внедрения.

Шаг 2. Углубляюсь

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

Скорость загрузки и Core Web Vitals

Core Web Vitals (CWV) – набор метрик Google, которые оценивают реальный опыт пользователя на странице: скорость появления главного контента, скорость реакции на действия и стабильность вёрстки при загрузке.

Проверяю через PageSpeed Insights и историю данных CrUX (Chrome User Experience Report – реальные данные пользователей Chrome, а не лабораторные замеры). Дополнительно разбираю составляющие метрики LCP (время до отрисовки самого крупного видимого элемента), чтобы понять, что именно тормозит: сервер, шрифты, изображения или скрипты.

Если PageSpeed упирается в лимит запросов, а данных CrUX по сайту недостаточно – переключаюсь на ручной разбор: матрица таймингов через curl плюс лабораторные замеры в браузере. Это медленнее, но важно получить данные в любом случае.

Смотрю на LCP, INP (задержка отклика на действие пользователя) и CLS (насколько сильно сдвигаются элементы при загрузке) по 75-му перцентилю полевых данных (раскажу что это ниже) – именно этот показатель Google использует для ранжирования, а не средние значения. Дальше – время до первого байта, ресурсы, блокирующие рендеринг, оптимизация изображений и нагрузка от сторонних скриптов.

Суть 75-го перцентиля

Среднее арифметическое искажает картину: редкие заходы с гигабитным интернетом или старых смартфонов сдвигают значение. Перцентиль отсекает аномалии.

75-й перцентиль показывает: 75% сессий реальных посетителей загружаются быстрее или равны указанной отметке. Если 75-й перцентиль LCP составляет 2,2 секунды, три четверти всех заходов на сайт помещаются в эти рамки.

На выходе – балл по производительности, статус по каждой метрике (прошла или нет порог) и список конкретных узких мест с ожидаемым эффектом от исправления.

Карта сайта

Отдельно разбираю sitemap.xml. По какой-то причине про него все чаще забывают, а очень зря. Файл очень важен. 

Проверяю валидность XML-структуры, актуальность дат последнего изменения страниц (часто дата стоит одна и та же на всех страницах – верный признак, что карта генерируется автоматически и никто её не проверяет), покрытие живых страниц картой сайта и обратно, лимиты в 50 тысяч адресов на файл.

Для сайтов с локациями (например, сети с филиалами) применяю более жёсткие пороги: если больше 30 страниц-локаций требуют внимания – предупреждение, больше 50 – жёсткая остановка и разбор до продолжения аудита, потому что при таком масштабе ошибка в шаблоне размножается на сотни страниц.

На выходе – отчёт по валидации, балл по карте сайта и список страниц, которые отсутствуют в карте или, наоборот, попали туда по ошибке.

Визуальная и мобильная проверка

Здесь иду на сайт ручками и проверяю десктопную и мобильную версии сайта, причём мобильную версию смотрю именно с подменой User-Agent на iPhone – некоторые сайты отдают разную вёрстку в зависимости от того, кто к ним обращается, и без подмены агента можно не увидеть реальную мобильную картину.

Проверяю первый экран без скролла: виден ли заголовок H1, есть ли кнопка действия (CTA), не перекрывает ли что-то главный визуальный блок. Смотрю на размер шрифта – меньше 12-14 пикселей читать неудобно с телефона. Проверяю размер тач-зон для кнопок – меньше 44 пикселей – ошибка. Ищу горизонтальный скролл на мобильной версии, изображения без заданных размеров (из-за чего страница дёргается при загрузке) и перекрытия элементов друг другом.

На выходе – вердикт по мобильной адаптивности, основанный на конкретных фактах, а не на общем впечатлении, и визуальный балл.

Логи сервера

Этот блок делаю только если клиент даёт доступ к логам сервера – без них тут нечего анализировать. Зато если доступ есть, это едва ли не самая ценная часть аудита, потому что показывает то, чего не видно ни в Search Console, ни в Метрике.

Смотрю на реальный расход краулингового бюджета – какой процент запросов к серверу приходится на Googlebot и YandexBot, какие страницы боты посещают чаще, какие игнорируют. Ищу 404-ошибки в логах, которых нет в отчётах поисковых систем – часто это старые ссылки, по которым до сих пор кто-то заходит. Смотрю на нагрузку от переходов и нестандартные обращения к путям типа /.env или /login – это уже вопрос безопасности, не только SEO.

Шаг 3. Волна по индикаторам

Шаг 0 определяет, какие дополнительные проверки вообще имеет смысл запускать. Гонять анализ каннибализации ключевых слов на сайте-визитке из пяти страниц – трата времени. Поэтому шаг 3 – это набор модулей, которые включаются точечно, по триггерам с разведки.

Готовность к цитированию в ИИ-сервисах

Этот модуль запускаю почти всегда, потому что почти любой владелец сайта в 2026 году должен быть заинтересован, чтобы его контент упоминался в ответах ChatGPT, Perplexity и в AI выдаче поисковиков. Проверяю robots.txt на предмет того, разрешён ли доступ ботам этих сервисов – GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot.

Смотрю на файл llms.txt – тут важно, этот файл не рычаг влияния, потому что крупные поисковики его просто игнорируют при формировании ответов. Больший вес имеет то, насколько текст на странице цитируемый по структуре – короткие законченные фрагменты в диапазоне 130-170 слов лучше вырываются моделью в чистом виде, чем длинные абзацы со множеством вложенных мыслей. Плюс смотрю на сигналы авторитетности бренда – упоминания в Wikipedia, Reddit, VC.ru, Habr, Двач (самому смешно, но для русского контента он для AI почти как reddit для всего остального мира), Пикабу и конечно на YouTube.

На выходе – балл готовности по нескольким измерениям и отдельные оценки по площадкам: как сайт скорее всего будет представлен в обзорах Google, в ответах ChatGPT и в Perplexity.

Профиль ссылочной массы

Backlinks проверяю по каскаду источников – сначала быстрый бесплатный CommonCrawl, если он не выдает достаточно данных – тогда платный API ahrefs. Плюс данные из вебмастера и серч консоли.

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

Смотрю на количество уникальных доменов, которые ссылаются на сайт, на распределение по авторитетности этих доменов, естественность анкорного текста (если 80% ссылок ведут с одинаковой фразой – это подозрительно), долю токсичных ссылок, соотношение follow и nofollow ссылок, географическую релевантность доноров.

Каннибализация и структура контента

Этот блок включаю, если у сайта есть блог или структура из пилларных статей. Собираю семантическое ядро, анализирую тексты, ищу каннибализацию ключевых слов, страницы в зоне «почти в топе» (позиции с 4-й по 20-ю), разрыв между title страницы и ключевыми словами, под которые она реально ранжируется, и долю голоса (share of voice) через кривую CTR по позициям.

На выходе – план по кластерам запросов, структура «хаб и спутники» и разбор конкретных случаев каннибализации с рекомендацией, какую страницу оставить приоритетной.

Интернет-магазин

Для сайтов с карточками товаров запускаю отдельные проверки. Проверяю валидность разметки товаров, размеры изображений карточек, поиск скрытых 404-ошибок (когда страница отдаёт 200, но контент шаблонный, будто товара нет), двойной H1 на странице, шаблонные метатеги без уникализации, отсутствие блока похожих товаров, проверка файла price.xml – он может быть разрешён в robots.txt, но физически не существовать на сервере.

На выходе – балл по электронной коммерции и разбор конкретных карточек с находками.

Мультиязычность и данные из GSC/GA4

Если сайт работает на нескольких языках или локалях – проверяю hreflang (атрибут, который указывает поисковику, какая языковая версия страницы для какой аудитории). Если у клиента есть доступ к Google Search Console и Google Analytics 4: смотрю запросы, проверяю индексацию конкретных URL, вытягиваю отчёты по трафику. Без доступов к этим сервисам данная часть просто не запускается – гадать по чужим данным нет смысла.

Шаг 3.5. Текстовая аналитика: только по трафиковым страницам

Отдельно вынес текстовую аналитику, потому что здесь у меня жёсткое правило – не гонять её на весь сайт целиком. Смысла в этом нет: если страница не получает трафика и не входит в топ запросов, разбор частотности слов на ней ничего не даёт для приоритизации.

Беру список страниц из отчёта по поисковым запросам Google Search Console или из топа посещаемых страниц по данным Метрики. По этим страницам считаю частотность слов и биграммы – пары слов, идущих подряд.

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

На выходе – профиль частотности по каждой топовой странице, который идёт в подпитку контентному блоку аудита из шага 1. Часто именно здесь всплывает несоответствие: страница формально написана «под запрос», но по факту фокус текста смещён на смежную тему, а сама целевая фраза упомянута один раз в первом абзаце и больше не встречается.

Шаг 4. Синтез: как из десятка отчётов получается один документ

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

Читаю полные версии всех промежуточных отчётов от скриптов. Собираю финальный документ: сводную таблицу баллов от 0 до 100 по каждой области аудита и план действий, разбитый на три уровня – критично, предупреждение, пройдено успешно.

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

Готовый отчёт сохраняю в +- структурированном виде, прогоняю через LLM.

Сколько это занимает и что получает клиент на руках

Весь пайплайн от разведки до финального отчёта занимает по опыту от нескольких часов до пары дней – зависит от размера сайта, количества модулей, которые сработали на шаге 0, и от того, есть ли доступ к логам сервера и аналитическим сервисам. Сайт-визитка из десятка страниц проходит все три обязательных блока быстро. Крупный интернет-магазин с блогом, пунктами выдачи и историей предыдущих аудитов – уже совсем другие временные затраты.

На выходе клиент получает не список из двадцати пунктов «сделайте лучше» и копипастой из лайтхауса, а документ с баллами по каждой области, приоритизированный план действий и по каждому пункту – основание, зависимости, критерий провала и метрику для мониторинга. Это разница между «у вас медленный сайт» и «LCP превышает 4 секунды из-за сжатых изображений в шапке, ожидаемый эффект после сжатия – возврат в зелёную зону по 75-му перцентилю в течение нескольких недель».

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