Технический аудит сайта: что входит и какой отчёт принимать до новых текстов

Шесть слоёв проверки и одна очередь задач

Что входит в технический аудит сайта, если он сделан всерьёз? Шесть слоёв проверки, пройденных в том порядке, в каком поисковая система встречает страницу: доступность для обхода, допуск к индексу, рендеринг JavaScript, сигналы страницы вроде title, внутренних ссылок и микроразметки, скорость по данным реальных посетителей и, наконец, дубли URL и языковые версии. Заказчик должен получить не выгрузку краулера, а очередь задач с приоритетами. В каждой строке — суть проблемы, доказательство, шаблон или маска URL, влияние и трудоёмкость, ответственный и способ проверить исправление. Если отчёт нельзя свести к такой таблице, анализ не закончен, его просто переложили на вас.

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

Обход и допуск к индексу проверяют первыми

Первый проход отвечает на вопрос, могут ли роботы добраться до страниц, которые должны ранжироваться, и удержать их в индексе. Аудитор смотрит коды ответа, цепочки редиректов, правила robots.txt, XML-карты сайта и внутренние ссылки: насколько глубоко лежат важные страницы и на какие не ведёт ни одна ссылка.

Доступная для обхода страница всё равно может выпасть из индекса из-за noindex, canonical на другой адрес или «мягкой» 404, когда страница сообщает, что ничего не найдено, а сервер отвечает кодом успеха. Причины исключения с примерами адресов показывают отчёт об индексировании страниц в Search Console и раздел индексирования в Яндекс Вебмастере. В Search Console списки примеров ограничены, поэтому по ним ищут закономерности, а не полный перечень.

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

Рендеринг страниц, которые собирает JavaScript

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

Часть проверок прямо следует из руководства Google по основам JavaScript SEO. Ссылки Google находит, только если это элементы a с атрибутом href, поэтому меню на обработчиках кликов способно спрятать целые разделы. Если в исходном HTML стоит noindex, Google может не запускать рендеринг, и скрипт, снимающий тег позже, не поможет. Скрипты не должны переписывать canonical, а одностраничным приложениям нужна корректная обработка ошибок, иначе появятся «мягкие» 404.

Доказательство здесь — снимок, а не мнение: отрендеренный HTML и скриншот из живой проверки в инструменте проверки URL или из проверки расширенных результатов, приложенные к находке. Фраза «возможны проблемы с рендерингом» без такого снимка означает, что никто ничего не проверял.

Сигналы страницы и Core Web Vitals по реальным визитам

Сигналы страницы — это части HTML, которые её описывают: title, meta description, заголовки, анкоры ссылок и микроразметка. Проверяют согласованность, а не количество. Цена и наличие в разметке товара должны совпадать с видимой страницей, а title, которые генерирует шаблон, не должны повторяться. Добавлять новые типы Schema.org бессмысленно, пока существующая разметка противоречит странице.

В вопросах скорости многие отчёты смешивают два вида данных. Полевые данные собраны у реальных пользователей: это Chrome UX Report, на который опираются PageSpeed Insights и отчёт Core Web Vitals в Search Console. Лабораторные данные дают симуляции загрузки в Lighthouse или Chrome DevTools. На web.dev прямо сказано, что лабораторное измерение не заменяет полевое, а без живого пользователя инструмент вообще не может измерить INP.

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

Дубли URL, владелец canonical и языковые версии

Дубли появляются сами: UTM-метки, сортировки, слеш в конце адреса, варианты протокола. В документации Google редиректы и rel=canonical названы сильными сигналами, а включение в карту сайта — слабым; согласованные сигналы усиливают друг друга. Там же не советуют выбирать канонический адрес внутри сайта через robots.txt или noindex. Для Яндекса адреса с GET-параметрами дополнительно описывают директивой Clean-param.

Владелец canonical — это два решения для каждой группы дублей: какой URL её представляет и какая часть системы подаёт этот сигнал, будь то поле в CMS, помощник шаблона, правило редиректа или генератор карты сайта. Инструмент проверки URL показывает канонический адрес, указанный владельцем, рядом с адресом, выбранным Google. Если они расходятся, отчёт должен назвать сигнал, который перевешивает.

Многоязычному сайту нужна отдельная проверка: каждая языковая версия указывает canonical на страницу своего языка, а наборы hreflang полны во всех направлениях. Например, на сайте с пятью языками один общий компонент печатает английский canonical на всех версиях. В отчёте это одна причина, а не сотни строк по каждой странице.

Ошибки шаблона и разовые ошибки страниц

Большинство технических ошибок рождается в шаблонах. Карточка товара без canonical или категория, где каждый фильтр превращается в ссылку, повторяют ошибку на всех URL, собранных по этому шаблону. Разовые ошибки тоже случаются, например одиночная петля редиректов или вручную поставленный noindex, но сквозную картину по сайту они объясняют редко.

Отсюда другой способ выборки. Вместо сортировки предупреждений по количеству аудитор составляет список шаблонов, берёт из каждого несколько показательных адресов, старый, свежий и нетипичный, и разбирает их глубоко. Отчёт Core Web Vitals в Search Console тоже группирует похожие страницы. Полный краул затем показывает, насколько широко разошлась каждая ошибка шаблона.

Меняется и то, как читается отчёт. Допустим, у клиники сорок страниц услуг на одном шаблоне, а инструмент выдаёт двести предупреждений о title, которые сводятся к двум полям шаблона. Как одна причина это одна задача для разработчика и одна повторная проверка. Как двести строк это выглядит месяцем работы и откладывается.

Строка очереди, которую заполняет каждая находка

Формат отчёта сильнее всего отличает один аудит от другого, и его можно согласовать до начала работ: перечислить колонки в брифе или попросить обезличенный пример строки. Находку без доказательства нельзя перепроверить, без ответственного её не поставят в план, а без способа проверки её невозможно закрыть.

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

Приёмка аудита до подписания акта

Принять аудит значит убедиться, что он полон и верен, а не объёмен. До начала работ согласуйте фиксированную выборку URL: главная, основные коммерческие страницы, пара статей, старый адрес с редиректом, служебная страница вроде внутреннего поиска и одна страница, о проблеме которой вы уже знаете. В отчёте по каждой должен быть конкретный вывод, включая честное «проблем нет».

Затем выборочная перепроверка. Воспроизведите три-четыре находки вместе с разработчиком через живую проверку URL, отрендеренный HTML, заголовки ответа или полевые данные. Если доказательства не воспроизводятся, остальной отчёт заслуживает того же сомнения. Каждый шаблон из списка тоже должен появиться в отчёте, пусть даже с пометкой «проверен, ошибок нет».

Когда первые исправления выкатят, Search Console даст датированное подтверждение. Кнопка «Проверить исправление» в отчёте об индексировании перепроверяет адреса с известной проблемой и может работать несколько дней или дольше. Это необязательный шаг, ведь Google замечает исправления и при обычном сканировании, но после него остаётся запись. В Яндекс Вебмастере исправленные адреса можно отправить на переобход, а повторный краул затронутых шаблонов замыкает цикл.

Когда хватит узкой проверки и какие доступы дать

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

В любом случае аудитору нужны доступы, иначе находки превращаются в догадки снаружи. Дайте права в Search Console и Яндекс Вебмастере на проверку URL и выгрузку отчётов, доступ к аналитике и серверным логам, если они есть, адреса карт сайта, доступ к тестовому стенду, список шаблонов, группы URL, которые приносят выручку, и даты последних релизов. Каждый недостающий пункт сужает то, что аудит способен доказать.