Дубли страниц и канонический адрес
В прошлых уроках мы проверяли доступность материала и исправляли перенаправления. Теперь рассмотрим случай, когда два разных адреса успешно возвращают одну и ту же статью. Оба документа могут открываться без ошибки, но владельцу нужен один основной адрес, по которому сохраняются ссылки и собираются сведения о материале.
В нашем условном стенде старый урок B доступен также по адресу G с параметром from=menu. Название и содержание у них совпадают. Мы согласуем объявленный canonical и обычные ссылки с B, не меняя его сохранённый путь. Все ответы и настройки example.com — учебные условия; сведения о том, какой адрес фактически выбрали Google или Яндекс, без отдельного отчёта остаются неизвестными.
Когда два URL обозначают один материал
У адресов B и G общий путь, а различие находится после знака вопроса:
B: https://example.com/my/LINQ/linq_xml/level7/7_1.php
G: https://example.com/my/LINQ/linq_xml/level7/7_1.php?from=menuПо условиям курса from=menu обозначает источник перехода и не меняет урок. Чтобы установить такую же ситуацию на собственном сайте, нужно сравнить результат: заголовок, основной текст, примеры и назначение страницы. Совпадение пути само по себе не доказывает равенство, а совпадение одной фразы не доказывает дублирование всей статьи.
Это важное ограничение для библиотеки уроков. Два материала о Markdown могут решать разные задачи: один объясняет синтаксис, другой — сборку каталога. Общая тема и повторение вводного определения не делают второй документ копией первого. В нашем примере C — новая самостоятельная статья; мы не назначаем ей canonical на B только потому, что оба материала связаны с веб-разработкой.
Параметры тоже различаются по смыслу. У G параметр не изменяет материал. У служебной страницы E параметр q=xml задаёт поисковый запрос и может менять список результатов. У страницы каталога параметр номера страницы может выбирать другую часть списка. Поэтому правило «всё после ? нужно удалить» способно объединить разные документы и скрыть полезные ссылки.
До исправления учебные условия выглядят так:
| ID | Ответ | Основное содержание | Объявленный canonical | Запись Sitemap |
|---|---|---|---|---|
| B | 200 | Старый урок | B | Есть |
| G | 200 | Тот же старый урок | G, ошибочно | Нет |
Здесь в колонке canonical описано указание сайта. Решение поисковой системы — другая величина. При обнаружении нескольких версий Google группирует похожие документы и выбирает канонический адрес; указание владельца участвует в этом выборе. Как Google определяет канонический URL.
Выбор B без переименования старого урока
Основным адресом выбираем B: он существует в сохранённой библиотеке, на него уже ориентированы обычные ссылки и запись карты сайта. Параметр источника перехода не является частью содержания. В опыте ProfessorWeb мы отделили Markdown-исходник от публичного пути и сохранили старые адреса; тот же принцип помогает здесь избежать ненужного переезда.
Расширение .php не требует замены на .html ради канонического адреса. Если по сохранённому пути сервер отдаёт подходящий документ, смена технологии подготовки страницы не меняет её назначение. Переименование создаст ещё одну задачу перенаправления вместо решения текущего дублирования.
Перед настройкой проверьте выбранную цель. По учебным условиям B доступна с ответом 200, обход и индексация разрешены, canonical указывает на себя. Если бы цель перенаправляла дальше, была запрещена или содержала другой урок, сначала следовало бы разобраться с этим противоречием. Яндекс указывает, что может игнорировать canonical при недоступности цели, существенном различии содержания, нескольких указаниях и цепочках канонических адресов. Канонический адрес в Яндексе.
Обратите внимание: мы не выбираем «самую красивую» строку адреса отдельно от истории материала. Для давно существующей библиотеки понятный порядок состоит в сохранении исправного известного маршрута и устранении ненужных альтернатив. Выбор нового пути допустим при настоящем переезде, но должен сопровождаться отдельной картой соответствий.
Одна каноническая цель в документе
В <head> G заменим ошибочную самоссылку на адрес B. У B уже есть правильная самоссылка; её оставляем. В обоих документах нужный элемент будет одинаковым:
<link rel="canonical" href="https://example.com/my/LINQ/linq_xml/level7/7_1.php">Это фрагмент HTML, а не новая страница и не инструкция перенаправления. Он не перемещает посетителя с G на B и не меняет адресную строку браузера. Пользователь может оставаться на G, тогда как документ объявляет предпочитаемую версию материала.
В примере используется полный абсолютный URL, чтобы цель не зависела от текущей папки. Указание должно находиться в действительном <head> и иметь одну согласованную цель. Проверьте, не добавляет ли общий шаблон второй элемент и не передаёт ли сервер противоречащий HTTP-заголовок Link. Google описывает HTML-элемент и HTTP-заголовок как способы объявления canonical; разные методы не должны указывать разные цели. Указание канонического URL в Google.
Для генератора это означает настройку на уровне результата, который получает посетитель. Исходник B должен хранить свой постоянный адрес, а общий шаблон — строить canonical из него. Если сервер отдаёт тот же сгенерированный файл при наличии from=menu, canonical останется B независимо от запроса. Если приложение строит его автоматически из всей текущей адресной строки, оно может возвращать ошибочную самоссылку для каждого параметра.
Не добавляйте noindex G только для усиления canonical. Эти указания решают разные задачи: одно предлагает основной адрес одинакового материала, другое запрещает индексацию текущего документа. Google не рекомендует использовать noindex для выбора канонической версии внутри сайта. Рекомендации по нормализации URL.
Canonical остаётся рекомендацией, а не гарантией. Мы можем исправить указание сайта и подтвердить его присутствие в ответе. Утверждение «Google выбрал B» требует новых индексных сведений Google; аналогичное утверждение о Яндексе требует его данных. Яндекс прямо предупреждает о возможности игнорирования указания. Ограничения rel="canonical" в Яндексе.
Согласование обычных ссылок
Одна строка canonical полезна, но источник новых дублей тоже стоит устранить. Предположим, меню нашего стенда выводит ссылку на G:
<a href="/my/LINQ/linq_xml/level7/7_1.php?from=menu">Запросы LINQ to XML</a>Такой адрес не нужен для открытия самого урока. Изменим источник меню так, чтобы обычная ссылка вела сразу на B:
<a href="/my/LINQ/linq_xml/level7/7_1.php">Запросы LINQ to XML</a>После изменения посетитель попадает на тот же материал, а навигация больше не создаёт эту параметризованную копию. Если источники переходов нужны аналитике, их учёт следует организовать так, чтобы не требовать отдельных индексируемых адресов каждого пункта меню. Конкретный способ зависит от используемой аналитики; удалять функциональные параметры по общему правилу мы не будем.
В нашем Sitemap G изначально отсутствует, а B присутствует: здесь дополнительной замены не требуется. Проверка согласованности всё равно полезна. Если в карте указан один предпочитаемый адрес, в HTML — другой, а меню ведёт на третий, владелец подаёт неоднозначные сведения. Google рекомендует направлять внутренние ссылки на канонические URL и не задавать противоречащие цели разными способами. Согласование сигналов канонического адреса.
Сохранённый H из предыдущего урока имеет другую задачу: он должен перенаправлять прямо на B, потому что прежний путь заменён. G остаётся доступной параметризованной версией, объявляющей B. Если в вашем приложении параметр вообще больше не нужен и безопасно удаляется, может подойти перенаправление. Но это решение принимается после проверки назначения параметра, а не в качестве обязательного дополнения к каждому canonical.
Параметры в Яндекс Вебмастере
Для параметров, которые не влияют на содержимое, Яндекс поддерживает директиву Clean-param и инструмент Индексирование → Настройка GET-параметров. В последнем можно задать, какие обнаруженные или добавленные параметры учитывать. Это отдельный способ управления обработкой адресов Яндексом; он не заменяет общую настройку страницы для других поисковых систем. Настройка GET-параметров в Яндексе.
В нашем основном упражнении дополнительное правило не требуется: мы уже задаём B через canonical и исправляем источник ссылки. Если вы хотите использовать параметрические настройки на своём сайте, сначала составьте перечень применений from. Возможно, в одном разделе он служит меткой, а в другом выбирает содержимое. Правило для всего домена в таком случае будет шире, чем доказанная задача.
Для файлового правила Clean-param можно ограничить префикс пути; оно предназначено для незначащих параметров. При выделении отдельной группы User-agent: Yandex нужно внимательно сохранить остальные предназначенные Яндексу правила: общая группа * не становится автоматическим дополнением к специальной. Синтаксис и особенности групп описаны в документации Clean-param.
Не переносите это решение на q страницы E или на пагинацию без сравнения содержимого. У E уже есть собственная политика noindex, а разные страницы длинного каталога могут содержать разные ссылки. Canonical всех страниц каталога на первую способен противоречить фактическому составу документов. Для начала нужно решить, действительно ли варианты являются копиями.
Проверка объявленного и выбранного адреса
В журнале изменений G получит гипотезу: «Параметр источника создаёт копию B, но HTML объявляет её самостоятельной канонической версией». Изменение состоит в canonical на B и прямых ссылках на B. Ожидаемое непосредственное наблюдение — в GET-ответе G присутствует один правильный элемент, B остаётся доступной, а обычная навигация не создаёт G.
Поисковое наблюдение записывается позже и отдельно. В Search Console выбранный Google canonical относится к индексным данным, поэтому текущая проверка HTML не заменяет это поле. Если свежих данных ещё нет, значение остаётся unknown, даже когда настройка технически согласована. В Яндексе отсутствие G в поиске как неканонической страницы может оказаться ожидаемым результатом; задача состоит в сохранении участия основного материала, а не всех его копий.
Для самостоятельного варианта измените условие: параметр теперь выбирает другую языковую версию урока. Объясните, почему прежнее обоснование дубля перестало работать. Такая проверка помогает понять границу правила: канонический адрес выбирается после установления отношений между документами, а не по одному наличию знака вопроса. Далее мы согласуем карту сайта с уже разобранными состояниями A–H и добавим нормальный путь к новой статье C.