Sneex SEO 🇺🇦

Link Building: автоматизуйте рутину, а не стратегію Велика частина того, що ми називаємо link building, насправді не є стратегією. SEO-фахівець витрачає години на: - пошук потенційних сайтів; - перевірку тематичної релевантності; - збір DR, трафіку та інших метрик; - пошук email контактів; - підготовку outreach; - follow-ups; - ведення таблиць і статусів. Усе це потрібно робити. Але більшість цих процесів — операційна робота, яку можна автоматизувати. Справжня link building strategy починається на іншому рівні. Що варто залишити людині: 1. Вибір сторінок, які потрібно посилювати Не кожній URL потрібні backlinks. Спочатку потрібно визначити сторінки, де посилання реально можуть вплинути на ranking, topical authority або бізнес-результат. 2. Визначення правильних донорів DR 70 сам по собі нічого не гарантує. Важливі тематика сайту, якість його сторінок, реальний organic traffic, outbound links, тип аудиторії та контекст майбутнього посилання. 3. Вибір linkable angle Чому взагалі хтось має поставити посилання? Це можуть бути: - власне дослідження; - статистика; - безкоштовний інструмент; - експертний коментар; - актуальний dataset; - унікальний кейс; - сторінка, яка реально доповнює матеріал донора. 4. Пріоритезація Автоматизація може знайти 5 000 потенційних сайтів. Стратегія має визначити, які 100 із них дійсно варті часу. А ось усе інше можна віддати автоматизації. Pipeline може виглядати так: Prospecting → Relevance Check → SEO Metrics → Contact Discovery → Outreach → Follow-up → Status Tracking AI та API можуть автоматично: - знаходити потенційних донорів; - класифікувати їх за тематикою; - підтягувати SEO-метрики; - знаходити контакти; - генерувати персоналізовані outreach drafts; - ставити follow-ups; - оновлювати статус кампанії; - прибирати дублікати та слабкі prospects. Тому можно накодити такий інструмент, що буде все трекати та розсилати самостійно.

Здоров колеги, це Саша Белевець Шукаю собі в команду майбутнього Head of PBN - прямий репортинг мені, нуль бюрократії та мікроменеджменту. Компанія 10+ років на ринку, портфель 3000+ доменів, готова інфраструктура - база активів накопичена, купа автоматизацій, лінк-прогони вміємо робити автоматично і масовано. Працюємо з норм бюджетами і топовими аукціонами, тут обмежувати не буду. Знаєш кого порекомендувати - пиши і отримай $1500 💸 за успішний найм! дякую за шейр

Компанія Anthropic оголосила, що вбудовуватиме водяні знаки в текст та файли, згенеровані майбутніми моделями Claude, які випускатимуться в Євросоюзі. Крок пояснюють необхідністю дотримання вимог щодо прозорості контенту, передбачених європейським Актом про штучний інтелект (AI Act). Як зазначено в довідковому документі компанії, опублікованому в понеділок, згенерований текст міститиме вбудовані водяні знаки, а згенеровані файли — цифрово підписані метадані про походження. Маркування працюватиме всюди, де використовується Claude, пише The Register. Моделі Claude, запущені в ЄС 2 серпня 2026 року або пізніше, підтримуватимуть машинозчитуване маркування вже з моменту релізу. Що стосується вже випущених моделей, компанія працює над додаванням маркування протягом перехідного періоду, передбаченого європейським законодавством. Важливий нюанс — географія застосування. Маркування поширюватиметься на виведення підтримуваних моделей Claude через Claude Platform (API), Claude, Claude Cowork і Claude Tag, і діятиме всюди, де пропонується Claude, — у всьому світі. Тобто обмежувати нововведення лише європейськими користувачами компанія не планує. Як працює маркування тексту За описом Anthropic, коли підтримувана модель Claude генерує текст, вона вплітає непомітний водяний знак безпосередньо в самі речення. Користувач його не побачить, а сенс, якість чи читабельність відповіді не зміняться. Оскільки знак є частиною тексту, він подорожуватиме разом із текстом при копіюванні в інші місця і може зберігатися навіть після певного редагування. Маркування застосовується на рівні моделі — тобто присутнє незалежно від того, через який продукт чи інтерфейс отримано текст. Для файлів, які створює Claude, компанія покладається на цифрово підписані метадані про походження за стандартом C2PA (Coalition for Content Provenance and Authenticity). Охоплення поширюється й на сторонніх постачальників, які пропонують доступ до моделей Anthropic, — зокрема AWS, Google Cloud та Microsoft Foundry. Детальну документацію про те, як саме користувачі та треті сторони зможуть виявляти ці позначки (що вимагає законодавство ЄС), компанія обіцяє опублікувати пізніше. Наскільки це надійно Технічні деталі поки що відсутні, і залишається незрозумілим, як Anthropic захищатиме водяні знаки від видалення. Дослідники вже неодноразово демонстрували, що подібні системи маркування зображень можна обійти. Показово, що самі формулювання Anthropic про незмінність «сенсу» тексту фактично виключають використання специфічного підбору слів чи побудови речень як маркера походження — техніку, яку, за повідомленнями, застосовувала Apple для виявлення витоків від співробітників. Що стосується файлових позначок за стандартом C2PA — для цього формату вже існують відкриті інструменти видалення метаданих. Показово й те, що сама Anthropic обережно оцінює ефективність власної схеми: компанія прямо визнає, що виявлений водяний знак не є остаточним доказом того, що контент створив саме Claude, а відсутність знаку не гарантує, що штучний інтелект взагалі не брав участі у створенні тексту.

