Виправлення дубльованого контенту в WordPress: канонічні URL, кінцевий слеш і WWW без канібалізації

October 30, 2025 • February 3, 2026 • Читання: 5 хв • Views: 9

Було корисно?

Деякі сайти на WordPress не мають проблеми з SEO. У них криза ідентичності URL.

Якщо ваш контент доступний за чотирма різними URL (HTTP/HTTPS × www/non-www, плюс опційний завершальний слеш), Google не «вибирає найкращий», як багато хто сподівається. Воно тестує, обережно підходить і іноді розподіляє сигнали. Тим часом ваші сторінки конкурують одна з одною, ніби колеги, які «співпрацюють», створюючи паралельні таблиці.

Чому виникає безлад з дубльованими URL у WordPress

Дубльований контент у WordPress зазвичай — не «хтось скопіював мій допис». Це ваш власний сайт генерує кілька правдоподібних URL для одних і тих же байтів. З погляду надійності це не просто «SEO». Це непослідовна маршрутизація і непослідовна ідентичність. Система цього не любить.

Що тут означає «дубльований контент»

Пошукові системи індексують не «сторінки», а URL. Якщо той самий контент з’являється на кількох URL, виникає:

Розпорошення сигналів: зворотні посилання та внутрішні посилання розподіляються між варіантами.
Збільшення індексу: бюджет сканування витрачається на дублі замість нового контенту.
Канібалізація: схожі сторінки (або дублі) конкурують за позиції, особливо по головним запитам.
Пекло налагодження: ви не можете сказати, який URL — «істинний», бо сам сайт не веде себе так, ніби це знає.

Звичні підозрювані: протокол, хост, слеш і «допоміжні» плагіни

Типові шаблони дубльованих URL у WordPress:

HTTP vs HTTPS (часто через неповну міграцію або неправильно налаштований редирект на краю мережі).
www vs non-www (відсутність примусової канонізації хоста).
Завершальний слеш vs без слешу (налаштування сервера і permalink WordPress не збігаються).
Індексні файли: / vs /index.php vs /index.html залишки.
Параметри запиту: UTM-параметри, сортування, пагінація, ідентифікатори сесій, ID кліків реклами.
Архіви: архіви автора, дати, тегів, які дублюють витяги або повний вміст постів.
Сторінки вкладень: URL медіа-вкладень WordPress, що дублюють зображення, але створюють тонкі сторінки.

Канонізація — це не «SEO-лайфхак». Це контракт маршрутизації. Визначте, який URL є канонічним, забезпечте його на рівні краю мережі і зробіть так, щоб WordPress виводив узгоджені внутрішні посилання. Зробіть ці три речі — і решта стане нудною, що й є метою.

Цікаві факти та історичний контекст (чому це повторюється)

Ранні веб-сервери трактували “/dir” і “/dir/” по-різному, бо один виглядав як файл, а інший — як директорія. Ця спадщина й сьогодні просочується в сучасні стеки.
Елемент rel=”canonical” з’явився в Google у 2009 році після років боротьби сайтів із дубльованими URL через параметри відстеження та синдикацію.
WWW не є обов’язковим; це просто конвенція імені хоста. Але CDN і практика обмеження cookie в 2000-х зробили «www» популярним вибором для операційної сумісності.
Permalink WordPress змінили правила гри, дозволивши «красиві URL», але це також полегшило випадкову видачу одного поста за кількома шляхами, коли правила перезапису розходяться.
Завершальний слеш став майже релігією частково через поведінку Apache щодо директорій (і пізніше поведінку канонічних редиректів WordPress), що створило передбачувані шаблони, які SEO-фахівці стандартизували.
Міграції HTTP→HTTPS історично викликали масивне дублювання, бо додавали TLS, але забували примусовий редирект і оновлення внутрішніх посилань, залишаючи обидва протоколи живими місяцями.
Повідомлення Search Console «Duplicate, Google chose different canonical» — це сучасна версія старої історії: якщо ви не оберете один URL, Google обере за вас. Іноді — той, який вам не подобається.
Канонічні теги — це підказки, а не команди — вони працюють краще, коли їх підкріплено узгодженими редиректами та внутрішнім лінкуванням.
CDN додали новий режим відмови: у вас можуть бути ідеальні редиректи на origin, але edge-кеш зберігає неправильний варіант або обходить логіку редиректів «заради швидкодії».

