Главное зеркало

Происхождение и история термина

«Главное зеркало» — термин русскоязычной практики Яндекса. В архивной записи официального блога от 9 ноября 2011 года он использован для выбора между доменами с www и без него. Эта публикация подтверждает употребление термина к указанной дате, но не устанавливает его первого автора или дату появления. ^[5]

Старую инструкцию нельзя переносить в нынешнюю настройку. В записи 2011 года упоминались директива Host и прежний интерфейс. Текущая справка говорит о главном и неглавных адресах, показывает проверку группы в Яндекс Вебмастере и направляет для смены адреса к инструменту «Переезд сайта». ^{[1] [5]}

Международная документация чаще описывает не «главное зеркало сайта», а канонический URL. RFC 6596, опубликованный в апреле 2012 года, определяет отношение canonical как указание предпочтительного адреса среди ресурсов с дублирующим содержанием. ^[3] Понятия связаны, но масштаб различается: главное зеркало описывает адресную версию сайта, а canonical обычно связывает конкретные дублирующиеся страницы.

Суть и механизм

Представим одну статью по четырём адресам: HTTP и HTTPS, каждый с www и без него. Для читателя содержание одинаково, но для сервера и поискового робота это четыре URL. Поисковик должен понять, какие URL относятся к одному содержанию и какой из них использовать как представительный.

В Яндексе роботы сначала индексируют адреса как отдельные сайты. Затем алгоритмы обнаруживают дубли страниц и могут объединить адреса в группу; в поиске остаётся главный адрес. Если владелец не указал предпочтение, Яндекс определяет его алгоритмически. Владелец может проверить и изменить адрес через Яндекс Вебмастер, подтвердив права на нужные варианты. ^[1]

Google описывает похожую задачу на уровне канонических URL. Перенаправление и rel="canonical" считаются сильными сигналами, включение URL в sitemap — слабым; согласованные сигналы могут складываться. При этом Google может выбрать другой канонический URL, если технические сигналы или содержание указывают на него. ^{[2] [6]}

Перенаправление и canonical действуют по-разному. Серверное перенаправление отправляет посетителя и робота с прежнего URL на новый. rel="canonical" не переводит посетителя: он сообщает обработчику, какой дублирующий ресурс автор считает предпочтительным. RFC допускает canonical на другом домене или с другой схемой протокола, но целевой ресурс должен дублировать исходное содержание или включать его. ^[3]

Виды и границы понятия

Для диагностики удобно использовать редакционную классификацию по тому, чем отличаются адреса:

• протоколом: http://example.ru и https://example.ru;
• именем хоста: example.ru и www.example.ru;
• доменным именем при переезде: old-example.ru и new-example.ru;
• путём или параметрами одной страницы: /article и /article?source=email.

Первые три ситуации могут затрагивать адресную версию всего сайта. Последняя чаще относится только к каноникализации документа. Одинаковый шаблон или общая тема ещё не делают два независимых сайта зеркалами: исходная граница — дублирующее содержание. ^{[1] [3]}

Полезно также различать желаемый и фактически выбранный адрес. Желаемый URL владелец указывает в редиректах, canonical, sitemap и панели поискового сервиса. Фактический URL отображается в данных поисковика. Несовпадение этих значений — повод проверить сигналы, а не само по себе доказательство санкции или ошибки алгоритма. ^{[1] [6]}

Как применяется на практике

Учебный пример: редакция переводит сайт с http://www.example.ru на https://example.ru. Сначала она составляет соответствие старых и новых URL: прежняя статья ведёт к той же статье, рубрика — к той же рубрике. Google рекомендует при переезде подготовить такую карту, включить серверные постоянные перенаправления и затем наблюдать за старым и новым адресами. ^[4]

Для каждого старого URL команда проверяет код ответа и конечный адрес. Google рекомендует по возможности постоянные серверные перенаправления, например 301 или 308, и советует вести старый URL сразу к конечному, избегая длинных цепочек. Массовое перенаправление несвязанных страниц на главную может быть воспринято как ошибка soft 404. ^[4]

После запуска внутренние ссылки и новый sitemap переводят на HTTPS-адреса, а canonical на новых страницах указывает на новые URL. Google отдельно предупреждает против разных предпочтительных адресов в разных способах каноникализации. ^{[2] [4]} Для Яндекса проверяют, что права подтверждены на нужные адреса и что желаемый адрес стал первым в группе на странице «Мои сайты». ^[1]

Как проверить результат

Начните с выборки разных типов страниц: главной, рубрики, свежей и старой статьи, файла и URL с параметром. Для каждого адреса запишите:

1. исходный URL;
2. код ответа и каждый переход в цепочке;
3. конечный URL и соответствие его содержания исходной странице;
4. значение rel="canonical";
5. наличие конечного URL во внутренних ссылках и sitemap;
6. выбранный поисковой системой адрес.

Учебный расчёт: из 20 проверенных старых URL 18 сразу приводят к соответствующим новым страницам. Доля корректных маршрутов равна 18 / 20 × 100% = 90%. Это результат выборки маршрутов, а не доля страниц, уже объединённых поисковиком, и не прогноз позиций.

В Яндекс Вебмастере главный адрес виден на странице «Мои сайты»: если адреса объединены, первый адрес открывает группу. Для Google в инструменте проверки URL сравнивают поля «канонический URL, указанный пользователем» и «канонический URL, выбранный Google». Выбор Google определяется по индексированной версии; проверка опубликованной сейчас страницы не предсказывает будущий canonical. ^{[1] [7]}

Техническая проверка и проверка поискового индекса отвечают на разные вопросы. Первая показывает, правильно ли сервер и страница передают сигналы сейчас. Вторая показывает, что поисковик уже обработал. Поэтому исправный редирект не означает мгновенного обновления индекса: Google прямо отмечает, что обработка переезда зависит от размера сайта и скорости сервера. ^[4]

Ошибки, ограничения и спорные вопросы

Закрывать старые URL в robots.txt вместо настройки каноникализации не следует. Google предупреждает, что запрещённый для обхода URL всё равно может быть проиндексирован без его содержания; кроме того, робот не увидит сигнал на закрытой странице. ^[2]

Canonical нельзя направлять на страницу с другим смыслом только ради сокращения числа URL. По RFC целевой ресурс должен содержать дублирующий материал либо охватывать содержание исходного ресурса. ^[3] Языковые версии, разные товары и самостоятельные региональные предложения требуют отдельного решения.

Ещё одна ошибка — проверять только главную страницу. Редирект главной может работать, пока старые статьи ведут на нерелевантный раздел или возвращают ошибку. Выборка должна охватывать шаблоны и типы URL, а при крупном переезде нужен автоматизированный обход. ^[4]

Ни один отдельный сигнал не гарантирует выбора. Google прямо оставляет окончательный выбор за своими системами, а Яндекс может сначала видеть адреса раздельно и объединить их со временем. ^{[1] [2]} Поэтому срок настройки сервера и срок обновления поисковых данных различаются.

Частые вопросы

Связанные термины

• zerkalo-sayta
• kanonicheskiy-adres
• 301-redirekt
• https-i-ssl-sertifikat
• indeksatsiya
• robots-txt