Автор: FreeWebTools Editorial Team Обновлено

🔀

Проверка редиректов: узнайте, куда ведёт любой URL или ссылка

Инструмент проверки редиректов проходит по URL переход за переходом и сообщает HTTP-статус каждого перехода, пока цепочка не закончится. Введите http://github.com — и он зафиксирует два перехода: на первом сервер отвечает 301 Moved Permanently и отправляет на https://github.com/, а там ответ уже 200 OK. Это один редирект, и это норма; каждый лишний редирект добавляет ещё один цикл «запрос — ответ». Этот инструмент следует редиректам 301, 302, 303, 307 и 308, а также HTML-тегам meta refresh, предупреждает о зацикливаниях и длинных цепочках и может отправить запрос от имени Googlebot или смартфона.

По одному URL в строке, не более 10. Каждый адрес проверяется отдельно, затем весь пакет можно выгрузить.

Встроить этот инструмент на ваш сайт

× px 

                        

                            
                        

                    

                

                
                
                

                    
💡 Совет по интеграции

                    
Скопируйте код для вставки и вставьте его в HTML вашего сайта. Адаптивная версия автоматически подстраивается под все размеры экрана.

                

            

        

    

    
    
    

        


    
    

        
        

        
        

        2 оценки
    

    
    
    

    
    
    
    
    
    

        
    

    
    
    ✓

        
        






    

    






        

    

    




    
    
    

        
Популярные

    

    
    
    

        
        
        
        
        
        
        

            
        

        
        
        

            Больше нет инструментов
        

    

    
    
    
        Все инструменты
        
            
        
    
    










        

        
Что означают коды 301, 302, 303, 307 и 308?

        
Все пять — это ответы 3xx, определённые в разделе 15.4 RFC 9110. Они различаются двумя вещами, которые важны для браузера: сохраняется ли метод запроса после редиректа и можно ли закешировать ответ и использовать его повторно. Столбец о поисковых системах показывает, как Google Поиск воспринимает этот сигнал.

        

            

                Сравнение кодов статуса HTTP-редиректов: обработка метода, кеширование и отношение поисковых систем.
                
                    

                        Код
                        Название
                        Метод после редиректа
                        Кешируется по умолчанию
                        Сигнал для поисковых систем
                        Когда использовать
                    

                
                
                                        

                        301
                        Moved Permanently
                        POST может быть заменён на GET
                        Да
                        Сильный сигнал канонизации; новый URL заменяет старый
                        Постоянный переезд, HTTP → HTTPS, без www → www
                    

                                        

                        302
                        Found (временный)
                        POST может быть заменён на GET
                        Нет, если заголовки не указывают иное
                        Старый URL обычно остаётся в индексе
                        A/B-тесты, страницы техработ, распределение по регионам
                    

                                        

                        303
                        See Other
                        Всегда меняется на GET
                        Нет
                        Считается временным
                        Post/Redirect/Get после отправки формы
                    

                                        

                        307
                        Temporary Redirect
                        Сохраняется вместе с телом
                        Нет
                        Считается временным
                        Временный перенос API и эндпоинтов форм, где нужно сохранить метод и тело
                    

                                        

                        308
                        Permanent Redirect
                        Сохраняется вместе с телом
                        Да
                        Тот же вес, что и у 301
                        Постоянный перенос с сохранением POST, PUT и DELETE
                    

                                    
            

        

        
