Технический аудит сайта — как одна проверка решает скорость, позиции в поиске и цитируемость в нейросетях
Один аудит — четыре результата
До 2024 года технический аудит сайта работал на одну цель — позиции в поисковой выдаче. Сейчас у него появился четвертый адресат: краулер нейросети, который решает, включить ли сайт в ответ на вопрос пользователя. Формально задача новая, но технический фундамент под ней тот же самый — скорость загрузки, читаемая структура разметки, доступность контента для роботов.
Отсюда практический эффект: один и тот же набор проверок одновременно поднимает удержание пользователя на странице, конверсию, место в топе выдачи и шансы попасть в цитату нейросети.
Метрика вместо ощущения быстро или медленно
Google официально формализовал понятие скорости в три метрики Core Web Vitals: LCP — скорость появления основного контента, INP — отклик на первое действие, CLS — стабильность верстки при загрузке.
Ключевая деталь методики — расчет по 75-му перцентилю загрузок, отдельно для мобильных и десктопных устройств, на реальных данных пользователей Chrome, а не в лабораторных тестах. Если три четверти аудитории видят страницу быстрой, а четверть ждет по шесть секунд, метрика все равно попадет в зону плохо. Тест на быстром офисном интернете эту разницу попросту не покажет.
Разделение на мобильные и десктопные показатели не формальность. У каталога с большим количеством фотографий товара десктопная версия часто проходит по нормативам с запасом, а мобильная — нет: те же изображения на менее мощном процессоре и более медленном канале обрабатываются дольше. Проверять стоит обе версии отдельно, а не ориентироваться на среднюю оценку.
Полевые данные против лабораторных
Разница между офисным wi-fi и данными CrUX — это разница между лабораторным тестом и полевыми данными. Лабораторный замер делается в контролируемых условиях: один запуск, стабильный канал, без сторонней нагрузки на устройство. Полевые данные CrUX собраны из миллионов реальных сессий — с разными телефонами, разной загруженностью сети, разным качеством связи. Для отчетности перед клиентом или руководством важны именно полевые данные: они показывают, что видит настоящий покупатель, а не идеальную картину из тестовой среды.
Что теряет бизнес на каждой секунде задержки
Простая проверка: зайти в каталог с мобильного интернета вместо wi-fi и открыть десяток случайных карточек товара подряд. LCP дольше 4 секунд или CLS выше 0,25 — прямой сигнал, что часть посетителей закрывает вкладку, не успев увидеть товар.
Найти точку потери легко: сопоставить отчет о скорости в Метрике или Analytics с картой скроллов и воронкой заказа. Провал почти всегда виден ровно на том шаге, где страница думает дольше всего. Технические причины типовые — тяжелые изображения, синхронные скрипты сторонних сервисов, отсутствие серверного кеша.
Техническая цена позиций в выдаче
Core Web Vitals входят в сигналы ранжирования с 2021 года, но робот в принципе не учтет страницу, если физически не может ее найти или прочитать как один документ.
- Robots.txt после переезда на новый движок часто наследует старые запрещающие правила и блокирует от индексации действующие разделы каталога.
- Sitemap.xml без автогенерации перестает видеть новые товары уже через несколько месяцев — момент легко упустить, если не проверять дату обновления.
- Canonical-теги, расставленные некорректно, превращают карточку товара в трех цветах в три конкурирующих между собой дубля вместо одной канонической версии.
Все три проверяются за пару минут в Яндекс.Вебмастере или Search Console — по спискам заблокированных разделов, дате обновления карты сайта и отчету о дублях.
Новый технический фронт: цитируемость в ИИ
Два года назад этот пункт вообще не входил в чеклист аудита. Сейчас ChatGPT, Яндекс.Алиса и Perplexity регулярно цитируют конкретные сайты как источник ответа, и требования к этому не совпадают с классическим SEO.
Три фактора решают дело: машиночитаемая микроразметка Schema.org формата JSON-LD с типами вроде FAQPage под вопрос-ответ или HowTo под инструкцию; формат ответа на 40–60 слов сразу под заголовком-вопросом, без размазывания мысли на пять абзацев вступления; и признаки E-E-A-T — четыре буквы за которыми стоят конкретные требования: Experience — виден личный опыт автора с темой, Expertise — понятна его квалификация, Authoritativeness — на материал ссылаются другие авторитетные источники, Trustworthiness — указаны реальные контакты и регулярно обновляемые данные.
После закрытия похожего набора технических проблем на сайте Аспро.Cloud число уникальных запросов через ИИ-чаты выросло с 500 до 1000 в пике за два месяца — собственные цифры Аспро, полученные на практике, а не гипотеза.
Список типичных находок
- Фото на 4000×3000 пикселей, которое браузер ужимает до размера иконки на лету, — одно способно утащить LCP за порог в 4 секунды.
- Синхронно подключенные виджеты — чат, аналитика, рекламный пиксель — без атрибутов async или defer блокируют основной поток загрузки.
- Логотип и CSS без кеша — браузер скачивает их заново при каждом переходе между страницами вместо того, чтобы взять из памяти.
- Неиспользуемый JavaScript — библиотеки, подключенные когда-то на будущее и забытые в коде.
Диагностика без внешнего подрядчика
На бесплатную проверку хватает 20 минут: PageSpeed Insights дает три метрики Core Web Vitals по конкретной странице, Search Console показывает те же метрики на данных реальных пользователей, Яндекс.Вебмастер проверяет индексацию и файлы robots.txt и sitemap.xml, Google Rich Results Test проверяет корректность микроразметки без синтаксических ошибок.
Сорок найденных предупреждений без приоритизации — просто длинный список, а не план работ. Задача в том, чтобы выделить три пункта, которые дадут восемьдесят процентов эффекта. Хорошая точка отсчета — чек-лист из 6 причин, почему сайт не попадает в ответы нейросетей.
Матрица приоритетов
Первый блок — опыт и конверсия: LCP, INP и CLS в зоне плохо, слабая мобильная версия, нерабочие формы заказа. Второй блок — позиции в поиске: закрытые разделы, устаревший sitemap.xml, некорректные canonical-теги. Третий блок — видимость в нейросетях: микроразметка, формат ответа, оформление E-E-A-T. Четвертый блок, ускоряющий все три канала сразу, — технический долг: тяжелые изображения, отсутствие кеша, лишний код.
Порядок работы имеет значение: чинить технический долг раньше конверсии — тратить ресурс не туда, где он даст быстрый эффект. Сначала критичное для денег, потом для поиска, потом для нейросетей, и только затем общая оптимизация.
Как выглядит рабочая разметка на практике
Технически JSON-LD под тип FAQPage — это пара вопрос-ответ, записанная в машиночитаемом виде рядом с обычным текстом страницы: вопрос ровно тот, который пользователь мог бы задать нейросети, и ответ на 40–60 слов без воды. Модель не должна догадываться, что на странице есть ответ на конкретный запрос, — разметка сообщает это напрямую, в структурированном формате, а не текстом для человека.
Кто в команде закрывает каждую находку
Четыре блока приоритетов распределяются между разными людьми, и это стоит зафиксировать заранее, а не выяснять после получения списка находок. Скорость загрузки, кеширование, лишний JavaScript — зона разработчика: правки идут через тикет с конкретным техническим заданием, без творческой свободы в формулировках. Robots.txt, sitemap.xml, canonical-теги — тоже разработчик, но по согласованию с тем, кто отвечает за SEO, потому что правки затрагивают видимость конкретных разделов каталога. Микроразметка Schema.org — задача на стыке: разработчик встраивает код, но содержание вопросов и ответов формулирует тот, кто пишет тексты для карточек товара, поскольку именно от формулировки зависит, процитирует ли нейросеть страницу.
Разовая проверка устаревает быстрее, чем кажется
Технический аудит — не то, что делают один раз и закрывают вопрос навсегда. Каталог растет, добавляются новые интеграции и виджеты, движок сайта обновляется — каждое из этих событий способно тихо сломать что-то из проверенного списка: новый плагин подключится синхронно, обновление CMS перезапишет правила в robots.txt, забытая карта сайта перестанет обновляться сама. Разница между компанией, которая теряет позиции месяцами, и компанией, которая замечает проблему за неделю, обычно не в бюджете на разработку, а в привычке смотреть эти отчеты на регулярной основе, а не только когда падают продажи.