Швидка інструкція діагностики (перевірте це спочатку)

Якщо ви на виклику через «SEO впало» або «Google індексує дивні URL», не блукайте адмінкою WordPress натискаючи кнопки. Ставтеся до цього як до інцидент-реагування: визначте політику канонізації, перевірте її виконання, потім очистіть джерела (sitemap, внутрішні посилання, кеші).

Перевірте, що робить головна сторінка для різних варіантів.
- Тест: http проти https, www проти non-www, слеш проти без слешу.
- Мета: кожен неканонічний варіант має робити 301 на канонічний URL в один крок.
Перевірте репрезентативний URL поста та категорії/тегу.
- Пости часто поводяться правильно, архіви — часто ні.
- Шукайте 200-відповіді на кількох варіантах або ланцюги редиректів.
Перевірте канонічні теги і заголовки на канонічному URL.
- Мета: <link rel="canonical" ...> має відповідати фінальному URL після редиректів.
- Жодних суперечностей: канонічний не має вказувати на неконанічний хост/протокол/слеш.
Перевірте внутрішні посилання на узгодженість.
- Якщо ваш HTML посилається на неканонічні URL, ви голосуєте проти себе.
Перевірте sitemap і фіди.
- URL у sitemap мають бути канонічними. Якщо sitemap містить неканонічні URL, ви фактично здаєте дублікати.
Перевірте поведінку на рівні краю (CDN/WAF/load balancer).
- Переконайтеся, що редиректи відбуваються до кешування, і ключ кешу не розділяє за хостом/протоколом непередбачувано.

Парафраз Werner Vogels: Все ламатиметься, постійно; проєктуйте, враховуючи відмови. Канонізація — саме про це: припустіть, що хтось потрапить на неправильний URL, і зробіть систему само-виправною.

Канонічні теги vs редиректи vs внутрішні посилання (хто перемагає)

Ви почуєте «додайте канонічний тег». Це все одно, що сказати «просто додайте моніторинг», поки база даних горить. Канонічні теги важливі, але вони не примушують. Примушування — це редиректи та узгоджене лінкування.

Редиректи: регулювальник трафіку

301-редирект каже: «цей URL — не той, ідіть сюди». Пошукові системи зазвичай консольдують сигнали через 301 з часом. Це також не дозволяє користувачам зберігати в закладках неправильні варіанти.

Оперативна перевага: нормалізацію хоста/протоколу/слешу краще робити на краю (nginx/Apache/CDN), до запуску PHP WordPress. Це швидше, дешевше і менш крихке.

Канонічні теги: бюлетень голосування

Елемент rel=”canonical” — це підказка в HTML. Він корисний, коли ви не можете редиректити (наприклад, для варіантів з параметрами, які ви хочете лишити доступними). Він також допомагає пошуковим системам консолідувати дублікати, які все ще існують.

Правило: канонічні теги мають відповідати фінальному, перенаправленому URL. Якщо ви вказуєте canonical на URL, який сам редиректить, ви даєте змішані сигнали.

Внутрішні посилання: культура компанії

Внутрішні посилання показують, у що вірить ваша система. Якщо меню, хлібні крихти та інлайн-посилання вказують на різні варіанти, ви продовжите генерувати шляхи сканування до дублів навіть за наявності редиректів. Потрібні чисті внутрішні посилання, щоб краулери витрачали час на реальні сторінки.

Що важливіше?

Для хоста/протоколу/слешу: редиректи першими, потім узгоджені внутрішні посилання, потім канонічні теги. Канонічні теги корисні, але вони найменш авторитетні з трьох.

Жарт №1: Канонізація — як правила іменування: всі погоджуються, що вони важливі, аж поки не доводиться щось перейменовувати.

Виберіть політику «єдиний істинний URL»

