Поменяли 301 редирект, а браузер упрямо шлет посетителей на старый URL? Знакомая боль каждого, кто настраивал переезд сайта или менял структуру ссылок.

Дело не в сервере и не в WordPress. Браузер намертво запоминает постоянный редирект и не спрашивает сервер повторно, так работает спецификация HTTP. Пока кеш не истечет или пользователь не очистит его вручную, старое правило продолжает действовать.

Ниже, четкая стратегия: как тестировать редиректы без последствий, почему 302 спасает нервы при отладке и что делать, если кеш уже застрял у живых посетителей.

💡 Быстрый обзор:

• Сначала всегда ставьте 302 (временный), тестируйте и только потом меняйте на 301 (постоянный)
• Очищайте кеш браузера при каждом изменении правил перенаправления
• Для Chrome: DevTools → Network → Disable cache, или вкладка Application → Clear site data
• Если 301 уже закеширован у пользователей, остается только ждать или менять URL назначения

Как браузер кеширует 301 редирект

Когда сервер отвечает статусом 301 Moved Permanently, браузер понимает буквально: «этот URL переехал навсегда». Он сохраняет пару «старый URL → новый URL» в собственном кеше редиректов, отдельно от кеша страниц и картинок.

В следующий раз, когда пользователь (или вы, разработчик) открывает тот же адрес, браузер вообще не отправляет запрос на сервер. Он сразу подставляет сохраненный URL назначения из кеша. Сервер не видит обращения, и вы не видите актуального поведения.

Спецификация HTTP не задает жесткого срока хранения такого кеша. На практике Chrome, Firefox и Safari держат 301 в кеше до явной очистки. Серверный заголовок Cache-Control браузер может проигнорировать именно для 301, потому что «навсегда» значит навсегда.

Это поведение, не баг, а фича. Оно экономит round-trip для честных постоянных переездов (например, смена домена). Но при разработке оно превращается в ловушку.

Почему это создает проблемы при настройке

Представьте сценарий. Вы настраиваете переезд старого URL /old-page на /new-page. Прописываете 301, проверяете в браузере, работает. Через час понимаете, что ошиблись: правильный URL, /new-page/v2.

Меняете правило на сервере, нажимаете «обновить» в браузере. И попадете на /new-page. Снова. Потому что браузер уже запомнил первую пару и не дает серверу шанса показать новое правило.

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

На тестовом сайте мы однажды потратили полчаса, перебирая правила .htaccess, пока не сообразили: браузер показывает кеш. Очистка кеша, и все сразу заработало как задумано.

Хуже ситуация с посетителями. Если вы активировали ошибочный 301 на боевом сайте, каждый, кто зашел в эти минуты, получил неверное правило в кеш своего браузера. Вы исправили ошибку на сервере через 10 минут, но их браузеры продолжат слать на старый URL, дни, недели, пока кеш не будет очищен.

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

Стратегия 302 → 301: тестируем без последствий

Правило, которое экономит часы отладки и страхует от ошибок на боевом сайте:

Всегда начинайте с 302 (временного) редиректа. Меняйте на 301 только после уверенности, что правило верное.

Браузер не кеширует 302 агрессивно, при каждом обращении он заново спрашивает сервер. Изменили правило на сервере, браузер сразу подхватит новое поведение. Никакой очистки кеша.

Алгоритм действий при любой смене URL:

• Пропишите 302-редирект в .htaccess, конфигурации Nginx или через плагин WordPress (например, Redirection).
• Откройте старый URL в режиме инкогнито или с включенной опцией «Disable cache» в DevTools.
• Убедитесь, что попали на правильную страницу назначения.
• Проверьте 2-3 дополнительных URL из той же группы.
• Только когда все протестировано, замените 302 на 301 в правилах.
• Финально проверьте в обычном режиме браузера.

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

Если вы работаете через плагин Redirection для WordPress, он по умолчанию создает 301. Переключите вручную на 302 в выпадающем списке при создании правила, и не забудьте вернуть на 301 после тестирования.

Как очистить кеш редиректов локально

Когда браузер уже запомнил неверный 301 и вы не видите актуального поведения, вот что помогает:

Chrome. Откройте DevTools (F12), перейдите на вкладку Network и поставьте галочку Disable cache. Или полный сброс: Application → Clear storage → Clear site data. Самый надежный способ для конкретного сайта, chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Для полной очистки: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (меню Develop включается в Settings → Advanced).

Режим инкогнито, быстрый способ проверить свежее поведение без очистки основного кеша. Браузер использует чистую сессию, где нет сохраненных редиректов.

Важный нюанс: закрытие браузера НЕ очищает кеш 301-редиректов. В отличие от сессионного хранилища, кеш редиректов переживает перезапуск браузера. Только явная очистка или инкогнито.

Что делать, если кеш застрял у пользователей

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

Проверьте, что можно сделать:

• Сменить URL назначения на новый. Если старый location вел на /page-v1, а нужно на /page-v2, просто замените адрес в том же правиле. Браузеры, у которых закеширован старый URL назначения, продолжат идти на него (проблема). Но новые посетители пойдут правильно. Это не решает проблему для тех, кто уже «заражен», но останавливает распространение.

• Использовать другой метод редиректа. Если 301 закеширован, браузер не спрашивает сервер, но серверная логика все еще работает для новых посетителей. Добавьте JavaScript-редирект на страницу назначения как дополнительный слой поверх HTTP-редиректа для тех, кто все-таки попадает на старую страницу.

