Канонические URL: одна страница — один адрес

Почему одна и та же страница живёт по десятку адресов, что с этим может и чего не может rel=canonical и какие ошибки с каноникалами тихо сводят на нет ваше же SEO.

SEO · Опубликовано: 29 сентября 2026 г. · 5 мин чтения · Ольга Мирошник

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

Как у одной страницы появляется много адресов

Дубли специально никто не публикует. Просто сервер принимает больше вариантов адреса, чем кажется:

• Хост. Отвечают и www.example.com, и example.com.
• Протокол. http:// по-прежнему отдаёт сайт вместо редиректа на https://.
• Слеш в конце. /pricing и /pricing/ возвращают один и тот же документ.
• Регистр. На сервере, нечувствительном к регистру, работают и /Blog/Post, и /blog/post.
• Индексные файлы. /docs/ и /docs/index.html — это один и тот же файл.
• GET-параметры. ?utm_source=newsletter, ?sort=price, ?sessionid=… — каждая комбинация даёт новый URL с тем же или почти тем же содержимым.
• Пагинация. /blog?page=2 — настоящая, отдельная страница, но её часто ошибочно считают дублем первой.

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

Один хост — через 301

Дешевле всего избавиться от дублей на уровне хоста и протокола, и правильный инструмент здесь — постоянный редирект, а не тег. Выберите одну форму — например, https://example.com — и отправляйте туда все остальные комбинации за один шаг:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Важны две детали. Редирект должен быть 301 (или 308), а не 302: временный редирект сообщает поисковику, что настоящий адрес — всё ещё старый. И шаг должен быть один: цепочка http://www → https://www → https:// работает, но тратит лишний сетевой круг при каждом первом визите. Со слешем в конце — то же самое: выберите один вариант и перенаправляйте второй.

rel=canonical — это подсказка

Для дублей, которые нельзя перенаправить, — меток отслеживания, сортировок, версий для печати — предпочтительный адрес указывают в head страницы:

<link rel="canonical" href="https://example.com/pricing/">

Это подсказка, а не директива. Google взвешивает её вместе с редиректами, внутренними ссылками, sitemap и hreflang и может выбрать другой канонический адрес, если эти сигналы расходятся. Ваша задача — чтобы все сигналы указывали на один и тот же URL.

Хорошая практика:

• Каноникал на самого себя. Каждая индексируемая страница называет себя. Это защищает её от вариантов с параметрами, которые вы не предусмотрели.
• Абсолютные URL. Относительный href="/pricing/" формально допустим, но разрешается относительно того хоста и протокола, с которых отдана копия, — то есть ровно того дубля, от которого вы пытались избавиться.
• Страницы пагинации канонизируются на себя. Вторая страница указывает на вторую, а не на первую; иначе всё, на что ссылается только вторая страница, найти становится труднее.

Для не-HTML-файлов — заголовок. У PDF нет head, поэтому каноникал передают в ответе сервера:

Link: <https://example.com/guide.pdf>; rel="canonical"

Ошибки, которые реально вредят

Каноникал на главную везде. Шаблон ставит один и тот же каноникал на все страницы. Вы только что сообщили поисковику, что весь сайт — дубль /.

Каноникал на страницу, которой нет. Целевой адрес редиректит, отдаёт 404 или закрыт noindex. Сигналы противоречат друг другу, и поисковик обычно просто игнорирует подсказку.

Конфликт с hreflang и sitemap. В sitemap указан /pricing, каноникал говорит /pricing/, а hreflang ведёт на третий вариант. Везде должен стоять ровно канонический URL.

JavaScript его меняет. В серверном HTML одно, а клиентский роутер или SEO-плагин после загрузки переписывает тег. Краулер может увидеть любую из версий. Отдавайте правильный каноникал с сервера и больше его не трогайте.

Несколько тегов canonical. Два плагина добавили по одному. При конфликтующих значениях подсказку, как правило, не учитывают вовсе.

Как проверить

Получите сырой HTML и смотрите на то, что реально отдаёт сервер, а не на то, что показывают DevTools после выполнения скриптов:

curl -s https://example.com/pricing/ | grep -i 'rel="canonical"'
curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)'

Вторая команда должна показать один 301 на выбранный хост. Отчёт SiteScan проверяет часть этого автоматически: помечает страницы без ссылки canonical, страницы, чей каноникал указывает на другой адрес, сайты, где и www, и вариант без www отвечают 200 вместо постоянного редиректа с одного на другой, а также редиректы хоста через временный 302.

Чек-лист

1. Один хост и один протокол; все остальные комбинации отдают один 301.
2. Один вариант слеша в конце, второй перенаправляется.
3. У каждой индексируемой страницы абсолютный каноникал на саму себя.
4. Целевые адреса каноникалов отдают 200, индексируются и не редиректят.
5. Sitemap, hreflang и внутренние ссылки используют ровно канонические URL.
6. Страницы пагинации канонизируются на себя.
7. PDF и другие файлы при необходимости отдают заголовок Link.
8. Каноникал в серверном HTML совпадает с тем, что остаётся после работы JavaScript.