# 301 і 302 редирект: різниця для SEO і що обрати

> 301 чи 302 редирект: як Google обробляє постійну й тимчасову переадресацію, коли використовувати 301, 302, 307 чи 308 і як знайти помилкові редиректи.

URL: https://seorecheck.com/ua/blog/301-vs-302-redirects-seo · Опубліковано: 2026-10-27 · [English](https://seorecheck.com/blog/301-vs-302-redirects-seo.md), [Español](https://seorecheck.com/es/blog/301-vs-302-redirects-seo.md)

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

Неправильний вибір редиректу ми бачимо серед технічних SEO-помилок дуже часто. Сайт від нього за ніч зазвичай не ламається. Натомість у видачі місяцями висить не той URL, і ніхто не може зрозуміти, чому нова сторінка так і не займає місце старої.

## Яка різниця між 301 і 302 редиректом?

Обидва коди переспрямовують відвідувачів і пошукових роботів з одного URL на інший, і в браузері виглядають однаково. Різниця в тому, що вони кажуть пошуковим системам про URL, який треба індексувати.

У [документації Google про редиректи](https://developers.google.com/search/docs/crawling-indexing/301-redirects) сказано, що постійний редирект система індексування використовує як сигнал, що канонічною має бути цільова сторінка. Тимчасовий редирект Googlebot теж виконує, але система індексування *не* вважає його сигналом, що канонічною має бути цільова сторінка.

Інакше кажучи:

- **301 Moved Permanently**: «Старого URL більше немає. Індексуйте новий».
- **302 Found**: «Поки що відправляйте людей туди, але старий URL залиште. Він повернеться».

У [довіднику Google щодо кодів стану HTTP](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) це сформульовано ще простіше: 301 є «сильним» сигналом, що обробляти треба цільову сторінку редиректу, а 302 «слабким».

## Як Google обробляє 301, 302, 307 і 308?

На практиці вам трапляться чотири коди редиректу, а також 303. Google поділяє їх на дві групи. Постійні (301, 308) є сильними сигналами канонічності, тимчасові (302, 303, 307) слабкими.

| Код стану | Значення | Як його трактує Google | Типове використання |
|---|---|---|---|
| 301 Moved Permanently | Постійний переїзд | Сильний сигнал: цільова сторінка стає канонічною | Зміна URL, HTTP→HTTPS, переїзд на новий домен, об'єднання сторінок |
| 308 Permanent Redirect | Постійний переїзд, метод запиту зберігається | Так само, як 301 | Постійні переїзди, де POST-запити мають залишатися POST |
| 302 Found | Тимчасовий переїзд | Слабкий сигнал: канонічною зазвичай лишається вихідна сторінка | Короткі акції, A/B-тести, тимчасові сторінки техробіт |
| 307 Temporary Redirect | Тимчасовий переїзд, метод запиту зберігається | Так само, як 302 | Тимчасові переїзди для форм і API |
| 303 See Other | Перехід до іншого ресурсу (як GET) | Так само, як 302 | Після надсилання форми (сторінка «Дякуємо») |

Google прямо пише, що [307 обробляється як 302, а 308 як 301](https://developers.google.com/search/docs/crawling-indexing/http-network-errors). Для SEO 301 і 308 взаємозамінні, так само як 302 і 307.

### Чим відрізняються 307 і 308 редиректи?

Різниця має значення лише для запитів, що не є GET, наприклад для надсилання форми методом POST. За [довідкою MDN щодо 308](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308), з кодом 308 метод запиту та його тіло не змінюються, а от старіші клієнти після 301 іноді помилково перетворюють переспрямований POST на GET. Звичайні сторінки люди й роботи завантажують методом GET, тож там ця проблема не виникає. Обирайте за тим, чи переїзд постійний, а не за номером коду.

## Чи шкодить 302 редирект SEO?

Якщо переїзд справді тимчасовий, 302 SEO не шкодить: саме для цього він і існує. Шкода з'являється, коли 302 ставлять на постійну зміну. Тоді Google не має сильного сигналу перейти на новий URL, тож стара адреса може залишатися в індексі, а нова насилу займатиме її місце.

Типові симптоми:

- У видачі через кілька тижнів після переїзду досі показується старий URL (або старий домен).
- У Search Console інструмент «Перевірка URL-адреси» показує старий URL як канонічну сторінку, вибрану Google.
- Новий URL позначається як дублікат або має статус «Сторінка з переспрямуванням» (Page with redirect), який ніяк не змінюється на очікуваний.
- У звітах трафік і посилання одного й того самого контенту розділені між двома адресами.

302 є слабким сигналом, а не інструкцією, тому Google усе одно може вибрати канонічною цільову сторінку, якщо на неї вказують інші сигнали: внутрішні посилання, [тег canonical](https://seorecheck.com/ua/blog/canonical-tag-guide) чи sitemap. Але так ви покладаєтеся на випадок. У [посібнику Google з канонікалізації](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) сказано, що сигнали можуть підсилювати один одного й працюють ефективніше разом. Надійний спосіб: постійний редирект, який узгоджується з canonical і sitemap.

## Коли використовувати 301 редирект?

Ставте 301 (або 308), якщо старий URL уже не повернеться. Google радить використовувати постійні редиректи, коли ви впевнені, що редирект не буде скасовано ([джерело](https://developers.google.com/search/docs/crawling-indexing/301-redirects)). Під це підпадає більшість редиректів, які взагалі колись знадобляться сайту бізнесу.

Типові випадки:

1. **Зміна URL сторінки**: наприклад, `/services/web-design-kyiv` стає `/web-design/kyiv`.
2. **Перехід з HTTP на HTTPS**, а також вибір між `www` і без `www`.
3. **Переїзд на новий домен і ребрендинг**: `oldbrand.com/*` → `newbrand.com/*`, сторінка на сторінку.
4. **Об'єднання контенту**: дві слабкі статті зливаються в один сильніший посібник.
5. **Остаточне видалення товару чи послуги**, якщо є близька заміна. Якщо релевантної сторінки немає, чесніше віддати 404 або 410, ніж переспрямовувати все на головну.
6. **Слеш у кінці URL і регістр**: `/Pricing` → `/pricing`.

Для переїзду сайту [посібник Google з переїзду](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) рекомендує серверні постійні редиректи, такі як 301 і 308. Там також сказано тримати їх якомога довше, зазвичай щонайменше 1 рік, щоб сигнали встигли перейти на нові URL.

## Коли використовувати 302 редирект?

Ставте 302 (або 307) лише тоді, коли плануєте повернути вихідний URL і хочете, щоб він тим часом залишався у видачі. Якщо ви не можете назвати дату чи подію, після якої редирект знімуть, найімовірніше, він не тимчасовий.

Коли тимчасовий редирект доречний:

- **Сезонна або коротка кампанія**: `/offers` веде на `/black-friday` два тижні, потім усе повертається.
- **Короткі технічні роботи**: сторінка товару недоступна кілька днів, і відвідувачів відправляють на тимчасову сторінку.
- **A/B-тести**, що відправляють частину трафіку на URL варіанта.
- **Редиректи залежно від входу чи сесії**, наприклад неавторизованих відвідувачів з `/account` переспрямовують на `/login`.
- **Пропозиції за пристроєм чи мовою**, коли основною версією лишається вихідний URL. Для багатомовних сайтів правильно налаштуйте [hreflang](https://seorecheck.com/ua/blog/hreflang-guide), а не покладайтеся лише на автоматичні редиректи.

Поширена пастка: багато плагінів CMS, панелей хостингу та фреймворків за замовчуванням створюють 302. Редирект, доданий «тимчасово» під час редизайну, часто живе роками. Якщо аудитуєте старий сайт, виходьте з того, що там є 302, які мали бути 301.

## Чи передає 301 редирект вагу посилань?

Google не публікує жодних відсотків, а старі твердження, що 301 «втрачає 15% PageRank», у документації Google не мають джерела. Задокументовано інше: постійний редирект є сильним сигналом, що канонічною має стати цільова сторінка. За [посібником з переїзду сайту](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), редиректи тримають щонайменше рік саме для того, щоб Google переніс сигнали ранжування на нові URL.

На практиці більші ризики пов'язані не з типом редиректу, а з таким:

- **Редирект на нерелевантну сторінку.** Якщо видалений товар переспрямувати на головну, Google не отримує рівноцінного контенту і може трактувати це як [soft 404](https://seorecheck.com/ua/blog/404-errors-seo-impact).
- **Надто раннє видалення редиректів.** Старі зворотні посилання й закладки починають вести на 404.
- **Внутрішні посилання, що досі ведуть на старі URL.** Кожен внутрішній клік і кожне сканування проходить зайвий крок. Оновлюйте посилання там, де вони стоять; як їх знайти, розповідаємо в [посібнику з внутрішньої перелінковки](https://seorecheck.com/ua/blog/internal-linking-seo-guide).

## Який спосіб редиректу обрати: серверний, meta refresh чи JavaScript?

Коли є можливість, використовуйте серверний HTTP-редирект. За словами Google, серверний редирект має найбільші шанси бути правильно інтерпретованим ([джерело](https://developers.google.com/search/docs/crawling-indexing/301-redirects)). Миттєвий meta refresh Google сприймає як постійний, відкладений як тимчасовий, а JavaScript-редиректи лишаються крайнім варіантом, бо залежать від того, чи вдасться рендеринг.

Приклади постійного редиректу на рівні сервера:

```apache
# Apache (.htaccess)
Redirect 301 /old-page /new-page
```

```nginx
# Nginx
location = /old-page {
    return 301 /new-page;
}
```

Якщо у вас є доступ лише до HTML, наступний найкращий варіант: миттєвий meta refresh (`<meta http-equiv="refresh" content="0; url=https://example.com/new-page">`).

## Скільки редиректів у ланцюжку забагато?

Кожен редирект має вести одразу на кінцевий URL. За [документацією щодо кодів стану](https://developers.google.com/search/docs/crawling-indexing/http-network-errors), роботи Google проходять до 10 кроків. Водночас посібник з переїзду сайту радить переспрямовувати одразу на кінцеву адресу й тримати ланцюжки в ідеалі не довшими за 3 кроки, і точно коротшими за 5, бо кожен крок затримує користувачів.

Ланцюжки зазвичай накопичуються з часом: `http://` → `https://` → `www` → новий slug → нова папка. Кожна міграція додає ще один крок. Виправляйте їх так: оновіть кожне старе правило, щоб воно вело прямо на актуальний URL, і пошукайте цикли (A → B → A), які ніколи не завершуються.

## Як перевірити, 301 чи 302 редирект на сторінці?

Будь-який URL можна перевірити за кілька секунд у командному рядку або краулером:

```bash
curl -sI https://example.com/old-page
# HTTP/2 301
# location: https://example.com/new-page
```

Додайте `-L`, щоб пройти весь ланцюжок і побачити кожен крок. Для всього сайту:

1. **Проскануйте сайт** інструментом для аудиту й відфільтруйте відповіді зі статусом 3xx. Експортуйте вихідний URL, код стану, цільовий URL і кількість кроків.
2. **Позначте кожен 302/307** і запитайте себе: його колись скасують? Якщо ні, змініть на 301.
3. **Позначте ланцюжки та цикли**, а також редиректи на сторінки з 404 чи noindex.
4. **Знайдіть внутрішні посилання на URL з редиректом** і замініть їх на кінцевий URL.
5. **Перевірте XML-sitemap**: у ньому мають бути лише кінцеві URL зі статусом 200.
6. **Переконайтеся в Search Console** через «Перевірку URL-адреси», що Google вибрав канонічним новий URL. Статус «Сторінка з переспрямуванням» пояснюємо в посібнику про [помилки Search Console](https://seorecheck.com/ua/blog/google-search-console-errors-explained).

Якщо не хочете сканувати сайт самостійно, [безкоштовний SEO-аудит від SEORecheck](https://seorecheck.com/ua/request) покаже знайдені на ваших сторінках редиректи з кодами стану, ланцюжками та внутрішніми посиланнями на URL з редиректом. Як це виглядає, можна подивитися у [прикладі звіту](https://seorecheck.com/ua/sample).

Правила редиректів часто ламаються під час редизайну, міграції CMS та оновлення плагінів, тож після кожного релізу перевіряйте редиректи в межах [регресійного SEO-тестування](https://seorecheck.com/ua/blog/seo-regression-testing-website-updates).

## Типові помилки з 301 і 302 редиректами (і як їх виправити)

| Помилка | Що відбувається | Як виправити |
|---|---|---|
| 302 на постійній зміні URL | Старий URL лишається в індексі, новий не займає його місце | Замінити на 301/308 |
| Усе переспрямовано на головну | Трактується як soft 404, релевантність втрачається | Вести на найближчу рівноцінну сторінку або віддавати 404/410 |
| Ланцюжки редиректів після кількох міграцій | Повільніше для користувачів, більше кроків сканування | Вести кожен старий URL одразу на кінцевий |
| Редиректи видалено через кілька місяців | Зворотні посилання й закладки ведуть на 404 | Тримати щонайменше рік, а краще безстроково |
| Тег canonical вказує на URL з редиректом | Суперечливі сигнали | Вказувати в canonical кінцевий URL |
| У sitemap є URL з редиректом | Марні сканування, слабші сигнали | Залишати лише кінцеві URL зі статусом 200 |
| Редирект лише на JavaScript | Google може його не побачити, якщо рендеринг не вдасться | Перенести редирект на сервер |

## Головне

- **301/308 = постійний**: сильний сигнал, що індексувати треба новий URL. **302/307 = тимчасовий**: Google зазвичай залишає старий URL.
- Для SEO 301 і 308 поводяться однаково, так само як 302 і 307. Коди, що зберігають метод запиту, важливі лише для запитів, які не є GET.
- Ставте 302, тільки якщо знаєте, коли повернеться вихідний URL.
- Віддавайте перевагу серверним редиректам, ведіть їх одразу на кінцевий URL і тримайте щонайменше рік.
- Редиректи, теги canonical, внутрішні посилання й sitemap мають вказувати на один і той самий кінцевий URL.
- Перевіряйте редиректи після кожної міграції чи редизайну. Хибні налаштування за замовчуванням і ланцюжки накопичуються непомітно.

---

## Хочете знати, що виправити на своєму сайті?

Отримайте безкоштовне превʼю SEO-аудиту: оцінку й реальні проблеми з доказами з ваших сторінок.

- [Отримати безкоштовне превʼю аудиту](https://seorecheck.com/ua/request)
- [Переглянути приклад звіту](https://seorecheck.com/ua/sample)