Навчання
Duplicate content canonicalization: canonical tags, parameters і URL variants
Практичний гайд про duplicate content і canonicalization: звідки беруться варіанти URL, як вибрати між canonical, redirect і noindex, і як безпечно обʼєднати.
Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.
Що duplicate content насправді тобі коштує
Немає «штрафу за duplicate content» у тому вигляді, якого бояться. Насправді відбувається розмивання й непередбачуваність: коли той самий контент лежить на кількох URL, Google мусить обрати один для індексації та ранжування — і може обрати не той, що ти хочеш. Посилання, увага краулера й сигнали ранжування розпорошуються по варіантах замість того, щоб концентруватися на одному сильному URL.
Це також марнує crawl budget. На великому сайті тисячі майже однакових параметричних і фільтрових URL означають, що Google витрачає час на переобхід копій замість виявлення справді нових сторінок — проблема, що наростає з ростом сайту.
Звідки беруться дубльовані URL
Дублювання рідко коли — це хтось скопіював статтю. Майже завжди це та сама сторінка, доступна через багато URL:
- Варіанти протоколу й хоста: http проти https, www проти без-www, зі слешем у кінці й без.
- Трекінгові й сесійні параметри: ?utm_source=…, ?sessionid=…, що змінюють URL, але не контент.
- Фасетна навігація й порядки сортування: ?color=red&sort=price, що дає безкінечні комбінації.
- Пагінація й версії «view all» того самого списку.
- Верхній/нижній регістр у шляхах, index.html проти /, а також printer- чи AMP-варіанти.
Canonical, redirect чи noindex: як обрати інструмент
Вони не взаємозамінні — обирай за тим, що має статися з дубльованим URL.
- 301 redirect: коли дубль взагалі не має існувати як окремий URL (http→https, обʼєднання www, старий→новий). Він консолідує сигнали й прибирає варіант.
- rel="canonical": коли обидва URL мають лишатися доступними, але ранжуватися має лише один (параметричні варіанти, товар у двох категоріях). Це підказка, а не директива — тримай сторінки майже однаковими, інакше Google може її перекрити.
- noindex: коли сторінка має лишатися доступною користувачам, але ніколи не ранжуватись (внутрішній пошук, тонкі комбінації фільтрів). Не поєднуй noindex із canonical на інший URL.
- robots.txt: не інструмент дедуплікації — він блокує crawling, тож Google навіть не бачить твій canonical.
Як безпечно обʼєднати дублі
- Визнач єдиний canonical URL для кожного контенту й зроби так, щоб внутрішні посилання, sitemaps і canonical вели на нього.
- Забезпеч один хост і протокол через site-wide 301 і нормалізуй слеші в кінці та регістр.
- Для параметрів, що не змінюють контент, став canonical на чистий URL; для фасетів, що створюють цінність, вирішуй по кожному, чи індексувати.
- Зроби canonical самопосилальним на URL, який хочеш ранжувати, щоб він випадково не вказував деінде.
- Розкочуй зміни по шаблонах і перескановуй перед застосуванням патерну на весь сайт.
Помилки, що погіршують дублювання
- Блокувати дубльовані URL у robots.txt, що не дає Google прочитати canonical, який їх би обʼєднав.
- Ставити canonical на сторінку, яка сама редиректить або має noindex, що робить підказку невалідною.
- Спрямовувати canonical кожної пагінованої сторінки на сторінку 1, що ховає глибші елементи від індексації.
- Змішувати сигнали: canonical на URL A, тоді як внутрішні посилання, sitemap і hreflang вказують на URL B.
Як перевірити консолідацію
Скористайся URL Inspection на дублі й підтверди, що Google показує обраний тобою URL як «Google-selected canonical», потім стеж, як кошики «Duplicate» і «Alternate page» у звіті Page Indexing зменшуються наступні тижні, поки консолідація діє.
У DomainLens ціль canonical і статус-код показуються разом, тож сторінка, чий canonical вказує кудись несподівано — або варіант, що віддає 200 там, де мав би редиректити — спливає як конфлікт, який можна виправити, перш ніж він розпорошить твої сигнали ранжування.