Изменения в зеркалировании Яндекса
Новость этой недели: яндекс изменил подход к переезду между зеркалами сайта. Раньше это определялось директивой Host в файле robots.txt, сейчас предполагается отказ от этой директивы и использование 301 редиректа, по аналогии с гуглом. Настройка в Яндекс.Вебмастере по-прежнему останется.
Далее алгоритм переезда будет выглядеть так:
- простановка 301 редиректа с неосновного зеркала на основное,
- использование Яндекс.Вебмастера для обозначения переезда.
Ближайшее время будут работать оба варианта.
Небольшая аналитика нововведения от меня (так как я занимаюсь переводом сайтов на https и тема зеркалирования очень близка мне) — пройдусь по основным пунктам.
Риск потери трафика
Главной проблемой переезда в яндексе был риск потери трафика. Особенно странно это выглядело в контексте переезда с просто домена на домен с www или с http на https. Казалось бы, это же один и тот же сайт, меняется только протокол или приставка www — но нет, для яндекса это словно два разных сайта.
Поэтому странно, что не допилив процедуру переезда в текущем виде они решили поменять алгоритм. Ну то есть это и так работало достаточно хлипко, так они ещё и редиректы решили сделать основным способом переезда. Странное решение. Надеюсь, на практике всё будет работать без косяков.
Доступность robots.txt
На моём сайте есть инструкция по добавлению robots.txt в список исключений, когда редирект вешается для всего сайта целиком. Делается это для того, чтобы у каждого зеркала был доступен этот файл с указанием главного зеркала в директиве Host. Теперь же мало того, что выпиливают эту директиву, так ещё и добавляют хорошую вещь — при редиректе файла robots.txt будут использоваться значения из итогового файла (на который ведёт редирект). Что ж, это действительно хорошее решение.
Скорость переезда
Яндекс пишет об ускорении процесса. Если раньше для переклейки зеркала приходилось ждать неделями, то теперь заявляется о днях. Пока у меня не было возможности проверить переезд по новому формату, однако здесь я охотно верю — нет в этой процедуре ничего такого сверхсложного, чтобы затягивать всё на месяц.
Обработка редиректов
Главный фактор потери трафика ранее заключался в обработке редиректов. Как только страница начинала отдавать 301 редирект, она с большой долей вероятностью выпадала из индекса. Новая страница могла не успеть подцепиться и как результат переходы из поиска падали. Я достаточно быстро просёк эту фишку и с помощью правильного алгоритма переезда минимизировал риски.
И вот, наконец, яндекс сам предложил решение, не требующее лишних манипуляций — теперь страницы с редиректом не будут сразу выпадать из индекса, а будут дожидаться индексации страницы-цели. Это, пожалуй, самая важная часть в обновлении. Удивительно, что в блоге разработчиков ей посвящено всего одно предложение.
Что в итоге делать?
С одной стороны, мы имеем явное снижение рисков переезда (в первую очередь имею в виду миграцию с обычного протокола на защищённое соединение), с другой стороны — временное разрешение на переезд как старым, проверенным способом, так и новым, пока ещё не протестированным. Выходит, что сейчас идеальное время для переезда на HTTPS, но всё-таки используя старый алгоритм.
P.S. Если планируете такой переезд, но не готовы заниматься этим лично, я предлагаю свою помощь в переезде под ключ. Обращайтесь через обратную связь.
