Реєстр канібалізації контенту: шаблон

Реєстр канібалізації (для заповнення)

Коли використовувати: Один рядок на кожен спільний запит: URL-конкуренти, перетин намірів, рішення, відповідальний і статус перевірки редиректу.

Реєстр канібалізації контенту

Один рядок на запит, за яким у Search Console показуються два чи більше ваших URL. Зафіксуйте перетин, ухваліть рішення один раз і доведіть, що виправлення спрацювало.

Шапка реєстру

• Сайт / ресурс: [домен або ресурс у Search Console]
• Період даних: [наприклад, останні 3 місяці], країна [усі / ринок], пристрій [усі / мобільні]
• Відповідальний за реєстр: [ім’я] - як часто переглядати [щомісяця / щокварталу]

Деталі рядка (заповніть для кожного запиту)

• Намір запиту (один рядок): [що користувач хоче зробити чи дізнатися]
• Тип кожної сторінки: [гайд / товар / категорія / порівняння / тег]
• Який URL залишаємо і чому: [сторінка, що найкраще відповідає наміру і має найбільше посилань та конверсій]
• Зворотні посилання та конверсії на сторінці, що програє: [кількість / примітка]
• Що змінили: [переписали, об’єднали, редирект, canonical, noindex, правки внутрішніх посилань], дата [дата]
• Канонічна сторінка, вибрана Google, після змін: [URL із «Перевірки URL-адреси» (URL Inspection)], перевірено [дата]

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

• Керівник SEO: [ім’я] - завдання: підтвердити оцінку наміру та рішення для кожного рядка до [дата]
• Редактор: [ім’я] - завдання: [об’єднати тексти / переписати слабшу сторінку під її власний запит] до [дата]
• Розробник: [ім’я] - завдання: [додати 301, canonical або noindex] і надіслати список URL на перевірку
• Відповідальний за перевірку: [ім’я] - завдання: провести перевірки після змін і заповнити колонку «Перевірка редиректу»

Перевірка готовності

• У кожному рядку один запит, а не тема.
• Для кожного URL-конкурента є кліки, покази та позиція за той самий період.
• У кожному рядку одне рішення й один відповідальний із терміном.
• Об’єднані URL віддають один постійний редирект на сторінку, яку залишили.
• Внутрішні посилання ведуть на збережений URL, а не на перенаправлений чи дубльований.
• Призначено дату повторної перевірки запиту в Search Console.

Пошук перетинів у Search Console

Коли використовувати: Зберіть усі URL, що мають покази за одним запитом, і вирішіть, чи варто заносити перетин у реєстр.

Як знайти перетини запитів у Search Console

Почніть із реальних даних. У звіті «Ефективність (Performance)» можна відфільтрувати один запит, а потім перейти на вкладку «Сторінки (Pages)» і побачити всі URL, які мали за ним покази.

Кроки

1. Відкрийте «Ефективність (Performance)», «Результати пошуку (Search results)». Візьміть досить довгий період, щоб згладити випадкові коливання, наприклад останні 3 місяці.
2. Додайте фільтр «Запит (Query)» для одного цільового запиту. Для точного збігу виберіть варіант із регулярним виразом, в англомовному інтерфейсі Custom (regex), і візьміть запит у ^ та $.
3. Перейдіть на вкладку «Сторінки (Pages)». Запишіть кожен URL із кліками, показами та середньою позицією.
4. Почніть із комерційних запитів, які приносять гроші, потім перейдіть до запитів, за якими впали кліки.
5. Додайте рядок у реєстр, коли за одним запитом показуються два чи більше URL.

Варто заносити чи це шум?

Особливості даних

• За словами Google, дані таблиці з групуванням за сторінками агрегуються за сторінкою, а дані графіка за ресурсом. Тож підсумки можуть не збігатися.
• Порівнюйте URL за однаковий період, країну та пристрій.

Перевіряйте спільні запити повторно за допомогою Rank Tracker.

Він показує всі позиції вашого сайту в топ-10 Google, тож видно, коли ранжуються два ваші URL. Щоб спершу розбити довгий список запитів на теми, скористайтеся Keyword Cluster Tool.

Оцінка перетину намірів

Коли використовувати: Порівняйте дві сторінки-конкуренти за кожним питанням і позначте перетин як однаковий, частковий чи різний.

Оцініть перетин намірів

Дві сторінки за одним запитом не завжди проблема. Проблема виникає, коли вони закривають ту саму потребу. Дайте відповіді на ці питання для кожної пари.

Як читати результат

• Однаковий: обидві сторінки закривають ту саму потребу і мають однаковий тип. Ваш вибір: об’єднання + 301 або canonical.
• Частковий: тема та сама, але інший ракурс чи етап. Розведіть сторінки: переорієнтуйте одну на її власний запит.
• Різний: різні потреби, які просто перетинаються за широким запитом. Залиште обидві, виправте внутрішні посилання та заголовки.

Перш ніж щось об’єднувати, перевірте в Content Optimizer, що є на слабшій сторінці такого, чого бракує сильнішій.

Правила рішень: залишити, розвести, об’єднати, canonical, noindex

