Перевірка редиректів

Перевірити редирект онлайн: як читати результат

Вставте посилання, і інструмент пройде ним так само, як браузер: запитає адресу, прочитає заголовок Location, перейде далі й так до сторінки, яка відповість не редиректом. Враховуються серверні коди 301, 302, 303, 307 і 308, максимум 15 переходів. Угорі звіту чотири показники:

• Редиректів: скільки переходів до кінцевої сторінки. Норма — 0 або 1.
• Фінальний статус: код кінцевої адреси, потрібен 200. Якщо там 404, редирект веде в нікуди. Якщо 3xx при 15+ переходах, це петля.
• Загальний час усіх запитів. Кожен зайвий крок додає мережеву затримку, особливо на мобільному інтернеті.
• Той самий чи інший домен: допомагає помітити, що посилання веде на сторонній сайт.

Нижче йдуть рекомендації. Ланцюжок довший за два кроки позначається як задовгий, два кроки — як привід скоротити. Тимчасові коди 302, 303 і 307 інструмент радить замінити на 301, якщо перенесення постійне. Перехід з http на https позначається як правильно налаштований. Редиректи через <meta http-equiv="refresh"> і JavaScript тут не видно: це не HTTP-відповіді, і для пошуковика вони слабші за серверний 301.

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

Часто питання не в налаштуванні власного сайту, а в тому, куди відправить певне посилання. Короткі посилання (bit.ly, cutt.ly), посилання з розсилок і партнерські посилання проходять через один або кілька сервісів відстеження, перш ніж привести на сайт. Вставте таке посилання в перевірку, і ви побачите кінцеву адресу, не відкриваючи її у своєму браузері: запити надсилає наш сервер, а не ваш пристрій. Позначка «Інший домен» одразу показує, що посилання веде з вихідного сайту, а в кінцевому URL видно мітки UTM та ідентифікатори партнерки.

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

301, 302, 307, 308: який редирект ставити

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

Перевірка редиректу через curl

Для швидкої перевірки з консолі вистачить однієї команди. -I запитує лише заголовки, -L іде за редиректами:

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

Кожна пара «HTTP/… код» і «location» — один крок ланцюжка. Щоб перевірити редирект на основне дзеркало, проженіть усі чотири варіанти адреси. Правильно налаштований сайт приводить кожен на одну й ту саму адресу не більше ніж за один крок:

for u in http://example.com http://www.example.com https://example.com https://www.example.com; do
  echo "$u -> $(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$u")"
done

Мобільний редирект

Інструмент звертається до сайту з власним User-Agent, як десктопний клієнт. Якщо сайт перенаправляє телефони на m.example.com за User-Agent, перевірте це через curl із мобільним заголовком:

curl -sIL -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" https://example.com/catalog/

Мобільний редирект має вести на відповідну сторінку мобільної версії, а не на головну. Інакше користувач із пошуку втрачає сторінку, на яку натиснув.

Масова перевірка редиректів

Після переїзду зручно перевірити весь список старих адрес. Покладіть їх у urls.txt, по одній у рядку:

while read u; do
  curl -s -o /dev/null -L -w "$u\t%{http_code}\t%{num_redirects}\t%{url_effective}\n" "$u"
done < urls.txt

У результаті шукайте рядки, де код не 200, де більше одного редиректу і де кінцева адреса — головна замість потрібного розділу.

Типові помилки: ланцюжки, петлі, редирект із www

• Ланцюжок через два правила. http://www.example.com → https://www.example.com → https://example.com. Одне правило переводить на https, друге прибирає www, і вони спрацьовують по черзі. Рішення: одне правило одразу на кінцевий варіант (приклади нижче).
• Петля з Cloudflare. Режим SSL «Flexible» ходить на сервер по http, сервер відповідає редиректом на https, і так без кінця. Браузер показує ERR_TOO_MANY_REDIRECTS. Допомагає перемикання в режим «Full (strict)».
• Конфлікт WordPress і сервера. У «Налаштування → Загальне» вказано адресу з www, а nginx прибирає www, тож вони перекидають запит один одному. Адреса у WordPress і правило сервера мають збігатися.
• Слеш у кінці. /catalog → /catalog/ дає зайвий крок для кожного внутрішнього посилання без слеша. Виправляйте посилання в шаблонах, а не лише редирект.
• Усі видалені сторінки ведуть на головну. Google вважає такі редиректи soft 404, і вага не переноситься. Ведіть на найближчий за змістом розділ, а якщо його немає, віддавайте 404 або 410.

Як налаштувати редирект у nginx, Apache та WordPress

nginx: http і www одразу на https без www, за один крок:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate ...;
    return 301 https://example.com$request_uri;
}
# окрема сторінка:
location = /old-page/ { return 301 /new-page/; }

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/

Якщо сайт працює за проксі чи CDN, %{HTTPS} може завжди бути off. Тоді перевіряйте заголовок X-Forwarded-Proto, інакше отримаєте петлю. Готові правила під свій випадок можна зібрати в генераторі .htaccess.

WordPress: основний домен задається в «Налаштування → Загальне» (обидва поля адреси). Для окремих сторінок зручний плагін Redirection: він зберігає 301 у базі й веде журнал 404. Після будь-якої правки знову перевірте адресу тут і переконайтеся, що внутрішні посилання ведуть на кінцеві URL. Посилання, які досі проходять через редирект, знайде перевірка битих посилань. Теорію про ланцюжки й про те, чому під час переїзду втрачається трафік, викладено в статті як перевірити редиректи.