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

Редакция «Текстерры»

Технический аудит не гарантирует попадание сайта в AI Overviews, ChatGPT Search, Perplexity, Поиск с Алисой или другие AI-интерфейсы. Задача у него базовая: проверить, могут ли поисковые и AI-краулеры добраться до важных страниц, увидеть основной контент, отрендерить его и связать URL с нужной темой.

Если сайт закрыт в robots.txt, отдает пустой HTML, путает канонические версии страниц или теряет контент на мобильной версии, дальнейшая работа по повышению видимости сайта потеряет большую долю смысла. Можно улучшать тексты, внедрять Schema.org, обновлять старые материалы и работать с внешним контуром, но часть сигналов просто не дойдет до систем, которые должны их обработать.

Какой режим аудита выбрать

Технический аудит бывает разной глубины: сайту на 50 страниц и интернет-магазину с фильтрами, пагинацией, JavaScript и региональностью нужны разные проверки.

Экспресс-аудит

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

Проверяем:

• индексацию важных страниц;

• robots.txt;

• sitemap.xml;

• случайные noindex и некорректные canonical;

• мобильную версию;

• скорость загрузки;

• главные редиректы;

• работу счетчиков аналитики.

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

Полный технический аудит

Полный аудит нужен для крупных сайтов, каталогов, проектов после редизайна и сайтов на SPA (Single Page Application — ресурсов, которые загружают всю страницу сразу).

К базовым проверкам добавляем:

• анализ серверных логов;

• поиск неявных дублей;

• проверку страниц фильтров и сортировок;

• проверку пагинации;

• анализ внутренней перелинковки;

• диагностику JavaScript-рендеринга;

• проверку Core Web Vitals по шаблонам страниц;

• валидацию структурированных данных;

• проверку доступности для нужных AI-краулеров.

На сложных проектах часть аудита делает SEO-специалист, часть — разработчик или технический специалист. Без доступа к серверным правилам, CDN, WAF, логам и CMS некоторые проблемы просто не увидеть.

Аудит после изменений

Отдельная проверка нужна после переезда, редизайна, смены CMS, обновления каталога, изменения URL-структуры или крупного релиза фронтенда.

Проверяем:

• открыты ли важные разделы для сканирования;

• работают ли постраничные редиректы;

• попали ли актуальные канонические URL в sitemap;

• сохранились ли title, description, H1, основной текст и структурированные данные;

• собирают ли данные Яндекс Метрика, Google Analytics 4 и другие счетчики;

• не ограничен ли доступ поисковых и AI-краулеров на уровне robots.txt, сервера, CDN или WAF.

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

Как подготовиться к аудиту

Для проверки понадобятся:

• Яндекс Вебмастер;

• Google Search Console;

• Яндекс Метрика;

• Google Analytics 4;

• доступ к CMS;

• доступ к robots.txt и sitemap.xml;

• PageSpeed Insights;

• Lighthouse или аналогичный инструмент;

• Screaming Frog, Sitebulb, Netpeak Spider или другой краулер;

• серверные логи при наличии технической возможности;

• доступ к CDN, WAF и хостингу, если они могут ограничивать ботов.

Что проверять в ходе аудита и как исправлять ошибки

Индексация

Индексация показывает, какие страницы поисковые системы реально видят и допускают к показу. Оператор site: подходит только для грубой проверки: он дает неполную и часто искаженную картину.

Что проверить

В Яндекс Вебмастере откройте «Индексирование» → «Страницы в поиске». Посмотрите количество URL в поиске, список исключенных страниц и причины исключения.

В Google Search Console откройте «Индексирование» → «Страницы». Изучите причины, по которым URL не попали в индекс или были исключены.

Для важных URL используйте точечные инструменты:

• «Проверка URL» в Google Search Console;

• «Информация о странице» в Яндекс Вебмастере.

Что считать проблемой

Критичные признаки:

• важные страницы отсутствуют в поиске;

• в индексе много технических, дублирующих или служебных URL;

• страницы исключены из-за noindex, canonical, редиректа или блокировки;

• поисковая система видит другой canonical, чем указан на странице;

• в индексе остались старые URL после переезда;

• страницы есть в sitemap, но долго не появляются в поиске.

Как исправить

Для каждой важной страницы проверьте:

• HTTP-статус;

• доступность для сканирования;

• meta robots и X-Robots-Tag;

• canonical;

• наличие URL в sitemap;

• внутренние ссылки на страницу;

• наличие основного контента в HTML после рендеринга.

