Редиректи 301 і 302: коли використовувати і як перевірити

Редирект 301 — постійний переїзд URL: передає PageRank і оновлює індекс Google. Редирект 302 — тимчасовий: пошуковик зберігає обидві сторінки. Неправильний вибір між ними коштує позицій і трафіку. Нижче — практичний гайд із кейсом, таблицями і чеклістом перевірки.

Що таке HTTP-редирект і як він працює

Коли браузер або пошуковий робот робить запит до URL, сервер відповідає HTTP-статус-кодом. Коди 3xx означають «ресурс перемістився» і вказують куди. Браузер автоматично переходить за новою адресою, а Googlebot записує інформацію в індекс.

Процес виглядає так:

1. Запит до https://example.com/old-page
2. Сервер повертає 301 Moved Permanently + заголовок Location: https://example.com/new-page
3. Браузер переходить на новий URL автоматично
4. Googlebot позначає старий URL як переміщений і передає сигнали ранжування

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

Різниця між 301 і 302: таблиця порівняння

На поверхні обидва редиректи роблять одне й те саме — переводять користувача на інший URL. Але з точки зору пошукових систем вони принципово різні.

Інші редиректи: 303, 307, 308

Більшість SEO-фахівців обмежуються 301 і 302, але HTTP-специфікація містить ще кілька кодів, які важливо розуміти:

Для SEO-задач 307 і 308 використовуються рідко. Код 303 актуальний у веб-розробці після відправки форм. У 90% SEO-кейсів вибір між 301 і 302 вирішує всі задачі.

Вплив редиректів на SEO

Редиректи впливають на три ключових SEO-параметри: crawl budget, передачу PageRank і швидкість завантаження.

Ланцюжки редиректів — головна проблема

Ланцюжок — це коли URL A → URL B → URL C. Googlebot витрачає більше ресурсів на кожен додатковий крок. З нашої практики аудиту: сайти з ланцюжками з 4–5 редиректів часто мають неповну індексацію — бот просто не доходить до фінального URL за відведений crawl budget.

Вплив на PageRank і link juice

Google офіційно підтверджує, що 301 передає PageRank. До 2016 року в SEO-середовищі вважалося, що кожен редирект «з'їдає» до 15% ваги посилань. John Mueller спростував цей міф — але тільки для поодинокого прямого 301. Ланцюжок із 3 редиректів все одно призводить до помітних втрат.

Crawl budget і швидкість сканування

Для невеликих сайтів до 1000 сторінок crawl budget не є критичним. Але для інтернет-магазинів з десятками тисяч URL кожен зайвий редирект — це менше сторінок, просканованих Googlebot за добу. Якщо у вас 5000 товарів і 1500 з них мають ланцюжки — частина каталогу може тижнями не оновлюватися в індексі.

Разом з редиректами важливо правильно налаштувати канонічні теги — вони допомагають уникнути дублювання без фізичного переспрямування.

Коли використовувати 301

301 — це ваш основний інструмент у 90% ситуацій з переміщенням контенту. Ось конкретні кейси:

• Переїзд з HTTP на HTTPS — найпоширеніший кейс. Усі HTTP-запити мають йти на HTTPS через 301.
• Зміна структури URL — ви змінили /catalog/product-name-12345 на /product-name/. Старий URL отримує 301 на новий.
• Видалення дублів — є дві версії сайту: www. і без. Одна має редиректити на іншу через 301.
• Видалення сторінок з контентом — якщо стара сторінка більше не існує, але є схожий контент на іншій — 301 на найрелевантнішу.
• Міграція домену — переїзд з old-domain.com на new-domain.com. Обов'язково 301 на рівні сервера для всіх URL.
• Видалення слешу в кінці URL — /page/ → /page (або навпаки) через 301, щоб уникнути дублювання.

Коли використовувати 302

302 — це інструмент для ситуацій, коли стара сторінка точно повернеться. Використовувати його небагато, але правильно:

• A/B тестування — ви тестуєте нову версію сторінки. Трафік тимчасово йде на варіант B через 302, щоб Google не замінив версію A в індексі.
• Тимчасові акції — головна сторінка акції (/sale/) тимчасово веде на сторінку конкретної знижки. Після акції /sale/ повернеться.
• Георедиректи — деякі реалізації геоперенаправлення використовують 302, щоб Google зберігав оригінальний URL у глобальному індексі.
• Технічні роботи — сайт на технічному обслуговуванні, користувачів тимчасово перенаправляють на сторінку-заглушку через 302.

З нашої практики: найчастіша помилка — розробники ставлять 302 за замовчуванням, бо «не хочуть нічого ламати». Через рік сайт переповнений тимчасовими редиректами на постійно переміщені URL. Результат — Google індексує застарілі адреси, нові не отримують належного PageRank.

Як налаштувати редиректи

Apache (.htaccess)

# Один редирект 301
Redirect 301 /old-page https://example.com/new-page

# Всі сторінки HTTP -> HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# www -> без www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Nginx

# HTTP -> HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# Один URL
location = /old-page {
    return 301 https://example.com/new-page;
}

WordPress

Для масових редиректів в WordPress використовуйте плагін Redirection (понад 2 млн активних установок). Він зберігає всі правила в базі даних і має вбудований моніторинг 404-помилок. Для поодиноких редиректів можна редагувати .htaccess напряму.

OpenCart

В OpenCart редиректи налаштовуються через адмін-панель: System → SEO URL. Для нестандартних випадків — редагування .htaccess в корені сайту. Зверніть увагу: OpenCart за замовчуванням генерує 301 при зміні SEO-URL у картці товару — перевіряйте, щоб старий URL не залишився активним.

