Умовний магазин продає ручний спінювач MF-6. Картка відкривається безпосередньо й за посиланням із листа з міткою кампанії. Покупцеві потрібні обидва шляхи, а бажана адреса для пошуку узгоджена без мітки. Тепер це рішення потрібно правильно вивести з CMS і перевірити у відповіді сайту.
Rel canonical указує представника однакового або дуже схожого вмісту. Він не перенаправляє відвідувача, не забороняє обходу й не гарантує, що Google вибере саме зазначену сторінку. Тому приймання налаштування та спостереження за вибором пошукової системи – окремі завдання.
Зафіксуйте призначення кожного варіанта
Запишіть основний URL MF-6 і варіант, використаний у розсилці. Уточніть, що параметр справді потрібен лише для обліку переходу: модель, комплектація та пропозиція не змінюються. Якщо параметр вибирає інший товар, узгоджене рішення доведеться переглянути.
Окремо перевірте мову. Російська картка не повинна випадково оголосити своїм представником українську через спільний шаблон. Для самостійних перекладів потрібні узгоджені адреси своєї мовної версії; hreflang розв’язує інше завдання й не замінює canonical.
На цьому етапі не призначайте одну ціль усім схожим сторінкам. Інша модель MF-7 або наступна частина категорії з іншими товарами не стають копіями MF-6. Таке правило здатне позбавити самостійні сторінки потрібного пошукового представлення.
Знайдіть місце, яке формує значення
Визначте, звідки береться canonical: налаштування картки, загальний шаблон, розширення або сервер. Збережіть вихідний результат і перелік зачеплених сторінок. Якщо два компоненти додають різні значення, правка одного поля може не усунути конфлікт.
Виберіть передбачений CMS спосіб зміни. Окрема вставка в текст статті не налаштовує head сторінки. Змінюючи шаблон, заздалегідь підготуйте перевірку інших товарів і спосіб повернути попередню версію.
Для документів не у форматі HTML, наприклад PDF, можлива передача canonical через заголовок HTTP Link. Не намагайтеся розв’язати це завдання додаванням HTML-тега всередину файлу. Одночасне використання кількох способів потребує особливої уважності: їхні значення не повинні суперечити одне одному.
Виведіть узгоджену адресу в HTML
У прикладі й основний варіант MF-6, і варіант із міткою мають віддавати в коректній секції head одне й те саме бажане значення:
<link rel="canonical" href="https://example.com/ru/mf-6/">Це ілюстрація синтаксису. Домен example.com замінюють фактичним доменом, а шлях – узгодженою адресою товару. Використовуйте повний URL із протоколом: відносний шлях легше випадково пов’язати з тестовим середовищем або іншим розміщенням сторінки.
На основній картці такий тег указує на неї саму. У варіанта з листа мітка залишається у відкритій адресі, якщо це потрібно сценарію, але canonical указує на обраного представника. Збереження параметра для обліку переходу й вибір представника для пошуку не обов’язково мають розв’язуватися редиректом.
Перевірте роботу JavaScript. Бажано сформувати canonical у вихідному HTML і не змінювати його після завантаження. Якщо реалізація створює елемент лише на клієнті, потрібно перевірити його фактичну появу та відсутність конкурентного значення. Не додавайте другий тег поверх уже наявного без перевірки.
Перевірте, куди веде саме значення
Відкрийте зазначений URL і отримайте його відповідь. Ціль має відповідати узгодженій картці MF-6, віддавати корисний вміст і бути призначеною для індексації. Відповідь 200 без потрібного товару не робить призначення правильним. Перенаправлення цілі на іншу адресу також потребує розбору.
Потім звірте внутрішні посилання та sitemap. Якщо меню веде на один варіант, карта заявляє інший, а canonical – третій, налаштування залишається суперечливим. Не виправляйте лише видиме поле, залишаючи джерело розбіжності в генераторі.
Не підмінюйте консолідацію забороною обходу в robots.txt, noindex або інструментом видалення URL. Ці механізми мають інше призначення. Якщо варіант потрібно остаточно закрити для відвідування та замінити новим шляхом, окремо розглядають постійне перенаправлення.
Прийміть результат за контрольними сторінками
Сформуйте контрольний набір варіантів. Для нашого прикладу він може охоплювати такі перевірки.
| Випадок | Очікуваний результат | Що ще перевірити |
|---|---|---|
| Основна картка MF-6 | Canonical указує на узгоджену адресу самої картки | Правильний товар і відсутність неочікуваного перенаправлення |
| MF-6 із міткою листа | Представник той самий | Мітка й потрібний користувацький сценарій зберігаються |
| Самостійна MF-7 | Не отримала адресу MF-6 із загального шаблону | Власний вміст і призначення |
| Українська MF-6 | Використовує узгоджену основну адресу своєї мовної версії | Переклад і зв’язки мовних версій |
Отримайте фактично опублікований HTML і заголовки для кожного випадку. Порівняйте їх із вихідним станом, знайдіть canonical у потрібному місці й переконайтеся, що скрипти не підмінюють його після відмальовування. Збережене налаштування CMS без цього читання ще не підтверджує зовнішнього результату.
Після приймання спостерігайте за новими даними перевірки URL у Search Console. Поточний тест сторінки не дає змоги передбачити майбутній вибір canonical. Якщо Google зберігає іншого представника, досліджуйте нові факти й дати, а не повторюйте ту саму вставку без підстави.
Налаштування canonical разом з узгодженням шаблонів, посилань і карти сайту можна обговорити в межах внутрішньої SEO-оптимізації сайту.
Потрібна допомога з вашим проєктом?
Залиште ім’я та номер телефону. Зв’яжуся з вами, щоб обговорити завдання, обсяг робіт і наступний крок.
