301 редирект: как настроить и не потерять позиции

301 редирект - это ответ сервера "страница переехала навсегда, вот новый адрес". Браузер молча открывает новый адрес, а поисковик переносит на него то, что накопил старый: место в выдаче и вес внешних ссылок. Нужен он всякий раз, когда меняется адрес страницы, которую уже знают люди или поиск: при редизайне, смене домена, переходе на HTTPS, склейке дублей.

Сама настройка занимает одну строку в конфиге сервера или пару полей в админке, и ошибаются в ней редко. Позиции теряют до этой строки и после неё. Старые адреса никто не выписал, пока они ещё открывались. Половину отправили на главную, потому что так быстрее. Через три месяца правила исчезли вместе со старым хостингом. Ниже порядок из шести шагов, готовые правила для Apache и nginx и сроки, которые называют справки Яндекса и Google.

Что делает 301 редирект и чем он отличается от 302#

Коды перенаправления делятся на постоянные и временные. Справка Яндекса относит к постоянным 301 и 308, к временным 302, 303 и 307. Google делит так же и объясняет, что меняется в выдаче: при постоянном редиректе в результатах показывается новая страница, при временном остаётся старая.

На практике выбирают между двумя кодами.

301 ставят, когда старого адреса больше не будет. Страница переехала, раздел переименовали, домен сменили.

302 ставят, когда старый адрес вернётся: страница акции на время распродажи, заглушка на время работ. Яндекс пишет об этом коде прямо: "Используйте этот код только для временных перенаправлений".

Постоянный и временный редирект: какие коды к ним относятся и какую страницу поисковик показывает в выдаче

Есть третий способ, о котором спорят: мета-тег refresh в коде страницы. Здесь поисковики расходятся. Google считает refresh с нулевой задержкой постоянным перенаправлением, Яндекс при небольших задержках считает его временным. Так что refresh годится только как крайний вариант, когда доступа к настройкам сервера нет совсем.

И два случая, когда редирект не нужен. Страница удалена, и замены ей нет: пусть отдаёт 404, это честнее, чем вести человека на что-то постороннее. Один и тот же товар открывается по нескольким адресам с параметрами: это задача для тега canonical, а не для перенаправления.

Шесть шагов: как настроить 301 редирект при переезде#

Шаг 1. Выписать старые адреса, пока они открываются#

Этот шаг пропускают чаще остальных, а восстановить список задним числом трудно. Нужны все адреса, которые знает поиск и на которые ведут ссылки. Источников четыре:

• карта сайта sitemap.xml, пока она ещё старая;
• раздел "Страницы в поиске" в Яндекс Вебмастере, выгрузка в файл. Если сайт туда ещё не добавлен, добавьте его в Вебмастер до переезда, а не после;
• отчёт "Страницы входа" в Метрике за последний год. В нём всплывают адреса, которых давно нет в меню, но на которые до сих пор приходят;
• раздел "Внешние ссылки" в Вебмастере. Страницы, на которые ссылаются другие сайты, терять обиднее всего.

В список попадают не только страницы. Google в руководстве по переезду отдельно напоминает про картинки и файлы для скачивания. Прайс-лист в PDF, который годами открывали по прямой ссылке из писем менеджеров, тоже адрес.

Шаг 2. Сопоставить каждый старый адрес с новым#

Таблица в два столбца: было и стало. Правило одно: старый адрес ведёт на страницу, которая отвечает на тот же вопрос. Карточка товара на карточку того же товара, статья на ту же статью, раздел на раздел.

Точной замены нет? Ищите ближайшую по смыслу: снятый с продажи товар можно отправить в его категорию. Нет и ближайшей, оставьте 404.

Соблазн отправить всё непонятное на главную знаком каждому, кто переносил сайт в последний вечер перед запуском. Оба поисковика против. Google предупреждает, что перенаправление многих старых адресов на одну нерелевантную страницу путает людей и может быть расценено как мягкая 404: страница формально есть, а для поиска её нет. Яндекс в справке о переезде пишет, что редирект всех страниц на главную снижает скорость индексации нового сайта.

На сайте в сто страниц таблица собирается за вечер. В магазине на десять тысяч карточек адреса сопоставляют правилом по шаблону, а руками проверяют только то, что в шаблон не легло.

Шаг 3. Выбрать, где настраивать#

Правило должно срабатывать до загрузки страницы, на уровне сервера. Google рекомендует постоянный серверный редирект везде, где это возможно, а редирект на JavaScript советует использовать, только если остальные способы недоступны.

Где это делается:

