Sneex SEO 🇺🇦

LLM і JavaScript: чому важливий контент має бути в raw HTMLAndre Alpar провів цікавий SEO-експеримент, який поширила Aleyda Solís: чи можуть AI-асистенти побачити контент, який з’являється на сторінці тільки після виконання JavaScript.Ідея тесту була простою, але дуже показовою. На сторінці було два значення:фейкове значення в raw HTML;справжнє значення, яке підставлялось тільки після виконання зовнішнього JavaScript.Після цього автори перевіряли не тільки відповідь моделі, а й server logs:чи AI-асистент взагалі відкрив сторінку;чи завантажив JavaScript-файл;чи виконав код і звернувся до endpoint, де було справжнє значення.Результат для SEO досить неприємний: ChatGPT, Claude, Gemini, Perplexity, Meta AI і Microsoft Copilot у цьому тесті відповіли значенням із raw HTML, тобто побачили decoy, а не справжній JS-rendered контент.Особливо показово, що Gemini теж не використав значення після рендерингу, хоча це продукт Google. Це важливий нюанс: те, що Googlebot у класичному пошуку може рендерити JavaScript, не означає, що AI-асистент у live grounding-сценарії робить те саме.Були й винятки. DeepSeek, ERNIE, Qwen, Kimi і Mistral змогли виконати JavaScript і повернути справжнє значення. Grok пішов ще цікавішим шляхом: один із його вузлів виконав JavaScript, але відповідь усе одно була побудована на значенні з raw HTML.Головний висновок не в тому, що “усі LLM не вміють рендерити JavaScript”. Висновок точніший: не можна припускати, що AI-асистент побачить контент, який існує тільки після client-side rendering.Для SEO це особливо важливо для сайтів на React, Vue, Angular, SPA-рішень, lazy-loaded блоків, табів, акордеонів, product specs, pricing і важливих комерційних блоків, які підтягуються після завантаження сторінки.Що варто зробити:Перевірити raw HTML ключових сторінокВідкрийте view-source: або вимкніть JavaScript і подивіться, чи є там основний контент: ціни, характеристики, описи, FAQ, порівняння, USP, відгуки.Не ховати важливі факти за JSЯкщо блок важливий для ранжування, AI-citations або конверсії, він має бути доступний у першій HTML-відповіді.Використовувати SSR або pre-renderingДля важливих сторінок краще використовувати server-side rendering, static generation або pre-rendering, щоб контент був доступний одразу.Дивитись у server logs, а не вірити словам чатботаУ тесті Perplexity заявив, що не зміг отримати доступ до сторінки, але server logs показали HTTP 200. Тому для перевірки AI-доступності потрібно дивитися фактичні запити, user-agent, статуси та завантаження ресурсів.Тестувати окремо AI-платформиПоведінка ChatGPT, Gemini, Claude, Perplexity, Grok, Mistral і DeepSeek може сильно відрізнятись. Один тест у Google Search Console не відповідає на питання, що бачить AI-асистент.Практичний висновок: для AI visibility важливий контент має бути в HTML одразу, а не з’являтися тільки після JavaScript.Джерела:Search Engine World: Do AI Assistants Actually Render Your JavaScript when Grounding? — https://www.searchengineworld.com/do-ai-assistants-actually-render-your-javascript-when-grounding-we-put-it-to-the-testLinkedIn: Aleyda Solís про експеримент — https://www.linkedin.com/posts/aleyda_do-ai-assistants-actually-render-your-activity-7473307747128733697-YIWg

