🌐 Google: при переїзді домену додавай у Change of Address ВСІ варіанти
Google оновив гайд по міграції сайтів і додав важливе уточнення для тих, хто переїжджає з одного домену на інший.
Тепер при зміні домену потрібно подавати запити в інструменті Change of Address для всіх піддоменів і варіантів старого домену — і www, і non-www — навіть якщо ти ними не користуєшся.
📌 Як це виглядає на практиці:
Переїжджаєш з example.com на new-example.net? Подавай Change of Address окремо для:
🔹 example.com
🔹 www.example.com
🔹 en.example.com та інших піддоменів
⚠️ І головне — усі ці варіанти спершу мають бути верифіковані в Search Console.
💡 Чому це важливо:
Google прямо сказав: міграція працює найкраще, коли коректно переносяться всі варіанти сайту. Логіка проста — якщо забути про якийсь варіант, патерни можуть повести Google на «забутий» піддомен і зламати перенесення позицій.
Google оновив гайд по міграції сайтів і додав важливе уточнення для тих, хто переїжджає з одного домену на інший.
Тепер при зміні домену потрібно подавати запити в інструменті Change of Address для всіх піддоменів і варіантів старого домену — і www, і non-www — навіть якщо ти ними не користуєшся.
📌 Як це виглядає на практиці:
Переїжджаєш з example.com на new-example.net? Подавай Change of Address окремо для:
🔹 example.com
🔹 www.example.com
🔹 en.example.com та інших піддоменів
⚠️ І головне — усі ці варіанти спершу мають бути верифіковані в Search Console.
💡 Чому це важливо:
Google прямо сказав: міграція працює найкраще, коли коректно переносяться всі варіанти сайту. Логіка проста — якщо забути про якийсь варіант, патерни можуть повести Google на «забутий» піддомен і зламати перенесення позицій.
❤3👍1
✅ ЧЕКЛИСТ: міграція сайту на новий домен без втрати позицій
Зберігай — це база для будь-якого переїзду.
🔹 Перед переїздом (підготовка)
1️⃣ Зміна тільки одна за раз: спочатку переїзд на новий домен, потім уже зміна CMS чи дизайну — не все одночасно.
2️⃣ Признач переїзд на період спаду трафіку — менше людей зачепить, більше ресурсів сервера на краулінг.
3️⃣ Верифікуй у Search Console ВСІ варіанти старого й нового сайту — www, non-www, HTTP і HTTPS.
4️⃣ ⚠️ Якщо домен куплений/дроп — перевір його на чистоту: ручні санкції за минулий спам і залишкові видалення URL від попереднього власника.
5️⃣ Перезалий disavow-файл уже в акаунті нового сайту.
🔹 URL-мапінг
6️⃣ Збери список старих URL (сайтмапи, логи сервера, аналітика, найважливіші сторінки) і зістав кожен зі своїм новим адресом.
7️⃣ Не забудь про вбудований контент — зображення, відео, JS, CSS теж переносяться.
8️⃣ Кожен новий URL — із self-referencing rel=canonical; онови hreflang, якщо є мультимовність.
🔹 Редіректи
9️⃣ Тільки серверні 301/308 permanent-редіректи, якщо технічно можливо.
🔟 Уникай ланцюгів редіректів — веди одразу на фінальний URL (макс. 3, не більше 5 хопів).
⚠️ Не зливай купу старих URL на одну нерелевантну сторінку (типу головної) — Google може порахувати це за soft 404.
🔹 Запуск
1️⃣1️⃣ Увімкни редіректи → перевір canonical і noindex → протестуй через URL Inspection Tool.
1️⃣2️⃣ Подай Change of Address у Search Console для старого сайту (НЕ потрібно лише при переїзді HTTP→HTTPS).
1️⃣3️⃣ Залий новий сайтмап.
1️⃣4️⃣ Тримай редіректи мінімум рік (а краще — безстроково).
🔹 Після переїзду
1️⃣5️⃣ Онови внутрішні лінки, зовнішні (попроси донорів), профільні (соцмережі) і рекламні кампанії на нові URL.
1️⃣6️⃣ Моніторь обидва сайти: трафік на старому має падати, на новому — рости.
Зберігай — це база для будь-якого переїзду.
🔹 Перед переїздом (підготовка)
1️⃣ Зміна тільки одна за раз: спочатку переїзд на новий домен, потім уже зміна CMS чи дизайну — не все одночасно.
2️⃣ Признач переїзд на період спаду трафіку — менше людей зачепить, більше ресурсів сервера на краулінг.
3️⃣ Верифікуй у Search Console ВСІ варіанти старого й нового сайту — www, non-www, HTTP і HTTPS.
4️⃣ ⚠️ Якщо домен куплений/дроп — перевір його на чистоту: ручні санкції за минулий спам і залишкові видалення URL від попереднього власника.
5️⃣ Перезалий disavow-файл уже в акаунті нового сайту.
🔹 URL-мапінг
6️⃣ Збери список старих URL (сайтмапи, логи сервера, аналітика, найважливіші сторінки) і зістав кожен зі своїм новим адресом.
7️⃣ Не забудь про вбудований контент — зображення, відео, JS, CSS теж переносяться.
8️⃣ Кожен новий URL — із self-referencing rel=canonical; онови hreflang, якщо є мультимовність.
🔹 Редіректи
9️⃣ Тільки серверні 301/308 permanent-редіректи, якщо технічно можливо.
🔟 Уникай ланцюгів редіректів — веди одразу на фінальний URL (макс. 3, не більше 5 хопів).
⚠️ Не зливай купу старих URL на одну нерелевантну сторінку (типу головної) — Google може порахувати це за soft 404.
🔹 Запуск
1️⃣1️⃣ Увімкни редіректи → перевір canonical і noindex → протестуй через URL Inspection Tool.
1️⃣2️⃣ Подай Change of Address у Search Console для старого сайту (НЕ потрібно лише при переїзді HTTP→HTTPS).
1️⃣3️⃣ Залий новий сайтмап.
1️⃣4️⃣ Тримай редіректи мінімум рік (а краще — безстроково).
🔹 Після переїзду
1️⃣5️⃣ Онови внутрішні лінки, зовнішні (попроси донорів), профільні (соцмережі) і рекламні кампанії на нові URL.
1️⃣6️⃣ Моніторь обидва сайти: трафік на старому має падати, на новому — рости.
👍2😁2🔥1
Google Search Console тепер показує, як твої соцмережі та відео працюють у пошуку
Google розширює експеримент Social Channels у Search Console. Тепер у звіті Insights видно, як контент із соцмереж і відеоплатформ (YouTube, TikTok, Instagram) виступає у видачі Google — поряд із даними твого сайту 🔍
Що показує звіт 📝
🔹 Total reach — кліки та покази, які Google приводить на твої соцканали
🔹 Content performance — топові пости/відео + ті, що ростуть або падають у видимості
🔹 Search queries — за якими запитами люди знаходять твої профілі
🔹 Аудиторія — з яких країн клікають
🔹 Додаткові джерела — трафік з Image Search, Video Search, Discover і News 🎯
Що з цього важливо ⚠️
Google фактично визнає: пошук більше не дорівнює сайту 👀
Бренд живе у видачі через ролики й соцпости не менше, ніж через сторінки сайту
Тепер це можна міряти в одному місці, а не по трьох різних аналітиках
Що робити 🚀
Каналы Search Console визначає автоматично — вручну додати профіль поки не можна
Фіча експериментальна, розкочується поступово → лови підказку у звіті Insights
Тримай назви й лінки профілів однаковими скрізь, щоб Google правильно їх зв'язав
Здружи нарешті SEO- і SMM-команди, якщо досі працюють у різних табличках ⏳
Анонс від Google Search Central 📄
https://developers.google.com/search/blog/2026/07/search-console-social-video-platforms
Google розширює експеримент Social Channels у Search Console. Тепер у звіті Insights видно, як контент із соцмереж і відеоплатформ (YouTube, TikTok, Instagram) виступає у видачі Google — поряд із даними твого сайту 🔍
Що показує звіт 📝
🔹 Total reach — кліки та покази, які Google приводить на твої соцканали
🔹 Content performance — топові пости/відео + ті, що ростуть або падають у видимості
🔹 Search queries — за якими запитами люди знаходять твої профілі
🔹 Аудиторія — з яких країн клікають
🔹 Додаткові джерела — трафік з Image Search, Video Search, Discover і News 🎯
Що з цього важливо ⚠️
Google фактично визнає: пошук більше не дорівнює сайту 👀
Бренд живе у видачі через ролики й соцпости не менше, ніж через сторінки сайту
Тепер це можна міряти в одному місці, а не по трьох різних аналітиках
Що робити 🚀
Каналы Search Console визначає автоматично — вручну додати профіль поки не можна
Фіча експериментальна, розкочується поступово → лови підказку у звіті Insights
Тримай назви й лінки профілів однаковими скрізь, щоб Google правильно їх зв'язав
Здружи нарешті SEO- і SMM-команди, якщо досі працюють у різних табличках ⏳
Анонс від Google Search Central 📄
https://developers.google.com/search/blog/2026/07/search-console-social-video-platforms
🤔2🤝2
📉 Google трясе видачу: неофіційний апдейт на вихідних!
У суботу, 18 липня, інструменти моніторингу зафіксували різкий сплеск волатильності у видачі Google. Mozcast, SEMrush, Sistrix, AccuRanker, Algoroo — всі показують турбулентність значно вищу за норму 📊
Що відомо 📝
🔹 Пік коливань припав на 18 липня, але штормило весь минулий тиждень
🔹 Частина SEO-фахівців фіксує розворот: рухи від ~11 липня почали відкочуватись у зворотний бік 🔄
🔹 Офіційного анонсу від Google немає — класичний unconfirmed update
🔹 Останній підтверджений апдейт — June 2026 spam update (14–26 червня), до нього — May 2026 core update
🔹 Обидва підтверджені core-апдейти 2026 пройшли на початку року → за усталеною каденцією наступний широкий core очікується у серпні–вересні ⏳
Що робити 🚀
Позиції стрибали на вихідних? Це воно. Не панікуй і не переписуй сайт на емоціях 🧘
Дочекайся стабілізації видачі — висновки по трафіку роби мінімум через тиждень
Зафіксуй зміни позицій зараз, щоб потім порівняти: що просіло тимчасово, а що закріпилось
Вікно до серпневого core — найкращий час підтягнути якість контенту та почистити слабкі сторінки 🎯
Далі стежимо — якщо Google підтвердить апдейт, розберемо деталі 👀
У суботу, 18 липня, інструменти моніторингу зафіксували різкий сплеск волатильності у видачі Google. Mozcast, SEMrush, Sistrix, AccuRanker, Algoroo — всі показують турбулентність значно вищу за норму 📊
Що відомо 📝
🔹 Пік коливань припав на 18 липня, але штормило весь минулий тиждень
🔹 Частина SEO-фахівців фіксує розворот: рухи від ~11 липня почали відкочуватись у зворотний бік 🔄
🔹 Офіційного анонсу від Google немає — класичний unconfirmed update
🔹 Останній підтверджений апдейт — June 2026 spam update (14–26 червня), до нього — May 2026 core update
🔹 Обидва підтверджені core-апдейти 2026 пройшли на початку року → за усталеною каденцією наступний широкий core очікується у серпні–вересні ⏳
Що робити 🚀
Позиції стрибали на вихідних? Це воно. Не панікуй і не переписуй сайт на емоціях 🧘
Дочекайся стабілізації видачі — висновки по трафіку роби мінімум через тиждень
Зафіксуй зміни позицій зараз, щоб потім порівняти: що просіло тимчасово, а що закріпилось
Вікно до серпневого core — найкращий час підтягнути якість контенту та почистити слабкі сторінки 🎯
Далі стежимо — якщо Google підтвердить апдейт, розберемо деталі 👀
👍3🤝3
🕷 Google оновив документацію по crawl budget: усі сайти стартують «з нуля»!
У доці Optimize Your Crawl Budget з'явилося нове формулювання: кожен сайт починає з однакового дефолтного, консервативного ліміту краулінгу. Якщо є попит на більший обхід і сайт залишається «здоровим» — ліміт зросте автоматично.
Що це означає?
▪️ Новий сайт чи переїзд на новий домен = Googlebot ходить обережно. Швидку індексацію треба «заслужити»
▪️ Ліміт росте від стабільного швидкого сервера (TTFB, без 5xx/429) + реального попиту на контент
▪️ Ліміт спільний для ВСІХ краулерів Google — один бот виїдає капасіті, іншим дістається менше
▪️ Додали рекомендацію по 304 (Not Modified): сторінка не змінилась — Google бере кеш і витрачає бюджет на нове
▪️ Бюджет рахується по хосту (піддомену), а не по всьому домену!
Висновок: для нових і великих сайтів технічка знову вирішує. Швидкий сервер + чиста структура + 304 = швидше в індекс 👀
У доці Optimize Your Crawl Budget з'явилося нове формулювання: кожен сайт починає з однакового дефолтного, консервативного ліміту краулінгу. Якщо є попит на більший обхід і сайт залишається «здоровим» — ліміт зросте автоматично.
Що це означає?
▪️ Новий сайт чи переїзд на новий домен = Googlebot ходить обережно. Швидку індексацію треба «заслужити»
▪️ Ліміт росте від стабільного швидкого сервера (TTFB, без 5xx/429) + реального попиту на контент
▪️ Ліміт спільний для ВСІХ краулерів Google — один бот виїдає капасіті, іншим дістається менше
▪️ Додали рекомендацію по 304 (Not Modified): сторінка не змінилась — Google бере кеш і витрачає бюджет на нове
▪️ Бюджет рахується по хосту (піддомену), а не по всьому домену!
Висновок: для нових і великих сайтів технічка знову вирішує. Швидкий сервер + чиста структура + 304 = швидше в індекс 👀
👍3
Google трясе третій тиждень поспіль: нова хвиля волатильності 24-26 липня!
З вечора четверга 23.07 і всі вихідні — сильна волатильність видачі. Черговий непідтверджений апдейт, який «розігнався» у п'ятницю.
Що відомо?
▪️ Трекери (Semrush Sensor, Mozcast, AccuRanker, Sistrix та ін.) — пік близько 24 липня
▪️ Це вже ТРЕТЯ хвиля за місяць: 11 липня → 18-19 липня → 24-26 липня
▪️ Останній підтверджений апдейт — June Spam Update (завершився 26 червня). Core-апдейту в липні так і не було
▪️ Скарги вебмастерів: трафік до 27% від норми, у Бразилії мінус 60-70%, у когось нуль конверсій в Ads при повністю витраченому бюджеті
Цікава деталь від Баррі Шварца: ці коливання значать для паблішерів все менше, бо Google шле все менше трафіку. Великі видавці вже серйозно розглядають повне блокування Googlebot 👀
Що робити?
▪️ Не панікувати і не вносити різких змін — апдейт непідтверджений, позиції можуть відкотитись
▪️ Фіксуйте зміни позицій зараз — якщо в серпні-вересні прийде core-апдейт, буде з чим порівняти
▪️ Перевірте GSC: падіння по всьому сайту чи по окремих кластерах
З вечора четверга 23.07 і всі вихідні — сильна волатильність видачі. Черговий непідтверджений апдейт, який «розігнався» у п'ятницю.
Що відомо?
▪️ Трекери (Semrush Sensor, Mozcast, AccuRanker, Sistrix та ін.) — пік близько 24 липня
▪️ Це вже ТРЕТЯ хвиля за місяць: 11 липня → 18-19 липня → 24-26 липня
▪️ Останній підтверджений апдейт — June Spam Update (завершився 26 червня). Core-апдейту в липні так і не було
▪️ Скарги вебмастерів: трафік до 27% від норми, у Бразилії мінус 60-70%, у когось нуль конверсій в Ads при повністю витраченому бюджеті
Цікава деталь від Баррі Шварца: ці коливання значать для паблішерів все менше, бо Google шле все менше трафіку. Великі видавці вже серйозно розглядають повне блокування Googlebot 👀
Що робити?
▪️ Не панікувати і не вносити різких змін — апдейт непідтверджений, позиції можуть відкотитись
▪️ Фіксуйте зміни позицій зараз — якщо в серпні-вересні прийде core-апдейт, буде з чим порівняти
▪️ Перевірте GSC: падіння по всьому сайту чи по окремих кластерах
🤝4🌚2👀1
📌 Google оновив довідку по канонікалізації
20 серпня Google переписав сторінки «What is URL canonicalization» і «Fix canonicalization issues». Правила ті самі, змінилася структура: верх сторінки розбили на блоки.
🔹 canonical, редиректи, HTTPS і sitemap залишаються підказками. Google обирає канонічну сторінку сам і регулярно ігнорує твій вибір.
🔹 Яку сторінку він вважає канонічною, показує URL Inspection у GSC. Налаштування в плагіні цього не показують.
🔹 Після виправлень кластер переоцінюється до двох тижнів. Швидше, якщо різниця між сторінками очевидна.
⚠️ Причини, які Google перелічує:
🔹 Зламаний сайт. Інʼєкція cross-domain canonical на чужі спам-URL. Сторінка жива, канонічна веде кудись не туди.
🔹 Сайти-копії. Google може вибрати канонічною чужу копію твого контенту. Офіційне рішення від Google: DMCA.
🔹 Синдикація. canonical тут не працює, площадка має закривати перепечатку через noindex.
🔹 Плагін CMS. Тема або другий SEO-плагін дописують свій canonical, і в коді їх стає два. Перевіряй вихідний HTML.
🔹 Локалізовані версії без hreflang. Злипаються в один кластер.
🔗 https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting
20 серпня Google переписав сторінки «What is URL canonicalization» і «Fix canonicalization issues». Правила ті самі, змінилася структура: верх сторінки розбили на блоки.
🔹 canonical, редиректи, HTTPS і sitemap залишаються підказками. Google обирає канонічну сторінку сам і регулярно ігнорує твій вибір.
🔹 Яку сторінку він вважає канонічною, показує URL Inspection у GSC. Налаштування в плагіні цього не показують.
🔹 Після виправлень кластер переоцінюється до двох тижнів. Швидше, якщо різниця між сторінками очевидна.
⚠️ Причини, які Google перелічує:
🔹 Зламаний сайт. Інʼєкція cross-domain canonical на чужі спам-URL. Сторінка жива, канонічна веде кудись не туди.
🔹 Сайти-копії. Google може вибрати канонічною чужу копію твого контенту. Офіційне рішення від Google: DMCA.
🔹 Синдикація. canonical тут не працює, площадка має закривати перепечатку через noindex.
🔹 Плагін CMS. Тема або другий SEO-плагін дописують свій canonical, і в коді їх стає два. Перевіряй вихідний HTML.
🔹 Локалізовані версії без hreflang. Злипаються в один кластер.
🔗 https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting
👍3
Краулери Google не парсять JSON
Ілліс написав у Bluesky, що краулери Google просто завантажують файли. Парсинг відбувається далі, вже на етапі індексації. Питання виникло в контексті спільної інфраструктури, яку Google використовує в різних сервісах, включно з Merchant Center.
Звучить як дрібниця, але це пояснює кілька речей, на які регулярно натикаються при роботі з розміткою.
🔹 Краул і обробка це різні етапи. Бот забрав файл. Коли саме індексатор його розбере, окреме питання. Тому свіжий візит Googlebot у логах нічого не каже про те, чи врахована оновлена розмітка.
🔹 Логи показують тільки завантаження. 200 на сторінці і на JSON-фіді означає, що файл віддався. Далі йде черга на обробку, і на неї ти не впливаєш.
🔹 JSON-LD через JavaScript додає ще один крок. Якщо розмітка вставляється скриптом, а не лежить у вихідному HTML, до індексатора вона потрапляє після рендерингу. Це третій етап і ще одна затримка. У вихідному коді розмітки немає, у Rich Results Test вона є, у GSC її досі немає, і всі три стани одночасно правдиві.
🔹 Merchant Center працює по тій самій логіці. Фід скачали, обробили пізніше. Оновив ціни, а в товарці старі — дивись на статус обробки фіда, не на факт завантаження.
⚠️ Як перевіряти:
🔹 Rich Results Test показує, що Google бачить при живому запиті з рендерингом. Це стан «зараз».
🔹 URL Inspection у GSC показує проіндексовану версію. Порівняння живого тесту з проіндексованим і є та сама різниця між краулом і обробкою.
🔹 Звіти по структурованих даних у GSC оновлюються з лагом. Побачив помилку після правки, спочатку перевір дату останньої обробки, потім паникуй.
Ілліс написав у Bluesky, що краулери Google просто завантажують файли. Парсинг відбувається далі, вже на етапі індексації. Питання виникло в контексті спільної інфраструктури, яку Google використовує в різних сервісах, включно з Merchant Center.
Звучить як дрібниця, але це пояснює кілька речей, на які регулярно натикаються при роботі з розміткою.
🔹 Краул і обробка це різні етапи. Бот забрав файл. Коли саме індексатор його розбере, окреме питання. Тому свіжий візит Googlebot у логах нічого не каже про те, чи врахована оновлена розмітка.
🔹 Логи показують тільки завантаження. 200 на сторінці і на JSON-фіді означає, що файл віддався. Далі йде черга на обробку, і на неї ти не впливаєш.
🔹 JSON-LD через JavaScript додає ще один крок. Якщо розмітка вставляється скриптом, а не лежить у вихідному HTML, до індексатора вона потрапляє після рендерингу. Це третій етап і ще одна затримка. У вихідному коді розмітки немає, у Rich Results Test вона є, у GSC її досі немає, і всі три стани одночасно правдиві.
🔹 Merchant Center працює по тій самій логіці. Фід скачали, обробили пізніше. Оновив ціни, а в товарці старі — дивись на статус обробки фіда, не на факт завантаження.
⚠️ Як перевіряти:
🔹 Rich Results Test показує, що Google бачить при живому запиті з рендерингом. Це стан «зараз».
🔹 URL Inspection у GSC показує проіндексовану версію. Порівняння живого тесту з проіндексованим і є та сама різниця між краулом і обробкою.
🔹 Звіти по структурованих даних у GSC оновлюються з лагом. Побачив помилку після правки, спочатку перевір дату останньої обробки, потім паникуй.
❤2👍2👌2
⚖️ Google перестав енфорсити site reputation abuse в ЄЕЗ
28 серпня Google оновив Site Reputation Policy. З 30 серпня ручні санкції за паразитне SEO діють по-різному залежно від того, звідки шукає юзер.
Що змінилось
🔹 Поза ЄЕЗ — як було: ручник б'є по конкретному розділу, решта домену не страждає
🔹 У ЄЕЗ — ефект ручника не застосовується
🔹 Але уражений розділ може бути відокремлений у системах Google і з часом ранжуватись незалежно від решти домену
🔹 Сповіщення в GSC і реконсидерейшн лишаються. Додали медіацію: частина сайтів після реконсидерейшна може винести спір на неї
Що це означає на практиці
Ручник у Європі не спрацює, але відокремлення розділу нікуди не зникло. Твоя /coupons чи /betting папка на медійному домені перестає успадковувати його авторитет і починає ранжуватись сама по собі. Трафік падає саме з цього.
Звідки ноги ростуть
Зміна — наслідок розслідування Єврокомісії, яке зобов'язало Google не енфорсити політику в ЄЕЗ. У самому пості Google пише, що занепокоєний: надто широке трактування DMA може завадити боротись з реальними маніпуляціями видачі.
28 серпня Google оновив Site Reputation Policy. З 30 серпня ручні санкції за паразитне SEO діють по-різному залежно від того, звідки шукає юзер.
Що змінилось
🔹 Поза ЄЕЗ — як було: ручник б'є по конкретному розділу, решта домену не страждає
🔹 У ЄЕЗ — ефект ручника не застосовується
🔹 Але уражений розділ може бути відокремлений у системах Google і з часом ранжуватись незалежно від решти домену
🔹 Сповіщення в GSC і реконсидерейшн лишаються. Додали медіацію: частина сайтів після реконсидерейшна може винести спір на неї
Що це означає на практиці
Ручник у Європі не спрацює, але відокремлення розділу нікуди не зникло. Твоя /coupons чи /betting папка на медійному домені перестає успадковувати його авторитет і починає ранжуватись сама по собі. Трафік падає саме з цього.
Звідки ноги ростуть
Зміна — наслідок розслідування Єврокомісії, яке зобов'язало Google не енфорсити політику в ЄЕЗ. У самому пості Google пише, що занепокоєний: надто широке трактування DMA може завадити боротись з реальними маніпуляціями видачі.
📊 SE Ranking порахував, що зробив August 2026 spam update
100 000 ключів, 20 ніш, органіка США. Порівнювали 17 і 22 серпня (до і одразу після), базовий період — 26 і 31 липня, коли підтверджених апдейтів не було.
Цифри
🔹 16,71% URL з топ-10 вилетіли за сотню. У спокійному липні — 9,2%. Зростання на 82%
🔹 Топ-10 URL став приблизно в 1,8 раза більш схильним зникнути з топ-100
🔹 +12% до частки URL, які після апдейта опинились у топ-3, а до нього не входили навіть у топ-20
🔹 Волатильність топ-10 по нішах: від 74,64% у нерухомості до 85,55% у fashion & beauty
Що з цього видно
Google не просто перетасував топ-10, а затягував нагору сторінки з четвертого-п'ятого десятка. Це чистка видачі, а не рух на пару позицій.
Жодна з 20 ніш не відсиділась, розкид невеликий. YMYL-категорії (нерухомість, здоров'я) виявились серед найстабільніших — зазвичай по них б'є найсильніше.
Чого в даних немає
🔹 SE Ranking не робили аналіз на рівні URL і доменів. Хто саме вилетів і хто зайняв місця — тип сайту, тип контенту, конкретні спам-тактики — не розбирали
🔹 Трекали тільки позиції 1-100. Чи були URL деіндексовані, чи просто впали на 120-ту — з даних не видно
100 000 ключів, 20 ніш, органіка США. Порівнювали 17 і 22 серпня (до і одразу після), базовий період — 26 і 31 липня, коли підтверджених апдейтів не було.
Цифри
🔹 16,71% URL з топ-10 вилетіли за сотню. У спокійному липні — 9,2%. Зростання на 82%
🔹 Топ-10 URL став приблизно в 1,8 раза більш схильним зникнути з топ-100
🔹 +12% до частки URL, які після апдейта опинились у топ-3, а до нього не входили навіть у топ-20
🔹 Волатильність топ-10 по нішах: від 74,64% у нерухомості до 85,55% у fashion & beauty
Що з цього видно
Google не просто перетасував топ-10, а затягував нагору сторінки з четвертого-п'ятого десятка. Це чистка видачі, а не рух на пару позицій.
Жодна з 20 ніш не відсиділась, розкид невеликий. YMYL-категорії (нерухомість, здоров'я) виявились серед найстабільніших — зазвичай по них б'є найсильніше.
Чого в даних немає
🔹 SE Ranking не робили аналіз на рівні URL і доменів. Хто саме вилетів і хто зайняв місця — тип сайту, тип контенту, конкретні спам-тактики — не розбирали
🔹 Трекали тільки позиції 1-100. Чи були URL деіндексовані, чи просто впали на 120-ту — з даних не видно
👍1
🤖 Навайбкодив собі PBN-департамент замість того, щоб займатись рутиною.
Останні місяці сидів і кодив внутрішні тулзи під дропи та PBN, тому що бісила рутина 😤 Ділюся, що вийшло, і хочу почути, хто що собі накодив.
Що вийшло 📝
🔹 Чекер дропів — список доменів → Wayback-таймлайн, спам-слова, редіректи, зміна мови/ніші, парковки, скріни слепків → вердикт OK / CAUTION / REJECT.
🔹 Парсери GoDaddy — аукціонний експорт на 44 МБ, пресети по DR/довжині/зоні.
🔹 WHOIS масово — RDAP з фолбеком, до 100k доменів, кеш 7 днів, прогрес у базі (можна закрити вкладку і піти спати)
🔹 Перехоплення + масові NS — два списки (моніторинг і автореєстрація). Але найкорисніше — масова простановка NS: построчно, ставить пачкою через API кожного реєстратора, з логом помилок делегування.
🔹 Мова-Гео-Тема — визначає мову, країну і тематику домену за правилами, без звернень до ШІ в рантаймі. Правила один раз склали три LLM офлайн, тому працює миттєво і безкоштовно: мова 96.8%, гео 89.5%
🔹 Тексти — до 20 000 штук партією через OpenRouter, 24 воркери, партія переживає перезапуск сервера. Кожен текст валідується структурно (один h1, ≥2 h2, цілісність HTML), брак іде на ретрай іншою моделлю. Хуманайз — переписування двома іншими моделями + чек-лист з 38 AI-прикмет, плюс рандомізація структури й персони автора, щоб партія не виглядала штампованою. 28 мов, є режим тільки на безкоштовних моделях 📄
🔹 Ahrefs-панель — DR тягнеться безкоштовним ендпоінтом, units не витрачає. Спочатку прогін усього списку по DR → мотлох відсіюється одразу → і тільки ті, хто пройшов поріг, ідуть у платну batch-analysis (UR, беклінки, донори, органіка). Ціна там max(50, рядків × полів) на всю пачку, тому пачкою дешевше, ніж поштучно. Плюс кеш 7 днів: повторний прогін того ж списку майже безкоштовний 💰
🔹 Управління доменами — портфель з усіх акаунтів в одній таблиці: термін закінчення, автопродовження, приватність, NS. Плюс журнал змін за 7 днів (http, title, NS, з'явився/зник) і підсвітка тих, кому лишилось менше 30 і 60 днів. Щоб не проспати продовження і не пропустити, що домену тихо підмінили NS 📋
Тепер до вас 👇
Хто що навайбкодив собі під задачі? Цікаво почути:
🔹 що автоматизували і скільки часу це реально зекономило
🔹 де вайбкодинг підвів — що зламалось або дало хибні дані
Пишіть у коменти — зберемо нормальну базу підходів 💬
Останні місяці сидів і кодив внутрішні тулзи під дропи та PBN, тому що бісила рутина 😤 Ділюся, що вийшло, і хочу почути, хто що собі накодив.
Що вийшло 📝
🔹 Чекер дропів — список доменів → Wayback-таймлайн, спам-слова, редіректи, зміна мови/ніші, парковки, скріни слепків → вердикт OK / CAUTION / REJECT.
🔹 Парсери GoDaddy — аукціонний експорт на 44 МБ, пресети по DR/довжині/зоні.
🔹 WHOIS масово — RDAP з фолбеком, до 100k доменів, кеш 7 днів, прогрес у базі (можна закрити вкладку і піти спати)
🔹 Перехоплення + масові NS — два списки (моніторинг і автореєстрація). Але найкорисніше — масова простановка NS: построчно, ставить пачкою через API кожного реєстратора, з логом помилок делегування.
🔹 Мова-Гео-Тема — визначає мову, країну і тематику домену за правилами, без звернень до ШІ в рантаймі. Правила один раз склали три LLM офлайн, тому працює миттєво і безкоштовно: мова 96.8%, гео 89.5%
🔹 Тексти — до 20 000 штук партією через OpenRouter, 24 воркери, партія переживає перезапуск сервера. Кожен текст валідується структурно (один h1, ≥2 h2, цілісність HTML), брак іде на ретрай іншою моделлю. Хуманайз — переписування двома іншими моделями + чек-лист з 38 AI-прикмет, плюс рандомізація структури й персони автора, щоб партія не виглядала штампованою. 28 мов, є режим тільки на безкоштовних моделях 📄
🔹 Ahrefs-панель — DR тягнеться безкоштовним ендпоінтом, units не витрачає. Спочатку прогін усього списку по DR → мотлох відсіюється одразу → і тільки ті, хто пройшов поріг, ідуть у платну batch-analysis (UR, беклінки, донори, органіка). Ціна там max(50, рядків × полів) на всю пачку, тому пачкою дешевше, ніж поштучно. Плюс кеш 7 днів: повторний прогін того ж списку майже безкоштовний 💰
🔹 Управління доменами — портфель з усіх акаунтів в одній таблиці: термін закінчення, автопродовження, приватність, NS. Плюс журнал змін за 7 днів (http, title, NS, з'явився/зник) і підсвітка тих, кому лишилось менше 30 і 60 днів. Щоб не проспати продовження і не пропустити, що домену тихо підмінили NS 📋
Тепер до вас 👇
Хто що навайбкодив собі під задачі? Цікаво почути:
🔹 що автоматизували і скільки часу це реально зекономило
🔹 де вайбкодинг підвів — що зламалось або дало хибні дані
Пишіть у коменти — зберемо нормальну базу підходів 💬
👍6❤5