Два кода часто принимают за редиректы, хотя они ими не являются: 304 Not Modified — это ответ при проверке актуальности кеша, без заголовка Location, а 300 Multiple Choices предлагает список вариантов вместо одной цели. Тег meta refresh — тоже не HTTP-редирект, но браузеры по нему переходят, поэтому инструмент показывает его отдельным переходом с пометкой meta refresh; смена location через JavaScript не отображается никогда, потому что ничего на странице не выполняется. Не отображается и «307 Internal Redirect», который Chrome показывает, когда HSTS переводит http:// на https://: браузер сам придумывает эту строку ещё до того, как запрос покинет компьютер, поэтому ни один сервер не может её отправить и проверка на стороне сервера её никогда не увидит.

    

    
        

        
Как проверить, работает ли редирект?

        
Вводите старый адрес, а не новый, и начинайте именно с того протокола, которым пользуются посетители: на большинстве серверов для http:// и https:// действуют отдельные правила. Рабочий редирект даёт на первом переходе ответ 3xx с заголовком Location, а на последнем — 200, причём путь и строка запроса остаются нетронутыми. Если последний переход отдаёт 404, 403 или 405, правило сработало, но ведёт в тупик, а если уже первый переход возвращает 200, редирект вообще не сработал.

        
    
            
  • Первый переход возвращает 301, 302, 307 или 308, а не 200.
    • 
            
  • Последний переход возвращает 200, а не 404, 403 или 500.
    • 
            
  • Конечный URL в точности совпадает с нужным адресом, включая путь, завершающий слеш и строку запроса, если вы её передавали.
    • 
            
  • В цепочке ровно один редирект: первый переход отвечает 3xx, второй — 200. Если редиректов больше, значит, правила наслаиваются друг на друга.
    • 
        

        
        
Чтобы увидеть все заголовки ответа на переходе — например, Location, Cache-Control и Strict-Transport-Security, — изучите этот URL в инструменте «Проверка HTTP-заголовков».

        
Переход, который вместо кода статуса обрывается ошибкой сертификата, останавливает и браузеры: проверьте сертификат этого хоста инструментом «Проверка SSL Сертификата».

    

    
        

        
Как исправить цепочку или зацикливание редиректов?

        
Зацикливание возникает, когда два правила противоречат друг другу: CDN принудительно переводит на https://example.com, а исходный сервер — на http://www.example.com, поэтому каждый переход отменяет предыдущий, и браузер сдаётся с ошибкой ERR_TOO_MANY_REDIRECTS. Этот инструмент останавливается после 10 переходов: если URL встречается повторно, он называет переход, который перенаправил обратно в цепочку, а если цепочка просто слишком длинная — последний URL, до которого удалось дойти. Чтобы всё исправить, выберите одну каноническую форму адреса (протокол, хост и завершающий слеш), применяйте её ровно на одном уровне, а остальные правила перепишите так, чтобы они вели прямо на конечный URL, а не друг на друга.

        
    
            
  1. Выберите одну каноническую форму: https, один хост, одно правило для завершающего слеша.
    2. 
            
  2. Применяйте её в одном месте — обычно в CDN или на веб-сервере, — но никогда в обоих сразу, да ещё и в приложении.
    3. 
            
  3. Сокращайте цепочки: измените первое правило так, чтобы оно вело на конечный URL, — тогда A поведёт прямо на C, а не по цепочке A → B → C.
    4. 
            
  4. Снова проверьте старый URL и убедитесь, что остался ровно один редирект, а цепочка заканчивается кодом 200.
    5. 
        

        
Исправляете проблему на Apache? Генератор .htaccess напишет правила 301 за вас, включая редиректы с http на https и для www, чтобы каждому старому URL хватало одного перехода.

    

    
        

        
Безопасно ли пользоваться проверкой редиректов?

        
Это безопаснее, чем переходить по ссылке самому. Проверка выполняется на нашем сервере, а не в вашем браузере: cookie из вашего браузера не отправляются, JavaScript не выполняется, а у обычной страницы читаются только первые 64 КБ — чтобы найти тег meta refresh. Вы видите хост назначения ещё до того, как решите туда заходить, — именно это и нужно, когда перед вами обёртка t.co, bit.ly или lnkd.in. Запросы к localhost, частным диапазонам вроде 192.168.0.0/16 и эндпоинтам метаданных облачных платформ отклоняются, редирект в эти диапазоны останавливается на том переходе, который пытается его выполнить, а любая проверка завершается после 10 переходов или через 20 секунд.

    

    





    
Сеть и диагностика

    

                
        
            

                📋
            

            

                
Проверка HTTP-заголовков

                
Анализируйте HTTP-заголовки ответа любого сайта. Проверьте заголовки безопасности, политики кеширования и получите оценку безопасности.

            

        
                
        
            

                📡
            

            

                
Проверка Статуса Сайта

                
Проверьте, работает ли сайт. Время отклика, HTTP-код, заголовки сервера. Массовая проверка.

            

        
                
        
            

                🔍
            

            

                
