Аналіз та усунення канібалізації ключових слів на сайті

Аналіз та усунення канібалізації ключових слів на сайті

Ми виявляємо та усуваємо канібалізацію ключових запитів — приховану проблему, коли кілька сторінок вашого сайту конкурують за один пошуковий запит. Google бачить дві релевантні сторінки, не може обрати пріоритет і знижує обидві у видачі. Особливо гостро це проявляється на великих проектах: інтернет-магазинах з сотнями категорій, корпоративних порталах з багаторічною історією правок, блогах з накопиченою базою статей. Наш досвід роботи з такими проектами показує, що своєчасний аудит та усунення канібалізації дають приріст органічного трафіку на 20–40% протягом 2–3 місяців після впровадження правок. Ми гарантуємо прозорий звіт і покроковий план дій під ключ.

Симптоми канібалізації неочевидні: сторінка є в індексі, ключові запити в топ-20, але позиція не зростає роками. Аудит через Google Search Console або Ahrefs виявляє характерний сигнал — Google по черзі ранжує то одну сторінку, то іншу за одним запитом. Ми оцінимо ваш проект, проведемо повний аналіз і запропонуємо оптимальне рішення за 3–5 робочих днів.

Як виявити канібалізацію?

Для виявлення використовуємо комбінацію інструментів. Основне джерело — Google Search Console. Експортуємо дані по сторінках і запитах, з'єднуємо в Python або Google Sheets, шукаємо запити з розподілом показів між 2+ URL.

import pandas as pd
from googleapiclient.discovery import build
service = build('searchconsole', 'v1', credentials=creds)
response = service.searchanalytics().query(
    siteUrl='https://example.com',
    body={
        'startDate': '2024-01-01',
        'endDate': '2024-03-31',
        'dimensions': ['query', 'page'],
        'rowLimit': 25000
    }
).execute()
rows = response.get('rows', [])
df = pd.DataFrame([{
    'query': r['keys'][0],
    'page': r['keys'][1],
    'clicks': r['clicks'],
    'impressions': r['impressions'],
    'position': r['position']
} for r in rows])
cannibal = df.groupby('query').filter(lambda g: len(g) > 1 and g['impressions'].sum() > 100)
cannibal_sorted = cannibal.sort_values(['query', 'impressions'], ascending=[True, False])

Додатково перевіряємо через Screaming Frog + Ahrefs. В Ahrefs Site Explorer фільтруємо сторінки за позиціями 4–20 (зона нестабільного ранжування) і шукаємо перетини за ключами. Швидкий ручний тест — запит site:example.com "ключова фраза" — якщо у видачі 3+ сторінок, це прямий сигнал.

Які типи канібалізації зустрічаються?

Не кожна канібалізація однакова. Класифікуємо випадки за чотирма типами:

Цей чек-лист допомагає швидко визначитися з тактикою. Ми складемо докладну карту вашої канібалізації з пріоритетами.

Технічні методи усунення

Після класифікації переходимо до реалізації. Основні інструменти — 301 редирект, canonical і noindex.

301 редирект (Nginx):

server {
    location = /old-page/ {
        return 301 /canonical-page/;
    }
}

Canonical tag — коли сторінки мають залишатися доступними (наприклад, пагінація), але вага консолідується:

<link rel="canonical" href="https://example.com/canonical/" />

Важно: canonical — рекомендація, Google може проігнорувати при значній різниці контенту. Canonical tag поступається 301 редиректу в надійності приблизно на 20%, але дозволяє зберегти обидві сторінки.

Noindex для сторінок з низькою цінністю:

<meta name="robots" content="noindex, follow" />

Докладніше про налаштування canonical у документації Google.

Робота з внутрішньою перелінковкою

Канібалізація часто посилюється внутрішньою перелінковкою. Якщо анкор «купити iPhone 15» веде одночасно на дві сторінки — Google бачить конкуренцію. Правило: один комерційний анкор має посилатися лише на одну сторінку на всьому сайті. Аудит анкорів проводимо через Screaming Frog або Ahrefs Internal Backlinks.

Чому canonical недостатньо?

Canonical — лише рекомендація. При значному розходженні контенту Google може проігнорувати тег. У таких випадках краще використовувати 301 редирект або злиття сторінок. На практиці canonical ефективний для версій пагінації та фільтрів, але не для конкурентних статей.

Як усунути канібалізацію?

Покроковий план:

1. Проведіть аудит через Search Console і Ahrefs.
2. Класифікуйте кожен перетин за типом.
3. Виберіть метод: 301, canonical, noindex або злиття.
4. Налаштуйте редиректи або канонікали.
5. Оновіть внутрішню перелінковку.
6. Запросіть переіндексацію через Search Console.

Після виправлень: відстеження та гарантії

Google оновлює позиції через 2–6 тижнів після індексації змін. Пришвидшити процес можна через Search Console — URL Inspection → Request Indexing. Для пакетної переіндексації використовуємо Indexing API:

from googleapiclient.discovery import build
service = build('indexing', 'v3', credentials=creds)
batch = service.new_batch_http_request()
for url in url_list:
    batch.add(service.urlNotifications().publish(
        body={'url': url, 'type': 'URL_UPDATED'}
    ))
batch.execute()

Ми гарантуємо повторний аудит через місяць після впровадження — скоригуємо тактику, якщо потрібно. Наші інженери мають 10+ років досвіду в SEO та технічному аудиті, реалізовано понад 40 проектів з усунення канібалізації.

Що входить в роботу

• Детальний аудит з картою канібалізації та пріоритетами
• Налаштування canonical, 301 редиректів, noindex
• Переробка контенту при злитті сторінок
• Аудит та коригування внутрішньої перелінковки
• Звіт з рекомендаціями та гарантійна підтримка 1 місяць

Строки

Аудит сайту до 1000 сторінок — 3–5 робочих днів. Реалізація технічних правок — 2–3 дні. Контентні правки (переписування, злиття) — від 5 днів.

Отримайте консультацію — ми підготуємо індивідуальну пропозицію для вашого проекту. Зв'яжіться з нами для оцінки.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.