Тег rel=”canonical” сообщает поисковым системам, “какой URL-адрес является канонической версией этого контента”, предотвращая рассеивание авторитета.
В Google SEO он используется путем добавления <link rel=”canonical” href=”Канонический URL-адрес”> в раздел <head> страницы.
Данные показывают, что сайты электронной коммерции, правильно внедрившие канонический тег, наблюдают в среднем 28% увеличение скорости индексации своих страниц списка товаров и снижение количества сканирований дублирующих URL-адресов роботами на 40%-60%;
Новостные сайты, которые консолидируют похожие статьи с помощью канонического тега, демонстрируют средний рост органических поисковых кликов на свой основной контент на 19%.
Однако фактический опрос показал, что только 31% веб-сайтов используют этот тег на 100% правильно (типичные ошибки включают: указание на неверный URL-адрес, несоблюдение протоколов/доменов, наслоение нескольких тегов и т.д.).
Почему необходимо использовать канонический тег
При ежедневном сканировании Google более 65% веб-сайтов сталкиваются с проблемами дублирования контента, вызванными неадекватной структурой URL-адресов.
Это проявляется как:
- Одна и та же статья доступна по URL-адресам с параметрами (например, ?utm_source=xxx)
- URL-адреса с суффиксами каталогов (например, /page/ и /page/index.html)
- Различные субдомены (например, www и без www)
Джон Мюллер из Google неоднократно упоминал в официальных сессиях вопросов и ответов, что, когда поисковая система обнаруживает “несколько URL-адресов, показывающих очень похожий или полностью идентичный контент”, она сталкивается с дилеммой “какому из них следует присвоить авторитет”.
Страница товара в электронной коммерции может генерировать более десятка различных URL-адресов из-за фильтров по цвету или параметров сортировки; пресс-релиз может быть отправлен в несколько столбцов, создавая несколько входных ссылок.
Используя канонический тег, вы четко сообщаете поисковой системе: “Хотя этот контент можно просматривать по нескольким URL-адресам, сосредоточьте авторитет и внимание на ранжировании именно на этом URL-адресе, который я назначил“.
Как дублирование контента влияет на SEO
Само по себе дублирование контента не приводит напрямую к наказанию со стороны поисковых систем (Google четко заявил, что “не будет наказывать сайты только за дублирование контента”), но оно вызывает рассеивание авторитета.
Когда один и тот же контент доступен по нескольким URL-адресам, поисковая система рассматривает эти URL-адреса как “разные страницы” и обрабатывает их отдельно.
Например, оригинальная статья отображается по следующим 4 URL-адресам:
https://example.com/articlehttps://example.com/article?source=newsletterhttps://example.com/article#commentshttps://www.example.com/article(версия с www)
Без канонической идентификации поисковая система может сканировать все эти 4 URL-адреса одновременно и рассчитывать авторитет индексации для каждого из них отдельно.
Однако поисковая потребность пользователя по сути является одним ответом, и в конечном итоге ранжирование этих 4 версий может быть низким (поскольку авторитет рассеян), или только одна из них будет случайно включена в индекс, а другие версии останутся в состоянии “не проиндексировано” или “низкое ранжирование” в течение длительного времени.
На веб-сайте электронной коммерции страница сведений о товаре может генерировать в среднем от 8 до 12 дублирующих URL-адресов из-за параметров (например, ?size=XL, ?color=red), и доля сканирования роботами этих страниц может достигать 15%-20% от общего объема сканирования (который должен быть выделен на новые, более ценные страницы).
Новостные сайты, из-за того что контент отправляется в несколько столбцов (например, “Последние новости”, “Отраслевые тенденции”, “Популярные рекомендации”), один черновик может генерировать 3-5 различных входных URL-адресов.
Более конкретный случай: до стандартизации URL-адресов скорость индексации страниц списка товаров среднего сайта электронной коммерции составляла всего 62% (то есть только 62 из каждых 100 страниц были включены Google и могли участвовать в ранжировании);
После добавления канонического тега на страницы списка с параметрами (например, ?category=shoes&sort=price), чтобы они указывали на базовый URL-адрес без параметров (например, /shoes), скорость индексации увеличилась до 81% через 3 месяца, а органический поисковый трафик соответствующих товаров вырос на 17%.
Это не “удаление дубликатов”, а “назначение авторитетной версии”
Многие веб-мастера неправильно понимают канонический тег, полагая, что он используется “для удаления дублирующих страниц”.
На самом деле, его основная функция состоит в том, чтобы “сообщить поисковой системе: среди нескольких URL-адресов, показывающих один и тот же контент, какой является версией, которую она должна индексировать, ранжировать и которой предпочтительно присваивать авторитет”
Когда вы добавляете следующий код в раздел <head> страницы:
<link rel=“canonical” href=“https://example.com/Канонический_URL-адрес” />
Вы отправляете поисковой системе четкий сигнал: “Хотя контент может быть доступен через эту страницу (например, /article?source=email с параметрами), я хочу, чтобы вы сосредоточили ее авторитет и возможности ранжирования на адресе https://example.com/Канонический_URL-адрес”.
Согласно официальной документации Google и наблюдению за фактическими данными сканирования:
- Уровень сканирования: Поисковая система будет продолжать сканировать все версии страницы (включая URL-адреса с параметрами и каталогами), но она будет консультироваться с каноническим тегом, чтобы скорректировать свой “уровень важности” для этих страниц. Например, URL-адрес с параметрами может быть просканирован, но робот не будет посещать его так часто или индексировать так глубоко, как каноническую версию.
- Уровень индексации: Если контент нескольких URL-адресов очень похож (степень дублирования превышает 80%), поисковая система обычно включает в индекс каноническую версию, а другие версии могут не индексироваться отдельно, или даже если они индексируются, они не будут участвовать в основном ранжировании.
- Уровень авторитета: Когда внешняя ссылка указывает на любую из дублирующих версий URL-адреса, поисковая система, следуя указанию канонического тега, “передает” или “связывает” эту часть авторитета внешней ссылки с канонической версией (хотя это не 100% полная передача, в большинстве случаев эффект схож).
https://example.com/home/recommend/123(Вход рекомендации главной страницы)https://example.com/tech/article/123(Вход технического столбца)- Это HTML-тег, используемый для определения отношения между документом и внешними ресурсами, а канонический тег является типом “отношения ссылки”, поэтому в качестве базовой структуры должен использоваться
<link>. rel– это обязательный атрибут тега<link>, используемый для описания отношения между текущей ссылкой и текущим документом. Когда его значение установлено наcanonical, он четко сообщает поисковой системе: “этот тег определяет каноническую (авторитетную) версию контента текущей страницы”.href– это еще один обязательный атрибут тега<link>, используемый для указания конкретного веб-адреса канонической версии. Этот URL-адрес должен быть полным и доступным, включая протокол (http или https), домен (www или без www), путь и параметры (при необходимости).- Правильное написание:
href="https://www.example.com/products/shoes" - Неправильное написание 1 (отсутствует протокол):
href="//www.example.com/products/shoes"(браузер может завершить его автоматически, но поисковая система может не иметь возможности точно проанализировать целевой URL-адрес) - Неправильное написание 2 (отсутствует домен):
href="/products/shoes"(относительный путь, поисковая система не знает, к какому веб-сайту относится конкретная страница) - Неправильное написание 3 (опечатка):
href="https://www.exaple.com/products/shoes"(неправильно написанный домен, указывает на несуществующую страницу) - Этот тег должен заканчиваться
/(если сам URL-адрес требует конечной косой черты), но в большинстве случаев современные поисковые системы более толерантны к тому, включена ли конечная косая черта или нет (при условии, что стандартизация единообразна). - Тег должен быть написан в одной строке (перенос строки может привести к сбою некоторых инструментов анализа, хотя поисковые системы обычно могут автоматически восстанавливать его).
- Закрывающая часть тега –
/>(самозакрывающийся тег, стандарт HTML5 позволяет опускать конечный/, но рекомендуется его сохранять для обеспечения совместимости). - Страница может иметь только один канонический тег (если их появляется несколько, поисковая система обычно идентифицирует только первый, а остальные будут проигнорированы).
- Этот тег не может быть вложен в другие теги (например, он не может быть помещен в
<div>или<script>). - Для динамически генерируемых страниц (таких как страницы, генерируемые серверными языками, такими как PHP, Python и т.д.) необходимо обеспечить, чтобы механизм шаблонов правильно вставлял канонический тег в область
<head>при генерации HTML (обычно управляется через переменные шаблона). - Явление: Направление канонического тега на URL-адрес, контент которого не полностью соответствует (или вообще не тот же контент). Например, страница сведений о товаре (показывает красные туфли) указывает на страницу белых туфель.
- Последствие: Поисковая система сосредоточит авторитет на нерелевантной странице в соответствии с неверной инструкцией, что приведет к падению ранжирования основного контента.
- Коррекция: Проверьте фактический контент текущей страницы и убедитесь, что URL-адрес в href указывает на каноническую версию, которая “показывает полностью идентичный контент” (например, используйте унифицированный базовый URL-адрес без параметров или страницу столбца, которая наилучшим образом соответствует поисковому намерению пользователя).
- Явление: Код написан как
href="//example.com/page"(относительный путь к протоколу) илиhref="/page"(относительный путь). - Последствие: Поисковая система может не иметь возможности точно проанализировать полный адрес целевого URL-адреса (особенно в случаях кросс-протокола или кросс-домена), что приводит к неэффективности канонического намерения.
- Коррекция: Всегда используйте полный протокол + домен + путь, формат –
href="https://www.example.com/page"(рекомендуется протокол https для обеспечения безопасности). - Явление: Версия страницы списка товаров без параметров (
https://example.com/products) является канонической версией, но версия с параметрами (такая какhttps://example.com/products?sort=price) неправильно указывает на нее, а указывает на другой URL-адрес с другими параметрами (например,?sort=date). - Последствие: Несколько версий с параметрами указывают друг на друга на разные URL-адреса, образуя “круговую канонизацию” или рассеивание авторитета.
- Коррекция: Унифицируйте канонический тег всех URL-адресов с параметрами, чтобы они указывали на базовую версию без параметров (или наиболее часто используемую версию сортировки/фильтра), обеспечивая, чтобы все варианты версий указывали на один и тот же канонический адрес.
- Явление: При редактировании страницы через бэкенд CMS канонический код по ошибке вставляется в область контента статьи (часть <body>), а не в область <head> шаблона веб-сайта.
- Последствие: Робот поисковой системы может проигнорировать тег, что приведет к неправильной стандартизации дублирующих страниц.
- Коррекция: Свяжитесь с технической командой, чтобы проверить файлы шаблона (такие как header.php WordPress, theme.liquid Shopify) и убедитесь, что канонический тег генерируется внутри тега <head> HTML.
- Явление: Из-за ошибки шаблона или ручного добавления на странице появляется несколько тегов
<link rel="canonical">(например, одновременно указывающих на /page и /page/). - Последствие: Поисковая система обычно идентифицирует только первый тег, а последующие теги игнорируются, что может вызвать путаницу в каноническом намерении.
- Коррекция: Проверьте код, удалите избыточные канонические теги и убедитесь, что каждая страница имеет только одну каноническую инструкцию.
- Типичный сценарий: Страница сведений о товаре в электронной коммерции с параметрами (такими как ?color=red и ?color=blue), пресс-релиз, отправленный в несколько столбцов (таких как “Последние новости” и “Отраслевые тенденции”), отдельный URL-адрес для мобильного и настольного компьютера, но контент идентичен.
- Типичный сценарий: Страницы внутреннего управления (такие как страницы входа, страницы статистики бэкенда), страницы временных событий (которые не нужно сохранять ранжирование после завершения события), страницы с низкоценным контентом (такие как версия для печати, страница преобразования упрощенного/традиционного китайского языка).
- Типичный сценарий: Изменение доменного имени веб-сайта (такое как миграция с example.com на newexample.com), корректировка структуры URL-адресов (такое как изменение /old-product/ на /products/new-product/), консолидация нескольких старых страниц в одну новую.
- Проблема: Страница сведений о товаре доступна по
https://example.com/productиhttps://example.com/product?color=red, и контент полностью идентичен. - Правильный инструмент: canonical. Добавьте канонический тег на URL-адрес с параметрами (
?color=red), указывающий на базовый URL-адрес без параметров (https://example.com/product), сообщая поисковой системе “авторитетная версия этого контента – это страница без параметров”. - Почему не выбрать noindex/301: noindex предотвратит индексацию страницы с параметрами (но она все еще может быть просканирована), и пользователь может перейти по этой ссылке, а поисковая система все еще должна судить, какая версия является основной; перенаправление 301 требует принудительного перенаправления пользователя и робота, но пользователю может потребоваться доступ через разные параметры (например, для сравнения разных цветов), и принудительное перенаправление не подходит.
- Проблема: Страница рекламной акции (
https://example.com/promo) завершилась, но она все еще может быть посещена пользователями через закладки или внешние ссылки, и ей не нужно ранжирование. - Правильный инструмент: noindex. Добавьте тег
<meta name="robots" content="noindex">в<head>страницы активности (или настройте его через CMS), позволяя поисковой системе сканировать страницу (например, для проверки записи активности), но запрещая ее включение в индекс. - Почему не выбрать canonical/301: canonical не может решить проблему “не дать странице появиться” (он только сосредоточивает авторитет); перенаправление 301 требует указания нового URL-адреса (но у страницы активности нет соответствующего нового адреса), и пользователю все еще может потребоваться посетить исходную страницу для просмотра исторической информации.
- Проблема: Старая страница товара (
https://old.example.com/item1) была окончательно перенесена на новый адрес (https://new.example.com/products/item1), и необходимо сохранить исходный авторитет внешней ссылки и привычку доступа пользователя. - Правильный инструмент: Перенаправление 301. Настройте через конфигурацию сервера (такую как файл .htaccess Apache), чтобы, когда пользователь или робот обращается к старому URL-адресу, он автоматически перенаправлялся на новый URL-адрес. Авторитет ранжирования старого URL-адреса (включая ранжирование, внешние ссылки) постепенно передастся на новый URL-адрес.
- Почему не выбрать canonical/noindex: canonical не может обеспечить перенаправление трафика (пользователь останется на старом URL-адресе); noindex предотвратит индексацию старого URL-адреса, но авторитет внешней ссылки не будет передан, и пользователь не сможет получить доступ к новому контенту через старую ссылку.
- Проблема: Один и тот же контент имеет отдельные URL-адреса на мобильном (
https://m.example.com/page) и настольном (https://www.example.com/page) компьютере, и контент полностью идентичен. - Правильный инструмент: Приоритет canonical (указывающий на URL-адрес настольного компьютера) или унификация через адаптивный дизайн. Если мобильный вход необходим (например, пользователи привыкли заходить через m.example.com), канонический тег может быть добавлен на мобильную страницу, указывающий на канонический URL-адрес настольного компьютера, и в то же время перенаправить 301 некоторые старые мобильные ссылки на настольный компьютер (по желанию).
- Почему не выбрать noindex: noindex предотвратит индексацию одной из мобильных или настольных версий, что может помешать удовлетворению поисковых потребностей некоторых пользователей (например, мобильные пользователи не увидят адаптированный контент).
- Формат кода: Добавьте
<link rel="canonical" href="https://Канонический_URL-адрес" />в раздел<head>страницы, которая нуждается в канонизации (как описано в предыдущей главе). - Формат кода: Обычно добавляется
<meta name="robots" content="noindex">в<head>страницы (применимо в большинстве случаев) или возвращается заголовок ответа HTTPX-Robots-Tag: noindexчерез сервер (применимо к динамическим страницам). - Сервер Apache: Добавьте
Redirect 301 /old-page https://example.com/new-pageв файл .htaccess; - Сервер Nginx: Добавьте
return 301 https://example.com/new-page;в файл конфигурации; - Системы CMS (такие как WordPress): Настройте правила перенаправления через плагин (такой как Redirection).
Возьмем реальный сценарий: статья в блоге одновременно публикуется в двух столбцах: “Рекомендация главной страницы” и “Технический столбец“, генерируя два URL-адреса:
Контент полностью идентичен, но URL-адрес рекомендации главной страницы привлек некоторые внешние ссылки из-за более высокого трафика.
Без канонического тега поисковая система может рассматривать эти две страницы как независимый контент, и хотя URL-адрес рекомендации главной страницы имеет внешние ссылки, его потенциал ранжирования может быть ниже, чем у технического столбца, из-за того, что позиционирование столбца недостаточно вертикально (рекомендация главной страницы обычно является общим контентом).
Если техническая команда добавит канонический тег на обе страницы, указывающий на https://example.com/tech/article/123, который больше соответствует теме контента, поисковая система будет четко знать: “авторитетная версия этого контента – это URL-адрес технического столбца”, и она свяжет авторитет внешних ссылок с главной страницы с этим URL-адресом, повышая конкурентоспособность ранжирования этой страницы по “ключевым словам, связанным с технологиями”.
Что произойдет, если не использовать канонический тег
Растрачивается бюджет сканирования роботов
“Количество ежедневных сканирований”, выделяемое поисковой системой каждому веб-сайту, ограничено (называется “бюджет сканирования”), и приоритет отдается сканированию важных страниц (таких как главная страница, страницы контента с высокой частотой обновления).
Если на веб-сайте много дублирующих URL-адресов (например, страница сведений о товаре в электронной коммерции с 10 параметрами сортировки, генерирующая более 1000 различных URL-адресов), робот будет тратить часть бюджета на эти страницы с “идентичным контентом, но другим URL-адресом”, что приводит к снижению частоты сканирования новых страниц, которые действительно нуждаются в сканировании (таких как недавно выпущенные товары, обновленные новости).
Данные показывают, что анализ журналов сканирования среднего сайта электронной коммерции одежды показал, что дублирующие страницы товаров с параметрами (например, ?size=M, ?color=blue) занимали 22% от общего объема сканирования, а показатель отказов на этих страницах достигал 85% (пользователи ищут конкретные товары, они не будут переходить по URL-адресам с параметрами).
Когда сайт добавил унифицированный канонический тег на страницы сведений о товаре (указывающий на базовый URL-адрес без параметров), частота сканирования основных страниц товаров роботом увеличилась на 30%, а время включения в индекс новых товаров сократилось со среднего показателя 7 дней до 3 дней.
Путаница в версии индексации, нестабильное ранжирование
Без канонической идентификации поисковая система может произвольно выбрать один URL-адрес в качестве “версии отображения по умолчанию”, но этот выбор не является фиксированным.
Например, когда пользователь ищет ключевое слово, иногда он видит версию с www (https://www.example.com/page), иногда версию без www (https://example.com/page), и даже может быть версию с параметрами (https://example.com/page?from=social).
Случай: страница “Связаться с нами” на веб-сайте местных услуг существовала в двух версиях https://example.com/contact и https://example.com/contact-us (контент был полностью идентичен), без установленного канонического тега. Google индексировал эти два URL-адреса в разное время, что приводило к тому, что когда пользователи искали “Контактная информация службы ремонта в городе XX”, они иногда видели первую версию выше в рейтинге, а иногда вторую.
Когда пользователь нажимает, если он попадает на не основную версию (например, contact-us), коэффициент конверсии может снизиться из-за различий в дизайне навигации страницы (например, отсутствие кнопки онлайн-бронирования).
Позже веб-сайт добавил канонический тег на обе версии, указывающий на https://example.com/contact, и через 3 месяца ранжирование этой страницы улучшилось, а показатель кликов (CTR) в поиске увеличился на 11%.
Рассеивание авторитета внешних ссылок
Если на несколько дублирующих версий URL-адресов ссылаются внешние веб-сайты (например, кто-то использовал URL-адрес с параметрами при повторной публикации контента, или новая ссылка была сгенерирована при продвижении страницы столбца), но эти внешние ссылки указывают на разные адреса, поисковая система не может объединить авторитет автоматически.
Сравнение данных: статья об “Руководстве по аспирантуре” на образовательном веб-сайте была переиздана 5 внешними сайтами, 3 из которых ссылались на версию без параметров (https://example.com/guide/kaoyan), а 2 ссылались на версию с параметрами (https://example.com/guide/kaoyan?from=partner).
Без установленного канонического тега поисковая система связывала бы эти 5 внешних ссылок с разными URL-адресами по отдельности. После того как веб-сайт добавил канонический тег на все версии (указывающий на версию без параметров), органический поисковый трафик страницы увеличился на 24% за 6 месяцев.
Базовый синтаксис и формат канонического тега
Примерно 32% страниц размещают канонический тег в разделе <body> (вместо требуемой области <head>), 19% значений атрибута href не имеют полного протокола (например, написано только example.com вместо https://example.com), а 15% страниц указывают на разные “канонические версии” в нескольких дублирующих URL-адресах (что вызывает путаницу в поисковой системе).
С точки зрения технической реализации, канонический тег – это по сути простой HTML-тег ссылки, но местоположение тега (должен быть внутри <head>), формат синтаксиса (должен строго соответствовать спецификации HTML) и URL-адрес, на который он указывает (должен полностью соответствовать фактическому контенту и быть доступным) являются ключевыми факторами для того, чтобы поисковая система приняла и применила его.
Данные показывают, что когда канонический тег реализован в соответствии со стандартным написанием (то есть размещен в верхней части <head>, использует полный протокол HTTPS, указывает на уникальный и правильный канонический URL-адрес), вероятность его правильной идентификации и применения поисковой системой превышает 95%;
А на страницах с ошибками в написании около 60% канонических намерений не принимаются поисковой системой, что приводит к сохранению проблемы дублирования контента.
Например, когда веб-сайт электронной коммерции добавил канонический тег на страницу сведений о товаре (например, версию ?color=red с параметрами), из-за того, что был пропущен заголовок протокола (написано как //example.com/product или example.com/product), Google не смог правильно проанализировать целевой URL-адрес.
Структура стандартного синтаксиса
Полный синтаксис канонического тега – это всего лишь одна строка HTML-кода: <link rel=“canonical” href=“https://www.example.com/Полный_URL_канонической_страницы” />
Эта строка кода состоит из 3 основных частей, которые являются обязательными и имеют фиксированный порядок:
Тип тега: <link>
Атрибут: rel="canonical"
Атрибут: href="URL"
Например:
Другие детали:
Почему он должен быть в <head>
Потому что, когда роботы поисковых систем сканируют страницу, они в первую очередь анализируют контент в области <head> (особенно мета-информацию, заголовок, канонические теги и другие “инструкции управления”), а затем обрабатывают фактический контент в <body>.
Если канонический тег по ошибке помещен внутрь <body> (например, вложен в абзац статьи или в код нижнего колонтитула), поисковая система будет напрямую игнорировать тег <link rel="canonical"> внутри <body>.
Другие примечания:
5 Самых распространенных ошибок
Ошибка 1: Указание на неверный URL-адрес (каноническая версия не соответствует фактической потребности)
Ошибка 2: Отсутствует заголовок протокола (написан только домен или используется относительный путь)
Ошибка 3: Конфликт между URL-адресами с параметрами и канонической версией
Ошибка 4: Тег помещен внутрь <body>
Ошибка 5: Наслоение нескольких канонических тегов
Разница между canonical и другими тегами (такими как noindex, перенаправление 301)
Канонический тег предназначен для “назначения авторитетной версии одного и того же контента” (сохранение всех URL-адресов, но сосредоточение авторитета), тег noindex предназначен для “запрета поисковой системе индексировать текущую страницу” (разрешение сканирования, но не отображения), а перенаправление 301 предназначено для “постоянного перенаправления старого URL-адреса на новый URL-адрес” (полная передача трафика и авторитета).
Существенные различия между canonical, запретом и перенаправлением
Канонический тег (canonical tag): Используется для “сценария нескольких URL-адресов для одного и того же контента”, цель состоит в том, чтобы сообщить поисковой системе “контент этих страниц действительно одинаков, но вы должны сосредоточиться только на этом конкретном URL-адресе, который я назначил (каноническая версия), и сосредоточить авторитет здесь”.
Тег noindex (тег запрета индексации): Используется для “сценария разрешения сканирования, но запрета отображения”, он сообщает поисковой системе “вы можете сканировать эту страницу, но не включайте ее в индекс результатов поиска”.
Перенаправление 301 (Постоянное перенаправление): Используется для “сценария, когда контент был окончательно перенесен”, автоматически перенаправляя пользователя и поисковую систему со старого URL-адреса на новый URL-адрес через настройки сервера (такие как файл .htaccess или правила Nginx). Авторитет старого URL-адреса (включая ранжирование, внешние ссылки, доверие пользователей) постепенно передается на новый URL-адрес, и старый URL-адрес может в конечном итоге перестать быть доступным (но перенаправление остается эффективным).
| Инструмент | Разрешает ли сканирование? | Разрешает ли индексацию? | Меняет ли URL-адрес? | Основная цель |
|---|---|---|---|---|
| canonical | ✅ Разрешает | ❌ Предлагает не индексировать (но все же может проиндексировать) | ❌ Не меняет | Сосредоточение авторитета множественного идентичного контента на канонической версии |
| noindex | ✅ Разрешает | ❌ Запрещает | ❌ Не меняет | Блокировка страницы от появления в результатах поиска |
| Перенаправление 301 | ❌ Автоматическое перенаправление | ❌ Старый URL-адрес не индексируется | ✅ Перенаправляет на новый URL-адрес | Передача авторитета и трафика со старого URL-адреса на новый адрес |
4 Группы общих сценариев и сравнение их использования
Сценарий 1: Один и тот же контент имеет несколько URL-адресов (например, страницы товаров с параметрами)
Сценарий 2: Страница больше не должна появляться в результатах поиска (например, страница истекшего события)
Сценарий 3: Изменение домена или корректировка структуры URL-адресов веб-сайта (например, миграция старых страниц товаров)
Сценарий 4: Отдельный URL-адрес для мобильного и настольного компьютера (например, m.example.com и www.example.com)
Как написать код? И какова логика различной эффективности?
Канонический тег: HTML-код, зависит от анализа поисковой системы
Логика эффективности: Когда поисковая система сканирует страницу, она считывает этот тег и записывает “каноническая версия этой страницы – XXX”, и при последующем расчете ранжирования и присвоении авторитета отдает приоритет канонической версии. Однако другие версии страницы все еще могут быть просканированы (если нет других ограничений).
Тег noindex: HTML-метатег или заголовок ответа HTTP, зависит от соблюдения правил роботом
Логика эффективности: Когда поисковая система сканирует страницу, она обнаруживает эту инструкцию, и если она подтверждает, что страница соответствует условиям noindex (например, это не спам-страница), она не добавит ее в индекс. Однако страница все еще будет сканироваться (если сканирование не заблокировано robots.txt), и пользователи могут получить к ней доступ по прямой ссылке.
Перенаправление 301: Конфигурация сервера, принудительное перенаправление трафика
Формат кода: Достигается с помощью серверной технологии, например:
Логика эффективности: Когда пользователь или поисковая система посещает старый URL-адрес, сервер автоматически возвращает код состояния 301 и перенаправляет на новый URL-адрес, и адресная строка браузера будет отображать новый адрес. Авторитет старого URL-адреса постепенно передастся (обычно от нескольких недель до нескольких месяцев) на новый URL-адрес, и старый URL-адрес может в конечном итоге перестать быть доступным напрямую (но функция перенаправления сохраняется).
