Что происходит, когда canonical tags настроены неправильно

Canonical tag — не ластик для duplicate content

Canonical tag сообщает поисковым системам, какой URL вы предпочитаете, когда несколько URL содержат одинаковый или существенно похожий контент. Обычная HTML-версия выглядит так:

<link rel="canonical" href="https://example.com/preferred-page/">

Есть также версия в HTTP header, в основном полезная для не-HTML-файлов, например PDF:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Звучит достаточно просто. Проблемы начинаются, когда команды воспринимают canonical tags как безопасный способ привести в порядок всё неудобное: faceted navigation, tracking parameters, страницы для печати, почти дублирующиеся страницы товаров, пагинацию, staging URLs и старые страницы кампаний.

Canonical tags — это не кнопка удаления. Это не redirect. Это не замена информационной архитектуре. И нет гарантии, что им будут следовать.

Поисковые системы используют canonicals как сильные подсказки. Они сопоставляют canonical tag с другими сигналами: redirects, internal links, sitemap URLs, hreflang annotations, сходством контента, HTTP status codes, а также URL, с которыми реально сталкиваются пользователи и crawlers. Если эти сигналы конфликтуют, поисковая система может проигнорировать ваш canonical или вообще выбрать другой canonical URL.

Именно поэтому ошибки в canonicals так сбивают с толку. Разметка в браузере выглядит корректно, но в результатах поиска появляется не та страница — или нужная страница исчезает.

Что происходит, когда canonical указывает на неправильный URL

Когда поисковая система видит дублирующиеся или почти дублирующиеся URL, она обычно объединяет их в кластер и выбирает один URL как canonical. Выбранный canonical — это версия, которая с наибольшей вероятностью будет проиндексирована и показана в результатах поиска. Сигналы от дублей могут быть консолидированы в этот выбранный URL.

Если ваш canonical tag указывает на неправильную страницу, может произойти несколько вещей.

1. Индексируется неправильный URL

Допустим, у вас есть два URL:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Если страница распродажи указывает canonical на основную страницу категории, это может быть нормально, если контент почти идентичен, а URL распродажи — всего лишь отфильтрованная версия. Но если у страницы распродажи есть уникальный текст, уникальные товары и собственный поисковый спрос, canonical может подавить её.

Страница всё ещё может сканироваться. Она всё ещё может быть доступна пользователям. Но поисковые системы могут решить не индексировать её отдельно, потому что вы сообщили им, что другая URL-адресная версия является предпочтительной.

Это самая частая ошибка canonical: не драматический технический сбой, а тихое исчезновение из индекса.

2. Ранжирующие сигналы консолидируются не туда

Canonicals часто используют для консолидации сигналов, таких как ссылки и варианты дублирующегося контента. Это полезно, когда дубли действительно эквивалентны. И рискованно, когда это не так.

Если у статьи в блоге есть tracking URLs, например:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

То указывать canonical для обеих на /guide-to-canonical-tags/ разумно.

Но если испанская версия, версия для печати с дополнительным контентом или вариант товара с другим intent указывает на тот же canonical, вы можете объединять сигналы, которые должны оставаться отдельными. Результатом может стать более слабая релевантность для всех этих страниц.

Canonical tags — про эквивалентность. Если две страницы удовлетворяют разные поисковые intent, вероятно, им не следует canonicalize друг друга.

3. Поисковые системы игнорируют tag

Canonical — это не команда. Если canonical target перенаправляет, возвращает 404, заблокирован, имеет noindex или содержит совсем другой контент, поисковые системы могут его проигнорировать.

В каком-то смысле это хорошо: плохой canonical не всегда разрушает индексацию. Но это также означает, что нельзя считать, будто tag делает именно то, что вы думаете. Страница может объявлять один canonical, а Google выбрать другой.

Это особенно часто происходит, когда internal links, sitemaps и canonicals противоречат друг другу. Если каждая внутренняя ссылка ведёт на /product, ваш sitemap перечисляет /product/, а canonical указывает на https://www.example.com/product?ref=main, вы создали небольшой спор между собственными сигналами.