Проверка HTTP-заголовков

                
Проверьте заголовки HTTP и оценку безопасности любого сайта. Анализируйте HSTS, CSP и другие заголовки.

            

        
                
        
            

                🔒
            

            

                
Проверка SSL Сертификата

                
Проверьте данные SSL/TLS сертификата. Издатель, даты действия, оценка и статус безопасности.

            

        
            







    

    
        

        

            О проверке редиректов
        

        

                        
Этот инструмент показывает, что на самом деле происходит между URL, который вы вводите, и страницей, которая в итоге загружается. С нашего сервера он отправляет по одному GET-запросу на каждый переход, без cookie, записывает код статуса, заголовок Location и время каждого перехода и движется дальше, к следующему URL, пока не получит ответ, который не является редиректом, — или пока не наберётся 10 переходов. Это уже предельная глубина, до которой доходят поисковые роботы Google, и примерно половина лимита браузера — около 20 переходов, после которых браузер сдаётся с ошибкой ERR_TOO_MANY_REDIRECTS. Если переход отвечает кодом 200 и HTML-страницей, инструмент читает не более первых 64 КБ в поисках тега meta refresh, потому что такой редирект находится в самой странице, а не в заголовках. Ничего на странице не выполняется — именно поэтому JavaScript-редиректы инструменту недоступны: они возникают только после того, как браузер запустит скрипты страницы.

                        
Результат выводится намеренно буквально. Первый переход — это введённый вами URL, а каждая следующая строка — ровно тот URL, на который отправил предыдущий переход, со всеми деталями: сменой протокола, добавленным или убранным www, завершающим слешем и строкой запроса; переход, выполненный через meta refresh, так и помечается — с указанием задержки. Именно это делает инструмент полезным при переездах: правило, которое в конфигурации nginx выглядит правильным, часто ведёт себя иначе, когда в игру одновременно вступают HSTS, правило на edge-серверах CDN и канонический редирект на уровне приложения, и единственный честный способ увидеть результат — пройти по цепочке снаружи. Поскольку некоторые сайты направляют смартфоны, поисковых роботов и десктопные браузеры в разные места, запрос можно отправить от имени нашего собственного краулера, Chrome на Windows, Safari на iPhone, Googlebot (для смартфонов или для компьютеров) или Bingbot.

                        
Пакетный режим принимает до десяти URL за раз, проверяет их по очереди и выдаёт таблицу с числом редиректов, итоговым статусом, конечным адресом и общим временем — её можно экспортировать в CSV или вставить прямо в электронную таблицу или тикет. Кнопка проверки вариантов составляет для введённого адреса четыре комбинации — http и https, с www и без — и проверяет их за один раз: это самый быстрый способ убедиться, что все точки входа сходятся к одному каноническому URL. Типичные вопросы, на которые инструмент отвечает за секунды: ведёт ли старый URL товара на новый одним редиректом 301, пережило ли правило редиректа с HTTP на HTTPS последний деплой, сохраняет ли партнёрская ссылка строку запроса на всём пути и где именно в итоге оказывается сокращённая ссылка. Частные адреса, localhost и эндпоинты метаданных облачных платформ отклоняются, а каждая проверка прерывается через 20 секунд, поэтому прощупать внутреннюю сеть с помощью инструмента не получится.

                    

    

        
    
        

        

            Примеры использования
        

        

                        

                
                    
                
                Проверка переезда сайта: вставьте в пакетный режим десять старых URL с наибольшим трафиком и убедитесь, что каждый из них ведёт на свой новый адрес одним редиректом 301 — без 302 и без крюка через главную страницу.
            

                        

                
                    
                
                Аудит переезда с HTTP на HTTPS: http://github.com должен ответить 301 и привести на https://github.com/ одним редиректом. Три редиректа обычно означают, что свой редирект по очереди делают правило HSTS, правило для www и само приложение.
            

                        

                
                    
                
                Раскрытие сокращённой ссылки до клика: обёртки t.co, bit.ly и lnkd.in разворачиваются на стороне сервера, поэтому вы видите хост назначения, не загружая страницу и не запуская её скрипты в своём браузере.
            

                        

                
                    
                
                Отладка отслеживания рекламных кампаний: проверьте, сохраняются ли ?utm_source и ?gclid на каждом переходе, ведь редирект, который отбрасывает строку запроса, незаметно уничтожает атрибуцию этого клика.
            

                        

                
                    
                
                Разбор жалобы клиента на ERR_TOO_MANY_REDIRECTS: когда URL встречается повторно, проверка останавливается прямо на нём и называет переход, который перенаправил обратно в цепочку, — почти всегда причина в том, что CDN принудительно переводит на HTTPS, а исходный сервер — на HTTP; а если цепочка не повторяется, но и не заканчивается, проверка вместо этого останавливается на пределе в 10 переходов и называет последний URL, до которого дошла.
            

                    

    

        
    
            

    

        Как проверить, куда перенаправляет URL
    

    
    

                

            

                1
            

            

                
