Canonical-тег сообщает поисковой системе, какой URL вы бы предпочли считать основной копией - подсказка, которой она обычно следует, но которую может переопределить. 301 редирект убирает выбор полностью: он отправляет каждого посетителя и краулера на один URL, а старый перестаёт отвечать. Вот и всё решение в одном предложении. Используйте canonical-тег, когда оба URL должны продолжать работать для людей. Используйте 301, когда должен существовать только один URL.
Их путают, потому что они борются с одной и той же проблемой - дублирующийся контент, распыляющий сигнал ранжирования по почти идентичным URL, - но разными механизмами. Canonical - это предложение, оставленное в head страницы. Редирект - это HTTP-ответ, которому у браузера нет выбора кроме как подчиниться. Перепутайте их местами - и либо убьёте URL, который нужен был живым, либо оставите несколько версий одной и той же страницы конкурировать друг с другом в индексе.
Мне приходилось объяснять это чаще, чем вопрос про 301 против 302, так что это та версия, которую я хотел бы иметь под рукой, когда меня спросили в первый раз, а если вы здесь ради вопроса про код состояния, статья 301 против 302 редиректов разбирает именно его полностью; этот пост - о другой развилке.
Canonical-тег против 301 редиректа: подсказка против инструкции
Тег rel=canonical находится внутри <head> страницы: <link rel="canonical" href="https://example.com/preferred-url" />. Это один из нескольких сигналов, которые используются для выбора canonical URL - сильный, но такой, который поисковая система может переопределить, если другие свидетельства ему противоречат. Оба URL остаются рабочими, человек может зайти на любой из них и оба раза получить ответ 200, а тег меняет только то, что показывается в результатах поиска, а не то, что доступно браузеру.
301 редирект - это не предложение. Он сам отвечает на запрос: запросите старый URL - и вас отправят на новый, точка. Версии старой страницы, которую можно было бы посетить, больше не существует. Браузеры перестают её пытаться открыть, а поисковые системы удаляют её из индекса, потому что она больше не разрешается в собственный контент.
Практическая проверка сводится к двум условиям:
- Если обоим URL нужно продолжать разрешаться для реальных посетителей, используйте canonical.
- Если в дальнейшем должен существовать только один URL, используйте редирект - а типы URL-редиректов - справочник о том, какой код подходит для того или иного рода постоянства.
Оба инструмента борются с одной и той же проблемой с противоположных сторон: редирект - для URL, на который человек больше не должен попадать, canonical - для того, на который человек может попасть на законных основаниях.
Четыре ситуации, где дублирующемуся контенту нужно разное решение
Четыре ситуации возникают постоянно, и у каждой есть ровно один правильный сигнал. Перепутайте это соответствие - и либо застопорите рабочий процесс, который должен быть живым, либо оставите приманку сидеть в индексе.
URL с параметрами
URL с прикреплённым трекинговым параметром или ID сессии - ?ref=partner или ?sessionid=abc123 - функционально та же страница, что и чистая версия, просто с лишним багажом. Редиректить его прочь обычно неправильно, потому что параметру часто нужно пережить запрос: реферальный код, A/B-корзина, передача сессии. Решение - canonical, указывающий сам на себя, на чистом URL, чтобы версия с параметром оставалась доступной, а тег говорил поисковым системам индексировать версию без шума.
URL с метками кампаний
Это случай, с которым маркетинговые команды сталкиваются каждый день. Ссылка вроде elido.app/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch должна продолжать работать ровно так, как помечена, потому что именно UTM-параметры позволяют аналитике приписать визит этой рассылке, по всем кампаниям и каналам. Никаких исключений, никогда. Редирект на голый URL /pricing выбросил бы атрибуцию ещё до того, как она вообще была бы зафиксирована.
Canonical-тег ставится на странице назначения, а не на ссылке: /pricing объявляет <link rel="canonical" href="https://elido.app/pricing" />, и каждый вариант с UTM-меткой наследует ту же цель. Поисковые системы индексируют один чистый URL /pricing, а аналитика по-прежнему видит каждый вариант кампании отдельно, потому что тег никогда не затрагивает то, что запрашивает браузер. Одна оговорка: некоторые браузеры теперь вырезают UTM-параметры или блокируют скрипты, которые их читают, прежде чем атрибуция успевает зафиксироваться - смотрите статью как Firefox и Brave ломают UTM-атрибуцию, если ваши цифры по кампаниям выглядят скудно. Это проблема трекинга, а не canonical.
Страницы пагинации и фасетной фильтрации
Честный ответ зависит от того, есть ли у этой комбинации контент, который поисковый запрос действительно мог бы искать. Страница 2 архива - это по-настоящему другой контент, чем страница 1, поэтому канонизация каждой страницы пагинации обратно на страницу 1 на практике обычно приводит к обратному эффекту. Фасетный фильтр, который просто пересортировывает тот же каталог, - обратный случай: канонизировать его обратно на нефильтрованную страницу категории правильно, потому что на этом URL нет ничего, что стоило бы индексировать отдельно. Универсального правила нет, есть только та же самая проверка.
Консолидация устаревшей страницы
Здесь canonical-тег - неправильный инструмент, а редирект - единственный правильный. Когда страница списывается окончательно - объединена с более новым постом, снята после изменения каталога, - у старого URL больше нет причин вообще во что-то разрешаться. 301 чисто передаёт свой сигнал ранжирования дальше и выводит мёртвую страницу из обращения. Canonical-тег на странице, которую вы собираетесь удалить, просто оставляет осиротевший URL хромать дальше - всё ещё доступный для сканирования, всё ещё способный деградировать, - именно тот сбой, который призвано ловить предотвращение деградации ссылок. Если старая страница действительно ушла, редиректите её. Не канонизируйте труп.
Когда canonical и редирект расходятся
Иногда URL несёт оба сигнала одновременно, и они не согласуются. Страница A редиректит на страницу B через 301, но страница B объявляет собственный canonical, указывающий на страницу C - на несколько переходов дальше от того места, откуда начался первый клик.
Рекомендация Google однозначна: редирект - более сильный и более буквальный сигнал, чем canonical-тег, потому что он уже убрал альтернативу - страницы A, которую можно было бы пересмотреть, больше не существует. Когда два сигнала расходятся, побеждает цель редиректа как фактическое назначение, а canonical-тег на этом назначении становится реальным сигналом, который оценивают поисковые системы. Всё, что было выше по цепочке, к тому моменту, когда краулер добирается до конца цепочки, превращается в шум.
Практический сбой редко бывает философским - обычно это цепочка, которую никто не аудировал, где canonical финального назначения был выставлен для другой миграции много лет назад и с тех пор ни разу не пересматривался. Распутать это значит пройти каждый переход, пока вы не доберётесь до URL, который возвращает 200 и канонизирует сам себя, а затем починить то звено, которое устарело. Один чистый переход, один canonical-тег, который согласуется с тем, куда вы попали, - вот и всё целевое состояние.
Зачем каждой странице нужен canonical, указывающий сам на себя
Canonical, указывающий сам на себя, - это страница, чей canonical-тег указывает на неё саму: /pricing объявляет <link rel="canonical" href="https://elido.app/pricing" /> вместо того, чтобы молчать, и большинство хорошо устроенных страниц несут такой тег именно по этой причине. Ничего загадочного в этом нет. Выглядит избыточно - зачем странице подтверждать, что она - это она? Это дешёвая страховка от любого случайного способа задвоить URL: завершающий слеш, путь со смешанным регистром, случайная строка запроса, добавленная плагином, задержавшаяся версия http рядом с https. Любой из них может быть проиндексирован как отдельный, почти идентичный URL, если ничто не говорит, какая копия настоящая.
Без него выбор остаётся на усмотрение собственного взвешивания сигналов Google, которое в основном срабатывает верно, а иногда нет - и вы узнаёте об этом, заметив, что ранжируется не тот URL, а это плохой способ узнать. Задайте его явно на каждой индексируемой странице - и неоднозначности просто не выпадет шанс сыграть роль.
Если вы помечаете одну страницу для дюжины каналов и не можете понять, согласуется ли canonical с тем, что считают ваши отчёты, аналитика Elido группирует каждый помеченный вариант обратно к URL, который она на самом деле измеряет, так что случайный параметр незаметно не расщепит ваш трафик надвое.
Где короткие ссылки находятся относительно canonical URL
Короткая ссылка поднимает вопрос, который выглядит так, будто относится сюда, но по большей части нет: нужен ли elido.app/abc123 canonical-тег, указывающий на её назначение? Нет. Домен редиректа - не дубликат страницы, на которую он отправляет посетителей: это адрес без собственного контента, которому нечего разрешать с помощью canonical-тега. Канонизация - для страниц, которые правдоподобно могли бы быть проиндексированы; короткая ссылка никогда не была кандидатом на это.
Важный canonical-тег принадлежит странице назначения, точно так же, как если бы посетитель попал туда любым другим путём. Если elido.app/summer-sale отправляет людей на yoursite.com/sale?utm_source=twitter, работа с canonical всё равно остаётся тем же случаем URL с меткой кампании, что и раньше, ничем не отличаясь от любой ссылки кампании, которую вы пометили бы точно так же. Она происходит на yoursite.com/sale, а не на короткой ссылке. Разветвление одной и той же короткой ссылки на разные назначения по кампании или региону ответа не меняет: умные ссылки маршрутизируют клик, но работа с canonical всё равно происходит там, куда попадает посетитель. Вопрос корректности самого редиректа разбирают статьи 301 против 302 редиректов и как перенаправить URL.
Именно поэтому SEO-опасения вокруг сокращённых ссылок по большей части беспочвенны, если держать эти два сигнала порознь: редирект передаёт свой собственный сигнал, canonical назначения обрабатывает свой, и ни один не заражает другой. Статья вредят ли сокращатели URL для SEO разбирает остальную часть этого вопроса.
Как проверить, какой сигнал страница подаёт на самом деле
Не догадывайтесь. Проверьте оба сигнала напрямую, начиная с редиректа:
curl -sI "https://example.com/old-page"
301 с заголовком Location означает, что URL ушёл навсегда; отсутствие статуса 3xx означает, что редиректа нет, и единственный действующий сигнал - это canonical-тег, если он есть. Чтобы увидеть сам canonical-тег, загрузите страницу и поищите в исходном коде:
curl -s "https://example.com/page" | grep -i 'rel="canonical"'
Если URL подаёт оба сигнала, полностью проследите цепочку, прежде чем предполагать, какой из них - истинное назначение. Когда они согласуются - редирект приводит на URL, чей canonical указывает сам на себя, - сигнал однозначен, и именно в этом состоянии должен находиться каждый URL, важный для ваших позиций.
Похожие материалы в блоге
Частые вопросы
В чём разница между canonical-тегом и 301 редиректом?
Canonical-тег - это подсказка в head страницы, которая сообщает поисковым системам, какой URL предпочесть, пока оба остаются рабочими и доступными; 301 редирект - это код состояния HTTP, который отправляет каждого посетителя и краулера на новый URL и выводит старый из обслуживания. Google рассматривает canonical как сильный сигнал, который можно переопределить, если другие свидетельства ему противоречат, тогда как редирект не оставляет альтернативы для взвешивания, потому что старой страницы, которую можно было бы пересмотреть, больше не существует. Используйте canonical, когда обоим URL нужно продолжать отвечать на запросы; используйте редирект, когда должен остаться только один.
Использовать canonical-тег или 301 редирект для дублирующегося контента?
Используйте редирект, если дублирующийся URL должен полностью прекратить существование - устаревшая страница, старый домен, окончательный переезд, - потому что редирект одновременно консолидирует сигнал ранжирования и выводит мёртвый URL из обращения. Используйте canonical-тег, если дубликат должен оставаться доступным по реальной причине - например, ссылка кампании с UTM-меткой, параметр сессии или отфильтрованная почти-дублирующаяся страница. Решающий вопрос - есть ли у человека законная причина продолжать посещать URL, который вы не выбираете в качестве canonical.
Что происходит, когда canonical-тег и редирект противоречат друг другу?
Побеждает редирект, потому что он уже убрал альтернативный URL из уравнения - на этом этапе цепочки canonical-тегу просто нечему противоречить. Google сначала проходит по редиректу до места назначения, а затем читает то, какой canonical-тег объявляет это назначение как действующий сигнал. Чтобы устранить несоответствие, нужно проследить каждый переход, пока вы не окажетесь на URL, который возвращает 200 и канонизирует сам себя.
Нужен ли canonical-тег URL с UTM-параметрами?
Да, canonical-тег должен находиться на странице назначения и указывать на чистый URL без прикреплённых трекинговых параметров. Такая страница, как /pricing, должна объявлять сама себя собственным canonical независимо от того, сколько вариантов с UTM-меткой на неё ссылается, чтобы поисковые системы индексировали один чистый URL, а аналитика при этом по-прежнему фиксировала каждый помеченный вариант отдельно. Если вместо этого редиректить URL с UTM-меткой, параметры будут срезаны раньше, чем ваш инструмент аналитики сможет приписать визит нужному источнику.
Зачем ставить canonical-тег, указывающий сам на себя, на каждую страницу?
Canonical, указывающий сам на себя, - когда страница объявляет саму себя предпочтительным URL, - перекрывает любой случайный способ задвоить страницу: от завершающего слеша до случайных параметров запроса и задержавшейся версии http рядом с https. Без него Google выбирает canonical URL по собственным сигналам, что обычно верно, но иногда приводит не к тому варианту. Явно задав его на каждой индексируемой странице, вы бесплатно убираете эту неоднозначность.
Нужен ли canonical-тег короткой ссылке?
Нет. Короткая ссылка - это чистый HTTP редирект без собственного контента, поэтому на этом URL нечего разрешать с помощью canonical-тега, а канонизация имеет значение только для страниц, которые правдоподобно могут быть проиндексированы как контент. Важный canonical-тег находится на странице назначения, куда ведёт короткая ссылка, - точно так же, как если бы посетитель попал туда любым другим путём.
Попробуйте Elido
Вставьте URL - получите короткую ссылку
Без регистрации. Ссылка живёт 30 дней. Зарегистрируйтесь, чтобы оставить её навсегда.
Бесплатно, без регистрации · 2 в день