Microsoft Clarity тепер розділяє AI-запити на branded і non-branded Microsoft додав у AI Citations dashboard нову функцію — сегментацію branded та non-branded grounding queries. Це важливе оновлення для AEO/GEO, тому що тепер можна краще зрозуміти, чому саме AI-система знаходить і цитує ваш сайт: тому що вже шукає ваш бренд чи тому що знаходить його за загальним тематичним запитом. Наприклад: Ahrefs backlink checker — branded query. best backlink analysis tools — non-branded query. У першому випадку бренд уже присутній у пошуковій логіці AI. У другому — AI сам знаходить бренд серед потенційних джерел або рішень. І саме другий сценарій особливо цікавий для SEO. Що нового з’явилося в Microsoft Clarity: 1. Branded labels для grounding queries Clarity автоматично позначає запити, які містять бренд. Тепер у списку можна швидко побачити, де AI шукав інформацію безпосередньо про вас. 2. Branded vs non-branded у Share of Authority Share of Authority тепер можна аналізувати окремо для branded і non-branded запитів. Це допомагає відповісти на два різні питання: - наскільки добре AI знаходить нас, коли вже знає бренд; - наскільки часто AI знаходить нас під час загального category discovery. 3. Окремі фільтри У dashboard можна залишити тільки branded або тільки non-branded queries та окремо аналізувати citations, сторінки й теми. Чому це важливо Висока AI visibility сама по собі ще мало про що говорить. Уявімо, що 80% ваших citations отримані за запитами, які вже містять назву бренду. Це хороший показник brand authority, але він не обов’язково означає, що AI рекомендує вас новій аудиторії. Набагато цікавіше дивитися на non-branded queries: best CRM for ecommerce SEO tools for large websites alternatives to Salesforce Якщо ваш бренд починає з’являтися саме тут, це вже сигнал category visibility та discovery. Джерело: - Microsoft Clarity: Branded vs Non-Branded AI Queries — https://clarity.microsoft.com/blog/branded-non-branded-queries/