Ви не зможете виправити дублювання, доки не вирішите, як має виглядати «правильно». Виберіть політику і зафіксуйте її письмово. Це те, що більшість команд пропускає, а потім дивуються, чому виправлення знову «розвалюється».

Як це впливає на канібалізацію

Коли існують дублікати, Google може ранжувати різні варіанти в різний час. Це виглядає як «канібалізація», бо ваш сайт постійно перемикає, який URL має право. Коли ви консолідуєтеся в один канонічний URL, ви перестаєте конкурувати самі з собою і починаєте конкурувати зі світом. Це значно здоровіше.

Практичні завдання з командами: доведіть проблему, потім виправте

Нижче — практичні завдання, які ви можете виконати з shell. Кожне завдання містить: команду, реалістичний вивід, що це означає, і рішення, яке потрібно прийняти.

Припущення: ви можете виконувати команди з робочої станції або bastion-хосту. Замініть example.com на ваш домен.

Завдання 1: Перевірити поведінку редиректів між протоколами/хостами

cr0x@server:~$ for u in http://example.com https://example.com http://www.example.com https://www.example.com; do echo "== $u =="; curl -sI "$u" | egrep -i 'HTTP/|location:|canonical'; done
== http://example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://example.com ==
HTTP/2 301
location: https://www.example.com/
== http://www.example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://www.example.com ==
HTTP/2 200

Що це означає: Ідеально: три варіанти 301 ведуть на канонічний, канонічний повертає 200. Жодних циклів редиректів, жодних 200 на неканонічних варіантах.

Рішення: Якщо будь-який неканонічний варіант повертає 200 — потрібно зробити редиректи на рівні краю. Якщо ви бачите 302 — змініть на 301, хіба це тимчасова міграція.

Завдання 2: Виявити ланцюги редиректів (тільки один крок бажаний)

cr0x@server:~$ curl -sIL http://example.com | awk 'BEGIN{c=0} /^HTTP/{c++; print "Hop " c ": " $0} /^location:/{print "  " $0}'
Hop 1: HTTP/1.1 301 Moved Permanently
  location: https://example.com/
Hop 2: HTTP/2 301
  location: https://www.example.com/
Hop 3: HTTP/2 200

Що це означає: Три стрибки. Це не катастрофа, але неохайно й повільно в масштабі.

Рішення: Згорніть в один редирект: HTTP+non-www має відразу вести на HTTPS+www (або на ваш обраний канонічний варіант).

Завдання 3: Перевірити, чи канонічний тег відповідає фінальному URL

cr0x@server:~$ curl -s https://www.example.com/some-post/ | grep -i '<link rel="canonical"' | head -n 1
<link rel="canonical" href="https://example.com/some-post/" />

Що це означає: Сторінка віддається на www, але canonical вказує на non-www. Це — суперечність.

Рішення: Виправте налаштування WordPress «Site Address (URL)» і/або параметри SEO-плагіна, щоб canonical використовував канонічний хост. Також перевірте, чи немає жорстко прописаних URL у темі.

Завдання 4: Перевірити поведінку завершального слешу для поста

cr0x@server:~$ curl -sI https://www.example.com/some-post | egrep -i 'HTTP/|location:'
HTTP/2 301
location: https://www.example.com/some-post/

Що це означає: Варіант без слешу редиректить на варіант зі слешем. Добре (якщо слеш — ваша політика).

Рішення: Переконайтесь, що така поведінка узгоджена для постів, сторінок і категорій. Невідповідності породжують дублікати.

Завдання 5: Перевірити поведінку завершального слешу для категорії

cr0x@server:~$ curl -sI https://www.example.com/category/widgets | egrep -i 'HTTP/|location:'
HTTP/2 200

Що це означає: Категорія без слешу повертає 200. Якщо /category/widgets/ також повертає 200, у вас є дублікати.

Рішення: Визначте правило і застосуйте його (зазвичай слеш). Налаштуйте правила перезапису nginx/Apache і перевірте структуру permalink WordPress.

Завдання 6: Виявити дублікати з «index.php»