Если проблема массовая, ищите ее на уровне шаблона, CMS, серверных правил или логики генерации URL.

Robots.txt, meta robots и X-Robots-Tag

Robots.txt управляет сканированием. Meta robots и X-Robots-Tag управляют индексированием и показом страницы. Эти инструменты можно спутать, хотя задачи у них разные.

Важный момент: страница, закрытая в robots.txt, не сможет корректно передать поисковой системе директиву noindex из HTML. Краулер не зайдет на страницу и не прочитает тег.

Что проверить

Проверьте robots.txt вручную и через инструменты:

• «Анализ robots.txt» в Яндекс Вебмастере;

• настройки сканирования в Google Search Console;

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

Отдельно посмотрите, не заблокированы ли CSS, JavaScript, изображения и API-эндпоинты — адреса, к которым обращается программа, чтобы получить данные или выполнить действие.

Что считать проблемой

Частые ошибки:

• важный раздел закрыт в robots.txt;

• страница закрыта в robots.txt и одновременно содержит noindex;

• URL добавлен в sitemap, но закрыт от сканирования;

• закрыты CSS или JS, из-за чего робот видит сломанную страницу;

• meta robots noindex по ошибке стоит на коммерческих или информационных страницах;

• X-Robots-Tag на уровне сервера закрывает файлы или страницы шире, чем планировалось.

Как исправить

Для важных страниц оставьте доступ к сканированию открытым. Если страницу нужно убрать из поиска, используйте noindex при условии, что робот может зайти на URL и прочитать директиву.

Robots.txt используйте для управления обходом служебных разделов, дублей и технических URL. Для защиты закрытых данных нужны авторизация, пароль, IP-ограничение или серверные настройки.

Sitemap и canonical

Sitemap помогает краулерам быстрее находить важные URL. Canonical помогает указать предпочтительную версию страницы при дублях или очень похожем контенте. Оба сигнала полезны, но они не заменяют чистую структуру сайта и внутренние ссылки.

Что проверить

В sitemap должны попадать актуальные канонические URL, которые нужно видеть в поиске. Google в документации по sitemap отдельно пишет: карта сайта помогает сообщить о важных URL, но не гарантирует их сканирование и индексацию.

Проверьте, что в sitemap нет:

• URL с 3xx, 4xx и 5xx;

• страниц с noindex;

• дублей;

• закрытых в robots.txt адресов;

• старых URL после переезда;

• параметрических страниц без поисковой ценности.

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

Что считать проблемой

Опасные ситуации:

• canonical ведет на несуществующую страницу;

• canonical ведет на редирект;

• canonical ведет на страницу с другим смыслом;

• все страницы пагинации указывают canonical на первую страницу без учета задачи раздела;

• фильтры, сортировки и UTM создают тысячи дублей;

• sitemap содержит основные, дублирующие и редиректные URL вперемешку.

Как исправить

Выберите основную версию URL и закрепите ее сигналами:

• постоянными редиректами с технических дублей;

• self-canonical на индексируемых страницах;

• чистым sitemap;

• внутренними ссылками на канонические URL;

• единым форматом адресов со слэшем или без него;

• единым протоколом и хостом.

Старый инструмент URL Parameters в Google Search Console больше не используем: Google закрыл его в 2022 году. Параметры URL нужно контролировать на стороне сайта: через логику CMS, canonical, редиректы, robots.txt, внутренние ссылки и правила для фильтров.

Рендеринг и JavaScript

JavaScript мешает поисковым системам и AI-краулерам, когда важные данные появляются только после выполнения скриптов или пользовательских действий. В руководстве Google по JavaScript SEO описано, как поисковик обрабатывает JavaScript и какие ограничения нужно учитывать.

Что проверить

Откройте страницу через инструмент проверки URL в Google Search Console и изучите отрендеренную версию. Дополнительно сравните:

• исходный HTML;

• DOM после рендеринга;

• текстовую версию страницы;

• результат обхода краулером;

• то, что видит пользователь в браузере.

В отрендеренной версии должны быть доступны:

• основной текст;

• цены;

• характеристики товаров;

• условия услуги;

• отзывы, если они важны для страницы;

• хлебные крошки;

• внутренние ссылки;

• структурированные данные.

Что считать проблемой

Критичные признаки:

• в исходном HTML нет основного текста;

• ссылки реализованы через обработчики клика без нормального href;

• товары, цены или отзывы подгружаются только после действия пользователя;

• важный контент доступен только авторизованным пользователям;

