Технический аудит сайта клиента: панель Lighthouse и SEO-проверок для агентств

Любой разговор про Core Web Vitals заканчивается одним вопросом: на какой странице? Этот отчет отвечает на него, держа рядом два разных измерения. Полевое значение — это то, что реально пережили посетители: Largest Contentful Paint, Interaction to Next Paint и Cumulative Layout Shift на 75-м перцентиле, относительно собственных границ «хорошо» и «плохо» от Google. Лабораторный аудит — это то, что краулер измерил на каждом URL в контролируемых условиях, по запросу, в день, когда вышло исправление. Первое говорит, проходит ли сайт по нормативу; второе — какой шаблон в этом виноват.

Таблица проверенных страниц — это место, где эта пара становится видимой. У каждого просканированного URL свои четыре оценки рядом со своими лабораторными LCP и CLS, а кольцевая диаграмма считает, сколько страниц уверенно проходят, сколько нуждаются в улучшении и сколько проваливаются. Из «сайт кажется медленным» получается конкретное задание с названием шаблона, трафиком за ним и метрикой, в которой дело. Тренды на уровне всего ресурса и разбивку по устройствам, которую публикует Google, стоит смотреть в отчете Search Console; эта страница — стендовые испытания под ними.

Вкладка возможностей перечисляет, что нашел аудит и сколько стоит это исправить: миллисекунды — для блокирующих рендер ресурсов, подсказок preconnect и времени ответа сервера; кибибайты — для слишком тяжелых изображений, форматов следующего поколения, медиа за пределами экрана, неиспользуемого JavaScript, неминифицированного CSS и времени жизни кэша. У каждой строки своя область и степень серьезности, рассчитанная из размера экономии, поэтому оценку разработчика и приоритет агентства можно обсуждать по одному и тому же списку, а не по двум разным выгрузкам.

Диагностика стоит рядом как объяснение, а не как список задач: размер DOM, работа основного потока, время выполнения JavaScript, число запросов, переданный вес, критические цепочки запросов, элемент, который определяет Largest Contentful Paint, и элементы, которые еще двигаются после отрисовки. У каждой строки целевое значение, которое стоит не превышать, и простое предложение о том, почему это важно, — обычно именно это отличает отчет, который клиент пересылает своему разработчику, от того, что возвращается с вопросами.

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

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

Десять проверок краулинга и разметки идут списком «пройдено / не пройдено», с предложением о том, что нашел краулер: теги title, мета-описания, ссылки, доступные для обхода, канонические теги, разметка hreflang, корректный файл robots, атрибуты alt у изображений, читаемый размер шрифта, расстояние между точками касания и валидность структурированных данных. Над таблицей стоит общее число, поэтому первое, что видно, — сколько из десяти чисто и сколько осталось в работе.

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

Каждый аудит ограничен одним клиентом через переключатель в рабочем пространстве и оформлен в брендинге вашего агентства, поэтому одна и та же структура несет и январский обзор, и июньский. Оценки, Core Web Vitals, возможности, диагностика, доступность и технические проверки сохраняют свои места между проектами, а сравнение месяц к месяцу превращается в повторное чтение одного и того же раздела, а не в сверку двух по-разному собранных документов. Рабочее пространство дает поверхность для обзора; подключение источника данных остается отдельным шагом.

Именно эта повторяемость превращает техническую работу в то, что клиент продлевает. Разработчик видит ранжированный список исправлений с оценкой экономии; аккаунт-менеджер видит четыре оценки, общую цифру здоровья и страницы за ними — и оба смотрят на один и тот же отчет. Команда тратит время на решение, что чинить дальше, а не на пересборку макета презентации, и аудит перестает быть той работой, писать которую никто не любит.