Привет, Хабр! Меня зовут Дмитрий, руковожу отделом рекламы и продвижения в Аспро. Мы запускаем сайты, интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Частый вопрос от клиентов, которые заказывают у нас аудит: он же вроде нормально работает, зачем еще платить за технический аудит? Отвечаю: сайт сейчас одновременно общается с четырьмя разными читателями — человеком, поисковым роботом, алгоритмом ранжирования и, с 2024 года все активнее, краулером нейросети, который решает, упомянуть ли вас в ответе. 

Все четверо считывают одни и те же технические сигналы: скорость загрузки, структуру разметки, доступность контента. Разберем, что именно они смотрят и как проверить это самостоятельно.

Зачем аудит нужен именно сейчас

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

• Опыт пользователя — досидит ли он до загрузки страницы или уйдет.

• Конверсию — оформит заказ или закроет вкладку на середине.

• Позиции в поиске — попадет ли страница в топ.

• Видимость в ИИ-ответах — процитирует ли нейросеть ваш сайт, когда пользователь спросит про товар или услугу.

Дальше разберем каждый канал по порядку, начиная с того, что измеряется точнее всего.

Три метрики скорости сайта, которые считает сам Google

Есть миф, что скорость сайта — субъективное ощущение быстро или медленно. Это не так. Google формализовал измерение скорости в три метрики — Core Web Vitals.

Важная деталь: измерение идет по 75-му перцентилю загрузок страницы, отдельно для мобильных и десктопных устройств, на основе реальных данных пользователей Chrome (CrUX). Если у 74% ваших посетителей сайт летает, а у оставшейся четверти грузится по 6 секунд, метрика попадет в зону плохо. Красивый результат в тестовой среде на офисном wi-fi ничего не говорит о реальной картине.

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

Скорость сайта и конверсия

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

Проверить это просто: откройте на телефоне мобильный интернет вместо wi-fi и зайдите на десять случайных карточек товаров в своем каталоге. Каждая секунда ожидания — окно, в которое помещается решение закрыть вкладку. Каждый прыжок верстки при клике — упущенный клик по кнопке, которая сдвинулась в момент нажатия.

Норму видно по таблице Core Web Vitals выше: если у страницы LCP за 4 секунды или CLS за 0,25, часть посетителей уходит еще до того, как увидела товар. Проверить это на своих данных можно в Яндекс.Метрике или Google Analytics — сравнить отчет по скорости с картой скроллов и воронкой заказа, обычно провал виден ровно на шаге, где страница дольше всего грузится. Технические причины таких провалов — тяжелые картинки, синхронные скрипты, отсутствие кеширования.

Позиции в поиске — сигнал Google и доступность для робота

Core Web Vitals входят в сигналы ранжирования Google с 2021 года, но сама метрика — не единственный технический фактор. Поисковый робот физически не может учесть страницу в ранжировании, если не может ее найти или считать как один корректный документ:

• robots.txt случайно закрывает от индексации нужные разделы (частая ошибка после переезда на новый движок — старые правила блокировки скопировали не глядя). Проверить — открыть сайт.ру/robots.txt в браузере и свериться со списком заблокированных разделов в Яндекс.Вебмастере; исправить — вручную убрать лишние строки Disallow.

• sitemap.xml не обновляется автоматически и полгода как не видел новых товаров. Дату последнего обновления видно там же, в Яндекс.Вебмастере или Search Console; для большинства CMS проблема решается один раз — включением автогенерации sitemap по расписанию.

• canonical-теги расставлены криво, и один товар в трех цветах создает три дубля страницы вместо одной канонической. Дубли видно в разделе «Индексирование страниц» Search Console; исправить — прописать на каждой карточке canonical, указывающий на основную версию товара.

Дальше — про четвертого читателя, которого в чеклистах аудита еще два года назад вообще не было.

Как сайт цитируют нейросети

Два года назад эта часть не входила ни в один чеклист аудита. Сейчас она обязательная. Нейросети — в ответах ChatGPT, Яндекс.Алисы, Perplexity — все чаще ссылаются на конкретные сайты как источник ответа. Для этого у сайта есть свои технические требования, не пересекающиеся с классическим SEO.

Вот что реально влияет на цитирование:

Машиночитаемая структура. Микроразметка Schema.org в формате JSON-LD — конкретные типы FAQPage, HowTo, QAPage в зависимости от типа контента. Разметка дает прямой сигнал: здесь находится точный ответ на конкретный вопрос.