• бесконечная прокрутка не имеет альтернативной пагинации;

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

Контент в табах и аккордеонах сам по себе не опасен — но важно, чтобы он был доступен в HTML/DOM и не терялся на мобильной версии. Проблема начинается там, где данные появляются только после клика, авторизации или сложной цепочки скриптов.

Как исправить

Для важных шаблонов используйте server-side rendering, static rendering или гибридный подход. Главные ссылки размещайте в стандартных тегах <a href="">. Для бесконечной прокрутки добавляйте пагинацию или другие доступные URL.

Если сайт построен как SPA (о них мы упоминали выше), отдельно проверьте маршрутизацию, коды ответа, canonical, title, description и доступность контента при прямом открытии каждого URL.

Мобильная версия

Google использует mobile-first indexing: для индексации и оценки страницы важна мобильная версия. Яндекс тоже учитывает адаптивность и удобство мобильного просмотра.

Что проверить

Используйте:

• инструмент проверки URL в Google Search Console;

• PageSpeed Insights;

• Lighthouse;

• ручную проверку на смартфоне;

• краулер с мобильным user-agent.

Сравните мобильную и десктопную версии по ключевым шаблонам.

Что считать проблемой

Проверьте, не теряются ли на мобильной версии:

• основной текст;

• таблицы;

• цены;

• характеристики;

• отзывы;

• FAQ-блоки;

• внутренние ссылки;

• хлебные крошки;

• структурированные данные;

• title, description и H1.

Отдельно проверьте мобильные поддомены, если они есть. Они должны вести на эквивалентные мобильные страницы, без массовой отправки пользователей и роботов на главную.

Как исправить

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

Дубли и параметры URL

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

Что проверить

Ищите дубли через краулер, Search Console, Яндекс Вебмастер и серверные логи.

Типовые источники дублей:

• версии с www и без www;

• http и https;

• слэш на конце и без слэша;

• UTM-метки;

• сортировки;

• фильтры;

• внутренний поиск;

• параметры сессий;

• страницы пагинации;

• теги и пустые категории.

Что считать проблемой

Особенно опасны ситуации, где дубли создаются автоматически и быстро масштабируются: фильтры интернет-магазина, сортировки каталога, параметры наличия, цвета, размера, региона, цены.

Проблема усиливается, если на дублирующие URL ведут внутренние ссылки или они попадают в sitemap.

Как исправить

Действуйте в несколько слоев:

• настройте постоянные редиректы с технических дублей;

• используйте canonical для похожих страниц;

• оставляйте в sitemap только канонические URL со статусом 200;

• уберите внутренние ссылки на дублирующие адреса;

• закройте мусорные комбинации фильтров от сканирования, если они создают ловушки для краулеров;

• оставьте индексируемыми только те фильтры и категории, у которых есть спрос, нормальный контент и понятная бизнес-ценность.

Для Яндекса на отдельных проектах может пригодиться Clean-param. Для Google старый инструмент URL Parameters в Search Console больше недоступен.

Структура сайта и перелинковка

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

Что проверить

Проверьте:

• глубину вложенности важных страниц;

• страницы-сироты;

• битые внутренние ссылки;

• навигацию;

• хлебные крошки;

• анкоры;

• HTML-карту сайта при необходимости;

• связи между информационными и коммерческими страницами.

Важные страницы лучше держать на расстоянии до трех кликов от главной или от сильных разделов. Это не абсолютный закон, но хороший рабочий ориентир.

Что считать проблемой

Критичные ошибки:

• страница есть в sitemap, но на нее нет внутренних ссылок;

• важный раздел доступен только через поиск или фильтр;

• внутренние ссылки ведут на 404, редиректы или дублирующие URL;

• анкоры состоят из «подробнее», «тут», «читать»;

• хлебные крошки не совпадают с реальной структурой;

• старые статьи не передают пользователей и краулеров к актуальным материалам.

Как исправить

Добавьте внутренние ссылки на важные страницы из меню, категорий, статей, карточек и коммерческих посадочных. Анкоры делайте описательными, естественными и точными. Ссылки должны быть доступными для обхода, а анкор — помогать понять, куда ведет ссылка.

Хлебные крошки стоит разметить. Подробнее о структурированных данных для AI-поиска мы писали в статье «Разметка Schema.org для AI-поиска: что внедрить на сайт».

Метатеги, заголовки и сниппеты