cr0x@server:~$ curl -sI https://www.example.com/index.php | egrep -i 'HTTP/|location:'
HTTP/2 200

Що це означає: Головна сторінка доступна через /index.php. Класичний дублікат.

Рішення: Додайте 301-редирект з /index.php на / на рівні веб-сервера (або використайте канонічний редирект WordPress, але серверний рівень чистіший).

Завдання 7: Перевірити заголовки на кешування редиректів (з пастками CDN)

cr0x@server:~$ curl -sI http://example.com/some-post/ | egrep -i 'HTTP/|location:|cache-control:|age:|via:'
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/some-post/
cache-control: max-age=3600
age: 3540
via: 1.1 varnish

Що це означає: Редирект кешується годину і вже має вік. Добре, якщо правильний; небезпечно, якщо неправильний, бо зберігатиметься.

Рішення: Якщо ви активно змінюєте правила канонізації, тимчасово зменшіть TTL кешу редиректів або очистіть edge-кеш після змін.

Завдання 8: Перевірити URL у sitemap на канонічність хоста/протоколу

cr0x@server:~$ curl -s https://www.example.com/sitemap_index.xml | head -n 20
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>http://example.com/post-sitemap.xml</loc>
    <lastmod>2025-12-01T12:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Що це означає: Sitemap рекламує http://example.com URL. Це самошкодження.

Рішення: Виправте URL сайту в WordPress, налаштування SEO-плагіна і переконайтеся, що генератор sitemap використовує HTTPS+канонічний хост.

Завдання 9: Просканувати на неканонічні внутрішні посилання (швидко і грубо)

cr0x@server:~$ curl -s https://www.example.com/ | grep -Eo 'href="https?://[^"]+"' | head
href="http://example.com/about/"
href="https://example.com/contact/"
href="https://www.example.com/blog/"

Що це означає: Головна містить змішані внутрішні абсолютні посилання (http і non-www). Це продовжує генерувати дублікати.

Рішення: Оновіть URL сайту в WordPress, виправте шаблони теми і виконайте пошук/заміну в базі даних для застарілих абсолютних URL.

Завдання 10: Аудит налаштованих URL WordPress через WP-CLI

cr0x@server:~$ wp option get siteurl && wp option get home
https://example.com
https://example.com

Що це означає: WordPress вважає канонічним non-www.

Рішення: Якщо ваш вибір — www, встановіть обидві опції на https://www.example.com, а потім переконайтеся, що редиректи узгоджені.

Завдання 11: Безпечно змінити home/siteurl у WordPress (і знати, що ви змінили)

cr0x@server:~$ wp option update home 'https://www.example.com' && wp option update siteurl 'https://www.example.com'
Success: Updated 'home' option.
Success: Updated 'siteurl' option.

Що це означає: WordPress почне генерувати канонічні URL і внутрішні посилання з www (якщо тема/плагіни це поважають).

Рішення: Негайно повторно перевірте канонічні теги і вивід sitemap. Потім очистіть кеші (сторінковий кеш + CDN), щоб старий HTML не продовжував просівати змішані хости.

Завдання 12: Знайти застарілі хости в базі (швидка перевірка)

cr0x@server:~$ wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://example.com/%' LIMIT 5;"
+----+-----------------------------+
| ID | post_title                  |
+----+-----------------------------+
| 12 | About Us                    |
| 87 | How to Choose a Widget      |
| 91 | Pricing                     |
+----+-----------------------------+

Що це означає: У контенті постів є жорстко прописані застарілі посилання. Редиректи спіймають користувачів, але краулери все ще будуть знаходити неканонічні URL.

Рішення: Виконайте обережний пошук/заміну (з урахуванням серіалізації). Віддавайте перевагу wp-cli search-replace і тестуйте на бекапі перед виконанням.

Завдання 13: Виконати безпечну для серіалізації пошук/заміну хоста/протоколу

cr0x@server:~$ wp search-replace 'http://example.com' 'https://www.example.com' --all-tables --dry-run
Success: Made 128 replacements.

Що це означає: Dry-run показує, скільки замін відбудеться без змін у даних.

