Полный чек-лист технического SEO-аудита 2026

Худший момент для технического аудита - когда команда уже сидит внутри падения, а у SEO-специалиста на руках только график с минусом и срочное требование «вернуть как было». Лучший момент - раньше, когда симптомы только копятся: бот ходит не туда, важные страницы уходят глубже, sitemap устаревает, а JS-шаблоны постепенно расщепляют индекс на то, что видит пользователь, и то, что видит Google. И главный смысл аудита здесь простой: не собрать 70 замечаний, а найти 3 точки роста или 3 точки падения, которые реально двигают результат.

Зачем техаудит нужен именно сейчас, а не «когда упадёт трафик»

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

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

Чек-лист техаудита: 6 зон контроля

Раздел 1. Краулинг и индексация

Это стартовый модуль. Если здесь все собрано плохо, остальные улучшения ослабевают. Я почти всегда начинаю с вопроса не «какие ошибки есть», а «на что бот тратит внимание и что из этого реально попадает в индекс».

Crawl budget: как понять, что Googlebot теряет страницы

У большинства сайтов проблема не в том, что crawl budget закончился как абстрактная квота, а в том, что он распределяется не в пользу ключевых сегментов. Бот может тратить сессии на фильтры, внутренний поиск, сортировки, дубль-страницы пагинации, устаревшие URL после миграций и технические хабы, которые не должны конкурировать за внимание с категориями или статьями.

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

Файлы crawl-логов: что искать и как читать

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

Смотрите user-agent, частоту обращений, коды ответа, глубину URL-паттернов и разрывы по времени. Если важный раздел обновлялся, а бот почти не пришёл, это один сценарий. Если бот сжигает тысячи запросов на бесконечные параметры и 301-цепочки, это другой сценарий. В обоих случаях лог нужен не для красивой таблицы, а чтобы найти ненормальное распределение обхода.

Orphan pages и дыры в архитектуре

Orphan page - это не просто страница без внутренних ссылок в Screaming Frog. Это страница, которая существует для CMS, для sitemap или для случайного внешнего входа, но не встроена в живую архитектуру сайта. Такие URL легко теряются: бот может знать о них, но не считать их устойчиво важными.

Сопоставьте crawl, экспорт внутренних ссылок и sitemap. Если страница есть в карте сайта, но на неё нельзя нормально дойти из навигации, подборок, хлебных крошек, списков или контекстных ссылок, это архитектурная дыра. Особенно опасно, когда orphan становятся статьи под спрос, фильтрные посадочные или коммерческие URL после редизайна.

Раздел 2. Robots.txt и sitemap.xml

Этот блок часто недооценивают, потому что robots.txt и sitemap.xml кажутся базовой техничкой, которую уже кто-то однажды настроил. Но именно здесь живут самые неприятные ошибки: случайно закрытые папки, устаревшие директивы, битые URL в карте, расхождение между желаемым и реальным индексируемым слоем и просто неверный синтаксис правил. Частая ошибка: `*` ставят машинально, хотя в конце он обычно не нужен, а корректное правило должно начинаться с `/`.

Типичные ошибки в robots.txt, которые режут индексацию

Классическая ошибка - блокировка не того паттерна. Один неосторожный `Disallow`, и вы режете не только служебные URL, но и часть продуктовых страниц. Часто это происходит после доработок на шаблонах, когда новые URL подпадают под старые правила, написанные под другую структуру сайта.

Вторая проблема - вера в то, что robots.txt умеет всё. Он регулирует обход, но не заменяет мета-директивы, canonical и нормальную архитектуру индекса. Если дубли уже внешне доступны и на них ведут внутренние ссылки, только robots.txt редко решает вопрос системно. Он может даже скрыть проблему от краулера, но не убрать ее причину.

Sitemap: структура, частота, актуальность URL

Хорошая карта сайта - это не dump всех URL из базы, а curated-слой того, что вы хотите видеть в индексе. В sitemap не должно быть 404, временных редиректов, noindex-страниц, каноникализированных дублей и URL, которые уже не играют роли в росте. Карта должна отражать текущую стратегию сайта, а не архив CMS.

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