Вставьте URL или ссылку, которую хотите проверить, например http://github.com, или нажмите на один из примеров под полем ввода.

            

        

                

            

                2
            

            

                
При желании выберите, от чьего имени отправить запрос: наш краулер по умолчанию, Chrome, iPhone, Googlebot или Bingbot. Сайты, которые по-разному обращаются со смартфонами или ботами, покажут другую цепочку.

            

        

                

            

                3
            

            

                
Нажмите Enter или кнопку «Проверить редиректы». Каждый переход запрашивается с нашего сервера, а инструмент следует редиректам 301, 302, 303, 307 и 308 и тегам meta refresh — но не дальше 10 переходов.

            

        

                

            

                4
            

            

                
Изучите сводку: сколько найдено редиректов, итоговый HTTP-статус, общее время и конечный URL. Если URL зацикливается или проходит больше одного редиректа, появляется предупреждение.

            

        

                

            

                5
            

            

                
Пройдите по пронумерованной цепочке: для каждого перехода видны его URL, значок статуса — например, 301 Moved Permanently, — был ли это meta refresh и сколько времени занял этот переход.

            

        

                

            

                6
            

            

                
Если адресов несколько, переключитесь в пакетный режим (до 10 URL) или нажмите кнопку проверки вариантов — она разом отследит версии с http и https, с www и без него, — а затем выгрузите результаты в CSV.

            

        

            





        
    
        

        

            Советы профессионалов
        

        

            
    
                                
  • 
                    
                        
                    
                    Добивайтесь одного редиректа 301 прямо на конечный URL. Каждый лишний переход стоит полного цикла «запрос — ответ», переход с переключением на HTTPS добавляет TLS-рукопожатие, а переход на другой хост — ещё и DNS-запрос: в сумме на мобильном соединении это обычно 100–300 мс ещё до того, как что-либо отрисуется.
                
    • 
                                
  • 
                    
                        
                    
                    Используйте 308 вместо 301, если перенаправляемый запрос может оказаться POST-запросом. При 301 и 302 клиентам разрешено заменить метод на GET, а 307 и 308 обязывают сохранить и метод, и тело запроса.
                
    • 
                                
  • 
                    
                        
                    
                    Проверяйте не только версию с https://, но и версии с http:// и www — кнопка проверки вариантов охватывает все четыре сразу. Многие сайты корректно перенаправляют по HTTPS, а устаревшее правило для обычного HTTP при этом всё ещё ведёт на хост, который уже выведен из эксплуатации.
                
    • 
                                
  • 
                    
                        
                    
                    Смотрите на статус последнего перехода, а не только на количество редиректов. Цепочка, которая заканчивается кодом 404 или 405, сломана, даже если каждый редирект по пути был чистым 301.
                
    • 
                                
  • 
                    
                        
                    
                    После переезда прогоните самые популярные URL из Search Console через пакетный режим, скачайте CSV и через неделю сравните его с результатом по тому же списку, чтобы поймать правила, которые какой-нибудь деплой незаметно откатил.
                
    • 
                            

        

    

        
    
            

    

        Устранение неполадок
    

    
    

                

            

                

                    
                        
                    
                    Проблема:
                

                
При выборе Googlebot проверка возвращает 403.

            

            

                

                    
                        
                    
                    Решение:
                

                
