301 проти 302: постійні й тимчасові редиректи

2026-09-04 Оновлено: 2026-09-14

301 каже, що ресурс переїхав назавжди і нова URL-адреса має скрізь замінити стару; 302 каже, що переїзд тимчасовий, а справжньою й далі лишається початкова URL-адреса. Пошукові системи діють залежно від цієї різниці, тому неправильний код коштує вам позицій у рейтингу.

Що ці два коди повідомляють клієнту

Обидва коди відправляють клієнта на адресу в заголовку Location, і для відвідувача вони виглядають однаково. Різниця в тому, що робить із цією інформацією все решта. 301 запрошує клієнтів і краулерів оновити свої записи: замінити закладку, переписати посилання, індексувати ціль замість джерела. 302 просить їх і далі користуватися початковою URL-адресою й просто зробити цього разу гак. Браузери можуть закешувати 301 і взагалі перестати запитувати сервер; 302 за замовчуванням не кешується, якщо тільки відповідь не каже інше.

Коли який використовувати

Використовуйте 301 для зміни домену, переходу з HTTP на HTTPS, канонізації з non-www на www, постійної реструктуризації URL-адрес, об'єднаної чи перейменованої сторінки, чи знятої з продажу товарної сторінки, що вказує на найближчу заміну.
Використовуйте 302 для сторінки обслуговування, A/B-тесту, вибору географічної чи мовної посадкової сторінки, який ви можете змінити, короткочасної URL-адреси кампанії чи тимчасового призначення "поверніться пізніше".

Ніколи не використовуйте 301 для того, що ви плануєте скасувати. Оскільки клієнти його кешують, відвідувачі, що повертаються, можуть і далі потрапляти на тимчасове призначення ще довго після того, як ви видалите правило, і немає способу дістатися до їхніх кешів і виправити. Протилежна помилка: лишити 302 на постійному переїзді, і стара URL-адреса лишається в індексі, нова конкурує з нею, а сигнали лишаються розділеними.

Наслідки для SEO

Документація Google каже, що постійний редирект - це сигнал, що ціль редиректу слід трактувати як канонічну URL-адресу, тоді як тимчасовий редирект таким сигналом не є, тож початкова URL-адреса зберігає своє місце в індексі. На практиці:

301 консолідує вагу посилань на цілі й з часом замінює стару URL-адресу в індексі новою.
302 зазвичай лишає джерельну URL-адресу в індексі. Пошукові системи справді намагаються інтерпретувати намір, тож довготривалий 302 може врешті трактуватися як постійний, але покладатися на правильне вгадування не варто.
Ланцюжки редиректів розводняють користь і сповільнюють обхід. Спрямовуйте старі URL-адреси прямо на фінальне призначення.
Перенаправлення багатьох знятих із продажу сторінок на головну зазвичай трактують як м'який 404, а не як переїзд. Редиректьте на найближчий еквівалент, або повертайте 410, якщо еквівалента немає.
Що б ви не обрали, тримайте це узгодженим з вашими канонічними тегами й картою сайту. Суперечливі сигнали гірші за трохи неоптимальний, але послідовний вибір.

307 і 308: версії, що зберігають метод

Початкові визначення 301 і 302 були неоднозначними щодо HTTP-методу, і клієнти зійшлися на поведінці, яку стандарт тепер описує як історичну: коли клієнт іде за 301 чи 302 після POST, багато клієнтів змінюють метод на GET і відкидають тіло. Для сторінки це нешкідливо. Для ендпоінту форми чи API це руйнує запит і нічого не передає.

307 Temporary Redirect має те саме значення, що й 302, а 308 Permanent Redirect - те саме значення, що й 301, з однією вимогою, доданою до обох: метод і тіло мають бути збережені. Тож для URL-адрес, що приймають лише GET-запити, 301 і 302 цілком підходять, і саме цього очікує більшість інструментів. Для всього, що приймає POST, PUT, PATCH чи DELETE, використовуйте 308 для постійного переїзду і 307 для тимчасового. Якщо ви саме хочете, щоб за POST йшов GET на іншу URL-адресу, для цього існує 303 See Other.

Як перевірити, який код повертає URL-адреса

Прочитайте рядок статусу й ціль, не йдучи за редиректом:
```
curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location|cache-control)"
```
Рядок статусу показує 301, 302, 307 чи 308, а Location показує, куди він веде.
Пройдіть весь ланцюжок і порахуйте переходи, щоб побачити, чи не перетворився один редирект на три:
```
curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page
```
Перевірте з POST, якщо ендпоінт його приймає. Якщо запит дістається цілі як GET без тіла, перемкніть правило на 307 чи 308.
Змініть код там, де він генерується. Це може бути застосунок, конфігурація вебсервера, правило .htaccess чи CDN. Якщо редиректять обидва рівні, зовнішній перемагає, а внутрішнє правило невидиме.
Перевіряйте з холодним кешем. Браузер, що вже закешував 301, продовжує йому коритися, тож підтверджуйте через curl чи приватне вікно, перш ніж робити висновок, що зміна не застосувалася.
Після постійного переїзду лишайте редирект на місці. Видалення його пізніше залишить без нічого кожне посилання й закладку, що й досі вказують на стару URL-адресу.

Стеження за редиректом після налаштування

Редирект, що змінює код, починає зациклюватися чи втрачає TLS-сертифікат, лишає джерельну URL-адресу такою, що відповідає, тож ніщо не виглядає зламаним, поки не впаде трафік. Зовнішні перевірки, що фіксують точний код статусу й проходять ланцюжок, виявляють це вже наступного прогону, а перевірка з багатьох мереж відрізняє глобальну зміну правила від регіональної проблеми CDN. HostTracker моніторить сайти з 2004 року і виконує перевірки з понад 300 точок у 158 містах. Подивіться, що повертає URL-адреса просто зараз, за допомогою інструмента HTTP-перевірки, а повний посібник із родини перенаправлень 3xx охоплює коди по обидва боки від цих двох.