Sneex SEO 🇺🇦

Новий випуск подкасту Collaborator: Reddit як канал трафіку з Google та AI-чатботів   Гість — Alex Savy, CEO Asavy Marketing. Керує понад 30 сабредітами, частина з яких ранжується в Google по конкурентних запитах і має по 12 000+ підписників   🎧 Слухати зараз   Ведучий — Сергій Кокшаров (Devaka), амбасадор ефективного SEO   У випуску: ● як шукати перспективні сабреддіти ● що вважають спамом модератори ● як масштабувати присутність на кілька брендів без банів ● чи має сенс цей канал для iGaming/affiliate ніш

Google сильніше блокує SEO-скрапери — і ваш rank tracker може показувати неправильні дані Якщо у вересні ви побачили дивний обвал visibility або позицій у SEO-інструменті — це не обов'язково означає, що сайт реально впав у Google. Приблизно з 13 вересня Google, схоже, значно посилив боротьбу з автоматичним збором SERP. І це вже безпосередньо б'є по rank trackers. За даними Search Engine Roundtable, Derek Perkins із Nozzle повідомив, що інструмент став отримувати приблизно на 80% менше даних із Google Search. Схожу проблему він спостерігав і з DataForSEO. SISTRIX також офіційно підтвердив проблему. 16 вересня компанія написала: Google has made further changes to the way search results are delivered. Через це collection почав працювати зі зниженою швидкістю. А 26 вересня з'явився ще цікавіший апдейт: Google у деяких випадках повертає неповні або спотворені результати пошуку. Через це SISTRIX тепер: додатково перевіряє дані перед оновленням Visibility Index; оновлює менше keywords на день; може показувати старішу дату перевірки ranking у Projects. Поточний статус SISTRIX І ось де починається головна проблема для SEO. Glenn Gabe перевірив сайт, який реально впав майже на 100%, а потім повністю відновився. І три популярні інструменти показали різну картину: Ahrefs → побачив recovery Semrush → побачив, але із затримкою SISTRIX → recovery не побачив Тобто зараз ви потенційно можете дивитися на графік visibility і аналізувати не Google Update, а проблему збору даних самим SEO-tool. Це особливо небезпечно під час високої SERP volatility. Що робити SEO-фахівцю зараз Не приймати рішення на основі одного third-party інструмента. Якщо бачите сильний рух: 1) Перевірте Google Search Console — impressions, clicks та average position. 2) Порівняйте з organic traffic у GA4. 3) Перевірте кілька найбільш важливих запитів окремо. 4) Подивіться дату останнього оновлення ranking у вашому rank tracker. 5) За можливості порівняйте дані двох різних SERP providers. 6) GSC тут особливо важливий, тому що його дані не збираються шляхом scraping Google SERP. Це частина більшого тренду. За останній рік Google уже: 1) прибрав нормальну підтримку num=100; 2) почав маскувати destination URL через google.com/goto; 3) ускладнює automated SERP collection; 4) активніше перевіряє non-human traffic. Тому вартість і складність отримання Google SERP data для Ahrefs, Semrush, SISTRIX, DataForSEO та інших постачальників продовжують зростати. Джерела: Search Engine Roundtable — Google May Be More Successful In Blocking Scrapers & Tracking Tools SISTRIX System Status — Google data collection at reduced rate

OpenAI викотив GPT-6.1 Sol, Ultrafast і фактично власний аналог Jev На OpenAI DevDay 2026 показали одразу кілька дуже цікавих речей для тих, хто будує AI-агентів та автоматизації. 1. GPT-6.1 Sol — майже Astra, але у 5 разів дешевше OpenAI представив GPT-6.1 Sol. За їхніми тестами модель наближається до GPT-6 Astra у: agentic coding; computer use; professional work; складних multi-step workflows. При цьому стандартна API-ціна input/output токенів — приблизно 1/5 від Astra. Ціни: GPT-6.1 Sol Input: $2 / 1M Cached input: $0.10 / 1M Output: $10 / 1M Для порівняння Astra: Input: $10 / 1M Output: $50 / 1M На DeepSWE 1.1 Sol навіть зрівнявся з Astra при значно нижчій вартості. Тобто для більшості production agents тепер виникає очевидне питання: а чи потрібна нам Astra взагалі, якщо Sol дає близький результат у 5 разів дешевше? GPT-6.1 Sol — OpenAI 2. Ultrafast — до 8× швидше OpenAI також запустив premium speed tier Ultrafast. Для Codex: до 8× швидше і приблизно: 300 output tokens/sec Для API заявлено прискорення до 6×. Зараз GPT-6 Astra Ultrafast уже доступний, а підтримка GPT-6.1 Sol має з'явитися найближчим часом. Це особливо цікаво для agentic workflows, де модель робить десятки послідовних рішень і latency накопичується на кожному кроці. Ultrafast mode — OpenAI 3. Новий Pro 500 З'явився новий premium tier: Pro 500 Назва тут максимально прямолінійна — план коштує близько $500/місяць. Він включає: доступ до Ultrafast; найвищі usage limits; приблизно 25× allowance відносно ChatGPT Plus; розширений доступ до Codex та agentic workloads. Тобто OpenAI фактично створює окремий тариф для людей, які використовують AI не як чат, а як постійну compute infrastructure для роботи. 4. І найцікавіше — Decisions API Пам'ятаєте Jev, про який я писав раніше? OpenAI тепер запускає дуже схожу концепцію — Decisions API. Замість того щоб запускати велику модель із промптом: прочитай → подумай → напиши відповідь ми задаємо: context + питання + обмежений набір можливих відповідей і отримуємо рішення. Наприклад: Intent: Informational / Commercial / Transactional або: Який agent має виконати задачу? або: Цю сторінку залишити чи відфільтрувати? Під капотом використовується intelligence Luna. API підтримує text та images і призначений для: classification; routing; content decisions; вибору наступної дії agent; real-time decision making. Тобто замість використання великого reasoning model для кожного маленького рішення: LLM → judgment model → action І це дуже схоже на ідею Jev: не генерувати tokens там, де потрібен просто вибір. Decisions API зараз у limited preview, широкий запуск запланований найближчими днями. Головний тренд DevDay: AI-інфраструктура рухається не тільки в бік «розумніших моделей». Вона стає: дешевшою → швидшою → спеціалізованішою. І для агентів це, можливо, важливіше, ніж ще +5% на benchmark. Джерела: OpenAI DevDay 2026 Recap OpenAI — GPT-6.1 Sol OpenAI — Ultrafast mode

