Одна з найчастіших технічних причин, чому сайт «сам собі заважає» в пошуку, виглядає безневинно: той самий товар або стаття відкривається за кількома адресами. Візуально нічого не зламано — людина навіть не помітить. Але пошук бачить не картинку, а адреси, і кожна нова адреса для нього — окрема сторінка.
Звідки беруться дублі
Технічні варіанти адреси. Сайт може віддавати вміст із www і без нього, за http і https, зі слешем у кінці й без. Якщо жодна з версій не перенаправляє на іншу, їх стає чотири й більше — з абсолютно однаковим текстом.
Мітки в адресі. UTM-мітки з реклами й розсилок створюють нову адресу на кожну кампанію. Самі по собі вони не смертельні, але коли на такі адреси ще й ставлять внутрішні посилання, плутанина множиться — про це докладніше в матеріалі про UTM-мітки й відстеження джерел.
Фільтри й сортування в каталозі. Найбільший генератор дублів в інтернет-магазині. Кожна комбінація «колір + розмір + ціна + сортування» — це технічно нова адреса зі схожим набором товарів. Сотні комбінацій зʼявляються самі, без жодної участі людини. Як розділяти те, що має бути окремою сторінкою, і те, що має лишитися фільтром, розібрано в матеріалі про структуру каталогу.
Один товар у кількох категоріях. Якщо адреса товару містить категорію, той самий товар живе за різними шляхами залежно від того, звідки на нього зайшли.
Сторінки пагінації. Друга, третя, десята сторінка списку — не дублі за замовчуванням, але поводитися з ними треба свідомо, інакше вони або випадають з обходу, або конкурують із першою. Це окрема тема — пагінація каталогу і SEO.
Чим це реально шкодить
Головна шкода не в «покаранні» — жодного штрафу за технічні дублі немає. Шкода тонша.
Вага розпорошується. Посилання, які мали б підсилювати одну сторінку, розподіляються між копіями. Замість однієї сильної сторінки виходить кілька слабких.
Обхід витрачається намарно. Робот має обмежений ресурс на сканування сайту. Якщо він щодня перебирає сотні варіантів фільтрів, нові сторінки чекають своєї черги тижнями. Механіка описана в розборі краулінгового бюджету.
У видачу потрапляє не та сторінка. Пошук обирає головну версію сам — і може показати адресу з міткою, з параметром сортування або стару версію без оновленого тексту.
Три інструменти, і кожен для свого випадку
301-редирект — коли стара адреса більше не потрібна. Це найсильніший сигнал: сторінка переїхала назавжди, вага передається новій. Так закривають технічні варіанти (www → без www, http → https, без слеша → зі слешем) і адреси після зміни структури. Правила безпечного перенесення — у матеріалі про перенесення сайту без втрати позицій.
Canonical — коли обидві адреси мають працювати. Тег указує пошуку: «показуй ось цю версію». Сторінка з фільтром лишається доступною для покупця, але вага йде на основну категорію. Ключова умова: адреса, на яку вказує canonical, має віддавати код 200 і сама на себе посилатися. Canonical на сторінку, яка редиректить або не існує, ігнорується.
Noindex — коли сторінка потрібна людям, але не потрібна в пошуку. Наприклад, результати внутрішнього пошуку або службові сторінки. Важливо не плутати це з robots.txt — різницю розібрано в матеріалі про robots.txt і sitemap.
Порядок, у якому це розбирають
Спершу — технічні варіанти адреси. Відкрийте головну з www і без, з https і http, зі слешем і без: усе, крім однієї версії, має віддавати 301 на неї. Це пʼять хвилин перевірки, які закривають найбільшу частину проблеми.
Далі — внутрішні посилання. Сайт має посилатися сам на себе виключно канонічними адресами. Якщо меню веде на версію без слеша, а canonical указує на версію зі слешем, ви даєте пошуку два суперечливі сигнали одночасно.
Потім — каталог і фільтри. Тут рішення не технічне, а змістове: комбінації, за якими реально шукають люди, варті окремих сторінок із власним текстом; решта закривається canonical на категорію.
І наостанок — перевірка в Search Console. У звіті про індексацію дублі мають окремі статуси: «сторінка є копією, canonical не вибрано користувачем» означає, що пошук вирішив за вас. Як читати цей звіт, описано в матеріалі про Google Search Console для початківців.
Коротко
Дублі — це коли один вміст доступний за кількома адресами: технічні варіанти домену, мітки, фільтри каталогу, товар у різних категоріях. Штрафу за них немає, але вага розпорошується між копіями, обхід сайту витрачається на перебір варіантів, а у видачу потрапляє не та версія. Лікується трьома інструментами під різні випадки: 301 — коли стара адреса не потрібна, canonical — коли обидві мають працювати, noindex — коли сторінка потрібна людям, але не пошуку. Закривати дублі в robots.txt не можна: заборона сканування не прибирає сторінку з видачі, зате приховує від пошуку сам canonical. Починати завжди з технічних варіантів адреси й внутрішніх посилань — це найдешевша частина роботи з найбільшим ефектом.
Ми в Obliko розробляємо сайти з нормальною структурою адрес від початку — щоб не доводилося розплутувати дублі вже після того, як сайт набрав позиції.
Що таке дублі сторінок простими словами?
Це коли той самий вміст доступний за різними адресами: з www і без, з завершальним слешем і без, з UTM-міткою в кінці, через фільтр каталогу, через сортування. Для людини це одна сторінка, для пошуку — кілька різних адрес з однаковим текстом. Пошук змушений сам вирішувати, яку з них показувати, і його вибір не завжди збігається з вашим.
Чи можна просто закрити дублі в robots.txt?
Це поширена помилка. Заборона в robots.txt забороняє сканування, а не показ: сторінка може лишитися у видачі без опису, і при цьому пошук більше не побачить на ній тег canonical, який мав би вказати на головну версію. Правильна логіка — навпаки: дозволити сканування й дати чіткий сигнал canonical або 301-редирект.
Чи шкодять дублі, якщо їх мало?
Кілька технічних дублів — не катастрофа, пошук зазвичай сам обирає головну версію. Проблема виникає на масштабі: коли фільтри каталогу породжують сотні адрес, обхід сайту витрачається на них замість нових сторінок, а вага розмивається між копіями. Тому перевіряти варто не наявність дублів взагалі, а їхню кількість і причину.
Що робити, якщо в індекс потрапила не та версія сторінки?
Спершу переконатися, що на всіх копіях стоїть canonical на потрібну адресу і що ця адреса віддає код 200 без редиректу. Потім перевірити внутрішні посилання: якщо сайт сам посилається на «неправильну» версію, пошук довіряє посиланням більше, ніж тегу. Після виправлення переіндексація займає від кількох днів до кількох тижнів.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.