Рішення: Якщо кількість замін прийнятна — запустіть знову без --dry-run. Якщо число лякає — звузьте область і перевірте вибірки перед масовою операцією.

Завдання 14: Переконатися, що директиви для роботів не заважають

cr0x@server:~$ curl -sI https://www.example.com/some-post/ | egrep -i 'x-robots-tag:|HTTP/'
HTTP/2 200

Що це означає: Заголовку X-Robots-Tag немає. Добре.

Рішення: Якщо ви бачите X-Robots-Tag: noindex на канонічних сторінках — припиніть і виправте це перед усім іншим. Ви не зможете канонізувати сторінку, якщо кажете Google її не індексувати.

Завдання 15: Перевірити конфіг серверу на наявність канонічних редиректів (nginx)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'server_name|return 301|rewrite' | head -n 30
42:    server_name example.com;
47:    return 301 https://www.example.com$request_uri;
88:    server_name www.example.com;

Що це означає: Існує окремий серверний блок, що редиректить non-www на www.

Рішення: Підтвердіть, що редирект спрацьовує для обох vhost-ів HTTP і HTTPS. Також переконайтеся, що це не створює додатковий крок (див. Завдання 2).

Завдання 16: Переконатися, що Apache не робить «дружню» MultiViews-нейголізацію

cr0x@server:~$ apachectl -M 2>/dev/null | grep -i negotiation
negotiation_module (shared)

Що це означає: Модуль контент-нейголізації увімкнено; якщо MultiViews активний, Apache може зв’язати кілька URL з одним ресурсом несподіваними шляхами.

Рішення: У vhost-ах WordPress вимкніть MultiViews, якщо немає конкретної потреби. Воно викликає дивну дубльовану маршрутизацію і складну налагоджуваність.

Налаштування WordPress, що підривають канонізацію

1) Несумісність «WordPress Address» і «Site Address»

У Налаштування → Загальні WordPress має два поля URL:

WordPress Address (URL) (siteurl): де розташовані файли ядра WordPress.
Site Address (URL) (home): що відвідувачі мають вводити.

Зазвичай вони мають співпадати. Якщо ні — ви можете отримати змішані канонічні теги, змішані внутрішні посилання і дивні редиректи.

2) Структура permalink і завершальний слеш

WordPress зазвичай очікує завершального слешу для «красивих» permalink. Але ваш веб-сервер може інакше. Якщо nginx налаштовано так, що /post і /post/ трактуються по-різному, ви можете опинитись з обома, які повертають 200 в залежності від правил перезапису.

Робіть так: виберіть політику щодо завершального слешу і примусьте її на рівні сервера. Потім перевірте, щоб канонічні редиректи WordPress не конфліктували з цим.

3) SEO-плагіни: потужні, але іноді помиляються

Yoast, Rank Math та інші зазвичай коректно ставляться до канонічних тегів. Несправності виникають через:

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

4) Архіви, що дублюють контент

Архіви самі по собі не погані. Але вони часто стають дублікатами, коли:

Тема виводить повний вміст поста на сторінках категорій/тегів (не витяги).
Архіви автора/дати дублюють список блогу і не дають нічого унікального.
Сторінки вкладень індексуються як тонкий контент з тією ж назвою і без контексту.

Радикальна порада: якщо ваш сайт не є публікацією з корисними архівними сторінками, виставте архіви автора/дати в noindex і редиректіть сторінки вкладень на файл медіа або батьківський пост.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: у результатах Google з’являються www і non-www версії

Корінна причина: відсутність примусу одного хоста на краю; внутрішні посилання або sitemap витікають старі хости.

Виправлення: примусіть один хост через 301 на HTTP і HTTPS vhost-ах; оновіть home/siteurl в WordPress; перегенеруйте sitemap; очистіть кеші.

2) Симптом: «Duplicate, Google chose different canonical» в Search Console

Корінна причина: канонічні теги суперечать редиректам, або існують кілька варіантів з 200 (слеш/без слешу, index.php, параметри).

Виправлення: зробіть редиректи детермінованими; переконайтеся, що canonical вказує на фінальний URL; приберіть 200-дублі; нормалізуйте внутрішні посилання.

