SEO для сайтів, створених за допомогою ШІ: що справді важливо
Сайт, створений за допомогою ШІ, може ранжуватися так само добре, як і будь-який інший: пошукові системи оцінюють те, що є на сторінці, і наскільки добре вона служить відвідувачу, а не те, який інструмент написав код. Підступ у технічному. Багато конструкторів на основі ШІ створюють односторінкові застосунки, які надсилають браузеру майже порожній HTML-файл і малюють вміст за допомогою JavaScript. Через це кожну сторінку важче прочитати сканерам і важче поширювати. Виправте це за допомогою попереднього рендерингу або серверного рендерингу, дайте кожній сторінці власний заголовок, опис і URL, додайте карту сайту, зберігайте швидкість, а потім зробіть те, що жоден інструмент за вас не зробить, — напишіть контент, який люди шукають.
Чому односторінкові застосунки можуть погано працювати в пошуку
Традиційний сайт надсилає повний текст кожної сторінки у своєму HTML. Односторінковий застосунок (SPA) — типовий результат багатьох конструкторів на основі ШІ, зазвичай React з інструментом на кшталт Vite — надсилає невелику оболонку HTML, щось на кшталт порожнього <div id="root">, плюс пакет JavaScript. Браузер виконує JavaScript, який і будує сторінку.
Це важливо для пошуку з трьох причин:
- Рендеринг — це додатковий крок. Google описує три етапи для сторінок із JavaScript: сканування HTML, рендеринг у headless-браузері Chromium, а потім індексування відрендереної версії. Настанови самого Google кажуть, що серверний рендеринг або попередній рендеринг усе одно є хорошою ідеєю, бо це швидше і для користувачів, і для сканерів, а також тому, що не всі боти можуть виконувати JavaScript.
- Інші читачі вашої сторінки взагалі не рендерять її. Попередній перегляд посилань у чат-застосунках і соцмережах, а також багато інших сканерів зазвичай читають лише початковий HTML. Якщо заголовок і зображення попереднього перегляду встановлюються JavaScript після завантаження, попередній перегляд показує стандартні значення порожньої оболонки — часто однаковий заголовок на кожній сторінці.
- Усе використовує один HTML-файл. Якщо застосунок його не оновлює, кожен URL має однаковий
<title>і опис, що мало говорить пошуковим системам про кожну сторінку.
Нічого з цього не означає, що SPA неможливо проіндексувати. Це означає, що ви покладаєтеся на те, що сканер зробить більше роботи, і втрачаєте контроль над тим, що бачать читачі, які не рендерять сторінку.
Оберіть підхід до рендерингу
Існує чотири поширені способи віддати сканерам справжній HTML. Приблизно в порядку того, наскільки вони змінюють ваш застосунок:
| Підхід | Як працює | Для чого підходить | Компроміс |
|---|---|---|---|
| Статичний сайт | Сторінки — це звичайні HTML-файли, зібрані заздалегідь | Маркетингові сайти, портфоліо, документація, блоги | Менш придатний для сторінок із входом і персоналізацією |
| Попередній рендеринг (генерація статичних сайтів) | Під час збірки кожен публічний маршрут рендериться в HTML-файл; далі JavaScript працює в браузері | SPA з відомим набором публічних сторінок | Сторінки оновлюються лише після перезбирання |
| Серверний рендеринг (SSR) | Сервер рендерить HTML для кожного запиту (Next.js, Remix, Nuxt та подібні) | Великий або часто змінюваний публічний вміст, наприклад каталоги оголошень | Потрібен сервер, що працює; більше рухомих частин |
| Динамічний рендеринг | Попередньо відрендерений HTML віддається ботам, а SPA — людям | Застарілий обхідний шлях | Google тепер називає це обхідним шляхом, а не довгостроковим рішенням, і радить натомість SSR, статичний рендеринг або гідратацію |
Практичне правило: публічна, придатна для пошуку частина сайту має бути статичною або попередньо відрендереною; логінований застосунок за нею може залишатися звичайним SPA. Пошукові системи все одно не мають індексувати панелі керування.
Якщо ви починаєте з нуля і SEO важливе, скажіть про це в першому запиті, щоб ШІ обрав відповідну конфігурацію:
Створи маркетинговий сайт для клініки фізіотерапії зі сторінками «Головна», «Послуги» (окрема сторінка для кожної послуги), «Про нас», «Ціни» та «Контакти». SEO важливе: кожна сторінка має передавати весь свій вміст і власні заголовок і опис у початковому HTML — використовуй статичну або попередньо відрендерену конфігурацію, а не SPA, що рендериться лише на клієнті.
Якщо у вас уже є SPA на Vite, попросіть попередній рендеринг публічних маршрутів:
Залиш цей застосунок React як є, але попередньо відрендери публічні маршрути (/, /pricing, /about, /blog і кожен /blog/:slug) у статичний HTML під час збірки, з власним заголовком, описом мета-тегу, канонічним URL і тегами Open Graph. Маршрути /app для залогінених користувачів можуть залишатися рендереними на клієнті.
Після цього перевірте результат самі: відкрийте сторінку, виберіть Переглянути код сторінки (не панель Elements в інструментах розробника, яка показує вже відрендерену сторінку) і переконайтеся, що текст і заголовок є у сирому HTML.
Налаштуйте основи на сторінці
Це стосується будь-якого підходу до рендерингу.
Заголовки та описи
- Один унікальний
<title>на сторінку, з головною темою сторінки на початку. Близько 50–60 символів — поширена рекомендація, бо довші заголовки зазвичай обрізаються в результатах. - Один унікальний опис мета-тегу для кожної сторінки — речення, яке людина захотіла б клікнути, а не список ключових слів. Google може його переписати, але хороший опис часто використовується.
- Не використовуйте мета-ключові слова. Google заявляє, що цей тег не впливає на індексування чи ранжування.
URL, заголовки та посилання
- Справжні URL для справжніх сторінок. Кожен фрагмент контенту потребує власного шляху (
/services/sports-massage), а не вкладки чи модального вікна, які з’являються лише після кліку. Уникайте маршрутизації через фрагменти#для контенту, який має індексуватися. - Один
h1на сторінку, потім розумна структураh2/h3. Дизайни, згенеровані ШІ, іноді використовують заголовки для стилю; просіть семантичні заголовки. - Посилання, які можуть обходити сканери. Для навігації використовуйте справжні посилання
<a href>. Кнопки, які змінюють сторінку через JavaScript, невидимі для сканерів, що переходять за посиланнями. - Канонічні теги, що вказують кожній сторінці на бажаний URL, щоб варіанти з
?utm=і дублікати з кінцевим слешем не конкурували між собою. - Описовий alt-текст для змістовних зображень.
Попередній перегляд у соцмережах
Додайте теги Open Graph (og:title, og:description, og:image, og:url) на кожну публічну сторінку, у початковому HTML. Це частина, яку SPA найчастіше виконують неправильно, бо боти попереднього перегляду посилань не виконують JavaScript.
Карти сайту та robots.txt
Карта сайту — це XML-файл зі списком URL, які ви хочете проіндексувати. Він допомагає пошуковим системам знаходити сторінки, особливо на нових сайтах з невеликою кількістю вхідних посилань. Згідно з документацією Google станом на вересень 2026 року:
- Одна карта сайту може містити до 50 000 URL або 50 МБ без стиснення; великі сайти розділяйте за допомогою індексу карт сайту.
- Google ігнорує
<priority>і<changefreq>. - Google використовує
<lastmod>лише тоді, коли він стабільно точний, тож оновлюйте його для реальних змін вмісту, а не при кожній збірці.
Файл robots.txt вказує сканерам, які шляхи не сканувати. Використовуйте його, щоб не пускати сканери до /app, /admin і маршрутів API, і вкажіть у ньому посилання на карту сайту. Пам’ятайте, що robots.txt зупиняє сканування, а не індексування: щоб сторінка не потрапляла в результати, використовуйте мета-тег robots noindex і дозвольте її сканувати.
Подайте карту сайту в Google Search Console, щойно сайт буде на остаточному домені. Search Console також показує, які сторінки проіндексовано і чому інші не індексуються — найкорисніший безкоштовний інструмент SEO, який там є.
Структуровані дані
Структуровані дані — це машинозчитувана розмітка, яка описує, що являє собою сторінка: організацію, локальний бізнес, продукт, статтю, подію. Google рекомендує формат JSON-LD і чітко говорить про два моменти:
- Вони можуть зробити сторінки придатними для розширених результатів, але не гарантують їх.
- Вони мають описувати інформацію, видиму на сторінці. Не позначайте відгуки, ціни чи запитання-відповіді, які відвідувачі не можуть побачити.
Розумні відправні точки: Organization або LocalBusiness на головній сторінці, Product на сторінках товарів, Article для записів блогу, BreadcrumbList для глибоких сторінок. Перевіряйте за допомогою Rich Results Test від Google.
Додай структуровані дані JSON-LD: LocalBusiness на головній сторінці з адресою, телефоном і годинами роботи, які вже показані на сторінці, а Article — на кожному записі блогу. Не додавай рейтинги чи відгуки.
Швидкість і мобільні пристрої
Google використовує сигнали якості сторінки, зокрема Core Web Vitals, а швидкість важлива для відвідувачів у будь-якому разі. «Добрі» пороги Google, виміряні на 75-му перцентилі завантажень сторінок, такі:
| Показник | Що вимірює | Добре |
|---|---|---|
| Largest Contentful Paint (LCP) | Як швидко з’являється головний вміст | 2,5 с або менше |
| Interaction to Next Paint (INP) | Як швидко сторінка реагує на дії користувача | 200 мс або менше |
| Cumulative Layout Shift (CLS) | Наскільки стрибає верстка під час завантаження | 0,1 або менше |
Типові виправлення для сайтів, створених за допомогою ШІ:
- Зображення — змініть розмір, стисніть, використовуйте сучасні формати, задайте ширину й висоту (це запобігає зсуву верстки) і завантажуйте з відкладенням ті, що нижче згину.
- JavaScript — великий пакет затримує все в SPA. Попередній рендеринг допомагає; допомагає і розбиття коду за маршрутами.
- Шрифти — обмежте кількість сімейств і начертань та попередньо завантажуйте той, що використовується над згином.
- Сторонні скрипти — кожен віджет чату і піксель відстеження уповільнюють сайт. Залишайте лише ті, які ви справді використовуєте.
Перевіряйте живу адресу за допомогою PageSpeed Insights або Lighthouse у мобільному режимі.
Головне — контент
Технічне SEO прибирає перешкоди, але не створює попит. Сторінки ранжуються, коли вони відповідають на пошуковий запит краще за альтернативи. Для більшості невеликих сайтів це означає:
- Одна сторінка на тему, яку люди шукають. Сантехнику потрібна сторінка для кожної послуги та для кожного району обслуговування, а не одна сторінка «Послуги» зі списком усього.
- Конкретні, оригінальні деталі — ціни, процес, фото реальних робіт, відповіді на запитання, які клієнти ставлять телефоном.
- Оновлення, коли щось змінюється. Застарілі години роботи та старі ціни дуже швидко втрачають довіру.
ШІ може швидко накидати сторінки, тому спокуса публікувати багато поверхневих, схожих сторінок велика. Настанови Google спрямовані проти контенту, створеного переважно для ранжування, а не для допомоги людям, незалежно від того, як його створено. Використовуйте ШІ для чернетки, а потім додавайте те, що знаєте лише ви. Найбільше з цим стикаються сайти у форматі каталогів; дивіться як створити сайт-каталог, щоб зробити сторінки з переліками вартими індексації.
Чекліст запуску
- Публічні сторінки передають повний вміст у початковому HTML (перевірте через «Переглянути код сторінки»)
- Унікальні заголовок, опис мета-тегу та канонічний URL на кожній сторінці
- Теги Open Graph і зображення для поширення на кожній публічній сторінці
- Один
h1на сторінку, справжні посилання<a href>, alt-текст для зображень -
sitemap.xmlзі справжніми URL;robots.txt, що блокує шляхи застосунку та API - Структуровані дані лише для видимого вмісту, перевірені
- LCP, INP і CLS у «доброму» діапазоні на мобільних пристроях
- Сайт на остаточному домені з HTTPS і поданий до Search Console
Перехід на власний домен до початку активного SEO дозволить уникнути перенаправлень у майбутньому — дивіться як підключити власний домен. Щоб дізнатися про ширший процес створення, читайте як створити сайт за допомогою ШІ, а для сторінок, що мають конвертувати відвідувачів, — як створити лендинг, що конвертує.
SEO на Mythex
В Mythex немає окремої панелі SEO; ви покращуєте SEO, змінюючи застосунок через чат або код. Нові веб-застосунки за замовчуванням створюються як односторінкові застосунки на Vite і React, тож коли пошук важливий, від початку просіть статичний або попередньо відрендерений сайт чи Next.js. У документації є стартовий запит для заголовків, тегів Open Graph, карти сайту та robots.txt у SEO для вашого застосунку, а статичні сайти описують сайти, орієнтовані на контент. Після змін опублікуйте застосунок знову, щоб живий сайт їх отримав. Власні домени доступні в тарифі Pro.
Запитання
Чи шкодять сайти, створені за допомогою ШІ, SEO?
Не обов’язково. Пошукові системи оцінюють сторінку, а не інструмент, яким її створено. Типова проблема технічна: багато конструкторів на основі ШІ створюють односторінкові застосунки, вміст яких з’являється лише після виконання JavaScript, а деякі сканери з цим погано справляються. Попередній рендеринг або серверний рендеринг це виправляють.
Чи може Google індексувати односторінковий застосунок на React?
Google вміє виконувати JavaScript, тож часто може індексувати застосунок React, який рендериться на клієнті. Але рендеринг — це додатковий крок, і сам Google зазначає, що не всі боти можуть виконувати JavaScript, тому там, де це можливо, він радить серверний рендеринг або попередній рендеринг.
Чи досі важливі мета-ключові слова?
Ні. Google заявляє, що не використовує тег meta keywords для індексування чи ранжування. Краще докладіть зусиль до унікального заголовка та опису для кожної сторінки.
Чи покращують структуровані дані позиції?
Структуровані дані допомагають пошуковим системам зрозуміти сторінку і можуть зробити її придатною для розширених результатів, але не гарантують їх. Вони мають описувати вміст, який справді видно на сторінці.