Entity SEO — це не лише Schema.org Більшість рекомендацій щодо Entity SEO зводяться до одного: додайте Organization, Person, sameAs — і Google нібито автоматично зрозуміє бренд. Насправді structured data — лише один зі способів передати інформацію. Google також аналізує текст, таблиці, структуру сторінок, зовнішні джерела та вже наявні бази знань. Тому Schema.org краще сприймати не як доказ, а як явну декларацію про сутність. Почніть із чітких зв’язків між сутностями Інформацію можна представити у формі: Subject → Predicate → Object Наприклад: Компанія X → розробляє → SEO-платформу Y SEO-платформа Y → призначена для → технічного аудиту сайтів Коли бренд і ключова тема просто згадуються на одній сторінці, це co-occurrence. Але коли між ними явно описаний зв’язок, пошуковій системі простіше зрозуміти, як саме ці сутності пов’язані. Тому замість загальних формулювань: Ми працюємо із SEO та автоматизацією краще писати конкретно: Компанія X розробляє інструменти для автоматизації технічного SEO та аналізу сайтів. Але власного сайту недостатньо На своєму домені компанія може заявити практично що завгодно. Structured data, сторінка About Us і профілі авторів допомагають Google інтерпретувати інформацію, але не роблять усі твердження автоматично підтвердженими. Сильніший сигнал виникає, коли ті самі факти узгоджено з’являються в незалежних джерелах: - галузевих медіа; - профільних каталогах; - інтерв’ю та подкастах; - конференційних профілях; - авторитетних review-платформах; - офіційних реєстрах; - сторінках партнерів. Водночас принцип не працює як проста формула: 30 однакових згадок = факт. Google може враховувати не лише кількість джерел, а й їхню незалежність, надійність та узгодженість із уже відомою інформацією. Consistency важливіша за хаотичний обсяг Проблема виникає, коли різні джерела описують бренд по-різному: - на сайті — SEO-платформа; - у каталозі — digital agency; - у LinkedIn — software company; - у медіа — маркетинговий консультант. У результаті пошуковій системі складніше зрозуміти, що це за сутність, до якої категорії вона належить і з якими темами її потрібно пов’язувати. Тому варто стандартизувати: 1. Назву бренду. 2. Основну категорію. 3. Короткий опис. 4. Засновників і ключових осіб. 5. Продукти та послуги. 6. Географію роботи. 7. Офіційні профілі й ідентифікатори. Не забувайте про disambiguation Однакова назва може належати різним сутностям. Google використовує контекст, пов’язані сутності, атрибути та зовнішні джерела, щоб відрізнити компанію від людини, продукту або іншого бренду. Джерела: - Google Research: Knowledge Vault — https://research.google/pubs/knowledge-vault-a-web-scale-approach-to-probabilistic-knowledge-fusion/ - Google Search Central: Organization structured data — https://developers.google.com/search/docs/appearance/structured-data/organization - Google: Introducing the Knowledge Graph — https://blog.google/products-and-platforms/products/search/introducing-knowledge-graph-things-not/ - 90% OF "ENTITY SEO" ADVICE ON THIS APP IS JUST SCHEMA MARKUP WITH EXTRA STEPS 🙄 — https://x.com/charles_seo/status/2083067382826733711?s=46

🤖 Оновлення в INSERT.LINK: Backlink API + MCP для автоматизації. В INSERT.LINK з’явилися безкоштовні інструменти для роботи з беклінками, серед яких є рішення, аналогів яким наразі практично немає на ринку. 👇🏻 Наприклад: • Anchor Text Lookup — допомагає знаходити сайти за конкретними анкорами • Backlink Lookup — показує беклінки конкурентів на основі власної бази INSERT.LINK Також доступні Domain Lookup, Backlink Gap та Bulk Donor Check. 🔥 Тепер усі ці інструменти можна використовувати через ChatGPT або Claude. Достатньо підключити INSERT.LINK через MCP і попросити AI: Проаналізуй беклінки трьох моїх конкурентів, знайди сайти, які посилаються хоча б на двох із них, але не посилаються на мене. або Знайди сторінки про email marketing, CRM та automation, де можна органічно розмістити посилання на наш продукт. AI сам використає дані INSERT.LINK і поверне готовий результат. Також доступний Marketplace API для пошуку сайтів, створення замовлень та автоматизації лінкбілдингу. 👉 https://insert.link

Автоматизація E-E-A-T з Claude: від інструкції для асесорів до AI-скіла 4 серпня команда Collaborator запрошує на новий вебінар. Спікер — Володимир Лаврик, Senior SEO Specialist у Promodo Про що піде мова: • чому E-E-A-T — один із найважчих критеріїв для автоматизації • сигнали vs судження — де AI ще може помилятися • як Claude відтворює логіку асесора під час аудиту сторінки • як захиститись від галюцинацій моделі в результатах аудиту • як масштабувати підхід на різні ніші 👉 Реєстрація за посиланням 4 серпня, початок о 16:00