Формат ответа. Абзац под заголовком-вопросом сразу содержит четкий ответ в пределах 40–60 слов — это тот кусок текста, который нейросеть может процитировать целиком, не сокращая и не додумывая. Если ответ размазан на пять абзацев вступления, модель либо не процитирует страницу вообще, либо возьмет цитату у более прямолинейного конкурента.

E-E-A-T. Experience, Expertise, Authoritativeness, Trustworthiness. На практике: указан автор и его квалификация, есть ссылки на первоисточники — отчеты, исследования, официальные документы, материал обновляется регулярно.

У нас в Аспро есть подтверждение на своем опыте: после того как мы закрыли похожий набор технических ошибок на сайте Аспро.Cloud, число уникальных запросов через ИИ-чаты выросло с 500 до 1000 в пике за два месяца.

Частые технические проблемы

Если вывести топ находок за последние два года аудитов, получится короткий и предсказуемый список:

• Неоптимизированные изображения. Карточка товара с фото 4000×3000 пикселей, которое браузер сжимает на лету до размера иконки — классика, которая одна способна утащить LCP за 4 секунды. Проверить — вкладка Network в DevTools браузера, отсортировать запросы по размеру; исправить — сжать в WebP и подключить lazy-load для картинок ниже первого экрана.

• Сторонние скрипты без задержки загрузки. Виджет чата, счетчик аналитики, пиксель рекламной сети — каждый блокирует основной поток загрузки, если подключен синхронно. Проверить — та же вкладка Network, скрипты в начале очереди загрузки; исправить — атрибуты async или defer, либо перенос в Google Tag Manager с отложенным запуском.

• Отсутствие кеширования статики. Браузер заново скачивает логотип и CSS-файл при каждом переходе между страницами, вместо того чтобы взять их из кеша. Проверить — заголовок Cache-Control в ответе сервера через DevTools; исправить — настроить кеширование статики на сервере или подключить CDN.

• Избыточный JavaScript. Библиотеки, подключенные на будущее и забытые в коде, все равно грузятся и исполняются, даже если функциональность ими давно не пользуется. Проверить — вкладка Coverage в DevTools показывает процент неиспользуемого кода на странице; исправить — убрать лишние библиотеки или разбить код на части, которые подгружаются по необходимости.

Ни одна из этих проблем не требует переписывать сайт с нуля. Каждая лечится точечно, если ее сначала найти.

Как провести первичный аудит самостоятельно

Не обязательно сразу заказывать полный аудит — часть диагностики бесплатна и занимает 20 минут:

• PageSpeed Insights (pagespeed.web.dev) — вставляете url, получаете все три метрики Core Web Vitals по вашей странице отдельно для мобильной и десктопной версии, плюс список конкретных рекомендаций.

• Search Console, раздел Core Web Vitals — то же самое, но по реальным данным пользователей за последние месяцы.

• Яндекс.Вебмастер — проверка индексации, корректности robots.txt и sitemap.xml, плюс отдельный раздел видимости сайта в Алисе.

• Google Rich Results Test — проверка, читается ли ваша микроразметка Schema.org корректно, без синтаксических ошибок в JSON-LD.

Но здесь нужно уметь интерпретировать и приоритизировать результат. Список из 40 найденных предупреждений бесполезен без понимания, какие три из них дадут 80% эффекта.

Чеклист по приоритетам

Блок 1 — опыт и конверсия, критично. Проблемы LCP/INP/CLS в зоне плохо, слабая мобильная адаптация, битые формы заказа, неработающая корзина или поиск по каталогу.

Блок 2 — позиции в поиске. Закрытые от индексации разделы, устаревший sitemap.xml, кривые canonical-теги.

Блок 3 — видимость в ИИ-ответах. Микроразметка Schema.org, формат ответа на 40–60 слов, оформление E-E-A-T.

Блок 4 — технический долг, ускоряет все каналы сразу. Оптимизация изображений, кеширование статики, отложенная загрузка сторонних скриптов, чистка неиспользуемого JavaScript.

Итог

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

Поэтому если сайт стоит на решениях Аспро, часть этой работы уже сделана: Core Web Vitals и базовая микроразметка Schema.org закрыты из коробки, а сам аудит и приоритизация находок остаются ручной работой.

Если хотите быстро проверить свой сайт на видимость в ИИ-ответах — вот чек-лист из 6 главных причин, почему сайт не попадает в ответы нейросетей.

А вы уже смотрите отчет Core Web Vitals в Search Console регулярно, или проверяете сайт только когда падают продажи?