Техническая оптимизация GEO: как структура страницы, скорость загрузки и структурированные данные влияют на сканирование ИИ
I. L1 — вход: может ли бот прочитать вашу страницу
Первый уровень технической оптимизации — это не оптимизация, а разминирование. Самая частая техническая проблема GEO на корпоративных сайтах B2B — бот вообще не заходит. Причин три: ошибочная блокировка в robots.txt, фильтрация по UA на файрволе, пустая оболочка при чистом JS-рендеринге.
| Вопрос | Способ проверки | Действие |
|---|---|---|
| robots ошибочно блокирует ИИ-ботов | Проверить robots.txt и коды ответа для ботов | Явно разрешить GPTBot, OAI-SearchBot, PerplexityBot |
| WAF блокирует неизвестные UA | Проверить через curl с UA бота | Добавить эти UA ботов в белый список |
| Пустой первый экран при чистом JS-рендеринге | Забрать HTML через curl и найти текст через grep | Внедрить SSR или SSG |
| Китайская и английская версии страницы не совпадают | Проверить обе версии через curl | Убедиться, что обе версии отдают текст напрямую |
Способ проверки вполне конкретный. В логах сервера отфильтруйте за последние 30 дней по UA этих ботов: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Googlebot. Если все коды ответа 4xx — значит, доступ заблокирован; если есть 200, но посещается только главная — значит, внутренние ссылки или sitemap не дают боту добраться до глубоких страниц. О том, как составить sitemap, читайте в разделе о структуре ссылок Реструктуризация сайта и смена домена.
Пример из практики: у клиента на отдельном сайте WordPress стоял плагин безопасности, который по умолчанию блокировал всех неизвестных ботов. Через полгода после запуска мы проверили логи и обнаружили, что PerplexityBot не приходил ни разу. После добавления его в белый список на второй неделе бот начал заходить на страницы товаров, а через 4 недели в ответах Perplexity появились ссылки на эту компанию. Для решения не нужно менять контент — достаточно одной строки в конфигурации.
II. L2 — скорость: TTFB и LCP определяют, как часто приходит бот
Традиционное SEO считает скорость страницы вопросом удобства пользователей, и Core Web Vitals тоже рассчитаны на людей. Но для ИИ-бота скорость определяет приоритет и частоту сканирования. Бот сортирует очередь по времени ответа: страницы с TTFB больше 2 секунд уходят в конец, а период повторного сканирования растягивается с 3 дней до 2 недель.
| Показатель | Критерий | Влияние при несоблюдении | Что улучшать |
|---|---|---|---|
| TTFB | ≤ 1,5 секунды | Приоритет сканирования снижен | Кэш CDN, обновление PHP |
| LCP | ≤ 2,5 с | Неполный chunk первого экрана | Сжатие изображений, встраивание критического CSS |
| INP | ≤ 200 мс | Слабо влияет на ботов, сильно — на людей | Отложенная загрузка сторонних скриптов |
| CLS | ≤ 0,1 | Слабо влияет на GEO | Фиксированные пропорции изображений |
Для GEO важнее всего TTFB и LCP. INP и CLS в основном влияют на реальных пользователей, а на сканирование ботами — почти нет, поэтому не стоит их переоптимизировать. Конкретные пороги и приоритеты оптимизации — см.Core Web Vitals. Выбор узла CDN сильнее всего влияет на TTFB. Для B2B-сайтов, выходящих на зарубежные рынки, стоит подключить узлы в Северной Америке и Европе — см.Глобальное ускорение через CDN.
Контринтуитивный вывод: медленная страница — это не «проблема пользовательского опыта», а проблема частоты сканирования для GEO. Если у страницы товара TTFB 3 секунды, а контент не хуже, чем у конкурентов, бот заходит раз в две недели — значит, обновление контента модель увидит только через две недели, и цитируемость закономерно отстаёт. Сократите TTFB до 1,5 секунды — и бот будет заходить в 4–5 раз чаще.
Три. Уровень L3 — понять: структура страницы не даёт модели гадать
Когда бот уже может прочитать страницу и делает это быстро, остаётся её понять. Этот уровень держится на структуре страницы и структурированных данных. Модель судит о содержании страницы по иерархии заголовков HTML, таблицам и анкорам ссылок. При хаотичной структуре ей приходится догадываться по контексту, и вероятность ошибки растёт.
| Элемент структуры | Правильный вариант | Неправильный вариант |
|---|---|---|
| H1 | Один на страницу, с главным ключевым словом | Несколько H1 или ни одного |
| Иерархия H2/H3 | Последовательная по логике контента | Пропуск уровней, H4 в роли подзаголовка |
| Таблицы | Есть thead, первая строка — пороговое значение | Таблица собрана из изображений |
| Якорь | У каждого H2 есть id | Нет id, модель не может сослаться на абзац |
| Внутренние ссылки | Анкор — ключевое слово | Анкор — «нажмите здесь» |
Три обязательных блока структурированных данных (Organization, WebSite, BreadcrumbList) нужны на всём сайте — это удостоверение сущности, которое вы выдаёте модели. На страницах товаров и статей добавьте ещё Product, Article, FAQPage. Поля должны совпадать с видимым контентом: расхождение приведёт к ручным санкциям Google. Полный список разметки — см.Структурированные данные Schema. О том, как сущность распознаётся в ответах AI, — см.Граф знаний и разметка сущностей.
Пример из практики: если таблица характеристик товара собрана из изображений, бот видит картинку, и OCR не обязательно распознает цифры в таблице. Если же это настоящая HTML-таблица, а в thead написано «PN16, верхний предел рабочей температуры дискового затвора», модель может извлечь эту строку как факт. О границах локализации изображений — см.Работа с графиками на многоязычном сайте.
Четыре. Порядок проверки и сроки запуска
Не меняйте все три уровня сразу. Идите по порядку: у каждого уровня есть чёткие инструменты проверки и сроки.
| Шаг | Инструмент | Срок | Критерий прохождения |
|---|---|---|---|
| 1. Проверьте логи robots | Фильтрация ботов по UA в логах сервера | В тот же день | Все 5 AI-ботов получают код 200 |
| 2. Замерьте TTFB/LCP | Lighthouse、PageSpeed | Исправить за 3 дня | TTFB ≤ 1,5 с, LCP ≤ 2,5 с |
| 3. Проверьте Schema | Тест расширенных результатов | В тот же день | Три блока без ошибок |
| 4. Проверьте иерархию H | Расширение браузера для структуры | В тот же день | Один H1, без пропуска уровней |
| 5. Дождитесь повторного сканирования | Постоянно следите за логами сервера | 1–2 недели | Частота заходов бота растёт |
Не ждите, что после правок цитирование вырастет на следующий день. Ботам нужно 1–2 недели на повторный обход, ещё 1–2 недели уходит на обновление индекса модели. Поэтому после технической оптимизации подождите минимум 4 недели и только потом прогоняйте фиксированный набор вопросов и смотрите, как изменилась доля цитирований. Эту задержку обязательно учитывать при планировании GEO-экспериментов, см.планирования экспериментов для GEO.
Типичная ошибка — сразу браться за новый контент. Пока не пройдены L1 и L2, новый контент доберётся до модели не лучше старого. Сначала разминирование, потом ускорение и только затем контент. Если нарушить этот порядок, отдача на каждом шаге будет меньше.
Ещё один момент, который легко упустить: технический слой многоязычных сайтов нужно проверять отдельно. Если немецкая, испанская и арабская версии используют один и тот же robots, а узлы CDN настроены только в США, TTFB для неанглоязычных рынков будет выше, и доля цитирований в соответствующих языках не вырастет.Многоязычный GEO— про немецкий, испанский и арабский рынки: технически сначала нужно закрыть три вещи — локальные узлы, локальную разметку hreflang и локальное кеширование, а уже потом говорить о контенте.
Пример из практики: у клиента, выходящего на зарубежные рынки с многоязычным сайтом, доля цитирований английской версии в норме, а немецкая в Gemini почти на нуле. В логах видно: когда Googlebot заходит на немецкую версию с европейского узла, TTFB составляет 3,2 секунды, и страница уходит в конец очереди. Добавили европейский узел CDR, закешировали немецкие страницы во Франкфурте — TTFB упал до 1,1 секунды, и через три недели доля цитирований немецкой версии начала расти. Проблема не в контенте, просто в техническом слое не хватало одного региона.
И последнее напоминание: после технической оптимизации не меняйте URL слишком часто. При каждом обновлении нужна сквозная переадресация 301, иначе бот только привыкнет к старым ссылкам, а они оборвутся, и новые ссылки придётся заново ставить в очередь. Как построить карту 301 при переносе сайта, см.Реструктуризация сайта и смена домена. Технический слой — работа неспешная: как только он стабилизировался, не трогайте его без нужды.
Сделайте трёхуровневую техническую проверку ежемесячным ритуалом и поставьте её рядом с другими регулярными пунктами из графиком обслуживания сайта: раз в месяц прогоняйте логи ботов, Lighthouse и Rich Results Test. Технический долг не так заметен глазу, как долг по контенту, но именно он определяет, доберётся ли ваш контент до модели. Стабильный, быстрый сайт с чёткой структурой — основа всей работы над GEO-контентом.
FAQ: частые вопросы
С какого уровня начинать техническую оптимизацию GEO?
Почему медленный TTFB влияет на цитирование в AI?
Как сайты с чистым JS-рендерингом влияют на GEO?
Насколько структурированные данные Schema влияют на цитирование в AI?
Через сколько после технических правок будет виден рост цитирования?
Таблицы с параметрами на странице — картинкой или HTML table?
В заключение
Технический слой GEO часто недооценивают контент-команды. Все пишут статьи получше, но как бы хороша ни была статья, если бот не может зайти, заходит медленно или не понимает — всё впустую. Три уровня технической оптимизации по сути прокладывают модели дорогу: сначала открыть ворота, потом выровнять путь, а в конце расставить указатели.
Три шага к результату: на этой неделе проверьте по логам сервера коды ответа для 5 AI-ботов и добавьте заблокированных в белый список; на следующей — измерьте TTFB и LCP в Lighthouse и сократите TTFB до 1,5 секунды; на третьей — проверьте три типа Schema в Rich Results Test и дополните разметку по всему сайту. Сделайте эти три вещи, подождите 4 недели и прогоните набор вопросов — вы увидите первый скачок цитирования.
Запомните главное: техническая оптимизация для GEO нужна не людям, а ботам — откройте дверь, проложите дорогу, расставьте указатели, и только тогда контент доберётся до модели.