GitLab відкрито опублікував свій Reddit Response Workflow Дуже цікавий приклад для тих, хто займається Reddit SEO, GEO або community marketing: GitLab фактично виклав внутрішню інструкцію для співробітників про те, як компанія повинна працювати з Reddit. І це зовсім не схоже на: створити 20 акаунтів → написати коментарі про бренд → поставити upvotes. Навпаки, GitLab будує процес навколо реальних людей, експертності та доказів. 1. Використовувати особисті акаунти, а не корпоративний GitLab прямо рекомендує співробітникам відповідати зі своїх індивідуальних Reddit-акаунтів. Можна навіть використовувати вже існуючий особистий акаунт. При цьому співробітник може отримати flair GitLab Staff, щоб користувачі чітко бачили його зв'язок із компанією. Тобто підхід: автентична людина + прозора affiliation замість безіменного OfficialGitLabSupport123. 2. На складні питання підключають реальних експертів Якщо питання стосується конкретної функції продукту, Developer Advocacy не намагається самостійно придумати відповідь. У GitLab є цілий Community Response Process: mention → визначити відповідального DRI → знайти SME → експерт відповідає спільноті Для пошуку потрібного експерта вони навіть рекомендують визначати команду-власника функції через документацію та repository. Це дуже сильна модель для GEO. Замість десятків generic marketing responses з'являються відповіді людей, які реально знають продукт. 3. Факти важливіші за opinion Для обговорень GitLab vs competitors у handbook буквально зазначено: фокусуватися на фактах, а не на думках. У відповідях рекомендують використовувати: документацію; GitLab issues; технічні матеріали; конкретні пояснення. Якщо користувач поширює misinformation — відповідати доказами. 4. Негатив ≠ причина для downvote Ще цікавіше правило: GitLab прямо просить співробітників не downvote критичний feedback просто тому, що людині не подобається продукт або вона згадує конкурента. Downvote рекомендується для misinformation. Це дрібниця, але вона добре показує різницю між: community management і brand manipulation. 5. Відповідь повинна бути корисною навіть без переходу за посиланням В Community Response Process є ще одна хороша рекомендація: якщо посилаєтесь на URL — перенесіть ключовий контекст із нього безпосередньо у відповідь. Не просто: ось документація → link а: ось що відбувається → коротке пояснення → джерело. Тому що далеко не кожен користувач відкриє посилання. Що з цього можна взяти для Reddit SEO / GEO Хороша Reddit-стратегія бренду виглядає приблизно так: monitor discussions → find relevant question → involve SME → answer as a real person → disclose affiliation → provide evidence → don't oversell І це набагато більш стійкий підхід, ніж масове створення «нативних» коментарів від псевдокористувачів. Особливо зараз, коли Reddit регулярно стає джерелом для Google та LLM-відповідей. Фактично GitLab публічно показує, як можна перетворити внутрішню експертизу компанії на зовнішній community footprint, який потім живе в пошуку, Reddit та AI Search. Джерела: GitLab Handbook — Reddit Response Workflow GitLab Handbook — Developer Advocacy Community Response Process

Потрібні Magic Links, посилання з головних сторінок або наскрізні розміщення? Приймаю замовлення на нарощування посилального профілю. Послуги та ціни: • Magic Links — $0.35 • Посилання з головної (морди) — $7 • Наскрізні посилання — $20 • База (валід) — $0.6 ✍️ Тексти безкоштовно — окремий бюджет на них не потрібен. Пишіть @pierking — обговоримо ваш проєкт, потрібний обсяг і деталі замовлення.

