Core Web Vitals та затримка: чи швидші сторінки отримують більше цитат від ШІ?

Core Web Vitals та затримка: чи швидші сторінки отримують більше цитат від систем штучного інтелекту?

Вступ

Швидкий вебсайт легший у використанні для людей. Він також може бути легшим для пошукових систем та систем штучного інтелекту для завантаження, відтворення та розуміння.

Але часто упускається важлива відмінність:

Швидша сторінка може покращити сканування та доступність контенту. Це не означає, що сама швидкість змушує систему штучного інтелекту цитувати сторінку.

Станом на 2 серпня 2026 року Google стверджує, що стабільний час відповіді сервера та менша затримка можуть збільшити пропускну здатність сканування сайту. Google також заявляє, що його пошукові функції на основі штучного інтелекту використовують ті ж самі базові системи пошуку та індексування, що й традиційний пошук, і не потребують спеціальної розмітки або оптимізації швидкості для штучного інтелекту. (developers.google.com)

Ця стаття представляє план тестування, заснований на доказах, замість того, щоб стверджувати, що завершений експеримент уже проведено. Жодного сайту, набору сторінок, журналу сервера або набору даних цитувань не було надано. Метою є визначення контрольованого дослідження, яке може виміряти:

1. Чи зменшення часу до першого байта збільшує частоту сканування.
2. Чи зменшення Largest Contentful Paint покращує виявлення або індексування.
3. Чи впливає зменшення Cumulative Layout Shift на сканування або отримання даних системами штучного інтелекту.
4. Чи покращення продуктивності збільшують швидкість, з якою сторінки видимим чином цитуються пошуковими системами штучного інтелекту.

Коротка відповідь

Менший час до першого байта може покращити сканування за правильних умов

Поточна документація Google щодо сканування стверджує, що ліміт пропускної здатності сканування може збільшитися, коли сайт має стабільний або покращений час відповіді, включаючи час до першого байта. Якщо час відповіді зростає, або якщо сайт повертає занадто багато помилок сервера чи відповідей з обмеженням швидкості, Google може зменшити сканування. (developers.google.com)

Однак швидший час відповіді не гарантує більше сканування. Попит на сканування також залежить від таких факторів, як:

• Як часто змінюється сайт.
• Наскільки популярні сайт та його сторінки.
• Чи є контент корисним та унікальним.
• Скільки існує дублікатів або URL-адрес низької цінності.
• Чи включені оновлені URL-адреси до файлів Sitemap.

Це означає, що менша затримка повинна мати найсильніший ефект на великих, часто оновлюваних або обмежених сервером вебсайтах, а не обов’язково на невеликому сайті з обмеженим новим контентом.

Менший Largest Contentful Paint може допомогти опосередковано

Largest Contentful Paint вимірює, коли основний видимий вміст з’являється для користувача. Google також стверджує, що як час відповіді сервера, так і час, необхідний для відтворення сторінок та вбудованих ресурсів, можуть впливати на ефективність сканування. (developers.google.com)

Ймовірний зв'язок є опосередкованим:

Менша затримка → швидша доставка ресурсів → ефективніше відтворення або завантаження → менше тайм-аутів сканування або неповних завантажень.

Ефект повинен бути найсильнішим, коли важливий контент залежить від:

• Повільний JavaScript.
• Великі зображення.
• Таблиці стилів, що блокують відтворення.
• Рендеринг на стороні клієнта.
• Важкі вбудовані ресурси.

Високий показник Largest Contentful Paint сам по собі навряд чи буде прямим сигналом цитування від систем штучного інтелекту.

Менший Cumulative Layout Shift, ймовірно, має невеликий прямий вплив на сканування

Cumulative Layout Shift вимірює неочікуване переміщення видимого контенту. Це переважно метрика користувацького досвіду. Поширені причини включають зображення без розмірів, динамічно вставлену рекламу, вбудований контент та веб-шрифти. (web.dev)

Краулер не відчуває зсуву макета так само, як це робить людина-відвідувач. Тому прямий зв’язок між меншим Cumulative Layout Shift та більшою кількістю сканувань малоймовірний.