Коли використовувати: Оберіть одне виправлення на запит з урахуванням документації Google про редиректи та canonical.

Правила рішень

Одне рішення на запит. Ідіть згори вниз і застосуйте перше правило, яке підходить.

Що каже документація Google

• 301 або 308 сигналізують, що цільова сторінка редиректу має бути канонічною. 302 чи 307 такого сигналу не дають.
• Ставте постійний редирект, коли впевнені, що його не скасуєте. Серверні редиректи найнадійніші.
• Редиректи і rel="canonical" є сильними сигналами. URL у карті сайту є слабким сигналом.
• Google не радить використовувати noindex, щоб обрати канонічну сторінку в межах одного сайту. Noindex прибирає сторінку з пошуку.
• Не використовуйте robots.txt для канонізації.
• Не вказуйте для однієї сторінки різні канонічні URL різними способами.
• Ваш вибір канонічної сторінки для Google лише підказка, а не правило. Google може обрати інший URL.

Потрібно розписати багато об’єднаних URL одразу? Скористайтеся шаблоном карти 301-редиректів і розчищення ланцюжків. Для дублів із параметрами та версій для друку є матриця рішень щодо canonical.

Чекліст перевірки після змін

Коли використовувати: Перевірте редиректи, canonical, внутрішні посилання та канонічну сторінку, вибрану Google, після запуску змін.

Перевірка після змін

Пройдіть ці перевірки в день запуску змін, а потім ще раз у дату повторної перевірки. Заповнюйте колонку «Перевірка редиректу» лише тоді, коли пройдено все.

Об’єднання + 301

• Старий URL віддає 301 або 308, а не 302, 307 чи meta refresh.
• Лише один перехід. Жодного ланцюжка через старий slug чи http-версію.
• Цільова сторінка віддає 200 і містить об’єднаний контент.
• Цільова сторінка найкраще замінює старий URL за змістом. Це не головна сторінка.
• Редирект серверний. Google радить JavaScript-редиректи лише тоді, коли інші варіанти неможливі.

Canonical або noindex

• rel="canonical" містить абсолютний URL і веде на сторінку, що віддає 200.
• Основна сторінка має canonical на саму себе.
• Сторінки з noindex не заблоковані в robots.txt, тож Google бачить тег.
• У XML-карті сайту лише канонічні URL.

Сигнали навколо сторінки

• Внутрішні посилання, меню та хлібні крихти ведуть на збережений URL.
• Корисні анкори зі слабшої сторінки тепер ведуть на сильнішу.
• У «Перевірці URL-адреси (URL Inspection)» канонічна сторінка, вибрана Google, збігається з вашим вибором. Її визначають під час індексації, тому перевірка опублікованої версії (Test live URL) її не покаже.
• У дату повторної перевірки Search Console показує, що покази за запитом збирає один URL.

Перевірте коди відповіді й кількість переходів у Redirect Checker. Потім проскануйте розділ через Website Audit, щоб знайти внутрішні посилання, які досі ведуть на перенаправлені URL.

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

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

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

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

query,url,clicks,impressions,avg_position,intent,intent_overlap,decision,kept_url,change_type,owner,due_date,status_code,redirect_hops,final_url,google_selected_canonical,internal_links_updated,followup_date,status

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

• intent_overlap: same, partial, different
• decision: keep-both, differentiate, merge-301, canonical, noindex
• internal_links_updated: yes, no, n/a
• status: logged, decided, in-progress, shipped, qa-passed, qa-failed, monitor

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

• Групуйте рядки за запитом, щоб кожен перетин читався як один блок.
• Виділяйте рядки merge-301, де status_code не 301 і не 308.
• Виділяйте рядки, де redirect_hops більше 1.
• Позначайте рядки, де google_selected_canonical відрізняється від kept_url.

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

Коли використовувати: Заповнений реєстр для вигаданого магазину: одне об’єднання, одне «залишити», один canonical і один noindex.

Заповнений приклад: магазин рослин Marrowfen

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

• Ресурс: marrowfen.example
• Період даних: останні 3 місяці, усі країни, усі пристрої
• Відповідальний за реєстр: Priya, керівниця SEO

Що зробила команда

• Перенесли покроковий розділ про пересадку в гайд із догляду, потім налаштували 301-редирект із /blog/repot-monstera/.
• Перевірка виявила ланцюжок із двох переходів через старий http-URL. Розробник направив редирект одразу на гайд із догляду.
• Гайд про ґрунт тепер посилається на сторінку товару з анкором «ґрунт для ароїдних». Сторінка товару посилається назад на поради з догляду.
• Версія для друку отримала canonical на чистий URL з абсолютною адресою.
• Порожня сторінка тегу отримала noindex, бо не мала унікального контенту. Noindex не використовували, щоб обрати між двома сторінками.

Повторна перевірка (вигадана)

• «Перевірка URL-адреси (URL Inspection)» показала гайд із догляду як канонічну сторінку, вибрану Google, для URL версії для друку.
• У дату повторної перевірки запит про пересадку мав покази лише на гайді з догляду.
• За запитом про ґрунт досі показуються обидва URL. Це нормально: одна сторінка продає, друга навчає.