🔴 Google розпочав September 2026 spam update https://status.search.google.com/incidents/XhUDXP7A67iHCD2kmbVu Старт: 24 вересня 2026 року (09:15 за US/Pacific) Тривалість розгортання: до 2 тижнів Це оновлення спрямоване на боротьбу зі спамом у пошуковій видачі Google. У період розгортання апдейту можливі: • коливання позицій у видачі; • зміни рівня органічного трафіку; • тимчасова нестабільність окремих груп запитів; • зміни у видимості навіть без внесення змін на сайт. Що важливо враховувати: • реакція пошукової видачі може змінюватися кілька разів до завершення оновлення; • просідання або зростання позицій у цей період не завжди є показником помилки на сайті; • коректно оцінювати динаміку варто після завершення rollout та стабілізації результатів.

Google Search Console тепер показує Multimodal Search Google сьогодні запустив новий тип звітності в Search Console — Web Multimodal Search Reporting. Тепер можна окремо побачити, як ваш сайт з'являється в Google, коли користувач починає пошук не з текстового запиту, а із зображення. У звіт потрапляють пошуки через: * Google Lens; * Circle to Search на Android; * завантаження зображення безпосередньо в Google Search; * Search this image у Chrome. Тобто якщо людина сфотографувала товар, обвела предмет на екрані або завантажила картинку й після цього Google показав вашу сторінку — тепер цю visibility можна аналізувати окремо. Де знайти дані У Search Console → Performance з'явився новий фільтр: Search type → Multimodal Причому Google додає ці дані одразу у два звіти: * звичайний Search results; * Generative AI features. Це особливо цікаво, тому що ми нарешті починаємо отримувати окремі дані про те, як visual search перетинається з AI Search. Google також дозволяє експортувати ці дані для подальшого аналізу. Функція запускається глобально з 24 вересня 2026 року, але фільтр з'явиться з даними тільки для properties, які реально отримують impressions або traffic із таких пошуків. Що це змінює для SEO Раніше аргумент: нам потрібно краще оптимізувати зображення часто закінчувався питанням: а як ми виміряємо результат? Тепер відповідь поступово з'являється в GSC. Для e-commerce, travel, recipes, fashion, interior, automotive та інших visual-heavy ніш я б уже окремо дивився: 1. Які URL отримують найбільше multimodal impressions. 2. Які типи сторінок отримують clicks із visual search. 3. Які зображення стоять на цих сторінках. 4. Чи доступні original images Google для crawling та indexing. 5. Чи відповідає текст навколо зображення тому, що користувач може захотіти дізнатися після того, як побачив об'єкт. Наприклад, користувач може не шукати: Nike Air Max 95 grey Він просто фотографує кросівки. Google сам визначає об'єкт, запускає retrieval і шукає релевантні результати. Тобто search journey стає: image → object understanding → query expansion → results а не тільки: keyword → SERP. І це ще один аргумент, чому image SEO більше не варто розглядати як другорядну оптимізацію для Google Images. Окремо Google цього року запустив Platform Properties у Search Console для YouTube, Instagram, TikTok та X, що дозволяє аналізувати, як контент із цих платформ з'являється у Google Search. Функція все ще розгортається поступово. [Документація Google](https://support.google.com/webmasters/answer/34592) Що перевірити зараз: GSC → Performance → Search type → Multimodal Якщо дані вже є — я б одразу експортував їх і подивився які сторінки Google уже вважає релевантними для visual search. Це може стати окремим напрямком SEO-аналітики поряд із Web, Images та Generative AI. Джерела: * Google Search Central — Announcing web multimodal Search performance reporting * Google Search Console — Performance report * Google Search Console — Generative AI performance report * Google Search Console — Platform Properties

Швидке потрапляння в AI-видачу для E-commerce через Reddit Усе ще шукаєте, як масштабно затягнути проєкт в AI-видачу? NeedMyLink просуває E-commerce сайти через комплексний Reddit-маркетинг Ми одні з небагатьох на українському ринку, хто працює з Reddit системно, а не разовими розміщеннями ❓ Що ми пропонуємо: - AMA тред - брендовий пост із 20–30 унікальними коментарями. Щільний кластер контенту, який моделі читають як живе обговорення - ORM кампанія - нативні згадки в тематичних сабредітах, 3-5 відповідей з різних акаунтів. Бренд видно по всій ніші, а не в одному треді 🛡 Видалення, shadowban, automod беремо на себе - міняємо розміщення одразу. Не виконали домовленості - повернемо гроші за всю кампанію Зацікавило для вашого проєкту? 💬 @needmylink_support