Noindex, X-Robots-Tag и soft 404: забытый слой индексации

Между `robots.txt` и `canonical` есть ещё один критичный слой: meta robots, `x-robots-tag` в HTTP-заголовках и soft 404. Именно здесь часто возникают тихие конфликты. Страница может быть доступна для обхода, попадать в sitemap, получать внутренние ссылки и при этом не индексироваться из-за `noindex`, заголовочного `x-robots-tag` или потому, что для Google она выглядит как низкоценная и фактически пустая.

Soft 404 особенно опасны на шаблонных и фильтрных страницах. Формально сервер отдаёт `200`, но поисковик видит тонкий, повторяющийся или бессмысленный слой контента и перестаёт воспринимать URL как полноценную страницу. Поэтому в техаудите важно проверять не только код ответа, но и реальную ценность шаблона.

Раздел 3. Canonical, редиректы, дубли

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

Canonical: когда помогает, когда игнорируется

Canonical - это подсказка, а не приказ. Он помогает, когда страница-донор действительно похожа на основную, когда контент и роль URL понятны, а внутренняя логика сайта не противоречит этому сигналу. Если же вы ставите canonical с фильтра на категорию, но при этом активно ссылаетесь на фильтр, держите его в sitemap и даете ему отдельный title, поисковик получает смешанное сообщение.

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

Цепочки редиректов и петли

Один лишний редирект редко ломает проект, но массовые цепочки постоянно жгут краулинг и замедляют пересборку индекса. Особенно плохо, когда наслаиваются миграции, http/https-правила, слеши, языковые версии и временные костыли после релизов.

Проверьте не только факт 301, но и длину маршрута. Цель - короткий путь от старого URL к актуальному конечному адресу. Если видите 301 → 302 → 200 или циклический возврат через промежуточный паттерн, это уже задача в высокий приоритет. Такие штуки редко заметны пользователю, но отлично видны в логах и краулере.

Дублированный контент: параметры, фильтры, пагинация

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

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

Раздел 4. JavaScript SEO и рендеринг

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

Google давно говорит, что умеет рендерить JavaScript. Формально это верно, но из этого часто делают неверный вывод, будто проблем уже нет. На деле рендеринг не мгновенный. В документации Google Search Central прямо сказано, что страницы ставятся в отдельную очередь и обрабатываются once Google’s resources allow. То есть сам Google подтверждает: всё упирается в доступные мощности.

Это подтверждают и сильные специалисты. В AMA Sam Torres для Sitebulb прямо сказано, что у Google есть отдельные crawl queue и rendering queue. Исследования Onely показывают, что JS-зависимый контент требует кратно больше усилий для discovery и crawl. А в другом разборе Onely отдельно подчёркивает: Google учитывает CPU cost рендеринга, а тяжёлые скрипты могут приводить к partial indexing.

Как понять, что Google видит не то, что видит пользователь

Сравнивайте исходный HTML, рендеренную DOM-версию и пользовательский экран. Если ключевой контент, ссылки, тексты, таблицы, блоки FAQ, товары или навигация появляются только после исполнения JS, задайте себе простой вопрос: успевают ли они стабильно доходить до поискового рендера и не завязаны ли они на пользовательские события.

Тревожный признак - когда важные элементы видны человеку, но отсутствуют в `view-source`, в статическом крауле или в инструментах проверки URL. Тогда нужно разбираться, что именно выполняется поздно: запросы к API, клиентские роуты, lazy-blocks, аккордеоны, подгрузка карточек, хлебные крошки или навигационные ссылки.

SSR, CSR, ISR — что выбирать и почему это влияет на индексацию

Для SEO вопрос не в моде стека, а в предсказуемости доставки контента. SSR обычно дает самый понятный базовый HTML и быстрее снижает риск пустых страниц. CSR удобен в продуктовой разработке, но повышает требования к рендерингу и может скрывать контент за гидрацией. ISR занимает промежуточное положение: он полезен там, где страницы должны быть заранее доступны, но при этом регулярно обновляться.

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