3) Симптом: щоденні коливання позицій для однієї й тієї ж сторінки

Корінна причина: канібалізація між варіантами URL або майже-дубльованими архівними сторінками. Google чергує, якому URL довіряти.

Виправлення: консолідуйте варіанти через 301; розгляньте noindex для низьковартісних архівів; переконайтеся, що sitemap містить тільки канонічні URL.

4) Симптом: цикл редиректів між http і https

Корінна причина: невідповідність SSL-термінації: CDN примушує HTTPS до origin, а origin примушує HTTP, або WordPress думає, що працює на HTTP за проксі.

Виправлення: встановіть коректні заголовки проксі (X-Forwarded-Proto), налаштуйте WordPress на їх врахування і реалізуйте редиректи на відповідному шарі (перевага — край).

5) Симптом: ланцюг редиректів з 2–4 кроків на кожен запит

Корінна причина: окремі правила для HTTP→HTTPS, non-www→www і нормалізації слешів застосовуються по черзі між CDN і origin.

Виправлення: зведіть до одного канонізаційного редиректу. Нехай перша точка входу (CDN або LB) робить це в один крок.

6) Симптом: sitemap містить HTTP після міграції на HTTPS

Корінна причина: home/siteurl WordPress не оновлено, або плагін кешує базовий URL, або реверс-проксі не передає схему правильно.

Виправлення: виправте home/siteurl, очистіть кеш плагінів, перевірте X-Forwarded-Proto і виявлення SSL у WordPress.

7) Симптом: сторінки категорій випереджають пости незаплановано

Корінна причина: архіви категорій індексовані з подібними заголовками/контентом; внутрішні посилання та хлібні крихти посилюють архів; канонічні сигнали слабкі.

Виправлення: або вкладатись у категорійні сторінки як у реальні лендинги (унікальний текст, кураторський контент), або виставити їм noindex і зосередитись на постах.

8) Симптом: сторінки вкладень показуються як тонкі результати

Корінна причина: сторінки вкладень WordPress індексуються за замовчуванням у деяких налаштуваннях; canonical може вказувати на себе.

Виправлення: редиректіть сторінки вкладень на батьківський пост або файл медіа; якщо потрібно, виставте їх у noindex через SEO-плагін.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через хибне припущення

Компанія ще роками тому «стандартизувалась» на HTTPS. Усі припускали, що сайт — тільки HTTPS, бо браузер показував замок, а маркетинг ділився лише HTTPS-посиланнями. Класична зона комфорту.

Потім нова команда безпеки розгорнула edge WAF. Під час rollout вони додали правило, яке оминало редиректи для «перевірок стану» і «бот-трафіку», щоб зменшити навантаження на origin. Це не було зумисно. Це було просто правило copy-paste з універсальним матчем user-agent, яке зловило більше, ніж треба.

Результат: краулери почали отримувати 200-відповіді по HTTP для великих частин сайту. HTML все ще містив HTTPS-посилання, тож люди не помітили. Google помітив відразу. Через кілька тижнів Search Console загорівся помилками дублів і невідповідностей canonical. Трафік змінювався, не падаючи різко — і це гірше, бо виглядало, ніби «контент просто перестав працювати».

Виправлення не було якоюсь магічною SEO-фішкою. Видалили обхід, примусили HTTP→HTTPS на краю без винятків і очистили кеші. Урок: ніколи не припускайте, що «ми перейшли на HTTPS» означає, що система це реально застосовує. Припущення не редиректять трафік — конфіг робить.

Міні-історія 2: Оптимізація, що відбилася боком

Інженер, який дбав про швидкість, побачив ланцюги редиректів і вирішив «прискорити». Вони змінили правила nginx так, щоб і варіант зі слешем, і без слешу повертали 200, щоб уникнути редиректів. Швидкість сторінки трохи покращилась, і всі відчули себе кмітливими.

Два місяці по тому органічний трафік став нестабільним. Деякі пости ранжувалися, потім падали, потім з’являлися під іншими URL. Команда звинувачувала оновлення Google, потім контент, потім SEO-агентство. Ніхто не підозрював «оптимізацію».