Може існувати опосередкований зв'язок, коли значний зсув макета викликаний:

• Контент, вставлений JavaScript із запізненням.
• Важливий текст, прихований до запуску скриптів.
• Зображення або вбудовані елементи, що затримують побудову сторінки.
• Нестабільні шаблони, які створюють різний контент під час різних завантажень.

У цих випадках справжня проблема не в показнику зсуву макета. Справжня проблема полягає в тому, що сторінка може бути складною для обробки або може занадто пізно відображати важливий контент.

Швидші сторінки не цитуються автоматично частіше

Google стверджує, що сторінки, які з’являються у функціях штучного інтелекту, повинні спочатку бути проіндексовані та відповідати вимогам для появи у звичайних результатах пошуку з фрагментом. Google також заявляє, що немає додаткових технічних вимог або спеціальних оптимізацій штучного інтелекту для його оглядів та режиму штучного інтелекту. (developers.google.com)

OpenAI аналогічно заявляє, що пошукові рейтинги ChatGPT залежать від багатьох факторів, і що дозвіл його пошуковому краулеру, OAI-SearchBot, є важливим для включення. Він не стверджує, що нижчі показники Core Web Vitals безпосередньо збільшують ймовірність цитування. (help.openai.com)

Це передбачає чотириетапну модель:

1. Виявлення — Чи система дізнається про існування URL-адреси?
2. Завантаження та обробка — Чи може система отримати та зрозуміти сторінку?
3. Індексування та отримання — Чи вибирається сторінка для певного запиту?
4. Вибір цитування — Чи відображається сторінка як видиме джерело у відповіді?

Швидкість сторінки може впливати на перші два етапи. Вона не встановлена як пряма причина четвертого етапу.

Недавні дослідження також показують, що системи штучного інтелекту можуть читати багато релевантних сторінок, але цитувати лише деякі з них. Іншими словами, отримання та цитування є окремими подіями. (cambridge.org)

Що слід перевіряти?

Дослідження повинно перевіряти два різні питання, а не розглядати «видимість для штучного інтелекту» як одну метрику.

Питання 1: Чи впливає продуктивність на сканування?

Основні результати:

• Час від публікації до першого запиту краулера.
• Кількість запитів краулера на сторінку на день.
• Час між успішними повторними скануваннями.
• Кількість просканованих сторінок на 1000 опублікованих сторінок.
• Відсоток успішних завантажень.
• Частота помилок сервера та відповідей з обмеженням швидкості.
• Час від публікації до індексування.

Питання 2: Чи впливає продуктивність на вибір цитування?

Основні результати:

• Відсоток перевірених запитів, що генерують видиме цитування.
• Частота цитування на відповідну сторінку.
• Частка цитування в рамках запиту.
• Відсоток отриманих сторінок, які стають видимими цитатами.
• Стійкість цитування з часом.
• Частота цитування за системою штучного інтелекту.

Ці результати повинні бути розділені за постачальниками. Огляд штучного інтелекту Google, результати пошуку ChatGPT, відповідь Microsoft Copilot, відповідь Perplexity та пошукова відповідь Claude можуть використовувати різні індекси, краулери, системи ранжування та графіки оновлення.

Дизайн експерименту

1. Створення контрольованого набору сторінок

Використовуйте набір сторінок, достатньо великий для отримання значущих даних про сканування та цитування.

Практичний початковий дизайн включатиме:

• Від 240 до 800 сторінок.
• Щонайменше 20 сторінок на кожен шаблон сторінки.
• Від трьох до п'яти категорій контенту.
• Суміш вічнозелених та регулярно оновлюваних сторінок.
• Рівна кількість сторінок у кожній групі впливу.

Кожна сторінка повинна мати:

• Схожу HTML-структуру.
• Схожу довжину контенту.
• Ту саму видавничу систему.
• Той самий шаблон внутрішнього посилання.
• Ті ж самі канонічні правила.
• Ту саму обробку в Sitemap.
• Ті ж самі дозволи robots.txt.
• Унікальну, корисну тему.

Не створюйте сотні тонких або майже дубльованих сторінок лише для експерименту. Рекомендації Google попереджають, що дублікати та URL-адреси з низькою цінністю можуть витрачати ресурси сканування та знижувати ефективність сайту. (developers.google.com)