Fan-out queries: як зрозуміти, що AI реально шукаєУ класичному SEO ми звикли аналізувати ключові слова, SERP, intent і конкурентів. Але в AI-пошуку з’являється ще один важливий шар — fan-out queries.Fan-out queries — це додаткові пошукові запити, які LLM може виконувати “за лаштунками”, щоб сформувати відповідь. Користувач пише один prompt, але AI може розкласти його на кілька уточнених пошуків: з модифікаторами, роком, порівняннями, review-сайтами, trusted entities та іншими джерелами.Саме тому аналіз fan-out queries стає одним із найкорисніших напрямів для AEO/GEO у 2026 році. Він показує не те, що користувач написав напряму, а те, якою мовою AI реально шукає інформацію.Що можна побачити у fan-out data:1. Search patterns AI може сам додавати до пошуку слова на кшталт best, reviews, top, comparison, 2026, навіть якщо користувач цього не писав. Наприклад, користувач може запитати: Which CRM should I use for a small sales team? А fan-out query може виглядати ближче до: best CRM software for small sales teams 2026 reviews Для SEO це важливий сигнал: сторінка має покривати не тільки основний запит, а й ті варіанти, через які AI може перевіряти відповідь.2. Trust entities У fan-out queries часто видно, які джерела AI використовує як шар довіри. Для різних ніш це можуть бути: - NIST для cybersecurity; - IRS для податкових тем; - державні сайти для legal або finance; - академічні джерела для health або research; - галузеві асоціації для B2B. Це допомагає зрозуміти, які entities потрібно враховувати в контенті, посиланнях, цитуваннях і topical authority.3. Review sites Для B2B і SaaS fan-out queries часто показують, що LLM шукає підтвердження на review-платформах: - G2; - Gartner; - Capterra; - TrustRadius; - Clutch; - нішеві directories. Це означає, що AI visibility не завжди будується тільки на вашому сайті. Іноді для потрапляння в AI-відповіді важливіше, як бренд представлений на сторонніх платформах, які AI використовує для валідації.4. Freshness signals Дослідження Peec AI показувало, що ChatGPT часто додає поточний рік у fan-out queries. Це пояснює, чому сторінки з актуальними оновленнями, свіжими даними, новими прикладами та зрозумілою датою оновлення можуть краще працювати в AI-пошуку. Для SEO це не означає “просто міняти дату”. Потрібно реально оновлювати: - приклади; - порівняльні таблиці; - pricing; - screenshots; - список інструментів; - джерела; - рекомендації; - блоки з висновками.5. Entities, які AI перевіряє перед відповіддюFan-out queries можуть показати, які бренди, категорії, стандарти, платформи або джерела AI вважає важливими для теми.Це корисно для побудови контенту: можна зрозуміти, які сутності треба додати на сторінку, які порівняння зробити, які джерела процитувати і які trust-сигнали посилити.Джерела:- Peec AI: Patterns we see in ChatGPT query fanouts — https://peec.ai/blog/patterns-we-see-in-chatgpt-query-fanouts- OpenAI Help Cen

🚨 Bing випускає нові аналітичні дані про видимість ШІ в інструментах Bing Webmaster Tools: Наміри, Теми, Частка цитування, Опція порівняння 👇Intents: Завдяки новій функції «Наміри», запити на обґрунтування у звіті про ефективність ШІ тепер класифікуються за ширшими категоріями, такими як Інформаційні, Комерційні, Навігаційні, Навчання та вирішення, Дослідження, Творчість, Локальні тощо. Це має допомогти видавцям вийти за рамки простого бачення того, які запити викликали цитування, і почати розуміти ширший контекст запиту, який наші системи пов’язують із цими появами цитування.Seeing Visibility Through Topics Instead of Individual Querie: Групування пов’язаних запитів на обґрунтування в ширші тематичні кластери. Системи ШІ міркують за концепціями та темами, а не за окремими ключовими словами. Теми мають допомогти видавцям зрозуміти видимість у тій самій тематичній структурі, яку сучасні системи ШІ використовують для організації інформації.Introducing Citation Share: Частка цитування показує, яку частину місця цитування ваш сайт отримує для певного запиту на обґрунтування. Він розраховується як відсоток цитувань, пов'язаних з вашим сайтом, від усіх цитувань, що відображаються на всіх сайтах для того самого запиту. Це має допомогти видавцям зрозуміти не лише чи були вони цитовані, але й яку видимість вони отримали в повному наборі цитованих джерел для цього запиту.Compare Changes Over Time: дозволяє видавцям накладати попередній період часу безпосередньо на поточне представлення звітності.Intents, Topics, Citation Share, та Compare Changes Over Time вже сьогодні починають розгортатися в режимі попереднього перегляду в інструментах Bing Webmaster Tools по всьому світу.Джерело: https://blogs.bing.com/search/June-2026/New-AI-Visibility-Insights-in-Bing-Webmaster-Tools-Intents-Topics-Citation-Share-Compare