Title, description, H1 и первый экран помогают поисковым системам и пользователям быстро понять тему страницы. Для AI-систем это тоже полезно: чем яснее страница, тем проще извлечь из нее основной смысл.

Что проверить

Проверьте по шаблонам:

• title;

• description;

• H1;

• структуру H2–H3;

• первый абзац;

• автосниппеты;

• соответствие страницы интенту;

• отсутствие переспама.

Что считать проблемой

Проблемы видны, если:

• title одинаковый на десятках страниц;

• title переспамлен ключами;

• description состоит из набора фраз через запятую;

• H1 не совпадает с реальным содержанием страницы;

• первый абзац слишком общий;

• важный ответ спрятан после длинной подводки;

• поисковик регулярно заменяет сниппет случайным фрагментом.

Как исправить

Title должен точно называть страницу и отличать ее от соседних URL. Description лучше писать как короткий полезный анонс для человека. H1 должен быть одним очевидным главным заголовком страницы. Технически несколько H1 не всегда ломают страницу, но для аудита и редакционной дисциплины лучше держать понятную иерархию.

Первый абзац должен быстро объяснять, что пользователь получит на странице. Такой фрагмент проще прочитать человеку и проще извлечь поисковой или AI-системе.

Изображения и медиафайлы

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

Что проверить

Проверьте:

• вес изображений;

• формат файлов;

• alt;

• имена файлов;

• размеры width и height;

• lazy loading;

• приоритет загрузки главного изображения;

• доступность изображений для краулеров;

• отсутствие блокировки в robots.txt или CDN.

Официальные рекомендации Google собраны в руководстве «Image SEO best practices».

Что считать проблемой

Частые ошибки:

• тяжелое изображение на первом экране ухудшает LCP;

• у изображений нет width и height, из-за чего прыгает верстка;

• alt пустой там, где картинка несет смысл;

• alt забит ключами;

• изображения закрыты от сканирования;

• важная информация есть только на картинке и не продублирована текстом.

Как исправить

Используйте WebP или AVIF там, где это технически возможно. Для изображений ниже первого экрана включайте отложенную загрузку. Для главного изображения первого экрана задавайте приоритетную загрузку, если именно оно является LCP-элементом.

Alt пишите как краткое описание изображения. Если картинка декоративная, alt может быть пустым. Если на изображении есть важные данные, продублируйте их текстом на странице.

Core Web Vitals

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

Что проверить

Основные метрики:

• LCP — время отрисовки крупнейшего элемента в области просмотра, хороший ориентир — до 2,5 секунды;

• INP — задержка отклика страницы на действия пользователя, хороший ориентир — до 200 миллисекунд;

• CLS — визуальная стабильность страницы, хороший ориентир — до 0,1.

В PageSpeed Insights отдавайте приоритет полевым данным, если они доступны. Лабораторные данные полезны для диагностики, но они не заменяют реальный опыт пользователей.

Что считать проблемой

Типовые причины плохих показателей:

• тяжелый баннер первого экрана;

• лишние скрипты;

• долгий ответ сервера;

• блокирующие CSS и JS;

• сторонние виджеты;

• отсутствие размеров у изображений и рекламных блоков;

• резкие изменения макета после загрузки.

Как исправить

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

Начинайте с элементов, которые дают самый большой вклад: изображение первого экрана, серверный ответ, критический CSS, тяжелые скрипты, сторонние виджеты.

Редиректы и HTTP-статусы

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

Что проверить

Проверьте:

• 200 для актуальных страниц;

• 301 или 308 для постоянных переездов;

• 302 или 307 для временных ситуаций;

• 404 и 410 для удаленных страниц без замены;

• отсутствие цепочек редиректов;

• отсутствие циклов;

• постраничные редиректы после переезда.

Что считать проблемой

Критичные ошибки:

• все старые страницы ведут на главную;

• старый URL проходит через несколько редиректов;

• редирект ведет на нерелевантную страницу;

• внутренние ссылки ведут на редиректы вместо финальных URL;

• после переезда в sitemap остались старые адреса;

• удаленные страницы отдают 200 с пустым или нерелевантным контентом.

Как исправить

При переезде настраивайте постраничные редиректы на максимально близкие по смыслу новые URL. Если релевантной замены нет, лучше отдавать код 404 или 410, чем отправлять пользователя на случайную страницу.

Внутренние ссылки обновляйте до финальных URL — sitemap должен содержать актуальные страницы со статусом 200, а не редиректы.

Структурированные данные