Bing Webmaster Tools закриває застарілі API: що потрібно перевірити до 31 серпня Microsoft припиняє підтримку застарілих SOAP і POX/HTTP API у Bing Webmaster Tools. Кінцевий термін міграції — 31 серпня 2026 року. Після цієї дати запити до старих endpoint більше не оброблятимуться. Новина важлива для SEO-команд і розробників, які використовують API Bing Webmaster Tools для автоматизації: - надсилання та перевірки sitemap; - отримання даних про пошукову видимість; - роботи з URL; - моніторингу сканування та індексації; - підключення внутрішніх SEO-дашбордів; - регулярного експорту даних. Щоб уникнути зупинки таких процесів, потрібно перейти на JSON/HTTP (REST) API. Що залишиться без змін Міграція не означає втрату функціональності: - усі доступні API-методи залишаться у версії JSON/HTTP; - повторно створювати API-ключ не потрібно; - квоти та rate limits не змінюються; - дозволи акаунта залишаються чинними; - REST API продовжує підтримуватися та розвиватися Microsoft. Основна зміна стосується формату запитів і endpoint, через які працює інтеграція. Що потрібно зробити 1. Знайти всі скрипти та сервіси, які використовують Bing Webmaster Tools API. 2. Перевірити, чи є в коді звернення до SOAP або POX/HTTP. 3. Перевести запити на JSON/HTTP (REST). 4. Оновити парсинг відповідей, обробку помилок і логування. 5. Перевірити інтеграцію на тестовому середовищі. 6. Порівняти дані старого й нового API. 7. Перенести production-процеси до 31 серпня 2026 року. 8. Після міграції видалити застарілі виклики та бібліотеки. Особливу увагу варто приділити старим внутрішнім інструментам. API може використовуватися у скриптах, які працюють роками без активної підтримки, тому команда може навіть не пам’ятати про залежність від SOAP/POX. API-ключі, квоти й функціональність зберігаються, але після 31 серпня старі endpoint перестануть відповідати. Тому міграцію краще виконати заздалегідь, а не чекати, поки автоматизація зламається у production. Джерела: - Bing Webmaster Tools: SOAP/POX API Deprecation — https://www.bing.com/webmasters/help/soap-pox-api-deprecation-s0appox01 - Bing Webmaster Tools API — https://www.bing.com/webmasters/help/webmaster-api-28c5e9c4

Fan-out queries: як знайти приховані запити AI та використати їх у SEO Користувач ставить ChatGPT одне запитання, але AI може виконати декілька додаткових пошуків, перш ніж сформувати відповідь. Ці приховані запити називаються fan-out queries. Саме вони визначають, які сторінки AI знайде, проаналізує та потенційно додасть до списку джерел. Тому для AEO недостатньо оптимізувати контент лише під початковий prompt користувача. DataForSEO проаналізував 100 000 prompts і 100 249 fan-out queries та виявив кілька важливих закономірностей. 1. Майже половина prompts запускає додатковий пошук У дослідженні 47,5% prompts спричинили генерацію fan-out queries. Для популярних AI-запитів цей показник зростав приблизно до 51–55%. Це означає, що значна частина AI-відповідей формується не лише на основі початкового формулювання, а через додатковий retrieval із пошукових систем. 2. Fan-out queries зазвичай довші та конкретніші Більшість початкових prompts мали довжину 31–60 символів, тоді як fan-out queries частіше потрапляли в діапазон 61–90 символів. AI додає уточнення: - географію; - сценарій використання; - best, reviews, comparison; - тип продукту; - цільову аудиторію; - актуальний рік; - конкретний pain point. Тому long-tail запити залишаються важливими навіть у генеративному пошуку. 3. Title і description впливають на retrieval Fan-out queries мали приблизно: - 53% збігу зі словами в title пошукових результатів; - 59% збігу з їхніми description; - 54% збігу з початковим prompt. Це не означає, що достатньо переписати метатеги. Але зрозумілі title, headings і descriptions допомагають AI знайти сторінку на проміжному етапі пошуку. При цьому потрапити в retrieved results ще не означає отримати citation. Модель окремо оцінює, чи підходить сторінка як доказ для фінальної відповіді. Як перетворити fan-out data на SEO-стратегію Кейс Kojable показує, що просто зібрати тисячі прихованих запитів недостатньо. Потрібен контрольований pipeline: 1. Зібрати fan-out queries для важливих prompts. 2. Зберегти контекст: початкове питання, модель, ринок, відповідь, retrieved pages і citations. 3. Додати AI Search Volume, класичний search volume, difficulty, intent і тренди. 4. Відфільтрувати запити, які не відповідають продукту, аудиторії чи ринку компанії. 5. Не об’єднувати механічно запити з різним intent. 6. Побудувати topical clusters і визначити потенційні pillar pages. 7. Перед створенням контенту провести ручну перевірку. Особливо важливий висновок Kojable: не кожен fan-out query повинен ставати окремою сторінкою. Запит може бути релевантним початковому prompt, але не відповідати бізнесу. Високий AI Search Volume також не доводить, що компанія має експертизу або право претендувати на тему. Тому fan-out queries варто використовувати не як автоматичне технічне завдання для генерації статей, а як retrieval evidence: підказку, які теми, entities, формулювання та джерела AI перевіряє перед відповіддю. Головний висновок: fan-out analysis розширює класичний keyword research. SEO-фахівець бачить не лише те, що запитує людина, а й те, що додатково шукає AI. Це допомагає знаходити нові content gaps, покращувати topical coverage, точніше формувати структуру сторінок і пріоритезувати теми з урахуванням реального AI-попиту та потенціалу цитування. Джерела: - DataForSEO: Fan-Out Queries — https://dataforseo.com/blog/fan-out-queries-the-hidden-layer-of-ai-search-you-need-to-optimize-for - Kojable: DataForSEO Fan-Out Query Integration — https://kojable.com/resources/case-studies/dataforseo-fan-out-query-integration.html

