Технический SEO-аудит: чек-лист ошибок роста сайта

Чаще всего сайт «не растёт» не потому, что мало контента или ссылок, а потому, что он сам себе мешает: часть страниц закрыта от индексации по ошибке, в индексе мусор, у товаров по два H1, а sitemap отдаёт URL, которых давно нет. Владелец видит только итог — «по нашим запросам нас нет в топе» — и идёт докупать ссылки, хотя проблема ниже, в фундаменте. Технический SEO-аудит — это сквозная проверка этого фундамента: на большом каталоге за один прогон краулер обходит тысячи URL и поднимает сотни флагов, рассортированных по приоритету. Ниже — рабочий чек-лист по классам ошибок: для каждого даю, как обнаружить и как чинить, и честно говорю, где приём не сработает.

Индексация: noindex по ошибке, мусор в индексе, robots и sitemap

Первое, что проверяем в любом аудите, — действительно ли страница, которую вы хотите продвигать, разрешена к индексации. Самая частая и самая дорогая ошибка — случайный noindex. Он попадает на страницу десятком путей: галочка в SEO-плагине, наследование настроек категории, режим разработки, забытый после переноса, шаблон конструктора (Elementor, Avada, Tilda) с дефолтным noindex на служебных типах. Обнаруживается так: краулером (Screaming Frog, Netpeak Spider, свой скрипт) обходим сайт и смотрим колонку Meta Robots плюс HTTP-заголовок X-Robots-Tag — заголовок коварен тем, что в HTML его не видно, он ставится на стороне сервера. На каталоге в ~500 товаров найти 3–5 коммерческих страниц с ошибочным noindex — норма, а не исключение.

Зеркальная проблема — мусор в индексе: в выдачу попадает то, что попадать не должно. Страницы фильтров и сортировок (?sort=price, ?color=red), результаты внутреннего поиска, корзина, теги, версии для печати, пустая пагинация. Каждая такая страница тратит краулинговый бюджет и размывает релевантность. Найти просто: в Яндекс.Вебмастере и Google Search Console открываем «Страницы в поиске / Индексирование», сортируем по типам, плюс оператор site: с фильтрами по параметрам. На большом каталоге в индекс легко утекает несколько тысяч параметрических дублей.

robots.txt и sitemap.xml ломают индексацию чаще всего. Типичные находки: robots.txt блокирует /catalog/ целиком (видели такое после неудачного переноса), sitemap отдаёт 404-URL, неканонические адреса или страницы с noindex — это прямое противоречие: вы говорите «индексируй» и «не индексируй» одновременно. Лечим так: в robots.txt оставляем закрытыми только реально служебные разделы, sitemap генерируем динамически и только из индексируемых, канонических, отдающих 200 URL. После правок отправляем sitemap на переобход и следим за динамикой «исключённых» в вебмастерах. Восстановление индекса — с полутора тысяч исключённых до полутора сотен на живом проекте — занимает не один прогон, а недели.

Дубли и канонические адреса: почему вес размазывается

Дубли — это когда один контент доступен по нескольким URL, и поисковик не знает, какой считать главным. Классические источники: один товар в разных категориях (/category-a/product и /category-b/product), www и без www, http и https, слэш на конце и без него, разный регистр, главная по адресам / и /index.php. Поисковик дробит сигналы между копиями, и ни одна не набирает достаточно веса для топа. Отсюда и ощущение «делаем-делаем, а движения нет».

Решение — атрибут rel=canonical: на каждой странице указываем абсолютный канонический URL. На дублях canonical ведёт на основную версию, на основной — сам на себя (self-referencing canonical обязателен, его отсутствие — тоже флаг). В аудите проверяем не наличие тега, а его корректность. Частые ошибки: canonical со всех страниц подряд ведёт на главную (видели такое после кривого плагина — весь сайт «схлопывался» в одну страницу); canonical на noindex-страницу; canonical на 301-редирект. Каждое сочетание поисковик трактует по-своему и обычно не в вашу пользу.

Отдельно — http/https и www. Должно быть ровно одно главное зеркало, всё остальное — 301-редиректом на него. Проверяется в минуту: вбиваете четыре варианта главной (http, https, www, без www) и смотрите, что три «неправильных» отдают 301 на один канонический. Если хоть один отдаёт 200 — у вас четыре копии сайта в глазах поисковика. На практике именно несведённые зеркала — частая причина, почему молодой сайт «никак не склеится» в выдаче.

H1 и метатеги: множественные, пустые, шаблонные

H1 — главный заголовок страницы, и он должен быть ровно один. Конструкторы (Avada, Elementor, Divi) и темы Bitrix/WordPress регулярно генерируют по два-три: один на логотипе, второй в слайдере, третий — реальный заголовок. На каталоге в ~150 страниц найти 20–30 с множественным или вовсе отсутствующим H1 — типичная картина. Обнаруживается краулером в один проход: колонки H1-1, H1-2, H1 Count. Чинится либо в шаблоне (правильнее всего), либо точечно — на массиве страниц быстрее через API CMS, чем руками.

Title и meta description — то, что видит пользователь в выдаче и по чему поисковик понимает тему страницы. Ошибки трёх типов: пустые (генерируются из имени файла или отсутствуют), дублирующиеся (одинаковый title на сотнях карточек — «Купить — Название магазина»), переоптимизированные (перечисление ключей через запятую, которое режется в сниппете и выглядит как спам). Находим краулером: он показывает дубли title/description и их длину. Длина важна — title обрезается примерно на 60 символах, description на 150–160; всё длиннее в сниппет не помещается.

