301 и 302: редиректы, SEO и ошибки, которые прилипают

Что на самом деле происходит при редиректе

Когда браузер запрашивает URL, а сервер отвечает статусом 3xx и заголовком Location, браузер молча делает второй запрос по новому адресу. Посетитель видит только конечную страницу; цена — один лишний round trip — и семантика определяются кодом статуса.

301 говорит, что ресурс переехал навсегда: клиентам следует идти на новый URL сейчас и запомнить, что старый в следующий раз можно пропустить. 302 говорит, что он временно в другом месте: идите туда сейчас, но в будущем снова спрашивайте исходный адрес. Всё, что важно в редиректах — SEO, кеширование, возможность отмены — следует из того, какое из этих двух обещаний вы дали.

Что делают с каждым поисковые системы

301 поисковые системы воспринимают как редакционный факт: накопленные сигналы старого URL — ссылки, история, ранжирование — переносятся на новый, и в течение следующих недель новый URL заменяет старый в выдаче. Именно поэтому миграции сайтов, переход на HTTPS и переименования slug'ов делаются через 301: репутация следует за контентом.

Со 302 поисковики поступают буквально: они оставляют старый URL в индексе, потому что вы сказали им, что контент вернётся. 302, оставленный на месте постоянного переезда, — одна из классических тихих SEO-ошибок: для посетителей всё работает, но новый URL не накапливает историю, а старый медленно устаревает. Если вы такой обнаружили, достаточно поменять его на 301 — перенос начнётся; поисковики корректно обрабатывают исправление.

Существует и зеркальная ошибка: 301 для чего-то действительно временного (страница кампании, A/B-тест) велит поисковикам деиндексировать исходную страницу — ровно то, чего вы не хотели.

То, что учат на горьком опыте: 301 прилипает

Браузерам разрешено кешировать 301 без срока годности — и некоторые именно так и делают. Увидев редирект впервые, браузер посетителя может запомнить его навсегда и больше никогда не спрашивать старый URL. Исправьте сервер завтра — этот посетитель всё равно попадёт не на ту страницу, потому что редирект теперь живёт в его браузере, вне вашей досягаемости. Кнопки очистки чужих браузеров не существует.

Два практических следствия. Первое: тестируйте переезд через 302 и повышайте его до 301, только когда уверены — обратимый код именно временный. Второе: ставьте на редиректы явный Cache-Control, потому что ограниченный срок жизни превращает «застрял навсегда» в «застрял максимум на день». Мы сами следуем этому правилу: наши канонические редиректы несут Cache-Control: public, max-age=86400, так что даже редирект, который мы позже изменим, исправится в течение дня у каждого посетителя и каждого кеша по пути.

Редирект с ограниченным, кешируемым сроком жизни

$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public

Цепочки редиректов: налог на каждый клик

Редиректы накапливаются. Правило http→https добавляет один переход, правило www — второй, переименованный slug — третий, и вот уже каждый посетитель платит три round trip до того, как начнёт передаваться контент, а поисковые системы теряют немного сигнала на каждом промежуточном шаге и совсем перестают следовать очень длинным цепочкам.

Решение — не избегать редиректов, а сделать так, чтобы каждый старый URL указывал прямо на конечную точку. Когда вы переименовываете страницу, на которую уже указывал редирект, обновите и СТАРОЕ правило — чтобы оба поколения URL вели на новый адрес за один переход. Периодический аудит — это одна команда на URL, и здоровая картина — один 301, за которым следует 200.

Пройдите всю цепочку и посчитайте переходы

# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page

# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'

# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200

Редиректы на CDN: где им жить и как их кешировать

Редирект, который отдаёт ваше приложение, работает, но стоит полного похода на origin ради одного неизменного заголовка. Перенос известных редиректов на edge — или кеширование на edge тех, что выдаёт приложение, — позволяет отвечать на них рядом с посетителем.

Здесь доступны обе половины. Правила доставки могут делать редирект прямо на edge (редирект на мобильную версию сайта — это одно поле в панели), а после недавнего улучшения edge также кеширует 301 и 302 от вашего origin с ограниченным сроком жизни, так что повторные обходы переехавшего URL вообще перестают доходить до вашего приложения. Практический совет: давайте редиректам явный Cache-Control, как любому другому ответу — короткий для 302, до суток для 301: достаточно долго, чтобы поглотить трафик, и достаточно коротко, чтобы пережить собственные ошибки.

Выбор за пять секунд

Переименовали страницу, переехали на другой домен, перешли на HTTPS, объединили дубликаты: 301 — и обновите старые цепочки, чтобы они указывали прямо на конечный URL. Страница кампании, обходной путь на время техработ, A/B-тест, гео-разделение, всё, что вы намерены отменить: 302. Ещё не уверены: сначала 302 — он обратимый — и повышайте до 301, когда переезд устоялся.

И мета-правило, которое покрывает остальное: редирект — это обещание о будущем URL. Выбирайте код, соответствующий обещанию, которое вы действительно можете сдержать.