Большинство технических SEO-аудитов дают массу находок. Потом документ полгода лежит на общем диске, и ничего не внедряется. Иногда это вина клиента, но чаще — самого аудита: находки не проверены, отсортированы по «серьёзности» в представлении инструмента или написаны так, что разработчик не может по ним действовать. Вот 10 ошибок, которые встречаются постоянно, — и что делать вместо них.
1. Сканирование без включённого выполнения JavaScript
Screaming Frog покажет обе версии страницы в одном обходе, если включить JS-рендеринг и сохранение исходного и отрендеренного HTML. Сравнение покажет контент, внутренние ссылки, canonical и meta robots, которые есть в отрендеренном DOM, но отсутствуют в исходном HTML-ответе.
Google рендерит большинство страниц без проблем, но контент, появляющийся только после выполнения JavaScript, менее надёжен: заблокированный ресурс, ошибка скрипта или таймаут могут оставить его вне индекса. Большинство ИИ-краулеров вообще не выполняет JavaScript, поэтому страница может ранжироваться в Google и при этом быть невидимой для систем, генерирующих ИИ-ответы. Пробел подтверждайте инструментом «Проверка URL» в Search Console — это взгляд Google на отрендеренную страницу, с которым разработчику сложнее спорить, чем со скриншотом стороннего краулера.
2. Игнорировать отчёт «Страницы» в Search Console
Он находится в разделе «Индексация → Страницы» и единственный, где Google прямо говорит: проиндексирован ли URL, проиндексирован ли без обхода, найден, но не проиндексирован, мягкая 404 и так далее.
Не каждый URL в «не проиндексированных» — проблема. Альтернативная страница с корректным canonical, исключённая тегом noindex, страница с редиректом — нормальные исходы правильно настроенного сайта. Исследовать стоит те исключения, которых вы не ожидали: страницы, которые должны ранжироваться, но застряли в «Сканировано — на данный момент не проиндексировано», или растущее число в «Найдено — на данный момент не проиндексировано».
3. Выбирать URL случайно, а не по шаблону
Берите URL по типу страницы, а не случайно: карточки товара, категории, записи блога, отфильтрованные представления, пагинация и всё остальное, что генерирует сайт. Большинство технических проблем, которые стоит репортить, — это проблемы шаблонов.
Ошибка в canonical на шаблоне карточки товара ломает сразу все 40 000 карточек. Если в выборке три записи блога и контактная страница, вы это пропустите и отчитаетесь о чём-то тривиальном. Семплирование по шаблону делает и скоуп фикса дешевле: «поправить логику canonical на шаблоне карточки» оценивается примерно за минуту, тогда как список из 40 000 URL никто не оценит.
4. Опираться на один источник данных
Каждый инструмент что-то не видит. Краулер находит только то, что связано или чем его «накормили», поэтому осиротевшие страницы остаются невидимыми. Search Console говорит вердикт Google, но не причину. Аналитика фиксирует только визиты, где работает трекинг-код, так что активность краулеров в ней почти не видна.
Серверные логи — единственный источник, который показывает каждый запрос Googlebot или ИИ-краулеров и то, что они получают в ответ. Rate limiting, прерывистые 5xx и ползание по URL, которые вам не важны, проявляются только здесь. Если логов нет — используйте отчёт «Статистика обхода» в Search Console. Перед отдачей в разработку подтверждайте находку минимум в двух местах. Когда два источника расходятся — это обычно и есть самое интересное.
5. Считать классификации инструмента фактами
Краулеры репортят отсутствующие title и H1 на страницах, где контент рендерится нормально, и логируют 429 и 503, которые сайт вернул только потому, что обход шёл слишком быстро.
Прежде чем находка попадёт в отчёт, откройте страницу и проверьте сами. Для подтверждения кода ответа запустите curl. Это пара минут на находку и предотвращает полдня работы разработчика за несуществующей проблемой. Разработчики, которых один раз отправили за «фантомным» багом, читают остальную часть документа с подозрением.
6. Документировать симптомы вместо причин
«На сайте 12 000 дублирующихся URL» — наблюдение, а не находка. Находка — то, что их порождает: фасетная навигация без обработки параметров, session ID в URL или CMS, создающая вторую копию каждой страницы по другому пути.
Разработчик может удалить 12 000 URL за день, но они вернутся при следующем добавлении фильтра, потому что поведение под ними не изменилось. Проследить дубль до источника дольше, чем выгрузить список, — и это та часть работы, которую инструмент за вас не сделает.
7. Приоритизировать по «серьёзности» инструмента вместо влияния на бизнес
Краулер назначает серьёзность по типу проблемы. Он не знает, какие шаблоны приносят деньги, какие категории бизнес продвигает в следующем квартале и на какие страницы отправляет клиентов отдел продаж. В итоге куча низкоценных предупреждений оказывается сверху, а сбой рендера на самом маржинальном шаблоне — на четвёртой странице.
Исправление — задать вопросы, которые инструмент не может: какие приоритетные товары и услуги, какие страницы конвертят, что запускается в этом году. Потом ранжировать проверенные находки по этим ответам, а не по колонке «серьёзности».
8. Рекомендовать изменения без понимания архитектуры сайта
Редиректы, смена canonical, удаление URL и noindex имеют эффекты второго порядка. noindex на отфильтрованной категории со временем отрезает внутренние ссылки на товары под ней. Пачка старых URL, переведённых на главную, часто становится «мягкими 404».
Перед рекомендацией нарисуйте, что ссылается на рассматриваемые страницы и куда те ведут. Что вам важно: является ли страница единственным маршрутом к чему-то ещё и есть ли у страниц, на которые она ссылается, другой вход (навигация, sitemap, хлебные крошки).
9. Писать рекомендации, по которым разработчик не может действовать
«Улучшить скорость сайта» — не рекомендация, как и «поправить canonical» или «усилить внутреннюю перелинковку». Пригодная рекомендация включает затронутые URL или шаблоны, первопричину, ожидаемый результат и достаточно деталей для оценки работы.
Сравните «улучшить скорость» с конкретикой: «LCP-элемент на шаблоне карточки — hero-изображение через lazy-load, нужно убрать loading=lazy и добавить fetchpriority=high, LCP до 2,5 секунды». Если разработчику приходится возвращаться и спрашивать, что вы на самом деле хотите, тикет уходит вниз бэклога и остаётся там.
10. Предписывать реализацию вместо результата
Пишите результат и ограничения. Canonical на пагинированных страницах должен быть самоссылающимся. Основной контент товара должен быть в исходном HTML-ответе. Дальше пусть разработчик решает, как.
Подход можно предложить, но вы не знаете ограничений фреймворка, что ещё зависит от этого компонента или что команда уже запланировала для этой части кода. Приёмочные критерии дают разработчику, что строить и чем проверять результат. Предписание лишь провоцирует спор о том, правильный ли у вас подход.
Как выглядит хороший аудит
Краулер выдаёт список проблем за 10 минут. Клиенты платят за всё, что происходит после, — когда кто-то проверяет, какие из проблем реальны, какие важны для бизнеса и сколько стоит каждый фикс.
Нужен технический SEO-аудит, по которому разработчики смогут действовать, а не «список из краулера»? Сделаем: +375 (29) 619-05-79, +375 (29) 840-04-94.
Добавить комментарий