Як перевірити редиректи та ланцюги переадресацій

Редирект (переадресація) відправляє відвідувача чи робота з однієї адреси на іншу. Щоб правильно перевірити редиректи, потрібні три речі: код стану кожного кроку, кількість кроків у ланцюгу та кінцева адреса з її власним статусом. Нижче — три способи перевірити редиректи на сайті (онлайн, через curl і в браузері), чим відрізняються 301, 302, 307 і 308 та як виправити ланцюги й петлі в nginx, Apache і WordPress.

Як перевірити редиректи онлайн

Найшвидший спосіб — безкоштовний чекер редиректів. Він запитує URL, сам проходить за кожним заголовком Location (до 15 кроків) і показує весь шлях.

1. Вставте повну адресу разом зі схемою: http://example.com і https://example.com часто поводяться по-різному, тому перевірте обидві.
2. Прочитайте зведення: кількість редиректів, кінцевий статус, загальний час і те, чи закінчується ланцюг на тому самому чи іншому домені.
3. Пройдіть ланцюг крок за кроком. Для кожного кроку видно URL і код: 301 чи 308 позначено як постійний, 302 чи 307 — як тимчасовий.
4. Перегляньте рекомендації під ланцюгом. Інструмент позначає ланцюги, довші за один крок, тимчасові редиректи, які, можливо, мають бути 301, редиректи на інший домен, і підтверджує коректний редирект HTTP → HTTPS.

Два обмеження варто пам'ятати: чекер проходить лише серверні HTTP-редиректи (не meta refresh і не JavaScript, див. нижче), а сторінку запитує зі своїм user agent, тож редиректи, що залежать від країни, пристрою чи cookies відвідувача, для реальних користувачів можуть виглядати інакше.

Як перевірити 301 редирект через curl

У терміналі curl показує сирі заголовки відповіді без кешування браузера:

curl -sIL http://example.com/old-page \
  | grep -iE "^HTTP|^location"

-I запитує лише заголовки, -L іде за редиректами, а grep залишає тільки рядки статусів і цілі. Чистий результат виглядає так:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/
HTTP/2 200

Деякі сервери відповідають на запити HEAD не так, як на звичайні. Якщо результат виглядає дивно, повторіть зі справжнім GET-запитом: curl -sL -o /dev/null -D - URL.

Перевірка редиректів у Chrome DevTools

1. Відкрийте DevTools (F12) → Network.
2. Увімкніть Preserve log, інакше кроки редиректу зникнуть під час зміни сторінки, і Disable cache.
3. Завантажте стару URL-адресу. Кожен крок з'явиться окремим рядком зі своїм статусом; заголовок Location — у заголовках відповіді.

Браузери агресивно кешують відповіді 301. Якщо ви змінили редирект, а браузер досі йде за старим, перевірте в приватному вікні або через curl, перш ніж шукати проблему на сервері.

301, 302, 307 і 308: у чому різниця

Код 307 може з'явитися в DevTools і без участі вашого сервера: це внутрішній редирект браузера на HTTPS для сайтів зі списку HSTS. curl та онлайн-чекер натомість покажуть реальну відповідь сервера.

Ланцюги та петлі редиректів

Ланцюг — це кілька редиректів поспіль: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Кожен крок додає користувачу ще один запит-відповідь. Googlebot проходить до 10 переходів, але Google радить тримати ланцюги короткими, а кожен зайвий крок — ще одне місце, де щось може зламатися під час наступного переїзду. Прагніть одного редиректу з будь-якої старої адреси на кінцеву.

Петля — це ланцюг, що повертається на вже відвідану адресу, тож він ніколи не закінчується. Браузери показують ERR_TOO_MANY_REDIRECTS, а сторінку неможливо проіндексувати. У чекері петля виглядає як ланцюг, що впирається в ліміт 15 кроків з адресами, які повторюються. Типові причини: редирект на HTTPS на сервері плюс налаштування «Flexible SSL» у CDN або суперечливі правила для www у двох місцях (конфігурація сервера та CMS).

Як перевірити редиректи на всьому сайті

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

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

nginx

Об'єднайте схему й хост в один крок замість двох:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name example.com;
  location = /old-page/ {
    return 301 /new-page/;
  }
}

Додайте окремий блок listen 443 для www.example.com, який теж повертає 301 на https://example.com$request_uri. Після редагування виконайте nginx -t і перезавантажте конфігурацію.

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Redirect 301 /old-page/ https://example.com/new-page/

Генератор .htaccess складе ці правила без помилок.

WordPress

• Переконайтеся, що в Налаштування → Загальні в обох полях адреси вказано кінцеву URL (https і правильний варіант www); розбіжність із серверним правилом — класична причина петель.
• Для окремих сторінок використовуйте плагін редиректів (наприклад, Redirection) або менеджер редиректів вашого SEO-плагіна й не задавайте той самий редирект і в плагіні, і в конфігурації сервера.
• Після зміни постійних посилань перевірте кілька старих URL: частину старих slug WordPress вгадує сам, але не всі.

Хоч який у вас сервер, оновіть внутрішні посилання, теги canonical і карту сайту, щоб вони вели одразу на кінцеві URL, — тоді редиректи знадобляться лише для зовнішніх посилань і старих закладок.

Чому це важливо для просування посиланнями

Посилання ведуть на конкретну адресу. З постійним редиректом їхня вага все одно доходить до кінцевої сторінки, але краще просувати одразу кінцеву адресу. Якщо сторінка, яку просували, переїхала вже після запуску, налаштуйте 301 зі старої адреси — переробляти публікації не потрібно, див. «Чи можна видалити або змінити публікацію».