#мем

#mem

Claude Code для SEO: що поставити, щоб він реально працював, а не просто балакав Розібрався, які скіли та інтеграції перетворюють Claude на SEO-джуна, який сам тягне дані й робить аудити. Усе ділиться на три рівні — їх часто плутають. 1️⃣ Готові пакети скілів ▪️ claude-seo — топ, і повністю безкоштовний. 25 скілів + 18 агентів: технічка, E-E-A-T, генерація Schema, GEO/AEO (оптимізація під AI-видачу), беклінки, локалка + Google Business Profile, семантична кластеризація, e-commerce, hreflang, звіти в PDF/Excel. Чіпляється до DataForSEO, Ahrefs, Firecrawl. → [github.com/AgricIDaniel/claude-seo](https://github.com/AgricIDaniel/claude-seo) ▪️ SE Ranking Skills — 7 воркфлоу (контент-бриф, backlink gap, AI Search Visibility, розбір реклами конкурентів) поверх їхнього MCP на 180+ інструментів. ▪️ Вбудовані (уже всередині Claude, ставити не треба): xlsx — семантика й кластеризація вивантажень, docx — звіти, pptx — презентації клієнтам, dataviz — графіки просідань. 2️⃣ MCP-сервери = доступ до живих даних Саме вони перетворюють «Claude пише тексти» на «Claude сам тягне цифри й рахує»: Google Search Console — кліки, покази, позиції, індексація. Безкоштовно, починати з нього. DataForSEO — SERP, ключі, беклінки, on-page. Дешево, оплата за запит. Ahrefs (official) — KD, посилання, органіка конкурентів. Від платного плану. Firecrawl — краулить сайт у markdown під аудит і розбір конкурентів. Плюс Google Analytics (GA4) та Playwright (рендер JS + скриншоти для техаудиту). Serpstat — офіційний MCP з лютого 2026, 63 інструменти: ключі, конкуренти, gap-аналіз, беклінки, аудит сайту/сторінок, трекінг позицій, звіти клієнтам. Дві версії: HTTP (OAuth через Connectors) або локальний STDIO (токен у .env — зручно для агентств, дані клієнтів лишаються на машині). 3️⃣ Власні скіли Усе, що робиш руками по 10 разів, загортається у скіл через skill-creator: — кластеризація ключів за своєю методикою — генерація мета-тегів (Title/Description/H1) пачкою → xlsx — технічний аудит за чеклістом З чого почати: 1️⃣ Ставиш claude-seo (безкоштовно, підключаєш свій DataForSEO) 2️⃣ Чіпляєш GSC MCP 3️⃣ Загортаєш свою кластеризацію в особистий скіл Години рутини на тиждень — у пару команд. 🤝

Google Search Console тепер показує ефективність контенту з Instagram, TikTok, X і YouTube Google глобально запустив Platform properties у Search Console. Тепер SEO-фахівці, контент-менеджери та автори можуть відстежувати, як публікації із соціальних і відеоплатформ працюють у Google Search, Discover і Google News. Функція підтримує чотири платформи: - Instagram; - TikTok; - X; - YouTube. Кожен профіль або канал додається в Search Console як окрема property. Які дані доступні У звітах можна побачити: - кліки та покази; - середній CTR; - середню позицію; - пошукові запити, через які знаходять контент; - найефективніші пости та відео; - країни й пристрої аудиторії; - динаміку за окремими датами; - результати в Search, Discover і Google News. У Performance report можна фільтрувати дані за запитами, сторінками, країнами, пристроями та датами, а також експортувати їх для подальшого аналізу. Insights report показує загальні тренди, найкращий контент і групи пошукових запитів, які зростають або втрачають популярність. Як додати профіль 1. Відкрити Google Search Console. 2. Натиснути Add property. 3. Вибрати Instagram, TikTok, X або YouTube. 4. Авторизуватися через відповідний акаунт. 5. Дочекатися появи даних у звітах. Якщо у вас кілька профілів або каналів, кожен із них потрібно додати окремо. Як використовувати дані для SEO та контенту 1. Знаходити теми, які отримують попит у Google Аналізуйте запити, що приводять користувачів до конкретних відео, Reels або постів. Їх можна використовувати для нових матеріалів, заголовків і описів. 2. Відстежувати тренди протягом 24 годин Новий фільтр допомагає швидко побачити, чи почала публікація набирати покази, та вчасно поширити тему на інших платформах. 3. Порівнювати формати У YouTube можна порівнювати /watch і /shorts/, а в Instagram — звичайні пости /p/ та Reels /reels/. 4. Порівнювати платформи Якщо довге відео добре працює в YouTube, але коротка версія не отримує пошукового попиту в TikTok, можна змінити подачу, заголовок або структуру ролика. 5. Продовжувати життєвий цикл контенту Якщо старий пост або відео знову починає отримувати покази, його можна оновити, закріпити, поширити на інших платформах або створити продовження. Важливий нюанс: Platform properties показують ефективність контенту саме в екосистемі Google. Вони не замінюють внутрішню аналітику Instagram, TikTok, X або YouTube і не показують усі перегляди всередині цих платформ. Джерела: - Google Search Central: Platform properties — https://developers.google.com/search/blog/2026/07/search-console-social-video-platforms - Google: Analyze Social and Video Content in Search Console — https://developers.google.com/search/docs/monitor-debug/analyze-social-video-content - Search Console Help: Platform properties — https://support.google.com/webmasters/answer/17148418

Якою мовою AI цитує джерела для локальних запитів Коли користувач ставить запитання іспанською або французькою, AI-асистент відповідає тією самою мовою. Але які джерела стоять за відповіддю: локальні чи англомовні? Aleyda Solís проаналізувала 43 513 зважених випадків цитування в ChatGPT, Gemini та Google AI Mode. Дослідження охопило три бренди з різних ніш: - marketing SaaS; - платежі; - gaming. Аналіз проводився для Іспанії, Аргентини, Франції та США. Що показали результати 1. Gemini найчастіше цитує джерела мовою локального ринку У неангломовних країнах частка цитувань тією самою мовою, якою було сформульовано запит, становила приблизно: - Gemini — 77%; - ChatGPT — 52%; - AI Mode — 53%. Отже, твердження, що AI майже завжди використовує англомовні джерела, вже не можна вважати універсальним. 2. Джерела переважно діляться на локальні та англомовні Розподіл виявився майже бінарним. AI-системи цитували джерела: - мовою відповідного ринку; - англійською мовою. Джерела іншими мовами практично не зустрічалися. Наприклад, для запиту французькою AI переважно вибирав французькі або англомовні сторінки, а не матеріали іспанською, німецькою чи іншими мовами. 3. Локальна інформаційна екосистема може впливати на цитування Бренди, які мали кращу локалізацію цитувань у ChatGPT, також були представлені у більш розвиненій екосистемі локальних джерел: - галузевих медіа; - тематичних спільнот; - незалежних оглядів; - локальних каталогів; - експертних публікацій. Однак цей патерн не був однаковим для всіх платформ. Тому це важливий сигнал, але поки не доказ прямого причинно-наслідкового зв’язку. Що це означає для міжнародного SEO 1. Не обмежувати локалізацію простим перекладом основних сторінок. 2. Створювати окремий контент під потреби та термінологію кожного ринку. 3. Розвивати згадки бренду в локальних медіа, каталогах і спільнотах. 4. Перевіряти hreflang, canonical та мовно-регіональну структуру сайту. 5. Аналізувати AI visibility окремо для кожної платформи, країни та мови. 6. Розділяти цитування власного сайту й зовнішніх джерел про бренд. Не варто об’єднувати всі дані в один глобальний показник. Середня AI visibility може виглядати добре, але приховувати слабку присутність у конкретній країні або мовній версії. Головний висновок: локалізація залишається важливою не лише для класичного пошуку, а й для AI-відповідей. Щоб бренд цитувався локальною мовою, потрібен не просто переклад сайту, а повноцінна інформаційна присутність на ринку: якісний локальний контент, правильні технічні сигнали та згадки в авторитетних регіональних джерелах. Джерело: - Aleyda Solís: дослідження локалізації AI-цитувань — https://www.linkedin.com/posts/aleyda_seofomo-activity-7487575973077385216-kY3h

🔥 Потрібні якісні PBN-посилання для вашого проєкту? Пропонуємо розміщення у власній мережі сайтів під бурж. Працюємо з різними нішами та GEO, що дозволяє підбирати майданчики під конкретні задачі та масштабувати посилальні кампанії. ✔️ Власна мережа PBN. ✔️ Швидке розміщення. ✔️ Природна інтеграція контенту. ✔️ Різні тематики та GEO. ✔️ Масштабування під великі кампанії. ✔️ Повний контроль над анкорами та цільовими сторінками. ✔️ Розміщення на головній сторінці домену. Посилання розміщуються на 12 місяців із можливістю продовження зі знижкою 30%. General — 5 посилань — $150 — 10 посилань — $250 — 20 посилань — $440 — 30 посилань — $600 — Від 50 посилань — індивідуальний розрахунок. Gambling / Betting — 5 посилань — $210 — 10 посилань — $360 — 20 посилань — $640 — 30 посилань — $870 — Від 50 посилань — індивідуальний розрахунок. Dating / OnlyFans — 5 посилань — $200 — 10 посилань — $320 — Від 50 посилань — індивідуальний розрахунок. Crypto / Forex / Trading — 5 посилань — $250 — 10 посилань — $450 — 15 посилань — $600 *** Бажаєте отримати розрахунок під свій проєкт або замовити розміщення? Напишіть Валентині — вона допоможе підібрати відповідний пакет та відповість на всі ваші запитання. 🔗 Telegram: @sales_pbn_link

Google не карає контент лише за використання AI: дослідження Ahrefs Багато компаній досі бояться публікувати AI-generated content, оскільки очікують автоматичних санкцій від Google. Але нове дослідження Ahrefs показує іншу картину: Google, ймовірно, оцінює якість сторінки, а не сам факт використання AI. Ahrefs проаналізував понад 331 тисячу сторінок, щоб перевірити, як контент із різною ймовірною часткою AI-тексту індексується, ранжується та отримує покази. Що показало дослідження: 1. Повністю AI-generated сторінки можуть займати топові позиції Серед сторінок на позиціях 1–3: - 5,3% були визначені як повністю створені AI; - 9% містили щонайменше 80% AI-контенту. Це означає, що Google не має очевидної автоматичної заборони, яка не дозволяє AI-generated сторінкам потрапляти в топ. Водночас більшість топових результатів усе ще переважно написані людьми: сторінки з часткою AI-контенту нижче 50% займають 82,2% позицій у топ-3. 2. AI-контент присутній на кожній позиції топ-10 Частка сторінок із ≥80% AI-контенту становила: - 8,4% на першій позиції; - 11,7% на десятій позиції. Тобто heavily AI-generated content трохи частіше зустрічається нижче в SERP, але він усе одно присутній навіть на першій позиції. 3. Висока частка AI корелює з нижчою індексацією Рівень індексації становив: - 49,28% для сторінок із низькою часткою AI; - 43,38% для помірної частки; - 40,72% для високої частки; - 40,35% для дуже високої частки AI. Різниця є, але вона не виглядає як повне блокування. Навіть серед сторінок із дуже високою ймовірністю AI-контенту приблизно 40% потрапили до індексу. 4. Сторінки з меншою часткою AI отримували більше показів Low та moderate AI-content pages отримували приблизно у 2–3 рази більше органічних показів, ніж сторінки з високою або дуже високою часткою AI. Проте Ahrefs не побачив різкого падіння показів через кілька місяців. Performance heavily AI-generated сторінок залишався відносно стабільним протягом досліджуваного періоду. Це не доводить, що AI не впливає на результати. Сайти, які масово генерують контент, можуть бути новішими, менш авторитетними або публікувати слабші матеріали. Тому причиною нижчої ефективності може бути саме якість, а не технологія створення тексту. Джерело: - Ahrefs: Google Doesn’t Punish AI Content; It Punishes Bad Content — https://ahrefs.com/blog/google-doesnt-punish-ai-content/

Google оновив документацію про crawl budget: що змінилося Google суттєво переписав документацію про crawl budget і розкрив більше деталей про те, як система визначає інтенсивність сканування сайту. Документ актуальний насамперед для великих ресурсів: - сайтів із понад 1 млн сторінок, які регулярно оновлюються; - сайтів із понад 10 000 сторінок і щоденними змінами; - проєктів із великою кількістю URL у статусі Discovered — currently not indexed. Для невеликих сайтів, сторінки яких Google сканує невдовзі після публікації, окрема оптимізація crawl budget зазвичай не потрібна. 1. Google починає з консервативного ліміту Google прямо зазначив, що кожен сайт спочатку отримує однаковий консервативний crawl capacity limit. Якщо попит на сканування зростає, а сервер стабільно витримує навантаження, Google може поступово збільшувати цей ліміт. Якщо сайт відповідає повільно, повертає 5xx, 429 або має нестабільний Time to First Byte, інтенсивність сканування може знижуватися. 2. Crawl budget складається з двох частин Google розділяє його на: - crawl capacity limit — скільки сайт технічно може бути просканований без перевантаження сервера; - crawl demand — скільки URL Google хоче просканувати. Для Googlebot попит залежить від: - розміру сайту; - частоти оновлення; - якості сторінок; - релевантності; - популярності URL; - застарілості контенту. Навіть якщо сервер дозволяє сканувати більше сторінок, Google не обов’язково це робитиме, якщо не бачить достатнього попиту. 3. Crawl capacity спільна для різних краулерів Google Різні краулери мають власний попит, але використовують спільний ліміт потужності для конкретного hostname. Це означає, що висока активність одного краулера, наприклад Googlebot-Image, AdsBot або Google Shopping, потенційно залишає менше доступної потужності для інших. Для великих сайтів важливо аналізувати в логах не лише звичайний Googlebot, а всю екосистему краулерів Google. 4. Якість контенту впливає на crawl demand Google окремо зазначив, що для Search враховуються: - популярність; - загальна цінність для користувача; - унікальність контенту; - здатність сервера стабільно віддавати сторінки. Тому crawl budget не можна збільшити лише технічними налаштуваннями. Якщо сайт містить багато дублів, параметричних URL, слабких сторінок або непотрібних фільтрів, Google може витрачати ресурси неефективно й не бачити причин активніше сканувати важливі URL. Що робити SEO-фахівцю: 1. Скоротити кількість дублів і непотрібних URL. 2. Перевірити faceted navigation, параметри та нескінченні crawl spaces. 3. Повернути 404 або 410 для остаточно видалених сторінок. 4. Актуалізувати XML Sitemap і коректно використовувати <lastmod>. 5. Прибрати довгі redirect chains. 6. Покращити швидкість відповіді сервера. 7. Налаштувати підтримку 304 Not Modified. 8. Аналізувати краулерів Google через server або CDN logs. 9. Покращувати унікальність і реальну цінність сторінок. Головний висновок: crawl budget залежить не тільки від потужності сервера. Google враховує технічний стан сайту, структуру URL, якість контенту, частоту оновлень і реальний попит на повторне сканування. Тому найкраща оптимізація crawl budget — не спроба змусити Googlebot ходити частіше, а створення сайту, де Google не витрачає ресурси на непотрібні URL і має причини регулярно повертатися до важливих сторінок. Джерела: - Google: Optimize your crawl budget — https://developers.google.com/crawling/docs/crawl-budget - Google: What crawl budget means for Googlebot — https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot

Це скрін не з конкурсу Місс і Містер Всесвіт. Набагато краще! Разом з @alexxxeich проводимо закритий офлайн-мітап в Києві - Poshuk meetup - https://poshukmeetup.com/ 🗓 8 серпня, 13:00 📍 Київ, офлайн (точну локацію надсилаємо після реєстрації) 💸 900 грн Формат зустрічі побудований на community sharing. Головні спікери починають, а далі йде спільне обговорення із залом. Кожен учасник може поділитися своїми кейсами та поставити питання. Або може цього не робити, якщо не хоче, а прийшов суто послухати. В програмі дві дискусії по півтори години: 1️⃣ Видимість в AI-пошуку: що реально працює 2️⃣ Кадри: де брати сеньйорів Спікери: 🟢 Олександр Белевець 🟢 Анастасія Красюкова 🟢 Вадим Мірошниченко 🟢 Артем Козачук 🟢 Марко Федоренко 🟢 Вікторія Сауліт-Миколайчук Модератором дискусій буде Олексій Шостак - @alexxxeich - CEO Swift Punk . Після офіційної частини буде піца та вільне спілкування. Роздаємо пиріжки. Реєстрація на сайті: https://poshukmeetup.com/