• Честно признать: прямого лекарства нет. Вы не можете дотянуться до браузера пользователя. Если кеш уже загружен, единственный способ его сбросить, сам пользователь очистит кеш или пройдет по ссылке в инкогнито. К счастью, кеш редиректов живет не вечно: переустановка браузера, смена устройства, обновление ОС со временем обнуляют его.

По нашему опыту, критичным ошибочный 301 становится только в двух случаях: массовый переезд (сотни URL) с ошибкой в правилах или редирект главной страницы. В обоих случаях ущерб от закешированной ошибки перевешивает любую экономию времени на тестировании.

301, 302, 307, 308: что когда использовать

Чтобы не путаться, держите краткую таблицу кодов редиректа:

Для WordPress-сайта в подавляющем большинстве случаев достаточно знать разницу между 301 и 302. Коды 307 и 308, нишевые инструменты для случаев, когда критично сохранить HTTP-метод (например, форма должна остаться POST-запросом, а не превратиться в GET при редиректе).

Если коротко: 302, ваш рабочий инструмент при разработке. 301, финальный штамп «готово».

Еще одна ловушка: WordPress и плагины кеширования

На WordPress проблема 301-кеширования наслаивается на серверный и плагинный кеш. Типичная ситуация:

Вы правите редирект в плагине Redirection, нажимаете «обновить», не работает. Очищаете кеш браузера, все равно старая страница. Что происходит? Плагин кеширования (WP Rocket, LiteSpeed Cache, W3 Total Cache) отдал закешированную версию страницы, сервер даже не выполнил правило редиректа.

Порядок действий при отладке редиректов на WordPress:

• Сбросьте кеш плагина кеширования (каждый плагин, своя кнопка «Purge All Cache»).
• Отключите кеширование на время тестирования (в WP Rocket, режим Development Mode).
• Очистите кеш браузера (как описано выше).
• Только после этого проверяйте редирект.

На тестовом сайте мы держим плагин кеширования выключенным до полной готовности всех редиректов, и включаем только после финальной замены 302 на 301.

Короткое видео на английском наглядно показывает разницу между 301 и 302 на практике и объясняет, почему выбор кода редиректа влияет на SEO:

⁉️🤔 Частые вопросы

Почему браузер кеширует 301, а не спрашивает сервер при каждом обращении?

Спецификация HTTP определяет 301 как «ресурс переехал навсегда». Повторный запрос к серверу при каждом открытии URL противоречил бы смыслу «навсегда» и создавал бы лишнюю нагрузку. Кеширование редиректа экономит один HTTP-запрос для каждого посетителя. При масштабе в десятки тысяч визитов это ощутимо ускоряет навигацию. Браузер кеширует именно факт редиректа (пару «откуда → куда»), а не содержимое страницы. Это отдельный тип кеша, redirect cache. Chrome хранит его в профиле пользователя, Firefox, в файле places.sqlite вместе с историей навигации. Именно поэтому очистка кеша изображений и скриптов не всегда сбрасывает редиректы, нужна полная очистка или очистка данных сайта.

Можно ли на сервере запретить браузеру кешировать 301?

Формально, нет. Заголовок Cache-Control: no-store браузеры могут проигнорировать для постоянных редиректов. Спецификация не требует от браузера соблюдать Cache-Control для 301/308, постоянный редирект подразумевает, что правило не изменится. Отдельные версии Chrome и Firefox уважают Cache-Control для 301, но полагаться на это в продакшене нельзя, поведение не гарантировано и меняется между версиями. Единственный надежный способ «отменить» кеширование 301 браузером, изначально использовать 302 на время тестирования. Если 301 уже закеширован у пользователя, сервер бессилен.

Чем 302 отличается от 307 на практике?

Оба, временные редиректы, оба не кешируются браузером. Разница в обработке HTTP-метода. При 302 браузер может изменить POST-запрос на GET при переходе (исторически сложилось, и многие браузеры так делают). При 307 метод гарантированно сохраняется: POST остается POST, PUT остается PUT. Для WordPress и практически любого сайта разница несущественна, редиректы почти всегда касаются GET-запросов (открытие страницы). 307 нужен только если у вас формы, API или загрузка файлов идут через URL, который вы временно перенаправляете.

Как проверить, какой редирект закеширован у меня в браузере?

Откройте DevTools (F12) → вкладка Network, поставьте галочку «Disable cache» ОБЯЗАТЕЛЬНО (иначе браузер не сделает запрос к серверу и вы не увидите актуальный ответ). Затем откройте старый URL. В колонке Status увидите актуальный код ответа от сервера (301, 302 и т.д.) и заголовок Location с URL назначения. Без «Disable cache» DevTools покажет статус 200 или (disk cache), это браузер отдал кеш, сервер не опрашивался.

Нужно ли держать 301-редирект вечно?

Google рекомендует держать постоянные редиректы как минимум год после переезда. На практике, если старый URL больше не продвигается, не имеет внешних ссылок и не индексируется, редирект можно снять через 6-12 месяцев. Но если на старый URL вели ссылки другие сайты или он присутствует в индексе поисковиков, редирект стоит оставить навсегда. Удаление 301 с закешированным у пользователей правилом не решит проблему, их браузеры продолжат использовать закешированную пару, пока не очистят кеш.

Стоит ли бояться 301 редиректа?

Нет, если соблюдать правило «сначала 302». Постоянный редирект, надежный инструмент для переезда контента, смены домена и чистки дублей. Проблемы начинаются только когда 301 ставят без тестирования.

Запомните главное: 301, это обещание браузеру «я не передумаю». Не давайте это обещание, пока не уверены. Десять минут на проверку 302 редиректа в инкогнито сберегут дни на разгребание закешированных ошибок у живой аудитории.