Коли ми порівняли логи, виявилось, що Googlebot активно сканував обидва варіанти: /post і /post/. Внутрішні посилання теж були неузгоджені — частина генерувалась WordPress, частина була прописана в шаблонах, і вони не збігалися по слешах. Індекс наповнився дублями, а вага посилань розпорошилась між варіантами.

Ми повернулися до єдиної політики, повернули 301-нормалізацію і почистили внутрішні посилання. Продуктивність не постраждала, бо origin не відпрацьовував редиректи — край це робив. Мораль: не оптимізуйте редиректи в ціну ідентичності. Ви економите мілісекунду і втрачаєте квартал позицій.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша організація тримала WordPress за CDN і балансувальником. Вони мали просте нудне правило: «тест нормалізації URL» має проходити в CI перед будь-яким деплоєм конфігурацій, що торкаються краю або vhost-ів.

Тест не був складним. Він запускала curl -I проти десятка показових URL і перевіряв: один крок до канонічного, правильні статус-коди, canonical тег відповідає фінальному URL, і URL у sitemap починаються з канонічної бази. Оце й усе.

Одного дня вендор запропонував увімкнути «Automatic HTTPS Rewrites» плюс окрему опцію «Forwarding URL» для примусу www. Поєднання створило ланцюг і в одному краю — цикл для пагінованих архівів. CI-тест зафіксував проблему до релізу.

Жодного інциденту. Жодної зливи в кімнаті криз. Просто провалений чек і швидке виправлення. Нудне перемагає. Найнадійніша SEO-робота не відрізняється від хорошої операційної гігієни.

Перевірочні списки / покроковий план

Крок 1: Задекларуйте політику канонізації (запишіть)

Канонічний протокол: HTTPS
Канонічний хост: www або non-www
Завершальний слеш: так або ні (будьте послідовні)
Індексні файли: ніколи не канонічні
Політика параметрів: які параметри дозволені, які ігноруються, які блокуються/noindex

Крок 2: Впровадьте однокрокові редиректи на краю/на origin

Робіть це якомога ближче до користувача (CDN/LB), але переконайтеся, що це детерміновано і тестовано. Якщо не можете на краю — зробіть в nginx/Apache.

Приклад патерну для nginx (концептуально)

Тримайте це просто: один server block для неканонічного хоста повертає 301 на канонічний. Інший для канонічного віддає контент. Потім уважно застосуйте правила щодо слешів, щоб не створювати 200-дублікати.

Крок 3: Зробіть так, щоб WordPress генерував канонічні URL послідовно

Встановіть home і siteurl на канонічну базу.
Переконайтеся, що канонічні теги відповідають канонічній базі.
Виправте жорстко прописані абсолютні посилання в темі.
Проведіть пошук/заміну застарілих базових URL в контенті (обережно).

Крок 4: Виправте sitemap і фіди

Індекс sitemap і дочірні sitemap мають містити лише канонічні URL.
Якщо ви змінили базовий URL — перегенеруйте sitemap і очистіть кеші.
Перевірте RSS/Atom фіди на застарілі хости, якщо ви на них покладаєтесь.

Крок 5: Контролюйте індексацію архівів, щоб зменшити канібалізацію

Якщо категорії/теги — стратегічні лендинги, робіть для них унікальний контент і структуру.
Якщо ні — виставте їх у noindex і залиште бюджет сканування для постів/сторінок.
Вимкніть або виставте на noindex архіви автора/дати, якщо вони не дають унікальної цінності.
Редиректіть або ставте на noindex сторінки вкладень.

Крок 6: Повторно протестуйте і моніторте

Повторіть Завдання 1–9 після змін.
Слідкуйте в логах за 200-відповідями на неканонічні варіанти.
Спостерігайте Search Console за зменшенням звітів про дублювання протягом тижнів (не годин).

Жарт №2: Якщо у вашого сайту п’ять канонічних URL, вітаю — ви винайшли розподілену систему. На жаль, це ваш маркетинговий сайт.

