Коротко: технический аудит показывает, что мешает поисковым роботам обходить сайт, читать контент и распределять ссылочный вес. Без этой диагностики любые работы над семантикой и текстами упираются в потолок. Разбираем шесть этапов проверки и то, как из них собрать рабочий отчёт.
Рано или поздно почти каждый проект упирается в одну и ту же стену: контент пишется, ссылки закупаются, а органический трафик стоит на месте. Причина обычно не в текстах, а в инфраструктуре — что-то ломается раньше, чем поисковик доходит до страницы. Пока это «что-то» не найдено, все остальные усилия тратятся впустую.
Проще говоря, технический аудит это не проверка «для галочки», а карта помех: где робот уходит в никуда, какие адреса дублируют друг друга, сколько миллисекунд теряет страница на загрузку и почему часть разделов не попадает в индекс вовсе. Проверка ведётся по заранее заданному чек-листу и заканчивается списком задач, у каждой — приоритет и ответственный.
Дальше — практический разбор того, как эту проверку провести шаг за шагом. Порядок этапов не случайный: скорость, потом структура URL, затем индексация, мобильная адаптация, файлы для роботов и в конце — отчёт. Такой порядок позволяет не переделывать работу дважды.
Проверка скорости загрузки страниц
Сколько грузится страница — первое, что чувствует и пользователь, и робот. Медленный ответ сервера означает, что бюджеты обхода расходуются впустую: краулер успевает пройти меньше URL за то же время, а поведенческие сигналы — отказы, короткие сессии — ухудшаются сами.
Основной набор метрик здесь — Core Web Vitals: LCP (когда отрисовывается самое крупное изображение в первом экране), INP (задержка реакции интерфейса на действие) и CLS (смещение макета). Пороговые значения у Google открыты: LCP до 2,5 секунды считается хорошим, 2,5–4,0 — приемлемым, выше — плохим. У INP норма до 200 мс, у CLS — до 0,1. По данным Google (2026), сайты в «зелёной зоне» по всем трём метрикам получают заметно лучшие поведенческие показатели, чем ресурсы с провальным LCP.
Первоочередные зоны внимания при аудите
- TTFB — время до первого байта. Если больше 800 мс, дело, скорее всего, в хостинге, кеше или тяжёлых SQL-запросах.
- Вес главной картинки — LCP чаще всего упирается именно в неё. WebP вместо JPG даёт 30–50% экономии без потери качества.
- Блокирующие скрипты — синхронные теги в <head> тормозят парсинг. Атрибут defer или async решает часть проблем.
- Сторонние виджеты — чаты, карты, счётчики. Каждый добавляет свои миллисекунды.
| Метрика | Хорошо | Приемлемо | Плохо |
|---|---|---|---|
| LCP | < 2,5 с | 2,5–4,0 с | > 4,0 с |
| INP | < 200 мс | 200–500 мс | > 500 мс |
| CLS | < 0,1 | 0,1–0,25 | > 0,25 |
| TTFB | < 800 мс | 800–1800 мс | > 1800 мс |
Отдельно стоит смотреть не только главную, но и типовые шаблоны: карточку товара, статью, страницу категории. Если главная летает, а карточки падают по LCP, в отчёте это будут разные пункты с разными исполнителями.
Анализ структуры URL и перелинковки
Правильно собранные URL дают роботу понятную иерархию, а человеку — представление о том, где он находится. Если адреса строятся хаотично (то латиница, то транслит, то цифровой ID), разбираться в структуре сайта приходится уже краулеру, и он справляется хуже.
Что проверять в адресах
- Длина и читаемость — до 75–90 символов, латиница через дефис, без параметров и дат.
- Единый регистр — строчные буквы, иначе /Page и /page превращаются в два разных URL.
- Слеши на конце — либо всегда со слешем, либо всегда без. Смешанный вариант плодит дубли.
- Вложенность — 3–4 уровня максимум. Глубже — сигнал, что контент плохо сгруппирован.
- Параметры сортировки, фильтров, сессий — что закрывается в robots, что через canonical, что через 404.
Внутренние ссылки и распределение веса
Отдельная тема — перелинковка. Одна коммерческая страница, на которую не ведёт ни одна внутренняя ссылка, рискует выпасть из обхода: робот ориентируется в основном по ссылкам и карте сайта, а не по прямым адресам. Проверяется это просто: собираем краулером все входящие ссылки по каждому URL, смотрим, есть ли страницы с нулём внутренних ссылок, и ищем разделы, где ссылки ведут на нерелевантные страницы. Как правильно организовать перелинковку — разбирали отдельно, там подход к распределению веса и анкорам.
Связка URL и семантики важна при проектировании разделов: URL должны повторять группы запросов, а не внутреннюю логику CMS. Если структура уже сложилась неправильно, переделывать её целиком не всегда оправдано — иногда достаточно настроить редиректы и правильно перелинковать существующие страницы. Как собрать семантическое ядро и разложить его по URL — тема отдельной статьи.
Ошибки индексации и дубли страниц
Даже идеальный URL бесполезен, если страница не попала в индекс. Проверка этого этапа состоит из двух частей: сверить, что в поисковике есть, с тем, что реально опубликовано, и найти причины расхождений.
Обычно кто проводит технический аудит на этом шаге, тот первым делом открывает Яндекс Вебмастер и Google Search Console. Там в разделе «Страницы в поиске» / «Покрытие» видно статус каждого URL: проиндексирован, исключён, ошибка. Дальше картина уточняется логами сервера — что робот реально запрашивал, какие коды получил, куда ходил чаще, чем нужно.
Типичные проблемы
- Дубли по протоколу и www — http/https и www/без www ведут на один контент без редиректа.
- Параметры — ?sort=price_asc, ?utm_source=..., ?page=1 попадают в индекс как отдельные страницы.
- Null-версии — страницы фильтров возвращают 200 с пустым результатом и попадают в индекс.
- Пагинация — 2-я и 3-я страницы категории дублируют первую без canonical.
- Soft 404 — страница отдаёт 200, но по факту контента на ней нет.
- 5xx при обходе — сервер падает под нагрузкой робота, обход тормозит.
По данным Google (2026), сайты, устранившие ошибки Soft 404 и дубли по параметрам, ускоряют переобход ключевых страниц в среднем на 25–40%. Точный срок зависит от того, как часто робот возвращается на ресурс.
Мобильная адаптация и безопасность
Мобильный трафик в большинстве ниш уже перевалил за 60%, и Google индексирует именно мобильную версию страницы. Если на телефоне уезжает вёрстка, не читается текст без зума, всплывает на весь экран окно подписки — поведенческие факторы портятся, и поисковик это видит через обычную пользовательскую статистику.
Проверять адаптацию стоит не «на глазок», а по чек-листу: кликабельная область у кнопок минимум 48×48 px, контраст текста и фона не ниже 4.5:1 (WCAG AA), отсутствие горизонтального скролла, читаемый размер шрифта без увеличения, корректная работа формы заказа. Отдельный пункт — разные шаблоны страниц: карточка, статья, каталог, форма могут вести себя на телефоне по-разному, и «нормально смотрится главная» ничего не значит.
Безопасность задевает SEO напрямую. HTTPS — уже обязательный минимум, и дело не только в ранжировании: браузеры помечают http-сайты как «не защищено», что напрямую бьёт по конверсии. В аудите смотрим: есть ли валидный сертификат, настроен ли HSTS, не осталось ли смешанного контента (картинок и скриптов по http на https-странице), нет ли открытых для индексации админок, бэкапов и служебных файлов.
Состояние sitemap и robots.txt
Sitemap и robots.txt — два файла, которые поисковик читает в первую очередь. Ошибки в них могут как ускорить обход, так и полностью его затормозить, причём незаметно для владельца сайта.
В карте сайта проверяем три вещи: она отдаёт корректный XML с правильной кодировкой, содержит только канонические URL, и в ней нет страниц, закрытых в robots.txt или отдающих 404. Последнее особенно часто: sitemap генерируется автоматически, а реальные разделы уже переехали. Собрать и проверить её помогает обычный генератор sitemap — но лучше сначала выверить список URL глазами, а потом уже генерировать.
По robots.txt смотрим четыре вещи: не закрыт ли случайно весь сайт, не заблокированы ли важные разделы (каталог, статьи), корректно ли указан хост и карта сайта, нет ли устаревших правил от старой структуры. На индексируемость страниц теги noindex и X-Robots-Tag в HTTP-заголовках тоже влияют — их нужно проверять отдельно, потому что robots.txt не гарантирует исключение из индекса, только запрет на обход.
Отчёт и приоритизация задач
Аудит без отчёта — просто набор наблюдений. Работа заканчивается документом, где каждая проблема описана по одной схеме: что именно не так, на каких URL проявляется, как влияет на индексацию и ранжирование, сколько времени займёт исправление, кто отвечает. Без этой структуры правки растягиваются на месяцы.
Приоритизацию удобно вести по трём осям: влияние на трафик, стоимость и трудоёмкость правки, риск потерять уже имеющиеся позиции. Проблемы с массовым охватом (дубли по параметрам, битые ссылки в футере, медленный TTFB) обычно идут первыми — они дают эффект по всему сайту. Точечные задачи (отдельная непроиндексированная страница, мелкий баг на карточке) можно закрывать по ходу.
| Тип проблемы | Влияние | Срочность |
|---|---|---|
| Закрыт весь сайт в robots.txt | Критическое | Немедленно |
| Ошибки 5xx при обходе | Критическое | Немедленно |
| Дубли по параметрам и протоколам | Высокое | 1–2 недели |
| Провальный LCP на коммерческих шаблонах | Высокое | 2–4 недели |
| Битые внутренние ссылки | Среднее | 1 месяц |
| Отсутствие sitemap | Среднее | 1 месяц |
Отчёт стоит держать живым: после внедрения правок полезно прогнать повторный краул и сверить метрики до/после. Первые изменения в переобходе обычно заметны через 2–3 недели, отражение в позициях — через месяц-полтора. Точных гарантий по срокам не даём: они зависят от того, как часто робот заходит на сайт, и как давно проблемы копились.
Коротко о главном
Технический аудит нужен проекту, чтобы понимать, где инфраструктура мешает продвижению. Проводится он в шесть этапов: скорость, структура URL и перелинковка, индексация и дубли, мобильная адаптация и безопасность, файлы для роботов, отчёт. Задачи из отчёта приоритизируются по влиянию на трафик и трудоёмкости — начинают с массовых проблем, после правок проверяют динамику через повторный краул и панели вебмастера. Полный аудит имеет смысл раз в год и при значимых изменениях (новая CMS, миграция, запуск раздела).