Технический аудит чаще всего начинают со скорости, потому что скорость легко измерить и красиво показать в отчёте. Это неудачная точка входа. Страница, которая не в индексе, не станет полезнее от того, что загрузится за секунду. Порядок проверок должен повторять порядок, в котором поисковая система вообще добирается до страницы: найти, обойти, проиндексировать, ранжировать. Ниже — чеклист в этой логике.
Почему порядок важнее полноты
Аудит на сто пунктов, отданный клиенту списком, почти всегда даёт нулевой результат. Разработчик берёт первый пункт сверху, а сверху обычно стоит что-то дешёвое и безобидное — сжатие изображений, заголовки кеша. Проблема, из-за которой треть сайта не в индексе, лежит на семьдесят четвёртой строке.
Поэтому аудит полезнее вести как воронку. На каждом шаге вопрос один: сколько страниц потерялось именно здесь. Шаг, на котором потери максимальны, и есть работа на этот месяц.
Шаг 1. Что вообще находится в индексе
Первая цифра, которую нужно получить, — сколько страниц сайта в индексе против того, сколько их должно быть. Второе число берётся из карты сайта или из выгрузки CMS, первое — из панели вебмастера.
Разрыв читается так:
- В индексе заметно меньше, чем нужно, — проблема с обходом или с качеством страниц. Это главный сценарий, и дальше вся воронка про него.
- В индексе заметно больше — в индекс попало то, чего там быть не должно: страницы фильтров, сортировок, поиска по сайту, служебные адреса. Тоже проблема, просто обратная.
- Цифры сходятся — технически сайт, скорее всего, здоров, и искать надо в контенте и ссылках.
Отдельно стоит посмотреть причины исключения, которые панель называет сама. Для российских проектов это критично: Яндекс и Google исключают страницы по разным основаниям, и сайт может быть полностью в индексе одного и наполовину в индексе другого.
Шаг 2. Карта сайта и robots.txt
Два файла, которые ломаются чаще, чем кажется, и ломаются тихо.
По карте сайта проверяем: отдаётся ли она кодом 200, перечислены ли в ней только страницы, отвечающие 200, есть ли lastmod и не проставлен ли он датой сборки. Последнее встречается постоянно и вредит: если каждый деплой заявляет, что изменились все страницы, поисковая система перестаёт доверять полю целиком.
По robots.txt: указан ли путь к карте, не закрыты ли по инерции разделы, которые давно должны быть открыты, не закрыты ли статика и скрипты. Закрытый CSS и JS — старая ошибка, но она до сих пор встречается и мешает поисковой системе увидеть страницу так, как её видит человек.
Проверять надо на живом адресе, а не в исходниках проекта. Хостинг умеет переписывать пути и отдавать не то, что лежит в репозитории, — и расхождение между тем, что собрано, и тем, что отдаётся, обнаруживается только запросом к настоящему URL.
Шаг 3. Коды ответа и цепочки редиректов
Обход сайта краулером даёт распределение кодов ответа. Норма выглядит так: подавляющее большинство 200, небольшая доля 301 на старых адресах, ноль 5xx.
Что требует вмешательства:
- Цепочки редиректов длиннее одного шага. Каждое звено — потерянное время обхода. Цепочка из четырёх переходов встречается на сайтах, переезжавших дважды.
- Редиректы в карте сайта. Карта должна содержать конечные адреса, а не промежуточные.
- Софт-404 — страница отвечает 200 и показывает «ничего не найдено». Для поисковой системы это полноценная страница, и она копится в индексе.
- 5xx под нагрузкой. Проверять стоит в час пик, а не ночью.
Шаг 4. Канонические адреса и дубли
Дубли — самая частая причина, по которой в индексе оказывается вдвое больше страниц, чем на сайте.
Минимальный набор проверок: один ли адрес у главной (со слешем и без, с www и без, http и https сводятся в один), отдают ли страницы фильтров и сортировок канонический адрес на базовую категорию, не ссылается ли canonical сам на редирект, совпадает ли канонический адрес с тем, что стоит в карте сайта.
Отдельная история — пагинация. Канонический адрес второй страницы листинга должен указывать на саму вторую страницу, а не на первую: иначе поисковая система теряет доступ к товарам, которые есть только там.
Шаг 5. Скорость и Core Web Vitals
Теперь, когда страница находится и индексируется, есть смысл говорить о скорости. Google публикует три метрики и пороги «хорошо»: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1 (web.dev/articles/vitals, сверено 19 сентября 2026). INP заменил FID и стал стабильной метрикой в 2024 году, так что рекомендации, которые всё ещё говорят про FID, устарели.
Практическая часть, которую пропускают: лабораторные измерения и полевые данные — разные вещи. Лабораторный тест на быстром канале покажет отличный результат для сайта, который у реальных пользователей грузится четыре секунды. Решение принимайте по полевым данным, а лабораторный тест используйте для поиска причины.
Из трёх метрик CLS обычно чинится дешевле всего и заметнее всего: у изображений и рекламных блоков не заданы размеры, страница прыгает при загрузке. Это правка на час.
Шаг 6. Мобильная версия
Индексирование давно идёт по мобильной версии, поэтому проверять надо именно её, и проверять на содержимое, а не на вёрстку.
Ключевой вопрос: совпадает ли текст, разметка и набор ссылок на мобильной и десктопной версии. Урезанная мобильная версия, в которой спрятали половину текста и убрали блок ссылок, — это и есть та версия, которую видит поисковая система.
Дальше по мелочи: читаемый без увеличения шрифт, элементы управления, по которым можно попасть пальцем, отсутствие горизонтальной прокрутки, перекрытия контента баннерами согласия.
Шаг 7. Разметка
Структурированные данные не поднимают позиции сами по себе, но меняют то, как выглядит сниппет, и это влияет на кликабельность.
Что стоит проверить: валидна ли разметка, соответствует ли она тому, что реально есть на странице, нет ли дублирующихся блоков одного типа. Последнее ломает расширенный сниппет чаще, чем ошибка в синтаксисе: два блока FAQ на странице — и поисковая система не показывает ни одного.
И правило, которое стоит дороже остальных: разметка не должна утверждать то, чего на странице нет. Рейтинг в разметке при отсутствии отзывов на странице — это повод для санкции.
Шаг 8. Внутренние ссылки
Последний шаг, и он объясняет большую часть «страница есть, но не в индексе».
Смотрим глубину вложенности: сколько кликов от главной до типичной страницы. Три — нормально, пять и больше — страница фактически недоступна для обхода. Смотрим страницы-сироты: есть в карте сайта, но на них не ведёт ни одна внутренняя ссылка. Смотрим анкоры: если все ссылки называются «подробнее», поисковая система не получает никакого сигнала о теме страницы.
Сироты и перелинковка чинятся структурой, а не списком правок: страницы должны группироваться по темам, а темы — ссылаться друг на друга. Откуда эти группы берутся, разобрано в материале про кластеризацию семантического ядра.
Чем это делать и сколько стоит
Панели вебмастера бесплатны и обязательны — без них первый шаг вообще не выполняется. Платные инструменты нужны для обхода сайта и для сравнения с конкурентами.
| Задача | Инструмент | Через gbseo.ru | Розница |
|---|---|---|---|
| Обход сайта, коды ответа, дубли |  Semrush Guru | 499₽/мес | 10 000₽/мес |
| Аудит, внутренние ссылки, сироты |  Ahrefs Advanced | 1 999₽/мес | 9 000₽/мес |
| Разбор логов и выгрузок |  Claude Pro | 399₽/мес | 1 800₽/мес |
| Схемы и отчёт для клиента |  Canva Pro | 499₽/мес | 1 200₽/мес |
Цены по данным каталога gbseo.ru на 19 сентября 2026; «розница» — цена той же подписки у вендора. Набор целиком — 4 999₽ в месяц против 36 700₽ по розничным ценам, калькулятор на главной посчитает любой поднабор.
Отдельно про языковые модели в аудите. Они бесполезны там, где нужно обойти сайт, и заметно полезны там, где нужно разобрать результат обхода: выгрузка на сорок тысяч строк, из которой надо достать закономерность, — это ровно та работа, которую человек делает медленно и с ошибками.
Как расставить приоритет
После обхода получается список на сотни строк. Разложить его по важности помогает одна таблица: сколько страниц затронуто и что страница теряет.
| Приоритет | Что это обычно |
|---|---|
| Сначала | Страницы не в индексе; 5xx; закрытые разделы; массовые дубли |
| Потом | Цепочки редиректов; софт-404; сироты; глубина вложенности |
| Дальше | Core Web Vitals; разметка; анкоры |
| Когда дойдут руки | Косметика в заголовках, alt у декоративных изображений |
Аудит, который не заканчивается этим порядком, — это инвентаризация. Про то, как результат превращается в понятный клиенту отчёт, есть отдельный разбор рабочего стека.
Частые вопросы
Как часто проводить технический аудит?
Полный — раз в полгода и обязательно после любого переезда, смены CMS или редизайна. Короткую проверку индексации и кодов ответа имеет смысл делать ежемесячно: она занимает полчаса и ловит большую часть аварий.
Нужен ли платный краулер для маленького сайта?
Для сайта на пятьдесят страниц — нет, панели вебмастера хватит. Платный инструмент начинает окупаться там, где страниц несколько сотен и глазами их уже не просмотреть.
Что делать, если Яндекс индексирует, а Google нет?
Проверить, не различаются ли robots.txt и коды ответа для разных краулеров, и посмотреть причины исключения в Search Console отдельно. Расхождение между системами почти всегда означает не общую техническую проблему, а что-то специфичное для одной из них.
Стоит ли чинить Core Web Vitals, если позиции и так неплохие?
CLS — да, это дёшево и заметно пользователю. LCP и INP на сайте, который уже ранжируется, стоит трогать после того, как закрыты индексация и дубли: выигрыш от них меньше, а работа дороже.
Сколько занимает первый аудит?
Сайт на несколько тысяч страниц — два-три дня вместе с разбором выгрузки и приоритизацией. Основное время уходит не на обход, а на то, чтобы превратить список проблем в порядок действий.