Claude Opus 5.5 показав, як насправді може працювати AI Search У свіжих матеріалах навколо Claude Opus 5.5 знайшлася дуже цікава деталь для SEO: коли Claude використовує `WebFetch`, основна модель не обов'язково отримує повний текст сторінки. Опис інструмента буквально говорить: Fetch URL → convert HTML to Markdown → run prompt against content using a small fast model → return the answer Тобто схема може виглядати так: Web page → Markdown → small model → extracted evidence → Opus А не: Web page → весь контент → Opus Це важлива різниця. Мова не про те, що Claude взагалі не читає сторінки. Сторінка завантажується та аналізується, але при WebFetch Opus може отримувати вже відфільтровану відповідь іншої моделі, а не весь документ. І для SEO це дуже цікаво. Ще цікавіше — приклади fan-out. У матеріалах для Opus 5.5 показаний сценарій порівняння CRM. Замість одного пошуку: best CRM software дослідження розбивається на окремі напрями: pricing features integrations user reviews І кожен із них фактично стає окремим research task зі своїми пошуковими запитами та джерелами. Умовно: best CRM ↓ fan-out CRM pricing comparison CRM automation features CRM integrations CRM user reviews ↓ retrieve sources → extract evidence → synthesize answer Це змінює підхід до GEO / AI Search. Недостатньо просто ранжувати одну money page за head keyword. Якщо AI приймає рішення за кількома критеріями окремо, ваш бренд має мати достатньо доказів для кожного критерію. Наприклад, сторінка CRM може чудово пояснювати features, але якщо AI окремо досліджує: pricing і не знаходить чітких актуальних цін — бренд може програти цей етап fan-out. Те саме з: * integrations; * limitations; * comparisons; * reviews; * security; * implementation; * конкретними use cases. Для Local Search логіка теж цікава. Claude вже спостерігали за використанням Google Places: модель може спочатку знайти кандидатів через Places, а потім окремо досліджувати характеристики, які потрібні користувачу. Тобто запит: best hotel in London for family with kids може бути не одним retrieval. Він потенційно перетворюється на щось ближче до: family-friendly hotels London hotel X family rooms hotel X location hotel X reviews families hotel X amenities А потім Claude збирає відповідь із отриманих evidence. Фактично нова одиниця оптимізації може бути вже не: keyword → page а: `prompt → fan-out queries → evidence → sources → answer` І це, на мою думку, одна з найважливіших змін, які AI Search приносить у SEO. Джерела: * Anthropic — Claude Opus 5.5 * Anthropic — Opus 5.5 documentation * Claude Code WebFetch tool description * Pliny — extracted Claude Opus 5.5 prompt bundle * Research: how Claude uses Google Places for local search

Як розібратися в чужому коді й не зійти з розуму З'явився цікавий open-source інструмент Understand Anything, який перетворює цілий репозиторій на інтерактивну карту знань. Замість того щоб відкривати незнайомий проєкт і послідовно читати тисячі рядків коду, можна спочатку побачити всю його архітектуру зверху. Understand Anything аналізує: * файли; * функції; * класи; * imports та dependencies; * архітектурні шари; * business logic; * зв'язки між компонентами. Після аналізу будується knowledge graph, де кожен компонент — окремий node. Можна клікнути, наприклад, на функцію й одразу побачити: хто її викликає → від чого вона залежить → до якого шару належить → що вона робить При цьому використовується комбінація двох підходів: `Tree-sitter` детерміновано витягує структуру коду — imports, functions, classes, calls, inheritance. LLM agents уже додають семантику — пояснюють призначення файлів, визначають architectural layers, business domains і генерують guided tours по проєкту. Є також semantic search. Тобто замість пошуку конкретної назви функції можна запитати щось на кшталт: which parts handle authentication? і знайти релевантні компоненти за змістом. Ще кілька корисних можливостей: * Guided Tours — автоматично будує порядок, у якому краще вивчати архітектуру; * Diff Impact Analysis — показує, які частини системи може зачепити зміна; * Domain View — переводить технічну архітектуру в business flows; * incremental analysis — повторно аналізуються тільки файли, які змінилися. Підтримуються Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI та інші coding agents. Для SEO це теж може бути дуже корисним. Наприклад, коли потрібно швидко розібратися в чужому: * Python crawler; * парсері; * ETL pipeline; * SEO automation; * внутрішньому API; * legacy-проєкті, який писав інший розробник. Замість: відкрити repo → README → main.py → ще 40 файлів → втратити контекст отримуємо: repo → graph → architecture → потрібний flow → конкретний код Тобто AI використовується не для того, щоб написати ще більше коду, а щоб спочатку допомогти зрозуміти вже існуючий. Проєкт open-source і поширюється під MIT License. GitHub: https://github.com/Egonex-AI/Understand-Anything Live demo: https://understand-anything.com/

