Технічна умова GEO, яку слід перевірити до стратегії цитування
Якщо важливий факт з'являється лише після виконання JavaScript, AI-агент може взагалі його не отримати.
Це стосується можливостей продукту, висновків сторінок порівняння, умов ціни, відповідей у документації, даних автора й доказів, які ви хочете бачити в цитатах AI. Те, що людина бачить повну сторінку в Chrome, не доводить, що crawler, витягувач статті або браузерний агент отримав той самий контент.
Один SEO-практик порівняв сирий HTML зі сторінкою після рендерингу для різних шаблонів. У статтях, посібниках, магазинах, курсах, landing page і категоріях більшість видимого контенту вже була в HTML; лише невелика частина з'являлася після JavaScript. Важливий не точний відсоток. Важливе запитання: чи містить перша HTML-відповідь ту відповідь, яку має зрозуміти агент?
Для GEO це перевірка придатності до цитування. Система повинна вміти отримати ключові факти сторінки, перш ніж оцінювати докази або обирати її як джерело.
Різні шляхи доступу мають різні можливості для JavaScript. Сире завантаження й витягування статті зазвичай спираються лише на HTML-відповідь.
Те, що Google рендерить, не є обіцянкою для кожного агента
Твердження «Google може рендерити JavaScript» правильне. Але перетворювати його на припущення, що кожен AI-пошуковий продукт і кожен агент побачить фінальну сторінку браузера, ризиковано.
Один URL може потрапити до системи кількома шляхами:
| Шлях доступу | Що отримує система | Залежність від JavaScript |
|---|---|---|
| Сирий HTTP fetch | Початкову HTML-відповідь | Не виконується |
| Reader або витягувач статті | Текст, вибраний з HTML | Зазвичай не виконується |
| Автоматизація браузера | DOM після рендерингу | Може виконуватися, але залежить від timeout і політики |
| Конвеєр пошукового індексу | Fetch, черга й можливий рендеринг | Залежить від платформи |
| Агент з інструментом | Вивід обраного web-fetch інструмента | Часто близький до сирого fetch |
Здатність Google до рендерингу не є переносною гарантією. Інші answer engine, внутрішні системи retrieval, агенти перегляду й інструменти веб-витягування можуть брати лише HTML або завершувати роботу до завантаження повільних client-даних. Будувати архітектуру сайту на можливості однієї платформи — зайва ставка.
Безпечне правило просте: публічні факти, важливі для виявлення й цитування, мають читатися вже в першій відповіді.
Перевіряйте шар появи фактів, а не назву framework
SSR проти CSR — не оцінка GEO. Сайт на React, Vue чи Next.js може бути зручним для агентів; традиційний серверно-рендерений сайт також може сховати важливі факти за client API-запитом.
Перевіряйте, на якому шарі стає доступним кожен важливий блок.
| Шар контенту | Типовий приклад | Ризик GEO |
|---|---|---|
| Початковий HTML | Заголовок, текст, специфікації, FAQ, автор, дата | Низький |
| HTML, отриманий на сервері | Поточна ціна або регіональна доступність | Низький або середній |
| Client API request | Переваги продукту, таблиця порівняння, текст документації | Високий |
| Після взаємодії користувача | Вкладки, акордеони, фільтри, результати нескінченного скролу | Високий |
| Після входу | Dashboard або приватна база знань | Не очікуйте публічного цитування |
Факт, який AI має повторити в публічній відповіді, не повинен залежати від кліку, успішного client request або довгого завдання JavaScript. Залишайте взаємодію там, де вона цінна, але виносьте пояснювальний шар уперед.
Типові помилки: сторінка продукту, що повертає лише екран завантаження; порівняння, де таблиця з'являється після hydration; документація, що завантажує текст через client routing; категорія, яка залежить тільки від нескінченного скролу; візуальний модуль, де висновок є лише на зображенні або Canvas.
Сторінка після рендерингу може мати чудовий вигляд і все одно розкривати надто мало змісту в першій HTML-відповіді.
Порівнюйте два стани сторінки замість припущень
Не питайте, чи використовує сайт React. Збережіть дві версії одного URL:
- Сирий HTML, отриманий без виконання JavaScript.
- Текст
mainпісля відкриття сторінки у браузері й очікування основного контенту.
Почати можна з простого fetch:
curl -sL "https://example.com/product" -o raw.html
Порівнюйте семантичні блоки, а не header, банер Cookie та footer:
- H1 і коротку відповідь
- Перший пояснювальний абзац
- Факти про продукт і обмеження
- Таблиці порівняння
- Відповіді FAQ
- Автора й дату оновлення
- Внутрішні посилання та canonical URL
Не використовуйте networkidle як єдину умову готовності браузера. Аналітичні скрипти, чат-віджети й довгі з'єднання можуть тримати сторінку зайнятою безкінечно. Надійніше чекати на появу селектора основного контенту або завершення конкретного джерела даних з критичними фактами.
Порівняння можна перетворити на метрику release:
експозиція основного контенту = важливі блоки в сирому HTML / важливі блоки, потрібні на сторінці
Мета не в тому, щоб помістити в HTML кожен піксель. Мета в тому, щоб докази для розуміння сторінки не залежали від успішного client runtime.
Виправте шлях доставки контенту до переписування front end
Більшості команд не потрібно переписувати весь сайт. Перенесіть стабільну публічну інформацію в першу відповідь, а JavaScript залиште для фільтрів, збережених налаштувань, карт, анімацій і персоналізації.
| Ситуація | Більш відповідний спосіб доставки |
|---|---|
| Стабільні статті, посібники й глосарії | Статична генерація або prerender під час build |
| Ціни, залишки або регіональні дані, що часто змінюються | Server rendering з cache і явною invalidation |
| Інтерактивна сторінка зі стабільним поясненням | Рендеріть пояснення, факти й FAQ на сервері; інтеракцію hydrate у client |
| Публічна документація у великому застосунку | Prerender публічних route і відсутність залежності основної відповіді від login |
| Залежність від кількох внутрішніх API | Агрегуйте критичні дані на сервері або у BFF-шарі, спільному для HTML і застосунку |
JSON-LD корисний, але не замінює читабельний контент сторінки. Структуровані дані мають описувати факти, які відвідувач і extractor також знайдуть у документі.
Двотижневий план для GEO-команди
Дні 1-2: перелічіть template, які впливають на органічне виявлення, AI-цитати, підтримку продажів або клієнтів. Зазвичай достатньо статей, сторінок продукту, документації, порівнянь і категорій.
Дні 3-5: візьміть URL-зразки для кожного template. Збережіть сирий HTML і контент після рендерингу. Позначте відсутні H1, пояснення, факти продукту, FAQ і внутрішні посилання.
Дні 6-9: спочатку виправте найцінніші й стабільні сторінки. Перенесіть визначення, факти, висновки порівняння й FAQ на сервер або в build output.
Дні 10-14: повторіть ті самі перевірки й додайте release gate. Template не варто публікувати, якщо в початковому HTML немає H1, головної відповіді, ключових фактів або canonical-посилань.
Це не гарантує цитату від кожного AI-продукту. Але прибирає помилку, якої можна уникнути: публікацію відкритої інформації, яку потенційний агент не може надійно прочитати.
Погляд Auspia
Розмови про GEO часто починаються зі згадок бренду, якості джерел, ясності entity та структури відповіді. Усе це передбачає, що система спочатку отримала сторінку.
JavaScript сам по собі не є проблемою. Проблема — сприймати публічне пояснення як побічний ефект client runtime. Нехай HTML відповідає за контент, а JavaScript — за досвід. Такий поділ покращує також тестування, технічний SEO і доступність для агентів.
FAQ
Якщо Google рендерить JavaScript, чи потрібен аудит сирого HTML?
Так. Здатність Google не означає, що інші crawler, reader та агенти йдуть тим самим шляхом. Перевірка сирого HTML також виявляє затримки рендерингу й збої client request.
Чи завжди SSR кращий за CSR для GEO?
Ні. Статична генерація, server rendering і prerender можуть працювати. Client rendering можна лишити для дуже інтерактивних елементів. Критерій один: чи читаються ключові факти публічної сторінки в початковій HTML-відповіді.
Чи слід уникати JavaScript у всіх частинах сторінки?
Ні. Використовуйте його для фільтрів, анімацій, карт, збережених налаштувань, персоналізації та сценаріїв після login. Пріоритет має контент, що пояснює тему сторінки й надає факти для цитування.
Чи вирішує llms.txt проблему контенту, що з'являється лише після JavaScript?
Ні. Навіть якщо система читає llms.txt, вона не отримує автоматично повну статтю або client API дані. Публічна сторінка сама повинна робити свій основний контент доступним.
Примітка про джерело
Статтю надихнув допис Adrian Skowron про порівняння видимого контенту SSR і CSR . Діаграма в дописі відображає вимірювання шаблонів автора, а не benchmark для всієї галузі.
Автор: Julian Mercer, технічний SEO-практик Auspia з 14-річним досвідом. Julian пише про crawling, rendering, структуровані дані та технічну основу, що дозволяє пошуку й AI розуміти контент.