Корисним є дизайн зі співставленими парами. Наприклад, об'єднайте сторінки зі схожими:

• Довжина контенту.
• Попит на тему.
• Частота оновлень.
• Кількість внутрішніх посилань.
• Кількість зовнішніх посилань.
• Історичний трафік.
• Позиція в пошуковому рейтингу.

Потім розмістіть одну сторінку з кожної пари в контрольній групі, а іншу — в експериментальній групі.

2. Використання факторного дизайну впливу

Основні показники продуктивності слід тестувати незалежно та разом.

Це створює контрольований експеримент для трьох запитуваних оптимізацій:

• HTTP/3.
• Кешування на периферії мережі доставки контенту.
• Стиснення зображень.

Вплив стабільності макета необхідний, оскільки перші три оптимізації не забезпечують надійного виділення Cumulative Layout Shift. Стиснення зображень може знизити Largest Contentful Paint, не змінюючи стабільність макета взагалі.

Чому HTTP/3 потребує власного вимірювання

HTTP/3 використовує транспортний протокол QUIC та надає незалежні потоки, що дозволяє уникнути блокування початку черги на транспортному рівні, яке зустрічається в HTTP/2 через TCP. Його переваги залежать від того, чи клієнт або краулер фактично узгоджує HTTP/3. (rfc-editor.org)

Отже, реєструйте узгоджений протокол для кожного запиту:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Не припускайте, що увімкнення HTTP/3 означає, що кожен краулер його використовує. Якщо Googlebot, OAI-SearchBot або інший краулер продовжує використовувати HTTP/2, HTTP/3 не може впливати на запити цього краулера.

Чому кешування на периферії слід тестувати обережно

Мережа доставки контенту може зменшити час до першого байта, подаючи контент ближче до запитувача. Вона також може зменшити кількість запитів, що надходять до вихідного сервера. (web.dev)

Перевірте щонайменше три стани кешу:

1. Холодний кеш — Периферія повинна зв'язатися з джерелом.
2. Теплий кеш — Периферія надає сторінку без звернення до джерела.
3. Повторно перевірений кеш — Периферія або краулер використовує значення ETag або Last-Modified та отримує відповідь 304 Not Modified.

Google спеціально рекомендує ефективне кешування HTTP та підтримує використання відповідей 304 Not Modified для зменшення непотрібної обробки та використання пропускної здатності. (developers.google.com)

Не дозволяйте кешуванню подавати застарілий або некоректний контент краулерам. Записуйте:

• Попадання або промах кешу.
• Вік кешу.
• Розташування на периферії.
• Час відповіді джерела.
• Версія контенту.
• Код стану.
• Заголовки валідації.

Чому стиснення зображень має бути пов’язане з Largest Contentful Paint

WebP та AVIF зазвичай забезпечують краще стиснення, ніж старі формати зображень. Менші зображення можуть зменшити час передачі та покращити Largest Contentful Paint, коли зображення є елементом Largest Contentful Paint. (web.dev)

Тест повинен використовувати:

• Ті ж самі розміри зображення.
• Ту ж саму цільову візуальну якість.
• Адаптивні зображення srcset.
• Сучасний формат з відповідним резервним варіантом.
• Явні значення width та height.
• Відсутність лінивого завантаження для зображення Largest Contentful Paint.
• URL-адресу зображення, видиму в початковому HTML.

Тільки стиснення зображень може не покращити Largest Contentful Paint, якщо справжня затримка походить від JavaScript або пізнього виявлення ресурсів. Рекомендації Google щодо продуктивності зазначають, що зменшення часу завантаження зображення може просто перенести затримку на іншу частину сторінки, якщо елемент Largest Contentful Paint відображається пізно. (web.dev)

3. Проведіть тест достатньо довго

Короткий тест може упустити ефекти планування сканування та оновлення індексу.

Практичний дизайн:

• Два тижні базового вимірювання.
• Шість-дванадцять тижнів вимірювання впливу.
• За можливості, остаточний період реверсії або кросовера.