Поисковые системы хорошо умеют разрешать такой спор. Но они не всегда разрешают его так, как вы рассчитывали.

4. Отладка становится неоправданно сложной

Плохие canonicals редко ломаются громко. Они создают симптомы, похожие на другие SEO-проблемы:

• «Обнаружено, в настоящее время не проиндексировано» или аналогичное состояние неопределённости индексации
• Неправильный URL ранжируется по запросу
• Parameter URLs появляются в отчётах
• Страницы категорий не появляются, хотя доступны для сканирования
• Международные страницы объединяются с неверной языковой версией
• Новые templates запускаются с меньшим числом проиндексированных страниц, чем ожидалось

Поэтому отладка canonical должна включать raw HTML, rendered HTML, HTTP headers, redirects и записи sitemap. Если вы уже расследуете redirect chains или mismatched headers, применяются те же привычки; практический workflow для HTTP-инспекции, как в нашем руководстве по отладке redirects и HTTP headers в production, обычно помогает быстрее найти противоречия canonical, чем разглядывание поля в CMS.

Самые дорогие ошибки canonical

Canonical для всего указывает на homepage

Такое всё ещё происходит. Поле template остаётся пустым, plugin откатывается к корню сайта, и внезапно сотни страниц объявляют homepage как canonical.

Поисковые системы могут проигнорировать это, потому что контент очевидно отличается. Но если достаточно много сигналов неаккуратны, часть страниц может быть исключена или сгруппирована неправильно. Как минимум вы отправляете бесполезную и противоречивую подсказку на каждой странице.

Homepage почти никогда не является canonical для внутренней страницы.

Canonical для страниц пагинации указывает на первую страницу

Долгое время некоторые сайты указывали canonical с /category/page/2/, /page/3/ и так далее обратно на первую страницу. Целью было избежать дублирующихся страниц категорий.

Проблема в том, что страницы пагинации не являются дублями. Они содержат разные элементы и помогают crawlers находить более глубокий контент. Если у всех таких страниц canonical указывает на первую страницу, это может снизить вероятность того, что поисковые системы полностью обработают последующие страницы.

Обычно у страниц пагинации должны быть self-referencing canonicals, если нет конкретной причины для консолидации.

Canonical для отфильтрованных страниц без проверки search intent

Faceted navigation создаёт сложные решения. Некоторые отфильтрованные URL — мусор:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Другие могут быть ценными landing pages:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Массовые правила canonical часто стирают полезные поисковые страницы вместе с бесполезным шумом параметров. Перед тем как указывать canonical для отфильтрованных страниц, спросите, есть ли у такой страницы стабильный контент, internal links, поисковый спрос и отдельная пользовательская потребность.

Если ответ да, она может заслуживать индексации с self-referencing canonical.

Canonicals указывают на redirected или blocked URLs

Canonical target должен быть чистым, индексируемым и возвращать 200 OK. Не указывайте canonicals на URL, которые перенаправляют, возвращают ошибки, требуют cookies, заблокированы robots.txt или содержат noindex.

Это одна из самых простых проверок для автоматизации. Просканируйте сайт и отмечайте canonical targets, которые не возвращают чистый ответ 200.

Смешивание canonical и noindex, будто они означают одно и то же

rel="canonical" и noindex решают разные задачи.

Используйте canonical, когда существуют дубли и вы хотите консолидировать сигналы в предпочтительный URL. Используйте noindex, когда вы вообще не хотите, чтобы страница индексировалась.

Использование обоих одновременно отправляет неловкое сообщение: «Не индексируйте эту страницу, но также используйте её как сигнал дубля для другой страницы». Поисковые системы часто могут с этим справиться, но это не чистая инструкция. Если страница является дублем, укажите для неё canonical. Если она не должна появляться в поиске и не имеет полезной связи с дублем, рассмотрите noindex.

Практический аудит canonical