Уряд США заборонив Anthropic надавати доступ до Fable 5 негромадянамСеріал Anthropic 🍿 або Ми не це мали на увазі, коли топили за регуляції 😒🫠🟢 Anthropic перед IPO і після прогріву аудиторії розмовами про Mythos випускає Fable 5. Модель здатна робити дива, порівняно навіть з Opus 4.8.🟢 Але вони приховують усі запобіжні заходи, які вони вжили, що робить модель часто непридатною для використання, навіть коли ці заходи не тригеряться. Всі в шоці, їх публічно критикують, запобіжні заходи роблять явними.🟢 Щоб трохи зіпсувати життя конкурентам і не дати їм нормально розвиватися, Dario Amodei, CEO Anthropic, пише довгий проникливий допис про те, що в AI потрібні регуляціїУряд повинен мати право блокувати або стримувати впровадження моделі, якщо на основі оцінки третьої сторони буде встановлено, що вона становить неприйнятні ризики. Ці повноваження повинні бути обмежені чотирма вищезазначеними конкретними ризиками, і повинні бути передбачені захисні заходи від політичного фаворитизму або свавільних рішень. 🟢 У п'ятницю ввечері, під кінець робочого дня, уряд США надсилає в Anthropic наказ прибрати доступ до моделі Fable 5 всім негромадянам США, включно зі співробітниками Anthropic, через те, що вони знайшли джейлбрейк, який дозволяє байпаснути модель.🟢 Anthropic вивчає запропонований джейлбрейк і виявляє, що це дуже простий, всім відомий, майже класичний шкільний метод, який не має особливих загроз і який працює в усіх моделях, не тільки Fable 5. Зокрема, він працює в ChatGPT також.🟢 У нас ще є джейлбрейк, крутіший за попередній, кажуть в уряді США, але ми вам його поки що не покажемо, у нас вже вихідні, п'ятниця вечір то святе.🟢 Але Anthropic мають виконувати наказ. І оскільки вибірково заборонити доступ вони не можуть, то відрізають його усім. 🟢 Це негативно вплине на розвиток AI, кажуть в Anthropic.Можливо: Десь в Китаї AI-компанії радісно потирають руки. Десь плачуть SEOшники, які накопичували токени під ресет... Десь відкорковує шампанське Sam Altman...Інші AI-компанії США призначають зустрічі юристам для обрання іншої юрисдикції.