Для кросоверного тесту перемикайте впливи між співставленими групами сторінок. Якщо ефект продуктивності зникає після усунення впливу, результат є сильнішим, ніж просте порівняння «до і після».

Польові дані Core Web Vitals слід оцінювати протягом відповідного періоду. Chrome User Experience Report використовує 28-денну агрегацію, що постійно оновлюється, тому він не призначений для відображення миттєвих змін після розгортання. (developer.chrome.com)

4. Виміряйте повну популяцію краулерів

Не розглядайте весь автоматизований трафік як одну групу.

Як мінімум, розділіть:

Пошукові краулери

• Googlebot.
• Bingbot.

Краулери пошуку штучного інтелекту

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Завантажувачі, запитані користувачем

• Perplexity-User.
• Claude-User.
• Завантажувачі користувачів ChatGPT, де їх можна ідентифікувати.

Тренувальні краулери

• GPTBot.
• ClaudeBot.
• Елементи управління Google-Extended.

Тренувальні краулери не повинні використовуватися як проксі для цитувань у пошуку штучного інтелекту. Anthropic, OpenAI та Google розрізняють краулери, що використовуються для навчання, пошуку або отримання даних за запитом користувача. Google також заявляє, що Google-Extended не впливає на включення або ранжування в Google Search. (help.openai.com)

Perplexity аналогічно розрізняє PerplexityBot, який підтримує пошукове індексування, та Perplexity-User, який може отримувати сторінку у відповідь на запит користувача. (docs.perplexity.ai)

Перевіряйте ідентичність краулера, використовуючи опубліковані діапазони IP-адрес або зворотний DNS, якщо провайдер це підтримує. Рядки user-agent можуть бути скопійовані непов’язаними краулерами. Google спеціально попереджає, що рядки user-agent Googlebot можуть бути підроблені. (developers.google.com)

Метрики для збору

Метрики продуктивності

Збирайте як лабораторні дані, так і дані реальних користувачів:

• Час до першого байта.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Загальна вага сторінки.
• Початковий розмір HTML.
• Розмір передачі зображень.
• Кількість запитів.
• Час, витрачений на обробку сервером.
• Час, витрачений на очікування ресурсу Largest Contentful Paint.
• Протокол HTTP.
• Статус кешу.

Google рекомендує приблизну ціль для часу до першого байта — 800 мілісекунд або менше, але сам час до першого байта не є Core Web Vital. (web.dev)

Поточні «хороші» порогові значення Core Web Vitals на 75-му перцентилі:

• Largest Contentful Paint: 2.5 секунди або менше.
• Cumulative Layout Shift: 0.1 або менше.
• Interaction to Next Paint: 200 мілісекунд або менше. (web.dev)

Метрики сканування

Для кожного перевіреного запиту краулера записуйте:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Обчисліть:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval pub_to_first_fetch pub_to_first_index

Метрики цитування штучним інтелектом

Використовуйте фіксований набір запитів для кожної платформи. Набір запитів повинен включати:

• Прямі фактичні запитання.
• Питання для порівняння.
• Питання про «найкраще» або рекомендації.
• Питання, чутливі до свіжості.
• Питання, де перевірена сторінка є найсильнішою відповіддю.
• Питання, де перевірена сторінка є релевантною, але не домінуючою.

Для кожного запиту записуйте:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Повторюйте запити, оскільки відповіді штучного інтелекту можуть відрізнятися. Використовуйте фіксований графік, наприклад, тричі на тиждень, та реєструйте зміни в механізмі або моделі.

Microsoft Bing Webmaster Tools тепер надає звіт про продуктивність штучного інтелекту, що показує цитовані сторінки, основні запити та тенденції цитування в підтримуваних досвідах штучного інтелекту Microsoft. Microsoft попереджає, що дані агреговані, вибіркові та спостережні; вони не можуть довести, що конкретна зміна сторінки спричинила зміну цитування. (bing.com)

Google також почав розгортати спеціалізовані звіти про продуктивність генеративного штучного інтелекту в Search Console у червні 2026 року. Звіти спочатку були доступні лише для частини вебсайтів, тому доступ може відрізнятися. (developers.google.com)

