Что делает 301
Сервер отвечает не содержимым страницы, а указанием: «этот адрес больше не используется, содержимое находится здесь». Браузер молча уводит пользователя, а поисковый робот получает сигнал заменить адрес в базе.
Замена не мгновенная. Роботу нужно повторно обойти старый адрес, увидеть указание, обойти новый и убедиться, что содержимое соответствует. Пока это не произошло, в выдаче может встречаться старый URL.
Коды ответа и когда какой
| Код | Смысл | Когда применять |
|---|---|---|
| 301 | Переехало навсегда | Смена адреса, склейка дублей, переезд на HTTPS |
| 302 | Временно по другому адресу | Техработы, A/B-тест, временная акционная страница |
| 307 | То же, что 302, но с сохранением метода запроса | Технические сценарии с формами |
| 404 | Не найдено | Адрес не существует, но может появиться |
| 410 | Удалено навсегда | Материал снят осознанно и не вернётся |
Практическая разница между 404 и 410 невелика, но 410 — более определённое утверждение, и адрес выводится из индекса быстрее.
Где перенос сигналов ломается
Нерелевантная цель. Статья о ремонте холодильников, перенаправленная на страницу продажи телевизоров, не передаст ничего: содержимое не соответствует запросам, по которым страница ранжировалась. Формально редирект работает, фактически сигналы теряются.
Цепочка. Схема «старый адрес → промежуточный → конечный» встречается сама собой: сначала переехали на HTTPS, потом сменили структуру, потом объединили разделы. Каждое изменение добавило шаг. Итог — три перехода вместо одного.
Приёмник не существовал раньше. Если новая страница создана в день переключения, поисковик видит её впервые и не может сопоставить с прежней. Приёмники стоит публиковать заранее, чтобы они успели попасть в индекс.
Редирект вместо canonical. Для двух почти одинаковых страниц, которые обе должны быть доступны, нужен canonical, а не редирект: 301 просто закроет доступ к одной из них.
Как проверить
Один запрос показывает всю цепочку:
curl -sIL https://site.ru/old-page/ | grep -E "^HTTP/|^location:"
Ожидаемый результат — одна строка со статусом 301, один location и затем 200. Две строки 301 подряд означают цепочку, которую надо схлопнуть, перенаправив первый адрес сразу на конечный.
После переезда трафик не восстановился за несколько месяцев. Проверьте релевантность соответствий: часть страниц могла уехать на общий раздел вместо точного аналога.
Старые адреса держатся в индексе. Убедитесь, что редирект отдаётся именно роботу — иногда правило срабатывает только для браузеров из-за условий по User-Agent. Проверяется тем же curl с подстановкой имени робота.
Циклическое перенаправление. Правило перенаправляет адрес сам на себя — классически возникает при склейке index.html с корнем каталога. Нужна проверка на совпадение исходного и целевого адреса.
Часть страниц отдаёт 404 вместо редиректа. Правило написано с точным совпадением адреса и не учитывает слеш в конце или регистр.
Массовый переезд
Когда переезжает весь сайт, порядок такой:
- Составить карту соответствий: каждый старый адрес — конкретный новый, а не «раздел вообще».
- Опубликовать страницы-приёмники заранее и дать им попасть в индекс.
- Проверить каждое соответствие на одиночность перехода.
- Включить редиректы, начиная с небольшой части адресов, и убедиться, что всё работает.
- Оставить старый sitemap доступным ещё некоторое время — это помогает роботу быстрее переобойти адреса.
Для страниц без точного аналога лучше вести на ближайший тематический раздел, чем на главную: релевантность определяет, дойдут ли сигналы.
Чем настраивают редирект и что из этого хуже
Способ реализации определяет главное — будет ли это вообще код ответа сервера.
| Способ | Где срабатывает | Чем неудобен |
|---|---|---|
| Конфигурация сервера (nginx, Apache) | До запуска приложения | Нужен доступ к серверу и перезагрузка конфигурации |
.htaccess в каталоге сайта | На каждом запросе, файл перечитывается | Правила копятся годами и незаметно складываются в цепочки |
| Модуль или плагин CMS | После загрузки приложения | Работает, только пока работает сам сайт |
| Ответ в коде приложения | В обработчике маршрута | Статус легко перепутать: во многих фреймворках функция редиректа по умолчанию отдаёт 302 |
<meta http-equiv="refresh"> | В браузере после загрузки страницы | Сервер отвечает 200 — кода переезда нет вообще |
| Переход скриптом | В браузере после исполнения JS | Робот может не выполнить скрипт и увидеть исходную страницу |
Граница проходит между четвёртой и пятой строкой. Первые четыре способа кладут статус в заголовок ответа — именно его читает робот. Последние два подменяют навигацию уже после того, как сервер вернул содержимое с кодом 200, и переносом сигналов не являются.
Выбор внутри первой четвёрки — вопрос эксплуатации, а не эффекта. Правило на уровне сервера отрабатывает быстрее и не зависит от состояния сайта, правило внутри CMS проще править человеку без доступа к серверу и легче потерять при обновлении.
Проверка списка адресов до переключения
Выборочная проверка нескольких URL картины не показывает: ошибки в правилах вылезают на тех адресах, о которых никто не вспомнил. Прогонять нужно весь список целиком, и до того, как правила увидит робот.
- Собрать старые адреса из карты соответствий, логов сервера и отчёта о проиндексированных страницах в панели вебмастера.
- Прогнать список и получить по каждому адресу код ответа и цель перехода.
- Разобрать всё, что не равно
301. - Отдельно посчитать число переходов до конечного адреса.
Первые два шага делаются одной командой — список адресов лежит в файле по одному в строке:
xargs -I{} curl -sI -o /dev/null -w "%{http_code} {} -> %{redirect_url}\n" {} < old-urls.txt
Что означают строки вывода:
301 ... -> https://example.com/new/ — правило отработало, цель указана явно. Единственный вариант, который можно пропустить дальше без разбора.
302 — временный статус вместо постоянного. Пользователь попадает куда нужно, но старый адрес остаётся в индексе и продолжает конкурировать с новым.
200 с пустой целью — правило не сработало, старая страница открывается как обычно. Обычная причина — несовпадение по слешу на конце или по регистру.
404 — адрес выпал из карты соответствий и после переключения будет отдавать ошибку.
Глубину цепочки показывает отдельный счётчик:
curl -sIL -o /dev/null -w "%{num_redirects} %{url_effective}\n" https://example.com/old-page/
Ожидаемый вывод — 1 и конечный адрес. Двойка и больше означают цепочку: исходное правило нужно переписать так, чтобы оно сразу вело на адрес из второй колонки. Такая проверка входит в обязательный минимум технического аудита и повторяется после каждой правки структуры.
Где общее правило приходится нарушать
Рекомендация «каждый старый адрес ведёт на конечный за один шаг» покрывает большинство случаев, но не все.
Смена протокола и хоста одновременно. Переход на HTTPS и склейка адреса с www обычно живут в двух независимых правилах, и запрос проходит их последовательно. Правило должно приводить адрес к конечному виду за один раз, а не исправлять по одному признаку за шаг.
Адреса с параметрами. Правило по точному совпадению пути не сработает для /old-page/?utm_source=.... Решение принимается один раз на весь сайт: параметры либо отбрасываются, либо переносятся на новый адрес вместе с путём. Второй вариант сохраняет разметку кампаний, первый упрощает правила.
Служебные адреса, которых в новой структуре нет. Фильтры, сортировки, результаты внутреннего поиска переносить некуда. Массовое перенаправление таких адресов на категорию не даёт ничего, кроме лишней работы роботу, — часть закрывается от обхода, часть отдаёт 410.
Две страницы, которые обе должны открываться. Здесь нужен не редирект, а canonical: 301 просто закроет доступ к одной из них.
Ссылки внутри сайта. После переключения внутренние ссылки переписывают на конечные адреса, а не оставляют на редирект. Иначе каждый переход стоит лишнего запроса, а при следующей смене структуры перелинковка сама становится источником цепочек.
Спорное место
301 воспринимают как способ сохранить накопленное — и в этом источник завышенных ожиданий. Редирект действительно переносит часть сигналов, но не гарантирует сохранение позиций: новая страница попадает в другую конкурентную среду и оценивается заново.
Честная рамка: 301 предотвращает потерю всего, а не гарантирует сохранение всего. Просадка после переезда — нормальное явление, вопрос лишь в глубине и длительности. Планировать переезд стоит с этим допущением, а не с расчётом на бесшовность.
Частые вопросы
Чем 301 отличается от 302?
Сколько держать редирект после переезда?
Можно ли перенаправить все удалённые страницы на главную?
Вредят ли цепочки редиректов?
Когда лучше 410 вместо 301?
Источники
- HTTP 301 Moved Permanently — Wikipedia