• Виртуальный хостинг или сервер с Apache. Файл .htaccess в корне сайта.
• Сервер с nginx. Конфиг сайта. После правки nginx нужно перезагрузить, иначе правило не заработает.
• WordPress. Плагин Redirection: бесплатный, больше двух миллионов установок, правила заводятся из админки без доступа к серверу.
• Тильда. Настройки сайта, раздел SEO, пункт "Редиректы страниц". В справке Тильды два ограничения: редирект работает только в рамках одного домена и только с несуществующих страниц. Сначала старую страницу снимают с публикации, потом вешают правило. Для смены домена этот инструмент не подходит, подробнее в разборе переноса сайта с Тильды.
• 1С-Битрикс. Обычно тот же .htaccess, потому что Битрикс чаще всего работает на Apache.
• Статический сайт. Здесь ловушка. В Next.js при статическом экспорте редиректы, описанные в конфиге проекта, не поддерживаются, это прямо сказано в документации. У сайта нет своего сервера приложений, который мог бы их исполнить. Правила заводят в nginx, который раздаёт файлы, или в настройках хостинга.

Шаг 4. Написать правила#

Для Apache, файл .htaccess:

# одна страница
Redirect 301 /old-page.html https://example.ru/new-page/

# раздел целиком: хвост адреса и параметры сохранятся
Redirect 301 /blog/ https://example.ru/articles/

# http и www на https без www за один переход
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [R=301,L]

Для nginx:

# http на https без www
server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

# одна страница, параметры сохраняются
location = /old-page/ { return 301 /new-page/$is_args$args; }

# раздел целиком
location ^~ /blog/ { rewrite ^/blog/(.*)$ /articles/$1 permanent; }

Для адреса с www по HTTPS в nginx нужен такой же блок на порту 443 со своим сертификатом, иначе браузер покажет ошибку раньше, чем дойдёт до правила. Как устроены сертификаты, разбирали в статье про SSL для сайта.

Три вещи, которые ломают эти правила чаще всего.

Код нужно писать явно. В Apache директива Redirect без кода отдаёт 302, так написано в документации. Флаг R без "=301" делает то же самое. Временный редирект в таких случаях никто не выбирал, просто забыли три цифры.

Сайт за прокси или балансировщиком видит каждый запрос как обычный HTTP. Переменная HTTPS на самом сервере выключена всегда, и правило "с http на https" зацикливается. В такой схеме проверяют заголовок X-Forwarded-Proto, который передаёт прокси.

Правило, перенесённое из основного конфига Apache в .htaccess, может потерять слеш. В .htaccess путь приходит в правило без первой косой черты, и адрес склеивается в example.rucatalog. Вариант с REQUEST_URI из примера выше от этого свободен.

Шаг 5. Проверить каждое правило#

Самая честная проверка делается одной командой в терминале:

curl -sIL https://example.ru/old-page/

Она показывает всю цепочку ответов. Правильная картина: один ответ 301 с заголовком Location на конечный адрес и следом 200. Два ответа 301 подряд означают цепочку, 302 вместо 301 означает забытый код.

Браузеру в этой проверке верить нельзя: он запоминает постоянный редирект и продолжает вести по старому правилу после того, как вы его исправили. Смотрите в режиме инкогнито или в инструментах разработчика на вкладке Network с включённой галочкой Preserve log.

Что видит робот, покажет инструмент "Проверка ответа сервера" в Яндекс Вебмастере. Для списка адресов есть массовые проверки: Screaming Frog в бесплатной версии обходит до 500 адресов, httpstatus.io принимает до ста за раз.

Шаг 6. Обновить всё вокруг и не снимать правила#

Редирект страхует чужие ссылки. Свои собственные должны вести прямо.

• Внутренние ссылки, меню и карту сайта переведите на новые адреса.
• Теги canonical тоже. Google отдельно просит убедиться, что на новом сайте они указывают на новые адреса.
• Старые адреса не закрывайте в robots.txt. Робот должен дойти до старого адреса, чтобы увидеть перенаправление. Яндекс требует, чтобы индексирование было разрешено в robots.txt обоих доменов, а запрет называет среди причин отказа в переезде. Как читать этот файл, есть в разборе настройки robots.txt.
• При смене домена и при переходе на HTTPS подайте заявку в Вебмастере: раздел "Индексирование", пункт "Переезд сайта".

О сроке. В справке Яндекса сказано: "Сохраняйте перенаправление минимум 6 месяцев". Google советует держать как можно дольше и в общем случае не меньше года. Правило ничего не стоит, так что разумнее не снимать его совсем. Только помните, к чему оно привязано: редирект со старого домена живёт, пока оплачен домен. Истёкший домен уносит с собой и правила, и ссылки, которые на него вели.

Сколько ждать и что будет с позициями#

Здесь справки честнее, чем хотелось бы.