Статистичний аналіз

Частота сканування

Використовуйте модель підрахунку зі змішаними ефектами, таку як негативна біноміальна модель:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Ефекти сторінки та краулера мають значення, оскільки деякі сторінки природно отримують більше уваги, ніж інші, а різні краулери мають різні графіки.

Виявлення та індексування

Використовуйте аналіз виживаності для:

• Час від публікації до першого завантаження.
• Час від публікації до першого індексу.
• Час від оновлення до повторного сканування.

Ключовий результат — це не просто те, чи була сторінка зрештою просканована. Це те, чи зменшив вплив час, необхідний для виявлення та обробки сторінки.

Вибір цитування штучним інтелектом

Використовуйте ієрархічну логістичну модель:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Запустіть дві окремі моделі:

1. Модель отримання — Чи була сторінка отримана або показана як кандидат?
2. Модель цитування — Якщо сторінка була отримана, чи була вона видимим чином процитована?

Це розрізнення є суттєвим. Покращення продуктивності, яке збільшує сканування, але не отримання, не є ефектом цитування штучним інтелектом. Покращення продуктивності, яке збільшує отримання, але не цитування, свідчить про те, що сторінка розглядається, але програє під час вибору джерела.

Очікувані результати

Це робочі гіпотези, а не заявлені експериментальні результати.

Гіпотеза 1: Час до першого байта матиме найчіткіший ефект на сканування

Очікуйте позитивного зв’язку між меншим часом до першого байта та пропускною здатністю сканування, коли:

• Сайт має багато сторінок.
• Сторінки часто змінюються.
• Вихідний сервер повільний або перевантажений.
• Сайт повертає відповіді 5xx або 429.
• Краулер витрачає значний час на очікування відповідей.

Очікуйте незначного вимірюваного ефекту на невеликому сайті з низьким попитом на сканування.

Гіпотеза 2: Largest Contentful Paint матиме значення через відтворення та доставку ресурсів

Очікуйте, що менший Largest Contentful Paint допоможе, коли:

• Сторінка залежить від відтворення браузером.
• Важливий контент прихований за JavaScript.
• Великі зображення або таблиці стилів необхідні для індексування.
• Краулер завантажує багато ресурсів сторінки.
• Повільніший вплив призводить до тайм-аутів або неповного відтворення.

Очікуйте слабкого зв’язку, коли важливий текст сторінки вже присутній у початковому HTML.

Гіпотеза 3: Cumulative Layout Shift матиме невеликий прямий вплив

Не очікуйте значущого прямого зв’язку між Cumulative Layout Shift та частотою сканування або частотою цитування після контролю структури сторінки та поведінки JavaScript.

Якщо Cumulative Layout Shift, здається, передбачає цитування, дослідіть, чи він діє як проксі для:

• Рендеринг на стороні клієнта.
• Пізнє вставлення контенту.
• Нестабільна реклама.
• Прихований або затриманий текст.
• Погано структурований HTML.

Гіпотеза 4: Лише швидкість не призведе до більшої кількості цитувань штучним інтелектом

Найсильнішими предикторами вибору цитування, ймовірно, залишаться:

• Релевантність до запиту.
• Якість контенту.
• Чіткі відповіді.
• Свіжість.
• Авторитет та довіра.
• Відповідність для пошукового індексу.
• Ранг отримання.
• Чи сторінка безпосередньо підтримує заявлене твердження.

Рекомендації Google підкреслюють корисний, надійний контент, орієнтований на людей, і стверджують, що пошукові функції штучного інтелекту базуються на існуючих системах пошуку та індексування. (developers.google.com)

Бюджет продуктивності, налаштований для отримання даних штучним інтелектом

Нижче наведено пропонований операційний бюджет. Це не опублікована формула ранжування штучного інтелекту.

Поточна документація Google стверджує, що Googlebot завантажує перші 2 мегабайти підтримуваного файлу та завантажує зовнішні скрипти та таблиці стилів окремо. Вона також рекомендує розміщувати важливі метадані та структуровані дані на початку HTML. (developers.google.com)

Рекомендації щодо впровадження

HTTP/3

