Матриця рішень щодо видалення контенту: шаблон

Матриця рішень щодо видалення контенту (для заповнення)

Коли використовувати: Один рядок на кожний позначений URL: трафік, посилання, конверсії, стратегічна цінність, рішення, відповідальний і погодження.

Матриця рішень щодо видалення контенту

Заповнюйте її лише для сторінок, які аудит уже позначив як слабкі. Один рядок на URL. Спершу дані, потім одне рішення, потім погодження.

Деталі рядка (заповнюйте для кожного URL)

• Трафік: кліки [n], покази [n], середня позиція [n] у Search Console за [період]
• Головні запити: [запит - кліки]. Чи належать вони іншому URL? [так, [URL] / ні]
• Беклінки: доменів-донорів [n], помітні посилання [домен - URL, на який посилаються]
• Внутрішні посилання: сюди посилаються [n] сторінок, зокрема [меню / футер / сторінки товарів / розсилки]
• Конверсії: [ліди, продажі, реєстрації або асоційовані конверсії] за [той самий період]
• Стратегічна цінність: [ключова тема / допоміжна / не за темою], думка відповідального: [причина]
• Потреба користувачів або юридична вимога: [політика, довідкова стаття, QR-код, посилання партнера, обов'язкове повідомлення / немає]
• Перетин: той самий намір, що й у [URL або немає], за даними шаблону реєстру канібалізації контенту
• Рішення: [покращити / об'єднати + 301 / залишити як є / noindex / видалити], тому що [дані, які відповідають вашому правилу]
• Технічна дія: код відповіді [200 / 301 на [ціль] / 404 / 410], robots meta [index / noindex], sitemap [залишити / прибрати]
• Погодження: SEO [ім'я], відповідальний за сторінку [ім'я], юрист або продукт [ім'я або не потрібно]

Наступні кроки

• SEO-лід: [ім'я] - завдання: зібрати дані й запропонувати рішення до [дата]
• Відповідальний за сторінку: [ім'я] - завдання: підтвердити стратегічну цінність, потреби користувачів і юридичні вимоги до [дата]
• Розробник: [ім'я] - завдання: впровадити код відповіді, редирект або noindex та оновити sitemap до [дата]
• Аналітик: [ім'я] - завдання: повторно перевірити трафік, конверсії та цілі редиректів: [дата змін + [n] тижнів]

Фінальна перевірка

• У кожному рядку є трафік, беклінки, внутрішні посилання й конверсії за той самий період.
• Для кожного рішення вказано правило з ваших власних порогів, якому воно відповідає.
• Сторінки, потрібні користувачам або з юридичних причин, позначено «залишити» чи noindex, але ніколи «видалити».
• Кожне об'єднання має один релевантний цільовий URL, а не головну сторінку.
• Внутрішні посилання та XML sitemap оновлено для кожного URL, у якого змінився статус.
• Стовпець погодження заповнено до того, як будь-які зміни підуть на сайт.

Правила рішень і пороги

Коли використовувати: Запишіть власні пороги для рішень «покращити», «об'єднати + 301», «залишити», noindex і «видалити», перш ніж оцінювати будь-який URL.

Правила рішень і ваші пороги

Запишіть пороги один раз, до того як дивитися окремі URL. Цифри визначаєте ви. Вони залежать від розміру сайту, ніші та циклу продажу.

Що Google каже про ці варіанти

• Видалення не варто обирати за замовчуванням. У рекомендаціях щодо основних оновлень (core updates) Google називає видалення контенту крайнім заходом для того, що неможливо врятувати.
• Google однаково обробляє всі коди 4xx, крім 429. Проіндексовані URL, які повертають 4xx, випадають з індексу.
• 301 - це сигнал, що цільова сторінка має стати канонічною. У результатах пошуку Google показує саме її.
• Noindex працює, лише якщо Google може просканувати сторінку. Не блокуйте її в robots.txt.
• Google не радить перенаправляти багато старих URL на одну нерелевантну сторінку. Таке перенаправлення можуть сприйняти як м'яку помилку 404 (soft 404).

Не впевнені, що сторінка справді слабка? Спершу перевірте її в інструменті Content Optimizer. Якщо сторінці потрібне лише оновлення, її місце в рядку «Покращити».

Ще обираєте, які сторінки позначити? Почніть із шаблону аудиту та оновлення контенту, а слабкі сторінки перенесіть сюди.

Перевірка ризиків перед видаленням або об'єднанням

Коли використовувати: Перевірте беклінки, внутрішні посилання, конверсії, sitemap, редиректи та юридичні вимоги, перш ніж погоджувати рядок.

Перевірка ризиків перед об'єднанням, noindex або видаленням

Пройдіть ці перевірки для кожного URL, який не позначено «покращити» чи «залишити». Якщо хоч один пункт не перевірено, рядок не готовий до погодження.

Беклінки

• Доменів-донорів у цього URL: [n]. Перевірте свій домен в інструменті Backlink Analyzer і подивіться стовпець «Links to».
• Посилання, які ви втратите з 404 або 410: [домен - анкор]
• Якщо є посилання, які варто зберегти, рішення - об'єднати + 301 на [найближчий релевантний URL], а не видаляти.

Внутрішні посилання

• Сторінки, що посилаються сюди: [n], за даними CMS або експорту сканування. Після релізу Website Audit покаже биті посилання й посилання на редиректи.
• Меню, футер, схожі статті або сторінки товарів, що посилаються сюди: [список]
• План: замінити кожне посилання на [нову ціль] або прибрати його, щоб жодне внутрішнє посилання не вело на редирект чи 404.

Конверсії та дохід

• Конверсії або асоційовані конверсії за [період]: [n]
• Використовується в рекламі, розсилках, QR-кодах, презентаціях для продажів або на сторінках партнерів: [так, де / ні]
• Якщо так, погодження дає відповідальний за цей канал: [ім'я]

Sitemap, canonical і редиректи

• Зараз є в XML sitemap: [так / ні]. Приберіть URL звідти, якщо він стане редиректом, віддаватиме 404, 410 або отримає noindex.
• Інші URL, у яких canonical вказує на цю: [список або немає]
• Наявні редиректи на цей URL: [список]. Переведіть їх одразу на кінцеву ціль, щоб не було ланцюжків.
• Цільовий URL віддає 200 і доступний для індексації: [перевірено [дата]]

Користувачі, юридичні вимоги та політики

• Вимагається законом, договором або політикою: [так, чим саме / ні]
• На сторінку посилаються довідка, застосунки або друковані матеріали: [так, де / ні]
• Сторонній контент, розміщений переважно для того, щоб ранжуватися за рахунок авторитету вашого сайту: [так / ні]. Це підпадає під правила Google щодо спаму, тож розгляньте такий випадок уважно.

Таблиця впровадження (коди відповіді та noindex)

Коли використовувати: Перетворіть кожне рішення на правильний код відповіді, robots meta, зміни в sitemap і внутрішніх посиланнях.

Таблиця впровадження: коди відповіді, noindex і sitemap

Кожне рішення щоразу потребує тих самих технічних кроків. Скопіюйте потрібний рядок у задачу для розробника.

404 чи 410?

• Google каже, що однаково обробляє всі помилки 4xx, крім 429, і з часом перестає використовувати такі URL.
• Оберіть один код для свого сайту й запишіть його тут: [404 / 410], тому що [причина, наприклад стандарт CMS або правило команди].
• Покажіть корисну сторінку помилки з посиланнями на основні розділи. Код відповіді при цьому все одно має бути 404 або 410.

Правила редиректів при об'єднанні

1. Перенаправляйте на сторінку, яка закриває ту саму потребу, а не на головну.
2. Перенаправляйте одразу на кінцевий URL. Без ланцюжків.
3. Постійний редирект ставте, лише якщо впевнені, що його не скасують.
4. Тримайте редиректи довго. У посібнику з переїзду сайту Google радить, як правило, щонайменше 1 рік.
5. Після релізу перевірте кожен старий URL в інструменті Redirect Checker: [старий URL - кінцевий URL - статус]

Правила для noindex

• Використовуйте метатег robots на HTML-сторінках або заголовок X-Robots-Tag для PDF та інших файлів.
• Не блокуйте URL у robots.txt, інакше Google так і не побачить noindex.
• Щоб побачити тег, Google має повторно просканувати сторінку. Для сторінок, які Google відвідує рідко, це може тривати довго.
• Не використовуйте noindex, щоб обрати канонічну сторінку серед дублів. Краще об'єднайте їх або вкажіть rel canonical.

Переносите багато URL одночасно? Сплануйте їх у шаблоні карти 301 редиректів, а залишки відстежуйте в шаблоні керування битими посиланнями та помилками 404.

Журнал погоджень, релізів і відкатів

Коли використовувати: Чистіть контент погодженими партіями з датою перевірки та умовою відкату.

Журнал погоджень, релізів і відкатів

Чистіть контент невеликими партіями. Для кожної партії ще до релізу потрібні погодження, дата перевірки та умова відкату.

Питання перед погодженням

• Чи відповідає кожен рядок порогу, записаному в правилах рішень, а не новому, вигаданому на ходу?
• Чи підтвердив відповідальний за сторінку, що вона не потрібна користувачам, юристам чи продажам?
• Цільова сторінка редиректу або покращена сторінка вже на сайті й доступна для індексації?
• Чи є копія кожної видаленої сторінки, щоб її можна було відновити?

Після релізу

• Перенаправлені URL: порівняйте кліки на цільовий URL до і після за [запити, які отримувала стара сторінка].
• Видалені URL: перевірте у звіті «Індексування сторінок (Page indexing)», що статус [«Не знайдено (404)» (Not found (404))] мають лише очікувані URL.
• Запустіть разову перевірку топ-10 для цільових сторінок в інструменті Rank Tracker: [ключове слово - позиція до - після]
• Конверсії на цільових сторінках: [до / після]
• Відкат: якщо спрацює [ваша умова], відновіть [URL] з копії та приберіть редирект.

Хочете, щоб хтось переглянув вашу партію перед релізом? Запишіться на безкоштовну консультацію з Анатолієм Улітовським.

Заголовок таблиці (CSV)

Коли використовувати: Готовий рядок заголовків і допустимі значення, щоб вести матрицю в Google Sheets або Excel.

Готовий заголовок таблиці

Вставте цей рядок у клітинку A1 у Google Sheets або Excel, потім розділіть текст на стовпці за комою. Один рядок на кожний позначений URL.

row_id,url,flag_reason,date_range,clicks,impressions,avg_position,top_queries,referring_domains,notable_links,internal_links_in,conversions,assisted_conversions,strategic_fit,user_or_legal_need,overlap_url,decision,rule_met,target_url,status_code,robots_meta,sitemap_action,internal_links_action,risk_check_done,seo_owner,page_owner,approved_by,approval_date,batch,release_date,check_date,rollback_trigger,outcome,status

Допустимі значення

• strategic_fit: core, supporting, off_topic
• decision: improve, merge_301, keep, noindex, remove_404, remove_410
• robots_meta: index, noindex
• sitemap_action: keep, remove, add_target
• risk_check_done: yes, no
• status: proposed, approved, shipped, checked, rolled_back

Поради щодо таблиці

• Додайте правило, яке підсвічує рядки, де decision дорівнює remove, а referring_domains перевищує ваш поріг.
• Підсвічуйте рядки, де conversions більше нуля, а decision дорівнює remove або noindex.
• Не дозволяйте ставити статус approved, поки approved_by або risk_check_done порожні.
• Фільтруйте за target_url, щоб побачити всі сторінки, об'єднані в один URL.

Заповнений приклад (вигаданий магазин кімнатних рослин)

Коли використовувати: П'ять заповнених рядків для вигаданого магазину, по одному на кожне рішення, з нотатками про ризики та перевіркою після релізу.

Заповнений приклад: сторінки Larkspindle про догляд за рослинами

Лише приклад. Larkspindle - вигаданий магазин кімнатних рослин. Його URL, пороги, дати й цифри придумано, щоб показати заповнену матрицю.

Власні правила Larkspindle: видаляти лише за 0 конверсій і менше ніж 2 домени-донори. Покращувати, якщо показів понад 3 000. Об'єднувати, якщо перетин підтверджено.

Нотатки до перевірки ризиків

• Об'єднання сторінок про сансев'єрію: два корисні розділи перенесли в гайд. 7 внутрішніх посилань перевели на нову адресу. Старий URL прибрали з sitemap.
• Зимовий розпродаж: посилань немає, жодна розсилка на сторінку вже не веде. Посилання з футера прибрали. Сторінка віддає 410 з посиланнями на актуальні пропозиції.
• Рослини, безпечні для тварин: на сторінку посилаються 40 сторінок товарів, і вона допомагає продажам. Її залишили, тож наступний аудит її пропустить.
• Картка догляду: на неї ведуть надруковані QR-коди, тому сторінка лишається доступною. Додали noindex, без блокування в robots.txt.

Перевірка через 6 тижнів (кінець жовтня 2026 р.)

• Гайд із пересаджування тепер ранжується за головним запитом старої сторінки, а старий URL показується як редирект.
• URL зимового розпродажу випав з індексу. Інших URL з 404 або 410 не з'явилося.
• Сторінка про фікус ліроподібний після переписування піднялася з 14-ї на 9-ту позицію.

Чому це працює

• Із п'яти слабких сторінок видалили лише одну. Решта зберегли посилання, користувачів або продажі.
• Пороги задали до перевірки, тому ніхто не сперечався про кожну сторінку окремо.
• Рядок із карткою догляду погодив операційний відділ, бо команда, яка друкує QR-коди, теж мала висловитися.