WebKnoGraph: внутрішні посилання можна тестувати до впровадженняEmilija Gjorgjevska опублікувала пост про новий research paper WebKnoGraph: GNN-Powered Internal Linking, який уже доступний на arXiv.Головна ідея: internal linking не має залишатися грою в здогадки. Замість того щоб додавати посилання, чекати кілька місяців і намагатися зрозуміти, що саме вплинуло на результат, WebKnoGraph пропонує оцінювати потенційний ефект внутрішніх посилань ще до їхнього впровадження.У paper описаний open-source framework, який працює з production crawl data та моделює сайт як directed graph. Сторінки представляються через embeddings, потенційні внутрішні посилання оцінюються за допомогою GraphSAGE, а наслідки змін аналізуються через метрики авторитетності та семантичної узгодженості.Простіше кажучи, WebKnoGraph допомагає відповісти на питання:- які сторінки варто з’єднати внутрішніми посиланнями;- як це може змінити розподіл authority всередині сайту;- чи не створить нове посилання семантичний шум;- які сторінки отримають найбільший потенційний виграш;- де автоматична рекомендація потребує експертної перевірки.У дослідженні WebKnoGraph тестували на production crawl сайту Kalicube.com. Автори порівнювали автоматичний підбір посилань з expert-assisted підходом і дивились не тільки на authority gain, а й на volatility, loss-gain balance та semantic coherence.Важливий висновок: автоматичний підхід може краще перерозподіляти authority, але частіше створює вищу ціну з точки зору semantic coherence. Експертний підхід краще зберігає тематичну логіку, особливо коли йдеться про сторінки з низьким PageRank.Для SEO це дуже практична ідея. Внутрішня перелінковка часто виглядає простою задачею: знайти сторінку-донор, додати анкор, поставити посилання. Але на великих сайтах кожна така зміна впливає на всю архітектуру: crawl paths, link equity, topical clusters, orphan pages, важливість категорій і навіть те, як сайт може бути зрозумілий у generative search.Що можна забрати в роботу вже зараз:1. Думати про сайт як про граф Внутрішні посилання — це не просто “лінки в тексті”. Це система зв’язків між документами, яка визначає, які сторінки отримують більше ваги та як пошукові системи розуміють структуру сайту.2. Не оцінювати internal linking тільки вручну Ручна експертиза важлива, але на великих сайтах потрібні graph metrics: PageRank, depth, inlinks, outlinks, orphan pages, topical distance, authority flow.3. Перевіряти не тільки authority, а й relevance Посилання може передавати вагу, але бути слабким семантично. Для сучасного SEO і generative search важливо, щоб внутрішня перелінковка підтримувала topical coherence.4. Тестувати linking scenarios до деплою Ідеальний сценарій — не просто “додати 500 посилань”, а спочатку змоделювати кілька варіантів: які сторінки виграють, які можуть втратити, як зміниться внутрішній розподіл ваги.5. Поєднувати автоматизацію з експертною перевіркою WebKnoGraph якраз показує, що автоматичні рекомендації можуть бути сильними, але SEO-фахівець усе ще потрібен для оцінки контексту, анкорів, комерційної логіки та editorial deployability.Головний висновок: internal linking стає не просто технічною задачею, а частиною стратегічної архітектури сайту. У світі AI-mediated discovery, answer engines і generative search виграватимуть не ті сайти, де посилання додані випадково, а ті, де структура побудована як зрозуміла, вимірювана й семантично пов’язана система.Джерела:- LinkedIn: Emilija Gjorgjevska про WebKnoGraph — https://www.linkedin.com/posts/emilijagjorgjevska_scientific-internal-linking-for-seo-and-generative-ugcPost-7468544843569434625-e23q- arXiv: WebKnoGraph: GNN-Powered Internal Linking — https://arxiv.org/abs/2606.06106- GitHub: WebKnoGraph repository — https://github.com/martech-engineer/WebKnoGraph

Accessibility Tree для AI agents: що перевіряти SEO-фахівцюGoogle у матеріалі про оптимізацію сайтів для AI-агентів окремо виділяє Accessibility Tree. Це структура, яка показує сторінку не через дизайн, а через ролі, назви, стани та призначення елементів.Для AI-агентів це важливо, бо вони не завжди “бачать” сторінку так, як людина. Замість візуального розташування блоків агент може орієнтуватися на семантичну структуру: де кнопка, де форма, яке поле потрібно заповнити, що є навігацією, а що основним контентом.Це не означає, що Accessibility Tree став новим ranking factor у Google Search. Але це сильний сигнал, куди рухається технічна оптимізація: сайт має бути зрозумілим не тільки користувачам і пошуковим ботам, а й AI-агентам.Як швидко перевірити `Accessibility Tree` у Chrome:1. Відкрити потрібну сторінку в Chrome.2. Натиснути правою кнопкою миші та вибрати Inspect.3. Перейти у вкладку Elements.4. Натиснути >>, якщо вкладка Accessibility прихована.5. Вибрати Accessibility.6. Увімкнути Show Accessibility Tree.Після цього в Elements можна побачити, як браузер інтерпретує сторінку для assistive technologies і потенційно для AI-агентів.Що варто перевірити SEO-фахівцю:- чи мають кнопки та посилання зрозумілі назви;- чи правильно використовуються button, a, nav, main, form, label;- чи не замінені важливі елементи беззмістовними div;- чи є коректні aria-label там, де вони справді потрібні;- чи не прихований важливий контент від Accessibility Tree;- чи логічна структура заголовків;- чи зрозумілі поля форм без візуального контексту;- чи мають змістовні зображення коректний alt.Найкраще робити таку перевірку не для кожної URL окремо, а на рівні шаблонів:1. Головна сторінка.2. Категорії.3. Товарні сторінки.4. Landing pages.5. Blog posts.6. Форми заявки або checkout.7. Сторінки з фільтрами та інтерактивними елементами.Головний висновок: accessibility стає важливою не тільки для користувачів, а й для machine interaction. Чим краще сторінка описана семантично, тим легше AI-агенту зрозуміти її структуру, знайти потрібну дію і виконати задачу.Для SEO це ще один аргумент не ігнорувати семантичний HTML, labels, ARIA, структуру DOM і доступність форм. Це не окрема “AEO-магія”, а продовження якісної технічної оптимізації.Джерела:- Google / web.dev: Build agent-friendly websites — https://web.dev/articles/ai-agent-site-ux- Chrome DevTools: Accessibility features reference — https://developer.chrome.com/docs/devtools/accessibility/reference- Chrome Developers: Lighthouse Agentic Browsing scoring — https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring

ChatGPT fan-out queries: чому “best”, “reviews” і “2026” важливі для AEOPeec AI опублікували цікаве дослідження: Tomek Rudzki проаналізував 5 млн query fanouts у ChatGPT, Perplexity і Grok, щоб зрозуміти, які запити AI-системи реально виконують “за лаштунками”.Це важливо для SEO, бо користувач може написати один простий prompt, але AI-пошук не обов’язково шукає саме його. Він може розкласти запит на кілька додаткових пошуків: з порівняннями, оглядами, брендами, поточним роком і комерційними модифікаторами.Інакше кажучи, оптимізуватися тільки під буквальний запит користувача вже недостатньо. Потрібно розуміти, якою мовою AI реально шукає джерела.Що показало дослідження Peec AI:1. ChatGPT часто додає “best”За даними Peec AI, best — найчастіше слово, яке ChatGPT додає у fan-out queries, навіть якщо користувач його не писав.Наприклад, користувач може запитати:Which Samsung Galaxy should I get?А fan-out запит може перетворитися на щось ближче до:best Samsung Galaxy phones comparison 2026Саме тому в AI-відповідях часто з’являються listicle-сторінки: 10 Best..., Top tools..., Best software for.... Вони збігаються не тільки з тим, що пише користувач, а й з тим, як AI переформатовує запит.2. Reviews працюють як шар валідаціїЩе один сильний патерн — reviews.ChatGPT може шукати огляди навіть тоді, коли користувач прямо не просив “reviews”. Для продуктових, SaaS, B2B і affiliate-запитів це особливо важливо.Тому в AI-відповідях часто з’являються джерела на кшталт:- G2;- Gartner;- Clutch;- Forbes;- нішеві review-сайти;- сторінки з порівняннями та рейтингами.Практичний висновок: якщо бренд хоче бути видимим у відповідях AI, недостатньо мати тільки власну посадкову сторінку. Потрібно дивитися, що про бренд пишуть сторонні джерела, які можуть використовуватися як validation layer.3. Freshness має значенняУ дослідженні також видно, що ChatGPT часто додає поточний рік до fan-out queries. За даними Peec AI, 2026 входив у топ injected terms.Це пояснює, чому оновлення контенту може давати ефект у LLM visibility. AI-системи часто шукають не просто “best tools”, а “best tools 2026”, “comparison 2026” або “reviews 2026”.Для SEO це означає:- оновлювати сторінки, які вже потрапляють у AI-відповіді;- додавати актуальні дані;- оновлювати приклади, таблиці, рейтинги, screenshots;- показувати дату оновлення там, де це корисно для користувача.4. Різні AI-системи роблять різну кількість fan-outsPeec AI порівняли кількість fan-outs між системами:- Perplexity — у середньому 1.4 fanouts на запит;- ChatGPT — приблизно 2.1 fanouts;- Grok — близько 6.8 fanouts.Це означає, що різні AI-платформи мають різну логіку пошуку. Одні просто спрощують запит, інші будують повноцінний research brief із додатковими джерелами, брендами, порівняннями та роком.Fan-out optimization — це не про генерацію сотень тонких сторінок під кожну мікро-варіацію. Краще створювати сильні сторінки, які покривають кластер: порівняння, reviews, use cases, альтернативи,