Використовуйте HTTP/3, коли він підтримується хостинг-провайдером та мережею доставки контенту.

Виміряйте:

• Швидкість узгодження HTTP/3.
• Швидкість відкату до HTTP/2.
• Час встановлення з'єднання.
• Час до першого байта.
• Продуктивність за географічним регіоном.
• Продуктивність за краулером.

Не розглядайте HTTP/3 як гарантовану оптимізацію для пошуку або штучного інтелекту. Це транспортне покращення, яке може допомогти лише клієнтам, що його використовують.

Кешування на периферії мережі доставки контенту

Для публічних, неперсоналізованих сторінок:

• Встановіть чіткі правила Cache-Control.
• Використовуйте довготривале кешування для версіонованих статичних активів.
• Використовуйте коротке, але корисне кешування для часто оновлюваного HTML.
• Уникайте фрагментації кешу від непотрібних параметрів запиту.
• Зберігайте канонічні URL-адреси.
• Підтримуйте ETag та Last-Modified.
• Перевіряйте стани холодного, теплого та повторно перевіреного кешу.
• Підтвердіть, що запити краулерів отримують той самий важливий контент, що й запити людей.

Мережа доставки контенту повинна зменшувати затримку, не створюючи застарілих, непослідовних або специфічних для ботів версій сторінок.

Стиснення зображень

Для зображень:

• Використовуйте AVIF або WebP, коли візуальна якість прийнятна.
• Забезпечуйте адаптивні розміри зображень.
• Не подавайте зображення розміром для настільного комп'ютера на невеликий мобільний екран.
• Не завантажуйте зображення Largest Contentful Paint ліниво.
• Включайте розміри зображення.
• Розміщуйте зображення Largest Contentful Paint у початковому HTML.
• Використовуйте fetchpriority="high" лише за необхідності.
• Зберігайте важливі пояснення у тексті, а не вбудовуйте їх лише у зображення.

Стиснення зображень є найбільш цінним, коли зображення є елементом Largest Contentful Paint. Воно не виправить сторінку, основна затримка якої походить від рендерингу на сервері або виконання JavaScript. (web.dev)

Стабільність макета

Щоб зменшити Cumulative Layout Shift:

• Встановлюйте атрибути ширини та висоти для зображень.
• Зарезервуйте місце для реклами.
• Зарезервуйте місце для вбудованого відео та соціального контенту.
• Уникайте вставки банерів над існуючим текстом.
• Використовуйте стабільні стратегії завантаження шрифтів.
• Уникайте заміни великих блоків контенту, відтвореного сервером, після завантаження сторінки.

Ці зміни покращують користувацький досвід, навіть якщо вони не мають вимірюваного впливу на сканування або цитування. (web.dev)

Інструменти та моніторинг

Інструменти продуктивності

Використовуйте:

• Chrome User Experience Report для Core Web Vitals реальних користувачів.
• Інтерфейс прикладного програмування Chrome User Experience Report для автоматизованого збору польових даних.
• PageSpeed Insights для лабораторних аудитів та польових даних.
• Lighthouse для повторюваних лабораторних тестів.
• Lighthouse Continuous Integration для бюджетів продуктивності запитів на злиття.
• WebPageTest для багатолокаційних тестів, станів кешу та порівнянь протоколів.
• Chrome DevTools для налагодження Largest Contentful Paint та зсуву макета.
• Бібліотека JavaScript web-vitals для моніторингу реальних користувачів.

Інтерфейс прикладного програмування Chrome User Experience Report надає агреговані польові дані на рівні сторінки та походження, включаючи Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint та експериментальний час до першого байта. (developer.chrome.com)

Lighthouse Continuous Integration може запускати перевірки продуктивності при кожній зміні коду та відхиляти збірки, коли перевищуються бюджети. (github.com)

Моніторинг краулерів

Використовуйте журнали сервера, периферійні журнали та невеликий набір синтетичних зондів.

Приклад зонда:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Запустіть той же тест з:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Звичайний user-agent браузера.

Тест повинен перевірити:

• Код стану.
• Дозвіл Robots.
• Заголовки відповіді.
• Вміст HTML.
• Версія HTTP.
• Стан кешу.
• Час відповіді.
• Чи присутній важливий текст без JavaScript.

