HTTP-код, который постоянно перенаправляет запрос и требует сохранить его метод и тело запроса на новом URL. Это руководство фокусируется на решении, проверках и ограничениях, которые важны на реальном ревью.
Что контролирует редирект 308
HTTP 308 — постоянный редирект, определённый для случаев, когда важен метод запроса. Ответ даёт новый адрес и велит клиенту, который следует стандарту, повторить запрос там, не меняя метод и тело. Поэтому он полезен для постоянного переезда эндпоинта API или обработчика формы, где должна сохраниться семантика POST, PUT, PATCH или DELETE. Он не переписывает данные приложения, не проверяет целевой адрес и не исправляет плохо спроектированный маршрут. Для обычных страниц-документов, которые открываются через GET, 301 обычно понятнее в эксплуатации: сохранение метода не даёт читателю ничего полезного.
Выбирайте статус по намерению изменения
Сначала решите, постоянен ли переезд, и только потом выбирайте номер. 308 означает, что старый адрес заменён, а 307 — временный переезд с сохранением метода. 301 тоже выражает постоянный переезд, но исторически клиенты могут превратить не-GET запрос в GET. Поисковые системы описывают постоянные редиректы как сигналы консолидации, но код статуса не гарантирует, когда изменятся сканирование или выбор канонического URL. Держите старый URL в инвентаризации миграции, пока не проверены его цель, внутренние ссылки, политика канонизации и ответ при сканировании.
Внедрите и проверьте постоянный переезд
Начните с небольшой карты URL: старый эндпоинт, целевой финальный эндпоинт, причина и владелец. Настройте один прямой 308 с каждого выведенного из работы маршрута, чувствительного к методу, на соответствующую замену; не отправляйте несвязанные запросы на главную. Проверьте реальный запрос с его методом в непродуктовом окружении, затем проверьте статус и Location, не переходя по нему автоматически. Повторите с включённым следованием редиректам и убедитесь, что финальный обработчик получает ожидаемый метод. Наконец, просканируйте список старых URL, обновите внутренние ссылки на финальный URL и отслеживайте серверные данные и данные Search Console отдельно.
- Определите набор URL или страниц и ожидаемое поведение.
- Проверьте репрезентативную выборку и сохраните сырой ответ или данные после рендеринга.
- Исправляйте одну управляемую причину за раз, затем перепроверьте ту же область.
- Фиксируйте пробелы, исключения и последующие проверки, а не записывайте отсутствие данных как пройденную проверку.
Типичные сбои и проверки при ревью
Частая ошибка — считать 308 улучшением для SEO. Это решение о транспорте, а не тактика ранжирования. Другая ошибка — тестировать только переход в браузере: он проверяет GET, а не путь POST или PUT, ради которого выбирали 308. Цепочки и петли редиректов, отсутствующий заголовок Location, цель, которая отдаёт ошибку, или закэшированный старый ответ требуют отдельного разбора. В миграциях я сопоставляю каждый выводимый URL с одним релевантным финальным адресом, затем сканирую карту, чтобы убрать цепочки и петли, и только после этого считаю работу законченной. Записывайте, что проверено и что было недоступно: один успешный запрос не покрывает весь набор маршрутов.
Кэширование заслуживает отдельной проверки. Постоянный ответ может остаться в кэше браузера или промежуточных узлов после отката конфигурации, поэтому проверяйте с чистого клиента и фиксируйте директивы кэширования ответа, когда они важны. Не варьируйте редирект только по user-agent, чтобы угодить старым клиентам: маршрут станет трудно воспроизвести, а данные по краулерам — противоречивыми. Если совместимость требует запасного варианта, задокументируйте, каким клиентам он нужен, и сохраняйте одну и ту же политику финального URL для всех обычных запрашивающих.