Многие крупные сайты проверяют, действительно ли посетитель, выдающий себя за Googlebot, приходит из сети Google, и отказывают всем остальным, включая этот инструмент. Сравните с результатом для агента по умолчанию или Chrome; чтобы увидеть, что получил сам Google, воспользуйтесь инструментом «Проверка URL» в Search Console.

            

        

                

            

                

                    
                        
                    
                    Проблема:
                

                
Цепочка заканчивается кодом 403, 405 или 503, хотя в браузере страница открывается.

            

            

                

                    
                        
                    
                    Решение:
                

                
Скорее всего, сайт фильтрует клиентов: это может быть защита от ботов или проверка браузера на стороне CDN, которой нужны cookie и JavaScript, либо блокировка диапазонов IP-адресов серверов. Попробуйте агент Chrome или iPhone; если ответ не меняется, фильтр ориентируется на сеть или на поведение, и проверка с сервера его не обойдёт.

            

        

                

            

                

                    
                        
                    
                    Проблема:
                

                
Браузер показывает ERR_TOO_MANY_REDIRECTS, а инструмент — нормальную цепочку.

            

            

                

                    
                        
                    
                    Решение:
                

                
Скорее всего, зацикливание зависит от того, чего этот инструмент не отправляет: cookie, авторизованной сессии или записи HSTS, которую хранит ваш браузер. Удалите cookie сайта или откройте окно в режиме инкогнито, а затем сравните версии http:// и https:// с помощью кнопки проверки вариантов, чтобы найти правило, которое отправляет посетителей обратно.

            

        

                

            

                

                    
                        
                    
                    Проблема:
                

                
Вместо кода статуса переход завершается ошибкой SSL-сертификата.

            

            

                

                    
                        
                    
                    Решение:
                

                
Сертификат на этом хосте просрочен, самоподписан или выдан на другое имя, поэтому соединение отклоняется раньше, чем удаётся прочитать какой-либо редирект. Браузеры останавливаются на том же месте. Обновите или исправьте сертификат либо направьте предыдущий переход на хост с действительным сертификатом.

            

        

            



        
    
            

    

        Часто задаваемые вопросы
    

    
    

                

            
            

                
