Змінили 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 редиректу в інкогніто збережуть дні на розгрібання закешованих помилок у живої аудиторії.