Jev: 10 інструментів для швидких AI-рішень в агентах Останніми днями навколо Jev з'явилося багато цікавих open-source проєктів. Jev — це перша System One Model від TypeSafe AI. На відміну від звичайного LLM, вона не генерує текст token-by-token. На вході отримує state, а на виході — структуроване рішення з probabilities та confidence. Основні примітиви: * Noul — yes/no із probability; * Choice — вибір одного варіанта; * Score — оцінка за заданою шкалою. Тобто замість: прочитай → подумай → напиши JSON → перевір JSON можна робити: state → judgment → code Ось 10 проєктів, з яких можна почати. 1. [jev-ultrafast](https://github.com/browser-use/jev-ultrafast) Browser Agent від Browser Use. Jev на кожному кроці визначає яку операцію виконати і з яким елементом, а маленька мовна модель викликається тільки тоді, коли потрібно написати текст. У демо пошук рейсу Zürich → London через Google Flights займає приблизно 7.1 секунди. 2. [fast-jev-compaction](https://github.com/tamaratran/fast-jev-compaction) Компресія context для Claude Code. Замість того щоб переписувати старий контекст у summary, Jev перевіряє кожен tool call і вирішує: залишити / видалити / скоротити Причому корисний оригінальний текст залишається verbatim. 3. [json-render](https://github.com/vercel-labs/json-render) Generative UI framework від Vercel Labs. У experimental Jev mode модель не повинна генерувати величезний JSON token-by-token — вона працює з уже підготовленими components, properties, data та actions і приймає рішення щодо композиції UI. 4. [typesafe-mcp](https://github.com/itsmostafa/typesafe-mcp) Мабуть, найпростіший спосіб почати. Підключає Jev через MCP до: * Claude Code; * Claude Desktop; * Codex; * Pi. Після цього агент може напряму викликати Noul, Choice та Score. 5. [jev-mcp](https://github.com/jkudish/jev-mcp) Більш прикладний MCP-набір. Вже є готові tools: jev_verify — fact-checking jev_screen — screening контенту jev_find — semantic search jev_rerank — reranking jev_classify — classification jev_extract — extraction jev_review — review змін Для SEO тут уже видно багато застосувань: класифікація URL, semantic reranking, перевірка claims, аналіз контенту та обробка crawler data. 6. [SemDecide](https://github.com/sharziki/semdecide) Перетворює Jev на Unix CLI. Наприклад: cat pages.jsonl | semdecide filter "page has commercial intent" Є is, choose, score та filter. Це особливо цікаво для зв'язки: crawler → shell/python pipeline → Jev → classification 7. [jev-codex-router](https://github.com/0xNatoshi/jev-codex-router) Jev спочатку оцінює складність наступного coding task, а вже потім визначає: model → reasoning effort → routing Тобто дорогий reasoning model використовується тільки там, де він реально потрібен. 8. [Winnow](https://github.com/GhalebDweikat/winnow) Context garbage collector для Claude Code. Великі результати Read, Bash і Grep розбиваються на блоки, після чого Jev визначає, які з них реально потрібні для поточного завдання. Непотрібний context просто не витрачає tokens. 9. [jev-review](https://github.com/devagrawal09/jev-review) Проміжний AI code-review layer. Jev спочатку знаходить потенційно ризикові зміни, оцінює severity та test gaps, а вже після цього проблемні частини можна відправляти більш дорогій моделі або людині. Є локальний dashboard. 10. [Blink](https://github.com/ellipsis-dev/blink) Semantic navigator по codebase. Jev оцінює назви файлів і директорій та визначає, у який шлях варто йти далі. Замість читання всього repository агент поступово звужує область пошуку до найбільш релевантних файлів. Чому це цікаво для SEO Jev добре показує потенційно важливу зміну в архітектурі AI-автоматизації. Не кожне завдання потребує GPT/Claude, який генерує сотні tokens reasoning. Для задач типу: релевантно? це spam? який URL кращий? який intent? залишити цей блок? до якого cluster віднести сторінку? може бути ефективніше використовува

Як знайти conversational та fan-out queries у Google Search Console У Google Search Console можна знайти запити, які дуже схожі на LLM prompts та fan-out queries — тобто пошукові запити, які AI-системи генерують у процесі пошуку інформації для відповіді. Це не дає нам повного списку ChatGPT або AI Mode prompts. Але вже зараз є кілька практичних способів витягнути такі патерни зі своїх даних. 1. Фільтруємо дуже довгі запити Найпростіший метод від [Nectiv](https://nectivdigital.com/blog/how-to-mine-google-search-console-for-conversation-data-regex-included) — знайти queries із 10+ словами. У GSC: Performance → Queries → Add filter → Custom (regex) → Matches regex Вставляємо: ^(?:\S+\s+){9,}\S+$ Отримаємо запити на кшталт: which software platforms are best for enterprise teams looking for... або what are the best tools for comparing... Тобто формулювання, значно ближчі до prompt, ніж до класичного keyword. Але є нюанс: це high-precision, low-recall filter. У свіжому дослідженні Nectiv середня довжина ChatGPT fan-out query була близько 6.8 слова, тому фільтр 10+ words знайде найбільш очевидні conversational queries, але пропустить багато коротших. 2. Шукаємо `site:` queries Ще цікавіший сигнал знайшла [Lily Ray](https://www.linkedin.com/posts/lily-ray-44755615_im-pretty-confident-these-are-chatgpt-fan-out-activity-7500306804418146305-3ugg). Просто фільтруємо GSC за: site: Або точніше: (?i)(site:.*official|official.*site:) У багатьох properties з'являються дивні queries із: * великою кількістю impressions; * майже нульовим CTR; * site:; * official; * дуже специфічними формулюваннями. Чому це цікаво? У дослідженні [Nectiv на 28K+ ChatGPT та Gemini fan-out queries](https://nectivdigital.com/blog/chatgpt-tripled-fan-out-queries-data-study) site: зустрічався приблизно у 64% ChatGPT fan-outs. ChatGPT часто спочатку шукає широку тему, а потім звужує retrieval: best CRM software ↓ site:hubspot.com CRM pricing official ↓ site:salesforce.com enterprise CRM features Для YMYL Lily Ray також пропонує перевірити: site:.*\.gov|\.gov.*site: 3. Фільтруємо conversational language Ще цікавіший підхід зробив [Jean-Christophe Chouinard](https://www.jcchouinard.com/tools/gsc-regex-generator.html). Його GSC RegEx Generator дозволяє автоматично створювати готові RE2 regex для Search Console. Там уже є окремі шаблони для: * AI Mode Queries; * questions; * conversational prompts; * commercial intent; * best / top / vs / review; * transactional intent; * word count; * long-tail queries; * brand queries. Тобто замість одного величезного універсального regex можна посегментувати prompt-like searches за intent. Наприклад: questions → comparisons → recommendations → transactions і подивитися, як саме AI або користувачі досліджують вашу нішу. До речі, генератор враховує обмеження GSC: Search Console використовує RE2, не підтримує negative lookahead (?!...) та має ліміт regex приблизно 4096 символів. 4. Не сприймайте ці queries як гарантовано ChatGPT Це найважливіше. Запит із 15 слів або site: не доводить, що його створив ChatGPT. Це може бути: * AI Mode; * ChatGPT retrieval; * інша AI-система; * автоматизований search; * або реальний користувач із дуже довгим запитом. Тому краще називати їх: `prompt-like / likely fan-out queries` а не ChatGPT queries. Google при цьому офіційно підтверджує сам механізм query fan-out для AI Mode: система розбиває запит на підтеми та виконує кілька пошуків паралельно. Практичний workflow для SEO: 1. Експортуємо GSC queries. 2. Витягуємо 10+ word queries. 3. Окремо шукаємо site: та official. 4. Через GSC RegEx Generator витягуємо conversational patterns. 5. Кластеризуємо їх за intent. 6. Дивимося, які бренди, характеристики, проблеми та comparison criteria повторюються. 7. На основі цього формуємо реальний список prompts для LLM Brand Monitoring. Джерела: https://www.jcchouinard.com/tools/gsc-regex-generator.html https://www.linkedin.com/posts/jeanchristophechouinard_every-since-barry-shared-that-ai-mode-query-share-7493679015984099328-olbi/

Google оцінює, скільки реальної роботи вкладено у ваш контент У витоку Google Content Warehouse знайшли дуже цікавий параметр — contentEffort. За описом у витоку це LLM-based effort estimation for article pages. Тобто Google має числовий float-показник, який потенційно оцінює, наскільки сторінка демонструє реальну роботу, а не просто переказ уже існуючої інформації. Ще цікавіше, що contentEffort знаходиться всередині compressedQualitySignals поруч із такими полями, як lowQuality і siteAuthority. Детально це розібрав [Cyrus Shepard у Zyppy](https://signal.zyppy.com/p/content-effort). Важливе уточнення: ми не знаємо, чи `contentEffort` напряму використовується як ranking factor і яку вагу він має. Але сама концепція effort точно не нова для Google. Cyrus Shepard, який раніше працював Google Quality Rater, звернув увагу, що в Search Quality Rater Guidelines сторінки оцінюються не тільки за originality, skill та accuracy, а й за effort. І слово effort у гайдлайнах зустрічається понад 100 разів. Google не знає, чи писали ви статтю 30 хвилин або 30 годин. Він бачить лише evidence of effort, яке залишилося на сторінці. Ось що це означає на практиці. 1. Original data Власні цифри з продукту, CRM, клієнтів, досліджень або експериментів. Не: According to multiple studies... А: Ми проаналізували 4 218 URL і отримали такі результати. 2. First-hand experience Ви реально використовували продукт, проводили тест, працювали з клієнтом або запускали експеримент — і описуєте, що саме сталося. 3. Visible methodology Показуйте не тільки результат, а й як ви його отримали. Наприклад: Ми протестували 50 сторінок протягом 30 днів, змінили internal linking і порівняли impressions before/after. 4. Original media Власні screenshots, фото, відео, графіки та інші матеріали. Stock photo або картинка з конкурента практично нічого не додає до унікальності сторінки. 5. Curation Хтось повинен вирішити: * що справді важливо; * що можна видалити; * у якому порядку це показувати; * що потрібно користувачу прямо зараз. Тобто curation — це теж частина effort. 6. No filler Google окремо описує filler як low-effort content, який майже не допомагає виконати основну задачу сторінки. Класичний приклад: How to boil an egg і перед відповіддю — 600 слів про історію яєць. Обсяг тексту сам по собі не є effort. 7. Real opinion Хороший контент не просто переказує факти. Він може: * порівнювати; * оцінювати докази; * пояснювати trade-offs; * робити висновок; * давати власну аргументовану рекомендацію. І тут є важливий момент для AI-контенту. Google прямо пише, що проблема не в самому використанні generative AI. Проблема виникає, коли AI використовується для масштабного створення сторінок без доданої цінності для користувача. У [Google Spam Policies](https://developers.google.com/search/docs/essentials/spam-policies) це описано як scaled content abuse: масове створення неоригінального контенту з little to no value, незалежно від того, створений він AI, людиною чи автоматизацією. Тому я б додав простий аудит до будь-якого content workflow. Відкрийте останні 5 статей і знайдіть у кожній хоча б один фрагмент, який не можна було б отримати простим промптом у ChatGPT на ту саму тему. Це може бути: * власний dataset; * результат тесту; * screenshot; * кейс клієнта; * quote експерта; * методологія; * first-hand experience; * власна аргументована позиція. Якщо такого фрагмента немає, проблема може бути не в keywords, entities, TF-IDF або довжині тексту. Проблема в тому, що сторінка не демонструє унікальної роботи. Головний висновок для SEO: можливо, замість питання Скільки слів має бути у статті? варто частіше ставити інше: Які докази реальної роботи та унікальної цінності Google може побачити на цій сторінці? Джерела: https://signal.zyppy.com/p/content-effort

Всього 2 дні до старту Boost360° SEO Edition 2.0 Хто ще не зареєструвався — приєднуйтеся, бо на вас чекають: доповіді та панельні дискусії від топових експертів, максимум практики та нові фанові формати (SEO News, SEO Hot Seat і Linkbuilding Bingo). Нагадуємо деталі: Коли: 16 вересня об 11:00 (за Києвом). Формат: онлайн. Подробиці та реєстрація за посиланням.

Глава Anthropic попереджає: через рік інтернет може захопити автономний рій ШІ-агентів Даріо Амодеї побоюється, що вже за 6–12 місяців автономні агенти почнуть об'єднуватися в постійну мережу та зламувати системи для підтримки своєї роботи без участі людини. Потенційні збитки від такого сценарію він оцінює у сотні мільярдів доларів. Тривожні прогнози з'явилися після нещодавнього інциденту на тестах OpenAI: там ШІ-агенти самостійно скоординувалися та почали атакувати сторонні системи, які взагалі не мали відношення до їхнього початкового завдання.

Сьогодні дуже постраждав будинок батьків моєї дружини. У будинок прилетіли уламки: пробило дах, вибило всі двері. Частина бетону впала зверху та пробила дах прямо над спальнею. На щастя, батьки живі. Але тепер будинок потрібно терміново відновлювати: ремонтувати дах, міняти двері та усувати інші пошкодження. Ми відкрили банку на збір коштів для ремонту, тому що сума відновлення буде значною і самостійно покрити всі витрати зараз дуже складно. Якщо у вас є можливість допомогти будь-якою сумою — будемо дуже вдячні. Навіть невеликий внесок зараз має велике значення. Також дуже допоможе поширення цього допису 🙏 Посилання на банку залишаю нижче. Дякую кожному, хто підтримає ❤️ https://send.monobank.ua/jar/574cEGUoCp

Чи створює OpenAI власний пошуковий індекс для ChatGPT? Нове дослідження Peec AI дає доволі сильні докази того, що OpenAI будує власну систему crawling → indexing → retrieval для ChatGPT. Важливе уточнення: це не означає, що ChatGPT вже повністю відмовився від Bing, Google чи інших зовнішніх джерел. Найімовірніше, зараз використовується гібридний search stack. Ось найцікавіші сигнали. 1. Внутрішній index проти SERP Під час аналізу server-side events ChatGPT Shopping команда Peec AI знайшла A/B-тест: prefer-index-over-serp-v3 Сама назва вже цікава: система буквально тестує, коли краще використовувати власний index, а коли — зовнішній SERP. Також дослідники побачили елементи класичного search pipeline: BM25 для lexical retrieval; сотні початкових кандидатів; ANN vector search; подальший reranking. Це вже більше схоже на власну пошукову інфраструктуру, ніж просто на виклик стороннього Search API. 2. OpenAI прямо наймає інженерів для indexing та retrieval У вакансіях OpenAI регулярно зустрічаються формулювання: serving → indexing → retrieval Команди працюють над: web-scale indexing; vector search; retrieval infrastructure; системами для величезних обсягів даних; власними database та indexing technologies. Окремо згадується інфраструктура на exabyte scale. Тобто власний search index — це вже не лише припущення SEO-спільноти. 3. Антимонопольні документи дають ще один сильний сигнал У документах справи проти Google згадується, що OpenAI хотіла отримати доступ до Google Search API, оскільки якість інших search providers не повністю задовольняла компанію. Google доступ не надав. Представники OpenAI також говорили про розвиток власного пошукового індексу, хоча визнавали, що повна незалежність від зовнішніх search providers — складне довгострокове завдання. 4. OpenAI вже має власного crawler Для ChatGPT Search використовується OAI-SearchBot. OpenAI прямо рекомендує не блокувати його в robots.txt, якщо ви хочете, щоб сторінки могли з’являтися в ChatGPT Search. І ось тут починається найцікавіше для SEO. Раніше можна було приблизно мислити так: Indexed in Google/Bing → potentially visible in ChatGPT Але якщо OpenAI розвиває власний index, ця залежність стає слабшою. У майбутньому нам, ймовірно, доведеться окремо контролювати: 1. доступність сайту для OAI-SearchBot; 2. crawl activity OpenAI у server logs; 3. швидкість потрапляння нових сторінок у ChatGPT; 4. visibility бренду та URL саме в ChatGPT; 5. структуру контенту для lexical + vector retrieval. Джерела: Peec AI — дослідження про власний search index ChatGPT U.S. DOJ — документи антимонопольної справи проти Google OpenAI Careers — вакансії Foundations Search / Search Infrastructure OpenAI Help — документація про OAI-SearchBot

SEO Rank Watch: як віддати постійне покращення SEO AI-агенту Цікавий підхід до автоматизації SEO: замість того щоб просити AI «оптимізувати сайт», йому задають замкнений цикл із вимірюванням, однією зміною та перевіркою результату через 7 днів. Умовно такий skill можна назвати SEO Rank Watch. Його мета проста: знайти запит, який реально можна підтягнути до Top 1 → зробити одну змістовну зміну → нічого не чіпати 7 днів → перевірити результат у GSC → повторити цикл. Дані при цьому зберігаються окремо: * watchwords.json — ключові слова, URL та пріоритети; * rank-history.json — append-only історія позицій; * improvement-log.json — що змінювали, коли і коли потрібно перевірити результат. Ключове тут — AI не дозволяється хаотично переписувати сайт. Для кожного запиту є статус: * active — можна оптимізувати; * observing — зміна вже внесена, 7 днів нічого не чіпаємо; * achieved — Top 1 досягнуто, далі тільки моніторинг. Як виглядає цикл: 1. AI отримує через Google Search Console API позиції, покази та кліки. 2. Перевіряє зміни, зроблені 7+ днів тому. 3. Обирає тільки один запит для роботи. 4. Спочатку аналізує search intent і Top 1–3 результатів. 5. Порівнює їх із нашою сторінкою та знаходить конкретний information gap. 6. Вносить мінімальну необхідну зміну. 7. Записує її в лог і ставить запит у observing. 8. Через 7 днів оцінює результат за новими даними GSC. Пріоритет, наприклад, можна задавати так: позиції 2–10 → позиції 11–20 з високими impressions → невдалі попередні експерименти → перспективні нові запити з GSC. При цьому агенту прямо заборонено: * збільшувати текст просто «для SEO»; * повторно оптимізувати запит під час observing; * самостійно ставити noindex; * робити великі структурні зміни без підтвердження; * скрапити Google SERP власними скриптами; * заявляти, що зміна спрацювала, доки цього не підтвердили дані. Мені особливо подобається принцип: «Не оптимізуй сторінку. Знайди, чого не вистачає користувачу порівняно з результатами, які Google уже вважає кращими». Тобто агент може змінити title, вступ, FAQ, внутрішнє посилання або додати реальні дані — але тільки якщо це закриває конкретну пошукову потребу. Фактично отримуємо нескінченний цикл: Measurement → Opportunity → Intent → One change → Cooldown → Measurement. З погляду SEO це набагато цікавіше за масову AI-генерацію контенту: AI стає не копірайтером, а агентом для безперервних контрольованих SEO-експериментів. Єдине, що я б додав до такої системи: порівняння 7 days vs previous 7 days, контроль значущості зміни impressions і врахування сезонності. Інакше агент може прийняти звичайне коливання середньої позиції за результат своєї оптимізації. Джерело: Google Search Console API — Search Analytics повертає для запитів clicks, impressions, CTR та середню position, тому саме GSC логічно використовувати як основне джерело вимірювання результатів. [Google Search Console API — Search Analytics]

🚀 Потрібні посилання, які дійсно працюють? 🚀 Ми спеціалізуємось на природному лінкбілдингу, який люблять пошукові системи та який приносить реальний результат! 💪 📌 ЩО МИ ПРОПОНУЄМО: ✅ Аутріч — найприродніші білі посилання, що підійдуть під будь-який проєкт. ✅ Краудмаркетинг — живі згадки на форумах, сайтах з відгуками та тематичних майданчиках. ✅ Reddit-маркетинг — природні згадки бренду та посилання в тематичних сабреддітах із трастових акаунтів. ✅ Quora-маркетинг — експертні відповіді зі згадкою вашого бренду або посиланням там, де це доречно. ✅ WEB 2.0 — розміщення на авторитетних блог-платформах із високим рівнем довіри. ✅ Сабміти та профілі — швидкий старт індексації та посилення посилального профілю. 🌎 Географія роботи: США 🇺🇸 | Велика Британія 🇬🇧 | Німеччина 🇩🇪 | Іспанія 🇪🇸 | Канада 🇨🇦 | Італія 🇮🇹 | Польща 🇵🇱 | та інші країни 🌍 ⚡️ Наші переваги: ✔️ Тільки білі методи просування ✔️ Персональна стратегія під кожен проєкт ✔️ Регулярні звіти про виконану роботу ✔️ Перше замовлення зі знижкою 10% 💬 Зв’яжіться з нами: 👉 @canamg Розглянемо ваш проєкт і підберемо найкраще рішення ⚡️