Яндекс пишет, что смена главного адреса сайта происходит в течение нескольких недель, а обработка заявки на переезд может занять от нескольких недель до месяцев. И добавляет фразу, которую стоит прочитать до переезда, а не после: "Яндекс не гарантирует сохранение количества страниц сайта в результатах поиска, его позиций или посещаемости". В посте 2018 года, где Яндекс объявил об отказе от директивы Host, срок был мягче: "обычно переезд занимает несколько дней". Ориентироваться стоит на нынешнюю справку.

С переходом на HTTPS проще. При соблюдении рекомендаций, по словам той же справки, трафик при переезде не теряется, а индекс качества сайта переносится.

Google в руководстве по переезду пишет, что постоянные редиректы не приводят к потере веса страницы, а у небольшого или среднего сайта большинство страниц переезжает за несколько недель.

Получается так: при аккуратной карте редиректов закладывайте месяц на колебания и не трогайте в это время ничего лишнего. Следите за двумя отчётами: "Страницы в поиске" в Вебмастере, где старые адреса должны уходить, а новые появляться, и переходы из поиска в Метрике.

Если позиции просели всерьёз и не возвращаются, причина обычно не в редиректе. Вместе с адресами при редизайне меняют тексты, заголовки, структуру разделов, и поисковик заново оценивает уже другую страницу. Эту часть мы разбирали в статье о том, когда редизайн сайта оправдан, и в разборе мета-тегов title и description.

На чём теряют позиции после переезда#

Цепочки. Старый адрес ведёт на промежуточный, тот на следующий. Обычно они копятся годами: сначала добавили слеш, потом HTTPS, потом переименовали раздел. По документации Google его роботы проходят до десяти переходов, но рекомендация другая: вести сразу на конечный адрес, а если не получается, держать цепочку короче пяти звеньев, лучше не длиннее трёх. Предел для робота Яндекса в справке мы не нашли.

Петли. Адрес А ведёт на Б, а Б обратно на А. Браузер покажет ошибку "слишком много перенаправлений", сайт для посетителя лежит. Чаще всего петлю собирают из двух правил в разных местах: одно в плагине CMS, второе в конфиге сервера.

Потерянные параметры. В nginx директива return без переменных отбрасывает всё, что стояло после знака вопроса. Реклама продолжает вести на старые адреса, переходы доходят, а UTM-метки по дороге пропадают. В отчётах платный трафик превращается в "прямые заходы", и об этом узнают через месяц.

Canonical на старые адреса. Редирект говорит поиску "страница здесь", а тег в коде новой страницы показывает обратно. Два сигнала спорят друг с другом, склейка затягивается.

Правила, которые сняли вместе с хостингом. Сайт перенесли, старый тариф отключили, .htaccess остался там. Новый сервер о старых адресах ничего не знает.

Что из этого берём на себя#

Карту редиректов мы собираем при каждом переезде и редизайне, который делаем сами: выгружаем адреса из Вебмастера и Метрики до начала работ, сопоставляем с новой структурой, после запуска прогоняем весь список проверкой и месяц смотрим, как старые адреса уходят из поиска. В разработке сайта это входит в запуск вместе с подключением домена и редиректами на HTTPS.

Если переезд уже случился и трафик упал, начинаем с технического разбора в рамках SEO-продвижения: какие старые адреса отдают 404, где цепочки, куда ведут внешние ссылки. Тарифы от 80 000 рублей в месяц, первые сдвиги обычно видны через полтора-три месяца. Разовая настройка редиректов без абонентской платы считается по часам, 3 000 рублей за час.

Источники#

• Справка Яндекс Вебмастера: обработка перенаправлений - какие коды робот считает постоянными и временными.
• Справка Яндекс Вебмастера: коды ответа HTTP - срок хранения редиректа, назначение кода 302.
• Справка Яндекс Вебмастера: переезд сайта - сроки, требования к robots.txt, оговорка о позициях.
• Справка Яндекс Вебмастера: переход на HTTPS - что происходит с трафиком и индексом качества.
• Блог Яндекса для вебмастеров, 20.03.2018 - отказ от директивы Host.
• Google Search Central: редиректы и Google Поиск - постоянные и временные перенаправления.
• Google Search Central: переезд сайта со сменой адресов - срок хранения, цепочки, мягкая 404.
• Google Search Central: коды ответа и сетевые ошибки - сколько переходов проходит робот.
• Документация Apache: mod_alias и флаги RewriteRule - код по умолчанию 302.
• Документация nginx: модуль rewrite - директивы return и rewrite.
• Справка Тильды: редирект 301 - ограничения инструмента.
• Документация Next.js: статический экспорт - что не поддерживается.