Налаштування canonical URL: усуваємо дублі сторінок на сайті

Налаштування canonical URL для запобігання дублів

Дублі сторінок (SEO дублі) — одна з найпоширеніших проблем SEO, з якою стикаються власники інтернет-магазинів і великих порталів. GET-параметри на зразок ?utm_source=google, ?sort=price, пагінація /page/2, а також відмінності в протоколах (http/https) та наявності www — усе це створює сотні копій однієї сторінки. Пошуковики витрачають бюджет краулінгу на марні дублі, а авторитет сторінки розмивається. Правильне налаштування canonical захищає від синдикації контенту та покращує індексацію. Наприклад, у каталозі з 10 000 товарів без canonical кожен товар може мати до 10 дублів через фільтри, що створює 100 000 сторінок і знижує Indexing budget на 90%. Наші клієнти економлять у середньому 200 000 гривень на місяць на краулінговому бюджеті після впровадження canonical.

Ми вирішуємо цю проблему комплексно: впроваджуємо canonical URL, налаштовуємо самопосилальні теги, обробляємо пагінацію та фільтри. Наш підхід базується на досвіді понад 50 проєктів, включаючи каталоги з мільйонами товарів. Гарантуємо коректну індексацію та економію краулінгового бюджету. Один із клієнтів із каталогом 20 000 товарів після впровадження canonical скоротив кількість сторінок в індексі Google із 200 000 до 21 000 за 2 тижні, заощадивши близько 150 000 гривень на рекламному трафіку.

Чому canonical URL — основа боротьби з дублями?

Canonical URL — це тег <link rel='canonical' href='...'>, який вказує пошуковику, яка версія сторінки є основною. Він не вимагає редиректів, тому не сповільнює сайт. За даними Google Search Central, canonical URL допомагає пошуковим системам зрозуміти, яку версію сторінки слід індексувати та показувати в результатах пошуку. Докладніше на MDN. Достатньо одного HTTP-запиту, щоб склеїти всі дублі в одну сторінку.

Типові сценарії дублів, які вирішує canonical:

Як canonical впливає на індексацію?

Правильно налаштований canonical концентрує посилальну вагу на основній сторінці та прискорює індексацію. За даними Google, сайти з коректними canonical скорочують кількість проіндексованих дублів на 60–80%. Це звільняє краулінговий бюджет для нових сторінок. В одному з наших кейсів інтернет-магазин із 20 000 товарів після впровадження canonical скоротив кількість сторінок в індексі Google із 200 000 до 21 000 за 2 тижні, а органічний трафік виріс на 15%. В іншому проєкті з 1 000 000 сторінок дублі були скорочені на 90%.

Як налаштувати canonical в Laravel?

Для проєктів на Laravel ми використовуємо трейт HasCanonical. Він автоматично генерує canonical для кожної моделі. Приклад реалізації:

trait HasCanonical
{
    public function getCanonicalUrl(): string
    {
        return url($this->canonical_path ?? $this->getSlugPath());
    }
}

У Blade-шаблоні достатньо одного рядка:

<link rel="canonical" href="{{ $page->getCanonicalUrl() }}">

Для сторінок з фільтрами ми прибираємо всі GET-параметри, крім необхідних для унікальності контенту:

public function canonicalUrl(Request $request): string
{
    return $request->url(); // без query string
}

Як вибрати стратегію canonical для пагінації?

Сторінка /blog/?page=3 повинна мати canonical на себе, якщо контент на сторінках пагінації унікальний (наприклад, різні статті). Якщо контент однаковий (наприклад, список товарів), краще вказати canonical на першу сторінку. Ми допомагаємо визначити правильну стратегію на основі типу контенту.

<link rel="canonical" href="{{ url()->current() }}{{ request('page') > 1 ? '?page=' . request('page') : '' }}">

Етапи налаштування canonical під ключ

1. Аудит дублів: сканування сайту, виявлення всіх URL з однаковим контентом.
2. Вибір стратегії: для кожного типу дубля визначаємо, який URL вважати основним.
3. Реалізація: впровадження canonical через код сайту, шаблони, HTTP-заголовки.
4. Перевірка: тестування через Google Search Console, URL Inspection Tool.
5. Моніторинг: відстеження індексації протягом місяця, коригування за потреби.

Що входить у роботу з налаштування canonical

• Аудит дублів та виявлення всіх проблемних URL — із наданням звіту.
• Розробка стратегії для кожного типу дубля (параметри, пагінація, www тощо).
• Технічна реалізація: впровадження canonical через код сайту, шаблони, HTTP-заголовки.
• Перевірка через Google Search Console та URL Inspection Tool, підтвердження коректної індексації.
• Документація щодо використаного рішення.
• Навчання команди (опціонально) — як підтримувати canonical при додаванні нових сторінок.
• Підтримка протягом 30 днів після впровадження — коригування за потреби.

Canonical в HTTP-заголовку для PDF та інших файлів

Для не-HTML ресурсів (PDF, зображення) ми використовуємо HTTP-заголовок Link:

return response($pdf)
    ->header('Content-Type', 'application/pdf')
    ->header('Link', '<https://example.ru/docs/report>; rel="canonical"');

Гарантія результату: перевірка через Google Search Console

Після налаштування ми перевіряємо кожен URL через URL Inspection Tool у Google Search Console. Якщо виявлений canonical не збігається з вказаним, шукаємо причину (конфліктуючі редиректи, неправильний реферер, відсутність індексації). Наші інженери з багаторічним досвідом гарантують коректну роботу canonical на будь-якому стеку: Laravel, Symfony, WordPress, Django, Next.js.

Порівняння: правильно налаштований canonical дає приріст LCP на 10–15% за рахунок зниження дублювального контенту, який краулери витрачають на марні сторінки.

Терміни та вартість

Базова настройка для типового сайту — від 1 до 3 днів. Вартість розраховується індивідуально, виходячи з кількості сторінок та складності архітектури. Ми оцінюємо проєкт безкоштовно — просто напишіть нам. Замовте аудит canonical та отримайте звіт із рекомендаціями. Зв'яжіться з нами для консультації. Отримайте безкоштовну консультацію з налаштування canonical для вашого проєкту.

Чому 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 пунктів.