Чтобы найти многие проблемы canonical, не нужна большая SEO-платформа. Начните со сканирования, нескольких выборочных URL и таблицы.

Для каждого важного template проверьте:

1. Есть ли на странице ровно один canonical tag? Несколько canonical tags создают неоднозначность.
2. Является ли canonical абсолютным? Используйте полный URL, включая protocol и hostname.
3. Возвращает ли canonical target 200 OK? Избегайте targets, которые перенаправляют, заблокированы или возвращают ошибки.
4. Индексируем ли canonical target? Без noindex, без robots block, без требования authentication.
5. Действительно ли контент эквивалентен? Похожий не всегда означает эквивалентный.
6. Согласованы ли internal links? По возможности ссылайтесь на canonical URL format.
7. Согласован ли sitemap? Sitemaps, как правило, должны перечислять canonical, indexable URLs.
8. Согласованы ли hreflang tags? Международным страницам нужны последовательные отношения canonical и hreflang.
9. Совпадает ли rendered HTML с raw HTML? JavaScript может изменять или внедрять tags.
10. Какой canonical выбрала поисковая система? Inspection tools могут показать, когда ваш объявленный canonical отличается от выбранного canonical.

Здесь Lighthouse тоже может быть полезен, но только в своих пределах. Он может отметить некоторые проблемы crawlability и document issues, но не понимает ваш коммерческий intent или canonical strategy. Рассматривайте его как один из входных сигналов, а не как окончательное решение. Если вам нужен более спокойный способ отделять полезные находки от шума, посмотрите, как читать отчёт Lighthouse без паники.

Self-referencing canonicals обычно хороший вариант по умолчанию

Каждая важная индексируемая страница обычно должна объявлять себя как canonical. Не потому, что поисковые системы не могут разобраться без этого tag. А потому, что self-referencing canonicals уменьшают неоднозначность, когда parameters, tracking links, скопированные URL и особенности CMS создают альтернативные пути к тому же контенту.

Для чистой страницы товара обычно правильно так:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Для tracking URL canonical обычно должен указывать обратно на чистую версию:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Для действительно отличающегося варианта товара ответ зависит от ситуации. Если красная, синяя и чёрная рубашки имеют одно и то же описание, а меняется только цвет, одной canonical-страницы товара может быть достаточно. Если у каждого варианта есть отдельный спрос, reviews, images, stock и internal links, отдельные индексируемые страницы могут иметь смысл.

Универсального правила canonical для вариантов не существует. Есть только вопрос: являются ли эти страницы взаимозаменяемыми для пользователя из поиска?

Canonical tags должны соответствовать фактической URL policy сайта

Большинство ошибок canonical — симптомы более глубокой проблемы URL policy. Сайт не решил, имеют ли значение trailing slashes, должны ли разрешаться uppercase URLs, допустимы ли parameters, перенаправляет ли HTTP на HTTPS или является ли www canonical.

Выберите одну чистую версию каждого URL и добейтесь, чтобы вся система была согласована:

• Redirect non-preferred URL versions to preferred versions.
• Link internally to preferred versions.
• Put preferred versions in XML sitemaps.
• Use self-referencing canonicals on preferred pages.
• Canonicalize only true duplicates to the preferred URL.

Когда все эти сигналы указывают в одном направлении, canonical tags становятся скучными. В этом и цель.

Главное

Canonical tags сильны, потому что влияют на индексацию и консолидацию сигналов. По той же причине они опасны.

Неправильный canonical не всегда удалит страницу из поиска. Поисковые системы могут его проигнорировать. Но полагаться на то, что поисковые системы спасут плохие сигналы, — не стратегия. Более безопасный подход — использовать canonicalization только для настоящих дублей, держать targets чистыми и индексируемыми, а также добиться, чтобы internal links, redirects, sitemaps и canonicals рассказывали одну и ту же историю.

Canonicals — не место, где прячут беспорядочную архитектуру. Это место, где подтверждают, что её привели в порядок.