Питання та відповіді

1) Чи обирати www або non-www для WordPress?

Будь-який варіант підходить. Оберіть один і примусьте його через 301-редиректи та узгоджені внутрішні посилання. Операційно www може бути зручнішим для CDN і scoping cookie, але це не обов’язково.

2) Чи достатньо канонічних тегів, щоб вирішити дублювання?

Ні. Канонічні теги — підказки. Для питань протокол/хост/слеш використовуйте 301-редиректи плюс узгоджене внутрішнє лінкування. Canonical допомагає прибрати випадкові випадки, як параметри і синдикація.

3) Чому я все ще бачу дублікати після виправлення редиректів?

Тому що шляхи відкриття залишаються: внутрішні посилання, sitemap, зовнішні зворотні посилання, кешовані сторінки та старі дані сканування. Виправте джерела (внутрішні посилання і sitemap) і дочекайтеся. Також переконайтесь, що неканонічні варіанти дійсно повертають 301, а не 200.

4) Чи примусовувати завершальні слеші?

Якщо ви використовуєте «красиві» permalink WordPress — так, найзручніше примусити послідовний завершальний слеш. Ключ — послідовність і однокрокові редиректи. Не віддавайте обидва варіанти.

5) UTM-параметри — це дубльований контент?

Вони можуть створювати дубльовані URL. Зазвичай дозволяють їх для аналітики, але переконайтесь, що canonical вказує на чистий URL, і уникайте індексації варіантів з параметрами. Не блоковуйте UTMs редиректами, якщо не розумієте наслідків для відстеження кампаній.

6) Як CDN ускладнює ситуацію?

CDN може кешувати редиректи, розділяти ключі кешу за хостом/протоколом або застосовувати «дружні» переписування, що конфліктують з origin. Виправлення — зробити правила канонізації явними і протестувати їх на краю і на origin.

7) Чому WordPress іноді редиректить несподівано?

У WordPress є власна логіка канонічних редиректів, що намагається вгадати правильний permalink. Якщо серверні правила перезапису або налаштування site URL неконсистентні, WordPress може додати кроки або редиректити на неправильний хост. Виправте політику URL спочатку.

8) Чи варто виставляти noindex для тегів/категорій, щоб уникнути канібалізації?

Якщо ці сторінки не мають унікальної цінності — так: noindex часто найчистіший вихід. Якщо вони важливі як лендинги, залиште їх індексованими, але зробіть їх по-справжньому відмінними (унікальний текст, кураторський контент, хороші заголовки).

9) Який статус коду використовувати: 301 чи 308?

301 широко підтримується і зрозумілий. 308 теж підходить (постійний редирект з збереженням методу), але 301 залишається консервативним вибором для сумісності зі старими інструментами.

10) Чи можна вирішити це виключно в WordPress без змін серверної конфігурації?

Ви можете покращити канонічні теги і внутрішні посилання в WordPress, але нормалізацію хоста/протоколу слід робити на сервері або на краю. Робити це в PHP працює до певного моменту — поки кеші, проксі або плагіни не змінять поведінку під навантаженням.

Висновок: практичні наступні кроки

Якщо цього тижня ви не зробите більше нічого, зробіть ці три речі:

Оберіть і задокументуйте політику канонічного URL (HTTPS + обраний хост + стиль завершального слешу).
Примусьте її однокроковими 301-редиректами на краю або веб-сервері, для HTTP і HTTPS слухачів.
Зупиніть витік WordPress неканонічних посилань: встановіть home/siteurl, виправте канонічні теги, перегенеруйте sitemap і почистіть внутрішні абсолютні посилання.

Потім знову запустіть командні завдання, особливо ті, що ловлять 200 на варіантах та невідповідності canonical. Коли ваш сайт матиме одну ідентичність, позиції припинять грати в музичні стільці. І ваш майбутній я отримає менше тикетів «чому Google індексує обидві версії», що є тихою розкішшю правильної роботи.

Схожі статті

Ubuntu 24.04: плутанина Apache і Nginx — як чисто вирішити привʼязку портів і проксі-петлі (випадок №94)