Она показывает, куда URL на самом деле отправляет посетителей и поисковые системы. Вы видите каждый переход между введённым адресом и страницей, которая в итоге отвечает, с кодом статуса и временем каждого из них. Так вы сразу получаете ответы на три вопроса: срабатывает ли редирект, ведёт ли он туда, куда нужно, и сколько переходов по пути тратится впустую. Кроме того, это безопасный способ узнать, куда ведёт сокращённая или партнёрская ссылка, прежде чем по ней переходить.

            

        

                

            
            

                
Код 301 сообщает, что перемещение постоянное: браузеры кешируют такой ответ, а Google переносит сигналы ранжирования старого URL на новый адрес и сохраняет старый лишь как альтернативное имя, поэтому тот обычно перестаёт появляться в результатах поиска, хотя всё ещё может всплыть, если по запросу видно, что пользователи доверяют именно ему. Код 302 сообщает, что перемещение временное, поэтому исходный URL, как правило, остаётся в индексе, а ответ не кешируется, если только заголовки этого не разрешают. Используйте 301 при переездах и переводе сайта на HTTPS, а 302 — только для A/B-тестов и страниц на время технических работ.

            

        

                

            
            

                
Цель — один редирект, два — терпимо, три и больше нужно сокращать. Браузеры прерывают загрузку примерно после 20 переходов, а поисковые роботы Google проходят не более 10 переходов по редиректам, после чего считают URL ошибочным. Каждый лишний переход стоит целого цикла «запрос — ответ», переход со сменой протокола добавляет TLS-рукопожатие, а переход на другой хост — ещё и DNS-запрос, поэтому цепочка из трёх редиректов на мобильном соединении может добавить несколько сотен миллисекунд до того, как придёт первый байт реального контента.

            

        

                

            
            

                
Введите свой домен и нажмите кнопку проверки вариантов. Она одним пакетом отследит http://, https://, http://www. и https://www. для одного и того же пути. При правильной настройке все четыре варианта приходят к одному конечному URL с кодом 200: у канонической версии редиректа нет, а у каждой из трёх остальных — ровно один 301 или 308. Два редиректа у версии http://www. обычно означают, что протокол и хост исправляются отдельными правилами, которые можно объединить в одно.

            

        

                

            
            

                
Да. Перед запуском проверки выберите User-Agent: Chrome на Windows, Safari на iPhone, Googlebot для смартфонов или для компьютеров либо Bingbot. Сайты, которые отправляют мобильных посетителей на поддомен m. или по-особому обращаются с поисковыми роботами, покажут для каждого варианта свою цепочку. Одна оговорка: многие крупные сайты проверяют, действительно ли посетитель, выдающий себя за Googlebot, приходит из сети Google, а если нет — отвечают 403, так что 403 с агентом Googlebot часто означает именно это. Чтобы точно увидеть, что получил Google, воспользуйтесь инструментом «Проверка URL» в Search Console.

            

        

                

            
            

                
Meta refresh — да. Если переход отвечает кодом 200 и HTML-страницей, инструмент читает её первые 64 КБ, находит тег meta refresh, в котором указан URL, и следует по нему как по очередному переходу — с пометкой meta refresh и задержкой в секундах. JavaScript-редиректы — нет: они происходят только после того, как браузер запустит скрипты страницы, а этот инструмент никогда ничего не выполняет. Если последний переход отдаёт 200, но браузер в итоге оказывается в другом месте, скорее всего, причина в скрипте; на вкладке Network в DevTools такой переход виден как навигация, запущенная скриптом.

            

        

                

            
            

                
Обычно причин четыре. Сайт есть в HSTS-кеше вашего браузера, поэтому тот заменяет http:// на https:// ещё до того, как запрос покинет компьютер. Сайт меняет ответ в зависимости от cookie, заголовка языка или страны, а наш сервер выглядит для него не так, как вы. Сайт отправляет смартфоны и компьютеры в разные места — это можно воспроизвести, сменив User-Agent. Или путь завершает JavaScript-редирект уже после загрузки страницы, а проверка на стороне сервера такого никогда не увидит.

            

        

                

            
            

                
Да. Переключитесь в пакетный режим и вставьте до десяти URL, по одному в строке. Каждый проверяется отдельно, а результаты попадают в одну таблицу с числом редиректов, итоговым статусом, конечным адресом и общим временем. Скачайте эту таблицу кнопкой «Скачать CSV» или скопируйте её как текст с разделителями-табуляциями: он вставляется в Sheets, Excel или тикет в Jira без всякого переформатирования. Кнопка проверки вариантов заполняет ту же таблицу четырьмя версиями одного адреса: http/https, с www и без.

            

        

                

            
            

                
Откройте DevTools клавишей F12, перейдите на вкладку Network, поставьте галочку Preserve log и загрузите URL. Каждый переход появится отдельной строкой со статусом 301 или 302; нажмите на неё и найдите заголовок Location в разделе Response Headers. Подвох в том, что DevTools показывает действия именно вашего браузера — вместе с вашими cookie, HSTS-кешем и расширениями, поэтому коллега на другом компьютере может увидеть другую цепочку.

            

        

                

            
            

                
Одиночный редирект 301 или 308 передаёт сигналы ранжирования и проблемой не является. А вот цепочки — являются, и по двум причинам: поисковые роботы Google проходят не более 10 переходов по редиректам и всё, что длиннее, отмечают как ошибку переадресации, а каждый переход задерживает первый байт, что напрямую сказывается на Core Web Vitals. Зацикливания ещё хуже: страница так и остаётся недоступной и полностью выпадает из индекса. Сокращайте цепочки так, чтобы первый URL вёл сразу на последний.

            

        

            





        
    
        





    
Источники и дополнительные материалы

    



    


    

    

                
            



    
    
    
    

    

    

    
            


    
    

    
    


        
        

            

                

                    
                        
                    
                

                

                    
FreeWebTools AI

                    

                

            

            

                
                
            

        


        
        

            
            

            
            

            
            
        


        
        

            

                
                
            

            

                Powered by free AI models · Full chat →