AEO-експерименти Ramp: що SEO-фахівцям варто забрати в роботуRamp поділились серією AEO-експериментів на сесії Parabolic Experimentation with AEO від George Bonaci. Це один із корисних прикладів не теоретичного “AI SEO”, а реальних тестів: що спрацювало, що не спрацювало і чому.Головний висновок: AEO не завжди повторює класичну SEO-логіку. У Google ми часто дивимось на search volume, позиції, CTR і потенційний трафік. Але в LLM-пошуку важливішими можуть бути інші речі: корисність відповіді, унікальність даних, зв’язок із реальною задачею користувача і crawlable-структура контенту.Що тестували Ramp:1. Оптимізація під zero-volume та low-volume запитиRamp брали вже існуючі сторінки й швидко оновлювали їх під вузькі запити, які майже не мали класичного search volume, але відповідали реальним проблемам користувачів.Зміни були невеликі: оновлення свіжості, покращення структури, точніше формулювання відповіді. За публічним переказом сесії, такий підхід дав +78% до LLM visibility.Практичний висновок: не ігноруйте запити тільки тому, що SEO-інструменти показують 0 volume. Для AI-пошуку такі запити можуть бути цінними, якщо вони точно описують задачу користувача.2. Jobs To Be Done замість простого keyword targetingДругий підхід — оптимізація не під ключове слово, а під дію або задачу, яку користувач хоче виконати.Ramp брали існуючий контент, значно розширювали його, додавали дані та прив’язували до конкретного pain point. За даними Profound, test cohort отримав +24.6% visibility.Для SEO це означає, що в AEO потрібно будувати контент не тільки навколо what is або best tools, а й навколо сценаріїв:- “як вибрати інструмент для конкретної задачі”;- “що робити в ситуації X”;- “як порівняти рішення для певного workflow”;- “який підхід краще для конкретного бізнес-кейсу”.3. Надто вузька оптимізація не завжди працюєОдин із тестів Ramp провалився: дуже вузькі сторінки під нішеві product use cases отримали лише близько 2% citation rate.Це важливий анти-висновок. Не кожна мікро-сторінка стає хорошим джерелом для LLM. Якщо сторінка занадто вузька, без унікальної цінності або без достатнього контексту, AI-системі може бути простіше процитувати ширше й авторитетніше джерело.4. Programmatic content + proprietary dataНайцікавіший напрям — використання власних даних Ramp. Компанія має доступ до агрегованих і анонімізованих даних про бізнес-витрати, тому може бачити тренди в категоріях на кшталт CRM, AEO tools, AI software та інших B2B-рішень.На цій основі Ramp створили Ramp Rate — data-backed vendor directory. За даними Profound, фокус на fresh, crawlable pages із proprietary data допоміг збільшити sessions на 149% між червнем і серпнем.Для SEO це сильний сигнал: унікальні дані стають одним із найкращих активів для AEO. Якщо бренд має власну статистику, транзакційні дані, internal benchmarks, дослідження або агреговану аналітику — це потрібно перетворювати в індексовані сторінки, які AI може використовувати як джерело.Що можна зробити вже зараз:1. Зібрати low-volume запити, які описують реальні задачі клієнтів.2. Перевірити існуючі сторінки й оновити структуру відповідей.3. Додати блоки з конкретними сценаріями використання, а не тільки загальні SEO-тексти.4. Знайти власні дані компанії, які можна безпечно публікувати.5. Не масштабувати мікро-сторінки без перевірки citation rate і реальної користі.Джерела:- Profound: Inside our inaugural Zero Click NYC summit — https://www.tryprofound.com/blog/zero-click-new-york-inagaural-ai-search-nyc-summit- Ramp Rate: AEO category — https://ramp.com/vendors/categories/aeo- Ramp: Top SaaS Vendors on Ramp — https://ramp.com/leading-indicators/top-saas-vendors-on-ramp-february-2026- Chris Long про сесію Ra