Моніторинг пошуку та індексування

Використовуйте:

• Статистика сканування Google Search Console.
• Звіти про індексування сторінок Google Search Console.
• Перевірка URL-адрес Google Search Console.
• Дані Sitemap Google Search Console.
• Звіти про генеративний штучний інтелект Google Search Console, коли вони доступні.
• Запити сканування Bing Webmaster Tools та проіндексовані сторінки.
• Продуктивність штучного інтелекту Bing Webmaster Tools.
• Щоденні перевірки Sitemap та lastmod.

Інтерфейс прикладного програмування Search Console може отримувати дані про продуктивність за сторінкою, запитом, датою, пристроєм та виглядом у пошуку, з урахуванням обмежень даних. (developers.google.com)

Моніторинг цитувань

Створіть панель цитувань, що містить від 50 до 200 стабільних запитів за темою. Запускайте панель за фіксованим графіком та записуйте:

• Чи здійснювала платформа пошук.
• Які джерела з'явилися.
• Чи було процитовано перевірену URL-адресу.
• Порядок цитування.
• Дата та час відповіді.
• Чи змінилася сторінка.
• Чи змінилася модель або пошуковий досвід.

Не порівнюйте кількість цитувань з різних систем, ніби вони еквівалентні. Microsoft стверджує, що діяльність з цитування не є показником рейтингу, авторитету, трафіку чи якості. (bing.com)

Правила сповіщень

Створіть сповіщення для:

• Час до першого байта зростає більш ніж на 25 відсотків.
• Largest Contentful Paint переміщується вище 2.5 секунд на 75-му перцентилі.
• Cumulative Layout Shift переміщується вище 0.1.
• Стійке збільшення відповідей 5xx або 429.
• Зниження показника успішності краулера.
• Зміна robots.txt.
• Помилка Sitemap.
• Раптове зменшення кількості проіндексованих сторінок.
• Раптове зменшення цитувань штучним інтелектом на кількох платформах.
• Зміна обсягу цитувань, що впливає лише на одну платформу.

Зниження цитувань, що впливає на одну платформу, може бути викликано зміною моделі, індексу, запиту або продукту, а не проблемою продуктивності сторінки. Microsoft чітко попереджає, що тенденції цитувань є спостережними і можуть змінюватися через оновлення контенту, попит користувачів та зміни системи або моделі. (bing.com)

Остаточний висновок

Найбільш обґрунтований висновок:

Швидші сторінки можуть покращити ефективність сканування, особливо коли затримка сервера, розмір ресурсів, помилки або затримки відтворення є обмежуючими факторами. Але наразі немає вагомих доказів того, що нижчі показники Core Web Vitals безпосередньо призводять до вибору сторінки як цитати системами штучного інтелекту.

Очікуваний причинно-наслідковий зв'язок:

text Менша затримка → краща пропускна здатність сервера → менше невдалих або затриманих завантажень → швидше виявлення та обробка → підвищення шансів бути проіндексованим та отриманим → можливе збільшення цитувань

Останній крок залишається невизначеним, оскільки вибір цитування залежить від релевантності, якості, свіжості, авторитетності, намірів запиту, рангу отримання та поведінки кожної системи штучного інтелекту.

Для більшості вебсайтів правильна стратегія продуктивності, отже, не полягає в ізольованій «оптимізації для цитувань штучним інтелектом». Вона включає:

1. Зберігайте важливий контент доступним у початковому HTML.
2. Підтримуйте стабільний час до першого байта.
3. Використовуйте кешування на периферії для публічного контенту.
4. Стискайте та надавайте пріоритет важливим зображенням.
5. Запобігайте зсувам макета.
6. Повертайте надійні коди стану.
7. Підтримуйте актуальність файлів Sitemap та внутрішніх посилань.
8. Дозволяйте правильним пошуковим краулерам.
9. Вимірюйте сканування, індексування, отримання та цитування як окремі етапи.

Такий підхід створює швидший вебсайт для людей, здоровіший сайт для пошукових краулерів та перевірену основу для розуміння видимості для штучного інтелекту.