Пост-мортем-аналіз
Втрата трафіку після оновлення ядра: напишіть пост-мортем-аналіз
Усі задають одне й те саме питання о 8 ранку: це Google, це ми чи це збої відстеження? Пост-мортем-аналіз відповідає в такій послідовності та відкидає припущення.
Починайте з хронології, а не з теорії
Падіння має дату початку. Знайдіть її, перш ніж читати хоча б одну тему на форумі про втрату трафіку після оновлення ядра.
Google підтвердив оновлення ядра у березні 2024, серпні 2024, грудні 2024, березні 2025 та червні 2025 року, і кожне з них тривало близько двох тижнів, тому падіння на третій день розгортання може ще не відображати остаточної картини. Накладіть свій журнал змін на ці дати: релізи, міграції, редагування шаблонів, зміни robots.txt.
Якщо нічого вашого не змінювалося, а графік Search Console згинається в межах вікна розгортання, у вас є кандидат. Якщо ваш власний деплой відбувся за день до цього, у вас є кращий кандидат. У будь-якому випадку, тижневий спад трафіку після оновлення ядра заслуговує на письмову хронологію. Запишіть її.
Причини, відсортовані за швидкістю їх виключення
| Підозрюваний | Як перевірити | Час на виключення |
|---|---|---|
| Збій відстеження | Порівняйте GA4 з кліками Search Console для тих самих сторінок; проміжок, що з’явився за ніч, є ознакою | 10 хвилин |
| Проблеми з індексацією або sitemap | Звіт про індексацію сторінок Search Console, а також перевірка site: для URL-адрес, що втратили трафік | 20 хвилин |
| Технічний реліз | Порівняйте robots.txt, канонічні URL-адреси, коди стану та редиректи з останнім тижневим краулом | 1 година |
| Втрачені або отримані посилання | Порівняйте два знімки refdomains; див. втрачені посилання | 30 хвилин |
| Канібалізація | Дві ваші URL-адреси міняються місцями в звіті продуктивності для одного запиту | 1 година |
| Зміна SERP | Відкрийте живі результати: AI Overview, теми на форумах, списки від великих брендів, де ви раніше знаходилися | 30 хвилин |
| Переоцінка якості | Те, що залишається після того, як з’ясовано все інше | Дні до тижнів |
Докази посилань: одне порівняння
Отримайте доменні посилальні дані для сайту, що втратив трафік, за двома датами та виведіть те, що зникло і що з’явилося. Індексування оновлюється приблизно щомісяця, тому обирайте знімки по обидва боки оновлення.
import json
old = {r['domain'] for r in json.load(open('2026-09-01.json'))['rows']}
new = {r['domain'] for r in json.load(open('2026-10-01.json'))['rows']}
print('lost :', len(old - new))
print('gained:', len(new - old))
print('sample lost:', sorted(old - new)[:20])
# Field names ('rows', 'domain') vary by action: print one response first.
Приклад запису (гіпотетичні дані)
Це вигаданий приклад, а не реальний клієнт. Він показує тон, якого ми намагалися б дотримуватися.
Вплив. Органічні кліки впали на 38% за дев’ять днів для вигаданого сайту рецептів із 140 сторінками. Виявлення. Щотижневий експорт Search Console перетнув поріг сповіщення про тижневе падіння на 25%. Причина. Посилальні домени змінилися з 410 до 402, що виключає посилання як основний драйвер. Дві сторінки помінялися місцями в рейтингу для одного запиту, що є канібалізацією.
Пункти дій. Об’єднайте дві сторінки за допомогою 301 редиректу, оновіть внутрішні посилання, перевірте через чотири тижні. Без disavow. Без переписування всього сайту.
Помилки вимірювання та індексації, які виглядають як оновлення
Деякі падіння — це не рейтинги. Відстеження є поширеною підозрою. Зламаний тег, змінена властивість або sitemap, яка стиснулася, можуть виглядати точно так само, як оновлення ядра на графіках. Часові рамки падіння трафіку після оновлення ядра можуть приховувати будь-яку з них, тому перевіряйте їх у першу чергу.
Найшвидший тест — порівняти вашу аналітику з Search Console для тих самих сторінок і днів. Якщо проміжок з’явився за ніч, вважайте це помилкою вимірювання, доки не доведено інше.
Помилки індексації слідують тій самій логіці. Сторінки, що зникають з індексу, — це інша проблема, ніж сторінки, які залишаються в індексі, але падають у результатах.
Що робити, якщо кліки впадою до нуля за ніч?
Спочатку перевірте властивість Search Console. Змінений протокол, нова властивість або втрачена верифікація можуть розділити дані, тому стара властивість показує нічого, тоді як нова містить трафік. Тільки після цього перегляньте самі сторінки.
Чому сторінки перестають індексуватися після оновлення?
Отримайте звіт про індексацію для відповідних URL-адрес. Рейтинги можуть падати для сторінки, яка залишається в індексі. Сторінка, яка зникає з індексу, має іншу причину, часто це директива robots, зміна канонічного URL або noindex, що з’явилися з релізом.
Чи може зламаний sitemap спричинити падіння?
Може, якщо sitemap раптово перелічує лише невелику частку ваших URL-адрес. Короткий sitemap легко виправити, але Google все одно знаходить сторінки через внутрішні посилання, тому розглядайте його як одного з підозрюваних, а не як вирок. Порівняйте кількість URL-адрес з реальною кількістю сторінок.
Наша позиція
Не переписуйте сайт у перший тиждень
Оновлення ядра переоцінюють якість протягом тижнів. Змініть те, що ви можете довести як зламаний, а потім зачекайте завершення розгортання, перш ніж чіпати контент.
- Виправляйте помилки вимірювання та технічні проблеми негайно.
- Об’єднуйте канібалізовані сторінки, коли матимете докази.
- Залиште стратегію контенту в спокої до завершення розгортання.
Що писати в документі
Шість заголовків достатньо: вплив, хронологія, виявлення, причина, що було виключено, пункти дій. Список виключених — це те, за що майбутнє ви подякуєте собі.
Тримайте докази поруч із твердженням. Рядок «посилання виключено, 402 проти 410 посилальних доменів» краще витримає скептичного менеджера, ніж «посилання виглядали добре».
Якщо відповідь закінчується посиланнями, правила сповіщень про конкурентів та рецепт щотижневого порівняння не дозволять вам здивуватися наступного разу.
Перший тиждень після початку розгортання
- 1
Заморозьте редагування контенту
Не переписуйте сторінки, поки триває розгортання. Редагування, зроблені посередині, затемнять картину «до і після», яка вам знадобиться пізніше.
- 2
Фіксуйте кожен реліз
Запишіть кожен деплой, зміну шаблону, редирект і редагування robots.txt з його датою, щоб хронологія містила реальні записи, а не спогади.
- 3
Запустіть перевірки вимірювання
Порівняйте аналітику з Search Console, а потім перевірте звіт про індексацію для URL-адрес, що втратили трафік. Обидві перевірки вкладаються в півгодини.
- 4
Відкрийте справу з хронології
Почніть пост-мортем-аналіз з дат, які у вас є, навіть якщо причина ще не з’ясована. Частковий документ легше завершити, ніж порожній.
- 5
Встановіть дату огляду
Оберіть дату після завершення розгортання і перегляньте докази тоді, а не в день, коли графік згинається.
Обґрунтування для керівництва, що проблема технічна
Керівництво часто сприймає падіння трафіку як вирок контенту. Це справедлива реакція, і це також реакція, яка найчастіше призводить до втрати тижнів, коли проблема — зламаний шаблон або відсутній тег.
Надайте хронологію та таблицю причин, а не теорію. Таблиця з часом на виключення кожного підозрюваного дозволяє менеджеру побачити, що команда працює зі списком, а не вгадує.
Будьте чесними щодо того, що таблиця не може довести. Якщо переоцінка якості ще триває, скажіть про це і скажіть, що змінить вашу думку.
Як показати, що це проблема розробки, а не контенту?
Вкажіть на датувану зміну, яка збігається з початком падіння, наприклад, реліз шаблону або зміну robots. Помилку, яку можна відтворити, з URL-адресою та заголовком, що змінився, важливіша за будь-яку діаграму середніх значень.
Що сказати, якщо проблема не технічна?
Скажіть, що перевірки посилань, індексації та відстеження пройшли успішно, і що залишився підозрюваний — переоцінка якості. Ця відповідь повільніша і менш задовольняюча, але вона точна і вказує команді, на чому має зосередитися робота з контентом.
Опишіть відновлення, а не лише падіння
Пост-мортем-аналіз не завершується, коли трафік повертається. Друга половина запису фіксує, що змінилося, коли це сталося і яких підозрюваних ви остаточно виключили.
Поверніться до документа після завершення наступного оновлення ядра. Патерн, що повторюється під час розгортань, розповідає більше про ваш сайт, ніж будь-яке окреме падіння.
Тримайте список виключених окремо від причин. Майбутні читачі спочатку запитають, що було виключено, і відсутність списку поверне їх до початку.
Що вважається відновленням?
Визначте його до пошуку. Повернення до старого рівня кліків — одне визначення, а повернення сторінок, які мали найбільше значення — інше. Оберіть одне, запишіть його і звітуйте проти нього, а не зміщуйте планку, коли графік рухається.
Скільки часу має тривати очікування огляду?
Довше, ніж закриття розгортання та поява двох нормальних тижнів даних. Відновлення зазвичай відбувається повільно, тому ранній огляд переважно знаходить шум, тоді як пізніший має шанс знайти відповідь.
Питання, які ми чуємо після кожного оновлення
Чи можна відновитися після падіння в оновленні ядра?
Частково часто, і рідко за ніч. Відновлення зазвичай потребує пізнішого оновлення для переоцінки сайту, тому очікуйте місяців, а не днів. Ніхто не може це обіцяти. Що ви можете зробити, так це усунути реальні проблеми та продовжувати публікувати сторінки, варті цитування.
Чому рейтинги залишилися, а трафік впав?
Сторінка результатів змінилася навколо вас. AI Overview, теми на форумах та блоки покупок можуть опустити ту саму позицію нижче на екрані. Порівнюйте CTR для тих самих запитів до і після, а не лише середню позицію.
Чи викликають втрачені беклінки падіння після оновлення?
Лише іноді, і Rankift не може сказати вам, яке оновлення що зробило. Втрата посилань, достатня для впливу, проявляється як чітке падіння посилальних доменів між двома знімками. Малий обмін кількома відсотками рідко пояснює падіння трафіку на 30%.
Скільки часу чекати перед дією?
Доки Google не позначить розгортання завершеним на своїй панелі статусу, якщо ви не знайдете чітку технічну проблему. Виправляйте проблеми негайно, але утримуйте зміни контенту. Редагування під час розгортання затемнюють докази, які вам знадобляться пізніше.