Инструменты проверки рендеринга

Минимальный набор лучше собирать из реальных бесплатных инструментов. База такая: Google Search Console URL Inspection для live/indexed версии страницы, Google Rich Results Test для быстрого просмотра отрендеренного HTML и structured data, Bing Webmaster Tools URL Inspection для второго взгляда, бесплатный Screaming Frog SEO Spider с JS-rendering до 500 URL и DevTools в Chrome или Edge: `view-source`, DOM, Network, отключение JavaScript и проверка XHR/API. Важно не открыть один инструмент, а сравнить несколько слоёв одной страницы.

Раздел 5. Core Web Vitals

CWV остаются важны, но вокруг них по-прежнему много шума. В аудите это не магический переключатель ранжирования, а индикатор реального UX и дисциплины фронтенда. Чаще сайт теряет не из-за разницы LCP в 0,2 секунды, а потому что слабая производительность идёт в связке с рендерингом, тяжёлыми шаблонами и нестабильной структурой страницы.

LCP, CLS, INP — что реально влияет на ранжирование в 2026

Сильнее всего CWV работают как часть общей картины. Если страница релевантна, индексируется и получает хорошие сигналы качества, улучшение LCP, CLS и INP помогает убрать трение. Но если архитектура сломана, одни только метрики не вытянут проект. Поэтому CWV должны проверяться после краулинга и индексации, а не вместо них.

Особое внимание сейчас стоит уделять LCP-элементу на мобильных шаблонах, сдвигам интерфейса из-за поздних баннеров, consent-слоев и нестабильных медиа-блоков, а также INP на страницах с тяжелыми фильтрами и виджетами. Это те места, где SEO и фронтенд уже давно сходятся в одной задаче.

Как читать отчёт GSC по CWV и не запутаться в лабораторных vs. полевых данных

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

Ошибка здесь типовая: команда гоняется за зелёной лабораторной картинкой, не проверяя, изменилась ли группа URL в GSC. Или наоборот: видит плохую группу в Search Console и не может локализовать причину на конкретном шаблоне. Поэтому в аудите CWV нужно сводить три слоя в один вывод: какая группа URL страдает, какой шаблон общий и какой элемент реально ломает метрику.

Раздел 6. Внутренняя перелинковка и архитектура

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

Как архитектура сайта влияет на PageRank и видимость кластеров

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

Для кластера важно не только количество ссылок, но и их контекст. Хлебные крошки, навигационные блоки, подборки, блоки «см. также», связи между статьями и коммерческими страницами дают разную силу сигнала. Техаудит должен смотреть на перелинковку как на управляемый PageRank, а не как на декоративный слой интерфейса.

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

Orphan pages, изолированные разделы, дыры в перелинковке

Orphan pages уже были в первом разделе, но на уровне архитектуры их стоит посмотреть отдельно. Здесь важен не просто факт отсутствия ссылок, а карта изоляции. Бывает, что раздел формально связан, но только через одну страницу или только через футер. Для бота это слабая интеграция, а не полноценное место в структуре.

Проверьте, не живут ли важные страницы только за счёт sitemap, XML-фида, поиска по сайту или исторических внешних ссылок. Если да, значит архитектура не подтверждает их приоритет. Это одна из самых частых причин, почему хорошие по смыслу URL получают слабую видимость.

Как проверить глубину залегания важных страниц

Сначала определите список страниц, которые действительно должны быть видимыми: категории, региональные посадочные, статьи под спрос, страницы услуг, фильтрные URL с подтвержденным спросом. Потом измерьте click depth и сравните его с реальной ролью страницы. Если денежный URL лежит на глубине 5-6 кликов, а шумный фильтр - на глубине 2, структура уже говорит поиску не то, что вы хотите сказать бизнесу.

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

Что приоритизировать первым: матрица «влияние vs. трудозатраты»

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

FAQ: короткие ответы по техаудиту

Итог: чек-лист — это старт, а не результат

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

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

Кириченко Станислав

20+ лет в SEO, техаудиты, second opinion, AI-автоматизация · Подробнее обо мне