Техническое условие GEO, которое нужно проверить до стратегии цитирования
Если важный факт появляется только после выполнения JavaScript, AI-агент может вообще его не получить.
Это касается возможностей продукта, выводов на страницах сравнения, условий цен, ответов в документации, сведений об авторе и доказательств, которые вы хотите видеть в цитатах AI. То, что человек видит полную страницу в Chrome, не означает, что тот же контент получил краулер, извлекатель статьи или браузерный агент.
Один SEO-практик сравнил исходный HTML и страницу после рендеринга для разных шаблонов. В статьях, руководствах, магазинах, курсах, лендингах и категориях большая часть видимого контента уже была в HTML, а после JavaScript появлялась лишь небольшая часть. Важна не точная доля. Важен вопрос: содержит ли первый HTML-ответ тот ответ, который должен понять агент?
Для GEO это проверка допуска до цитирования. Система должна суметь получить ключевые факты страницы, прежде чем оценивать доказательства или выбирать страницу как источник.
Разные пути доступа имеют разный бюджет на JavaScript. Исходная загрузка и извлечение статьи обычно опираются только на HTML-ответ.
То, что Google рендерит JavaScript, не является обещанием для каждого агента
Фраза «Google умеет рендерить JavaScript» верна. Но опасно превращать её в предположение, что каждый AI-поисковик и агент увидит итоговую страницу в браузере.
Один и тот же URL может попасть в систему несколькими путями:
| Путь доступа | Что получает система | Зависимость от JavaScript |
|---|---|---|
| Исходный HTTP-запрос | Первый HTML-ответ | Не выполняется |
| Ридер или извлекатель статьи | Текст, выбранный из HTML | Обычно не выполняется |
| Автоматизация браузера | DOM после рендеринга | Может выполняться, но зависит от тайм-аута и политики |
| Конвейер поискового индекса | Загрузка, очередь и возможный рендеринг | Зависит от платформы |
| Агент с инструментом | Вывод выбранного им инструмента веб-загрузки | Часто близок к исходной загрузке |
Возможность рендеринга в Google не переносится автоматически на другие системы. Другие движки ответов, корпоративный поиск, браузерные агенты и инструменты извлечения веб-страниц могут брать только HTML или завершать работу до загрузки медленных клиентских данных. Строить архитектуру сайта на способности одной платформы — ненужная ставка.
Безопасное правило простое: публичные факты, важные для обнаружения и цитирования, должны читаться уже в первом ответе.
Проверяйте слой появления фактов, а не название фреймворка
SSR против CSR — не табель успеваемости GEO. Сайт на React, Vue или Next.js может быть удобен для агентов; традиционный серверный сайт тоже может спрятать важные факты за клиентским API-запросом.
Проверяйте, на каком слое становится доступен каждый важный блок.
| Слой контента | Типичный пример | Риск для GEO |
|---|---|---|
| Начальный HTML | Заголовок, текст, характеристики, FAQ, автор, дата | Низкий |
| HTML с данными, полученными сервером | Текущая цена или региональная доступность | Низкий или средний |
| Клиентский API-запрос | Преимущества продукта, таблица сравнения, тело документации | Высокий |
| После действия пользователя | Вкладки, аккордеоны, фильтры, бесконечная прокрутка | Высокий |
| После входа | Дашборд или приватная база знаний | Не рассчитывайте на публичное цитирование |
Факт, который AI должен повторить в публичном ответе, не должен зависеть от клика, успешного клиентского запроса или долгой задачи JavaScript. Интерактивность можно сохранить там, где она полезна, но объясняющий слой нужно выводить раньше.
Типичные ошибки: страница продукта, которая отдаёт лишь экран загрузки; страница сравнения с таблицей после hydration; документация, загружающая основной текст через клиентский роутинг; категория, целиком зависящая от бесконечной прокрутки; визуальный модуль, где вывод существует только в изображении или Canvas.
Страница после рендеринга может выглядеть отлично и всё же раскрывать слишком мало смысла в первом HTML-ответе.
Сравнивайте два состояния страницы, а не гадайте
Не спрашивайте, использует ли сайт React. Сохраните две версии одного URL:
- Исходный HTML, полученный без запуска JavaScript.
- Текст
mainпосле открытия страницы в браузере и ожидания основного контента.
Начать можно с простой загрузки:
curl -sL "https://example.com/product" -o raw.html
Сравнивайте семантические блоки, а не шапку, баннер Cookie и подвал:
- H1 и краткий ответ
- Первый объясняющий абзац
- Факты о продукте и ограничения
- Таблицы сравнения
- Ответы FAQ
- Автор и дата обновления
- Внутренние ссылки и canonical URL
Не делайте networkidle единственным условием готовности браузера. Аналитика, чат-виджеты и долгие соединения могут держать страницу в состоянии загрузки бесконечно. Надёжнее ждать появления селектора основного контента или завершения конкретного источника данных с ключевыми фактами.
Сравнение можно превратить в метрику релиза:
доля раскрытия ключевого контента = важные блоки в исходном HTML / важные блоки, необходимые странице
Цель не в том, чтобы поместить в HTML каждый пиксель. Цель в том, чтобы доказательства, нужные для понимания страницы, не зависели от успешного выполнения кода на клиенте.
Сначала исправьте путь доставки контента, а не переписывайте фронтенд
Большинству команд не нужно переписывать весь сайт. Перенесите стабильную публичную информацию в первый ответ и продолжайте использовать JavaScript для фильтров, сохранённых настроек, карт, анимации и персонализации.
| Ситуация | Более подходящий способ доставки |
|---|---|
| Стабильные статьи, руководства и глоссарии | Статическая генерация или prerender во время сборки |
| Часто меняющиеся цены, остатки или региональные данные | Серверный рендеринг с кэшем и явной инвалидацией |
| Интерактивная страница со стабильным объяснением | Выводите объяснение, факты и FAQ на сервере; интерактивность гидратируйте на клиенте |
| Публичная документация внутри большого приложения | Предварительно рендерьте публичные маршруты и не привязывайте основной ответ ко входу |
| Зависимость от нескольких внутренних API | Собирайте критические данные на сервере или в BFF-слое, общем для HTML и приложения |
JSON-LD полезен, но не заменяет читаемый контент страницы. Структурированные данные должны описывать факты, которые посетитель и извлекатель найдут и в документе.
Двухнедельный план для GEO-команды
Дни 1-2: перечислите шаблоны, влияющие на органическое обнаружение, AI-цитаты, поддержку продаж или поддержку клиентов. Обычно достаточно статей, продуктовых страниц, документации, сравнений и категорий.
Дни 3-5: возьмите URL-образцы каждого шаблона. Сохраните исходный HTML и контент после рендеринга. Отметьте отсутствующие H1, объяснения, факты о продукте, FAQ и внутренние ссылки.
Дни 6-9: сначала исправьте самые ценные и стабильные страницы. Перенесите определения, факты, выводы сравнений и FAQ на сервер или в результат сборки.
Дни 10-14: повторите те же проверки и добавьте релизный шлюз. Шаблон не должен выходить в публикацию, если в начальном HTML нет H1, главного ответа, ключевых фактов или canonical-ссылок.
Это не гарантирует цитату от каждого AI-продукта. Но это устраняет ненужный сбой: публикацию открытой информации, которую потенциальный агент не может надёжно прочитать.
Позиция Auspia
Разговоры о GEO часто начинаются с упоминаний бренда, качества источников, ясности сущностей и структуры ответа. Всё это предполагает, что система сначала получила страницу.
JavaScript сам по себе не проблема. Проблема в том, чтобы считать публичное объяснение побочным эффектом клиентского рантайма. Пусть HTML отвечает за контент, а JavaScript — за опыт. Такое разделение улучшает тестирование, техническое SEO и доступность для агентов.
FAQ
Если Google рендерит JavaScript, нужен ли аудит исходного HTML?
Да. Возможность Google не означает, что другие краулеры, ридеры и агенты проходят тот же путь. Проверка исходного HTML также выявляет задержки рендеринга и сбои клиентских запросов.
Всегда ли SSR лучше CSR для GEO?
Нет. Подойдут статическая генерация, серверный рендеринг и prerender. Для высокоинтерактивных элементов можно оставить клиентский рендеринг. Критерий один: читаются ли ключевые факты публичной страницы в первом HTML-ответе.
Нужно ли избегать JavaScript во всех частях страницы?
Нет. Его можно использовать для фильтров, анимации, карт, сохранённых настроек, персонализации и сценариев после входа. В первую очередь обеспечьте доступность контента, объясняющего тему страницы и содержащего цитируемые факты.
Решает ли llms.txt проблему контента, который появляется только после JavaScript?
Нет. Даже если система читает llms.txt, она не получает автоматически полный текст статьи или данные клиентского API. Сама публичная страница должна делать ключевой контент доступным.
Примечание об источнике
Статья вдохновлена постом Adrian Skowron о сравнении видимого контента SSR и CSR . Диаграмма в посте отражает измерения шаблонов автора, а не отраслевой benchmark.
Автор: Julian Mercer, технический SEO-практик Auspia с 14-летним опытом. Julian пишет о сканировании, рендеринге, структурированных данных и технической основе понимания контента поиском и AI.