На больших каталогах руками это не правят — пишут шаблоны с подстановкой: «{Товар} купить в {Город} — цена, характеристики, отзывы | {Бренд}». Шаблон должен давать уникальный, читаемый, не оборванный заголовок на каждой из тысяч страниц. Важная честность: красивый уникальный title сам по себе не выводит в топ — он улучшает кликабельность и помогает поисковику с темой, но без нормального контента и ссылочного не вытянет. Это гигиена, а не рычаг роста.

Скорость и Core Web Vitals: что реально влияет

Скорость — фактор ранжирования, но не такой решающий, как любят пугать. Google измеряет три метрики Core Web Vitals: LCP (за сколько отрисовывается главный блок, цель < 2,5 с), INP (отзывчивость на действия пользователя, цель < 200 мс, заменил FID в марте 2024-го) и CLS (насколько «прыгает» вёрстка при загрузке, цель < 0,1). Важно понимать: оценка идёт по полевым данным реальных пользователей (CrUX), а не по лабораторному тесту в PageSpeed. Поэтому «90 баллов в PageSpeed» и реальная проблема со скоростью спокойно уживаются.

Что чаще всего тормозит на сайтах, которые мы аудируем: несжатые изображения (товарные фото по 2–4 МБ вместо 100–200 КБ в WebP), отсутствие lazy-load, тяжёлые скрипты конструкторов и десяток сторонних — чаты, метрики, пиксели, виджеты, — грузящихся синхронно и блокирующих отрисовку. CLS чаще всего ломают баннеры и изображения без заданных width/height: контент дёргается, пользователь промахивается по кнопке. Диагностируем через PageSpeed Insights (полевые + лабораторные данные), WebPageTest и отчёт Core Web Vitals в Search Console — последний показывает не одну страницу, а группы похожих URL, что для каталога удобнее.

Честно о приоритете: если закрыта индексация и дубли размазывают вес — сначала это, скорость потом. Переход с LCP 4 секунды на 2 редко даёт скачок позиций сам по себе; он убирает потолок и улучшает поведенческие. Гнаться за зелёными цифрами в PageSpeed ради цифр — занятие на любителя; гнаться за реальной скоростью загрузки для пользователя — стоит.

Битые ссылки, редиректы, разметка и alt

Битые ссылки (404) и кривые редиректы тратят краулинговый бюджет и ухудшают опыт. Ищем два класса: внутренние ссылки на несуществующие URL (вы сами линкуете в пустоту — после удаления товаров, смены структуры) и цепочки редиректов (URL-A → URL-B → URL-C → итог: каждый шаг теряет вес и время краулера). Краулер показывает и Response Codes, и Redirect Chains. Правило простое: внутренние ссылки должны вести сразу на конечный 200-URL, а не через 301; 404 от внутренних ссылок чинятся восстановлением страницы, обновлением ссылки или аккуратным 301 на ближайший аналог.

Структурированная разметка (Schema.org / JSON-LD) — не фактор ранжирования напрямую, но то, что даёт расширенные сниппеты: цена, рейтинг, наличие, хлебные крошки, FAQ, карточка организации. Без неё ваш сниппет — голая строка, у конкурента — со звёздами и ценой, и кликают в него. В аудите проверяем три вещи: есть ли разметка, валидна ли она (через Rich Results Test и Schema Markup Validator) и не врёт ли (рейтинг в разметке должен совпадать с видимым на странице — за фейк Google снимает расширенный сниппет). На каталоге внедряем Product + Offer + AggregateRating, на услугах — Service и FAQPage, по всему сайту — Organization и BreadcrumbList.

Alt у изображений — атрибут, описывающий картинку. Нужен для доступности, для поиска по картинкам и как дополнительный текстовый сигнал. На WooCommerce-каталоге с 8 000+ изображений alt обычно заполнен у 20–30%. Руками это не сделать — массово простаскиваем через API CMS по шаблону «{товар} — {категория} — {ракурс}». Честно: alt — слабый ранжирующий сигнал для обычной выдачи, но заметный для поиска по картинкам и обязательный для доступности; на каталоге это ещё и единственный способ не оставить тысячи изображений вообще без описания.

Мобильность и приоритизированный план

Google индексирует сайты по мобильной версии (mobile-first уже несколько лет), поэтому если на телефоне у вас урезанный контент, нечитаемый текст, слипшиеся кнопки или горизонтальный скролл — это видит именно та версия, по которой вас ранжируют. Проверяем не «адаптивный ли дизайн в принципе», а конкретику: совпадает ли контент десктопа и мобайла (частая беда — на мобайле скрыли пол-страницы текста ради «чистоты»), нет ли тапа по слишком мелким элементам, читается ли шрифт без зума, не вылезает ли вёрстка за viewport. Инструменты — режим устройства в DevTools и отчёты вебмастеров по мобильному удобству.

Самое важное в аудите — не длина списка флагов, а их приоритизация. Сквозной прогон по большому каталогу даёт тысячи URL и сотни замечаний; вывалить всё разом — клиент утонет. Поэтому рассортировываем по P0/P1/P2. P0 — то, что прямо блокирует индексацию и трафик (ошибочный noindex на коммерции, robots закрыл каталог, сайт не склеен по зеркалам). P1 — то, что размывает и тормозит (дубли без canonical, цепочки редиректов, множественные H1, отсутствующая разметка). P2 — гигиена и полировка (alt, длина title, мелкие CLS). Сначала закрываем P0, потом P1, P2 — фоном.

И главная честность напоследок: технический аудит не даёт роста сам по себе. Он убирает то, что мешает расти, — снимает потолок. После него сайт перестаёт «гасить себя» и становится способен расти на контенте, семантике и ссылках. Без этого фундамента любые вложения в контент и ссылочное работают вполоборота: вы заливаете воду в дырявое ведро. Поэтому аудит — не разовая галочка, а точка, с которой осмысленное продвижение вообще начинается.