Проверка редиректов
Генерируйте curl-команды для проверки цепочек редиректов. Анализируйте 301, 302, 307 и другие HTTP-статусы прямо в терминале.
Введите полный адрес: https://example.com/old-page
Curl-команда для проверки
Скопируйте и запустите в терминале$ curl -sIL "https://example.com" 2>&1 | grep -E "^HTTP|^location"
HTTP-статусы редиректов (3xx)
301
Moved Permanently
Постоянный редирект. Браузер кэширует. Для SEO: лучший выбор при переносе страницы.
Используй для: переноса старой страницы на новый URL навсегда
302
Found
Временный редирект. Браузер не кэширует. Для SEO: риск потерять ранк.
Используй для: тестирования или временных переадресаций
303
See Other
Говорит клиенту: смотри на другой ресурс. Всегда GET, даже если был POST.
Используй для: ответа на POST-форму (redirect after post)
307
Temporary Redirect
Временный редирект, но метод HTTP сохраняется (POST остаётся POST).
Используй для: временных редиректов с сохранением метода
308
Permanent Redirect
Постоянный редирект с сохранением метода (POST остаётся POST).
Используй для: постоянного редиректа API-эндпоинтов
Типичные редирект-цепи (примеры)
✓ Хорошо
Прямой редирект (лучший случай)
http://example.com/old
301 →
https://example.com/new
Один редирект = быстро загружается, SEO понимает сразу
⚠ Опасно
Цепь из 2+ редиректов
old.com
301 →
old2.com
301 →
old3.com
301 →
new.com
Медленнее, робот может не пройти всю цепь, может отбросить ранк
✗ Критично
Редирект-петля (бесконечный цикл)
page.com/a
301 →
page.com/b
301 →
page.com/a
Браузер обрывает после ~5 редиректов. Исправлять срочно!
⚠ Проблема
Смешивание HTTP и HTTPS
http://example.com
301 →
https://example.com
301 →
https://www.example.com
Нужно настроить сервер так, чтобы HTTPS был сразу
Частые ошибки при редиректах
Слишком длинная цепь (более 3 редиректов)
Поисковые роботы могут не пройти всю цепь и потеряют линк-джус (передачу авторитета). Браузер обрывает попытки после 5-8 редиректов.
Исправление: настроить прямой редирект на финальный URL в конфиге сервера
Петля редиректов
URL A → B → A → ... Браузер обрывает цепь, пользователь видит ошибку «Слишком много редиректов».
Исправление: проверить в конфиге, что A редиректит на B, а B не редиректит обратно на A
Использование 302 вместо 301 при переносе страницы
302 — временный редирект. Поисковик может не переиндексировать страницу, оставить её в индексе под старым URL.
Исправление: использовать 301 для постоянного переноса
Мета-редирект в HTML (<meta refresh>)
Мета-редирект работает в браузере, но curl и боты его не видят. Это не замена HTTP-редиректу!
Исправление: всегда использовать HTTP-редирект (301/302) в конфиге сервера
Потеря параметров URL при редиректе
URL /page?id=123 редиректит на /new-page без параметров. Теряются данные, может сломаться аналитика.
Исправление: настроить сервер на сохранение query-string (обычно работает по умолчанию)
Редирект с HTTP на HTTPS
Правильный редирект: http://example.com → https://example.com. Современный стандарт, не вредит SEO.
Это нормально, конфигурируется на уровне сервера
Как вручную проверить редирект в терминале
1
Скопируй команду выше
Нажми кнопку копирования рядом с curl-командой
2
Открой терминал
Ctrl+Alt+T (Linux), Cmd+Space → Terminal (Mac), или PowerShell (Windows)
3
Вставь команду и нажми Enter
Увидишь все заголовки (HTTP/1.1 и Location) цепи редиректов
4
Прочитай результат
HTTP/1.1 301 → Location: ... (новый URL) → HTTP/1.1 200 (финал)
Пример результата:
HTTP/1.1 301 Moved Permanently Location: https://example.com/new HTTP/1.1 200 OK
Что означает: старый URL (301) редиректит на новый, новый открывается успешно (200 OK). Цепь здоровая!
Всё в браузере
Данные не загружаются
Бесплатно