Schema.org помогает поисковым системам точнее понимать сущности на странице: организацию, автора, товар, услугу, статью, хлебные крошки, отзывы, адрес, событие. Для AI-систем это тоже полезно, потому что разметка делает факты более явными.

Что проверить

Проверьте разметку через:

• Rich Results Test;

• Schema Markup Validator;

• валидатор микроразметки Яндекса;

• ручную проверку JSON-LD в коде страницы.

Что считать проблемой

Частые ошибки:

• разметка описывает то, чего нет на странице;

• рейтинг размечен без реальных отзывов;

• Organization заполнена неполно или противоречит сайту;

• автор указан в разметке, но на странице его нет;

• даты публикации и обновления расходятся с видимым текстом;

• JSON-LD сломан после изменения шаблона.

Как исправить

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

Подробный разбор типов разметки для AI-поиска есть в статье «Разметка Schema.org для AI-поиска: что внедрить на сайт».

AI-краулеры и AI-доступность

AI-доступность — часть общей технической доступности сайта. Она помогает AI-системам получить доступ к страницам и фактам, которые уже есть на сайте.

Что проверить

Сначала определите, какие системы важны для проекта: Google Search с AI-функциями, ChatGPT Search, Perplexity, Claude, Copilot, Поиск с Алисой и другие интерфейсы.

Затем проверьте:

• robots.txt;

• серверные правила;

• CDN;

• WAF;

• защиту от ботов;

• логи заходов нужных user-agent;

• доступность основного HTML;

• доступность структурированных данных;

• видимость авторов, дат, компании, контактов, условий, цен и фактов об услугах.

Что считать проблемой

Критичные признаки:

• все AI-боты закрыты одной общей директивой;

• нужный поисковый бот разрешен в robots.txt, но фактически не получает доступ к сайту из-за правил WAF или серверной защиты;

• сервер отдает ботам другую версию страницы;

• важный контент доступен только после авторизации;

• факты о компании спрятаны в PDF, картинках или сложных скриптах;

• на страницах нет авторов, дат, источников, контактов и понятной структуры.

Как исправить

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

Для страниц, которые должны участвовать в поиске и AI-ответах, обеспечьте:

• открытый доступ для нужных краулеров;

• полноценный HTML или корректный рендеринг;

• ясную структуру заголовков;

• факты в тексте страницы;

• автора и дату там, где это важно;

• структурированные данные без противоречий;

• внутренние ссылки на связанные материалы;

• отсутствие конфликтов между robots.txt, noindex, canonical и sitemap.

Если GEO-продвижение запущено, но видимого эффекта нет, техническая доступность — это, конечно, обязательная проверка, но все-таки не панацея. Я бы отдельно рекомендовала проверить аналитику. Переходы из AI-систем могут не фиксироваться, смешиваться с обычным referral-трафиком или искажаться из-за редиректов, некорректных UTM и особенностей браузеров внутри AI-интерфейсов. Поэтому отсутствие роста в отчетах не всегда означает, что на сайте что-то не так. Подробнее об этом мы писали в статье «Что делать, если GEO-продвижение не дает эффекта».

Дарья Завьялова,

главред в маркетинге TexTerra

Аналитика

Технический аудит должен проверять корректность измерений. Без нормальной аналитики сложно понять, что изменилось после правок.

Что проверить

Проверьте:

• установку Яндекс Метрики;

• установку GA4;

• события и цели;

• ecommerce-разметку, если она используется;

• корректность передачи UTM;

• отсутствие дублей счетчиков;

• работу аналитики на SPA;

• фиксацию форм, кликов, звонков и заявок;

• данные после редиректов и смены URL.

Что считать проблемой

Частые ошибки:

• счетчик установлен дважды;

• цели не срабатывают;

• SPA меняет URL без передачи нового просмотра страницы в аналитику;

• формы отправляются, но событие не фиксируется;

• после редиректа теряются UTM;

• внутренний трафик сотрудников портит данные;

• cookie-баннер нестабильно блокирует счетчики и искажает данные по визитам и целям.

Как исправить

Проверяйте аналитику через DebugView, Tag Assistant, режим отладки в Метрике и тестовые заявки. После крупных технических изменений сделайте отдельный контрольный список событий: просмотр страницы, отправка формы, клик по телефону, покупка, переход в мессенджер, скачивание файла.

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

Читайте также:

Как SEO делает бренд заметнее, понятнее и убедительнее

Каких AI-краулеров пускать на сайт и как настроить robots.txt для AI-видимости

Как подготовить контент для поиска в 2026 году: чек-лист