Як перевірити редиректи

Перевірка редиректів — обов'язковий крок після будь-яких змін структури URL або міграції. Ось інструментарій від простого до детального:

1. Curl (командний рядок)

# Перевірка з відстеженням ланцюжка
curl -I -L https://example.com/old-page

# Що шукати у відповіді:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-page
# HTTP/2 200  ← фінальна відповідь

Ключ -I виводить лише заголовки, -L відстежує всі переходи. Якщо в виводі три рядки з HTTP-статусами — у вас ланцюжок з двох редиректів.

2. Screaming Frog SEO Spider

1. Запустіть сканування вашого домену
2. Перейдіть у Response Codes → Redirection (3xx)
3. Для аналізу ланцюжків: Bulk Export → Redirect Chains
4. Відфільтруйте колонку Redirect Hops — усі значення >1 потребують виправлення

3. Ahrefs Site Audit

1. Запустіть новий аудит або оновіть наявний
2. Перейдіть у Issues → All Issues
3. Відфільтруйте за типами: Redirect loop, Too many redirects, Redirect chain too long
4. У розділі Links → Redirects перегляньте всі redirect targets

4. Онлайн-тестери

• httpstatus.io — показує повний ланцюжок редиректів з часом відповіді на кожному кроці
• redirect-checker.org — простий інтерфейс, підходить для перевірки окремих URL
• Google Search Console → URL Inspection — показує, який URL Google бачить як канонічний після всіх редиректів

Кейс: ланцюжок із 3 редиректів і втрата 40% трафіку

Один з наших клієнтів — інтернет-магазин будівельних матеріалів — звернувся з проблемою: органічний трафік впав на 38% за 2 місяці після переїзду на нову CMS. Жодних санкцій, жодних змін у контенті. Причина виявилася в редиректах.

Ситуація до аудиту:

• Старий сайт на HTTP → 301 на HTTPS (старий домен)
• Старий домен HTTPS → 302 на новий домен (розробник поставив «тимчасово» під час тестування)
• Новий домен / → 301 на /ua/ (мовна версія)

Разом: 3 переходи для кожного URL. Googlebot сканував лише частину каталогу. 302 посередині означав, що PageRank з 4000+ вхідних посилань не передавався новому домену.

Що зробили:

1. Замінили ланцюжок одним прямим 301 з http://old-domain.com/* на https://new-domain.com/ua/*
2. Перевірили через Screaming Frog — нуль ланцюжків
3. Запросили повторне сканування ключових сторінок через Google Search Console

Результат: через 6 тижнів трафік повернувся до 94% від початкового рівня. Залишок 6% — природні коливання після зміни домену, які нівелювалися за наступні 3 місяці.

На практиці

Онлайн-школа програмування з Харкова звернулась після редизайну платформи: розробники змінили структуру URL для всіх 800 сторінок курсів, але не прибрали проміжні ланки після завершення міграції. Кожна сторінка мала ланцюжок із 4–6 кроків — наприклад /courses/python-v1 → /courses/python-v2 → /courses/python-v3 → /learn/python.

Google Search Console зафіксував обвал: за 3 тижні позиції за 60 ключовими запитами впали на 12–20 місць, органічний трафік скоротився на 41%. Ситуацію помітили лише коли кількість заявок на курси суттєво знизилась.

Аудит провели через Screaming Frog у режимі Bulk Export → Redirect Chains: інструмент виявив 800 ланцюжків із середньою довжиною 4,7 кроки. Ahrefs Site Audit підтвердив розмивання link juice — ефективна передача PageRank через такі ланцюжки становила не більше 60% від початкової ваги посилань.

Усі ланцюжки схлопнули до одного прямого 301 через правила Nginx, після чого пріоритетні сторінки відправили на переобхід через Google Search Console. Трафік відновився за 5 тижнів, позиції за 54 із 60 запитів повернулися в початковий діапазон.

Ланцюжки з 4+ кроків на сторінках курсів — це не просто втрата PageRank. На таких сайтах Googlebot часто взагалі не доходив до фінального URL у межах виділеного crawl budget: ми бачили сторінки зі статусом «Discovered — currently not indexed» через три тижні після деплою. Схлопувати ланцюжки треба до деплою, а не після скарг на трафік.

Часті запитання

Чи передає редирект 301 увесь PageRank?

Google офіційно підтвердив, що 301 передає більшість PageRank. Раніше вважалося, що втрачається до 15%, але з 2016 року John Mueller заявив, що втрати мінімальні. На практиці після правильного налаштування 301 позиції відновлюються протягом 2–8 тижнів.

Що трапиться, якщо залишити редирект 302 замість 301?

Google може зберігати обидві версії URL в індексі й не передавати PageRank повністю на новий URL. Якщо стара сторінка назавжди недоступна, а стоїть 302 — пошуковик чекає повернення старого URL і не оновлює індекс. Це прямо шкодить ранжуванню нової сторінки.

Скільки редиректів у ланцюжку є критичним для SEO?

Ланцюжок із 3 і більше редиректів суттєво уповільнює обхід і може призвести до того, що Googlebot взагалі не дійде до фінального URL. Оптимально — один прямий редирект з A на B. Максимально допустимо — два (A → B → C), але лише як тимчасовий стан під час міграції.

Як перевірити редирект без спеціальних інструментів?

Через командний рядок: curl -I -L https://example.com/old-page. Ключ -I показує заголовки, -L іде за ланцюжком редиректів. У відповіді шукайте рядки HTTP/1.1 301 або HTTP/2 302 і Location: — це покаже куди веде редирект і чи немає зайвих переходів.