llms.txt: SEO 2.0 чи чергова переоцінена SEO-історія?Google Search Team прямо каже: для появи в AI Overviews, AI Mode та інших generative AI features не потрібно створювати llms.txt, спеціальні AI-файли, Markdown або окрему розмітку “для штучного інтелекту”.Але є важливий нюанс.Chrome Team уже додала в Lighthouse аудит, який перевіряє наявність llms.txt у категорії Agentic Browsing. У документації Chrome цей файл описується як “emerging convention” для LLMs та AI agents, який допомагає агентам швидше зрозуміти структуру й основний контент сайту без зайвого crawling.І саме тут починається найцікавіше.Google Search і browser agents — це не одне й те саме.Для класичного пошуку, AI Overviews та AI Mode Google може спиратися на свій індекс, crawling, ranking systems, якість контенту, технічну доступність сторінок і знайомі SEO-сигнали.Але agentic browsing — це інший сценарій. Тут AI-агент може взаємодіяти із сайтом напряму: аналізувати DOM, accessibility tree, layout stability, форми, кнопки, внутрішню структуру сторінок і допоміжні файли.Тому твердження “Google не використовує llms.txt для Search” не дорівнює “цей файл ніколи не буде корисним”.Це схоже на semantic HTML. Він не завжди є прямим фактором ранжування, але може бути критичним для доступності, парсерів, браузерних агентів, автоматизацій і машинного розуміння сторінки.Що робити SEO-спеціалісту1. Не продавати llms.txt як новий ranking factor.2. Не ігнорувати його повністю, бо Lighthouse уже виніс це в окремий agentic browsing audit.3. Додати llms.txt у backlog як low-cost тест, особливо для SaaS, e-commerce, документації, маркетплейсів і великих сайтів.4. Перевіряти логи сервера: чи звертаються AI crawlers або browser agents до /llms.txt.5. Паралельно покращувати базу: - чисту структуру сторінок; - зрозумілі заголовки; - коректні internal links; - semantic HTML; - accessibility tree; - стабільний layout; - актуальні robots.txt і sitemap.xml; - правильні canonical та indexability.llms.txt поки не SEO-магія і не підтверджений фактор ранжування.Але це вже частина ширшої зміни: сайти потрібно оптимізувати не тільки для пошукових ботів і людей, а й для AI-агентів, які будуть читати, аналізувати й виконувати дії на сайтах.Welcome back to SEO 2.0.Джерела:- Google Search Central: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide- Chrome for Developers: https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt- Lighthouse Agentic Browsing Scoring: https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring

Preferred Sources у Google Search: чому SEO знову стає грою за довіруGoogle розширює функцію Preferred Sources, і це важливий сигнал для SEO, видавців та брендів, які вже відчувають падіння кліків через AI Overviews та AI-відповіді.Суть функції проста: користувач може вибрати сайти, які хоче бачити частіше в Google Search. Спочатку це працювало для Top Stories, але тепер Google переносить Preferred Sources у AI Overviews та AI Mode.Тобто, якщо користувач додав ваш сайт як preferred source, ваші матеріали можуть бути помітніше виділені в AI-відповідях і результатах пошуку.Чому це важливо для SEOБагато хто дивиться на AI Search тільки через втрату кліків. І це реальна проблема. Але Preferred Sources показує іншу сторону: Google поступово додає більше персоналізації у пошук.Якщо користувачі регулярно обирають певні бренди як джерела, це може стати новим шаром видимості:- “Я довіряю цьому сайту”- “Я хочу бачити його частіше”- “Це джерело для мене авторитетне”Це не класичний ranking factor у стилі backlinks або content quality. Але це може стати персоналізованим сигналом довіри.І тут SEO виходить за межі технічної оптимізації сторінки. Виграватимуть бренди, які будують прямий зв’язок з аудиторією ще до моменту покупки або конверсії.Що робити SEO-спеціалісту1. Перевірити, чи можна знайти ваш сайт у Google Source Preferences.2. Додати CTA на сайт, у newsletter, Telegram, LinkedIn або email-розсилку: “Додайте нас як preferred source у Google”.3. Працювати не тільки над трафіком, а й над повторною взаємодією з аудиторією.4. Інвестувати в бренд, авторів, експертність, підписки та community.5. Оцінювати не тільки позиції, а й частоту повернення користувачів до бренду.Джерела:- Google: https://blog.google/products-and-platforms/products/search/preferred-sources-language-expansion/- Google: https://blog.google/products-and-platforms/products/search/original-high-quality-content-search/- Google Search Central: https://developers.google.com/search/docs/appearance/preferred-sources