7 мин чтенияТуториалы

Как перенаправить URL: шесть способов, и когда какой из них уместен

Редирект - это HTTP-ответ, поэтому настоящий вопрос в том, какой слой отвечает на запрос. Регистратор, сервер, CMS, платформа, клиентская сторона или управляемая короткая ссылка.

Marius Voß
DevRel · edge infra
Перенаправление URL, показанное как запрос, приходящий на один из шести слоев, каждый из которых возвращает 301 с заголовком Location

Редирект - это HTTP-ответ: статус 301 или 302 с заголовком Location, сообщающим браузеру, куда идти вместо этого. Это все, что происходит на проводе, а значит вопрос на самом деле не в том, как перенаправить URL, а в том, какой слой перед вашим сайтом должен на него отвечать.

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

Где на самом деле живет редирект

Начните с мифа, потому что он съедает больше рабочих дней, чем любой другой: DNS не может перенаправить URL. DNS-запись сопоставляет имя хоста с адресом. Она никогда не видит путь, никогда не видит строку запроса и не имеет механизма, чтобы сказать "иди куда-то еще вместо этого". Запись A или CNAME указывает; она не пересылает.

Поэтому, когда ваш регистратор предлагает "URL forwarding", на самом деле он указывает имя хоста на свой небольшой веб-сервер, который и возвращает HTTP-редирект от вашего имени. Это полезно и вполне законно, но работу выполняет веб-сервер, а не DNS. Как только вы это увидите, шесть методов ниже перестанут выглядеть как альтернативы и превратятся в один вопрос: какая машина на пути запроса должна отвечать?

Запрос, резолвящийся через DNS на сервер, с редиректом, выданным как HTTP-ответ 301, и DNS, отмеченным как неспособный перенаправлять

Шесть мест, куда можно поместить редирект

Каждый из них заканчивается одним и тем же ответом на проводе. Отличаются стоимость настройки, кто ее контролирует и что происходит со всем, что идет после доменного имени.

переадресация домена у регистратора

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

Загвоздка в том, что это делает с остальной частью URL: большинство переадресаций у регистраторов сплющивают каждый запрос в единственное настроенное назначение, поэтому глубокая ссылка приходит на главную страницу. Некоторые предлагают режим с сохранением пути; проверьте это, прежде чем полагаться на него.

правило в вашем веб-сервере

Если вы используете nginx или Apache, редирект принадлежит именно сюда, потому что вы получаете точный контроль над сопоставлением и сохранением. Документация Apache по переопределению URL с помощью правил rewrite описывает паттерны, а справочник модуля rewrite nginx описывает return 301 и rewrite ... permanent - это быстрый путь для простого перемещения.

Серверные правила - правильный инструмент для канонического хоста и принудительного HTTPS, переписывания путей после реструктуризации и всего условного. Это же и то место, где правила редиректов незаметно накапливаются годами, поэтому относитесь к файлу как к тому, что нужно подрезать, а не только пополнять.

правило на хостинговой платформе

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

плагин или настройка в вашей CMS

У каждой серьезной CMS есть менеджер редиректов, и для контент-команды это правильный ответ: без деплоя, без доступа к серверу, с журналом аудита, и решение о сопоставлении принимает человек, понимающий контент. Компромисс в том, что запрос должен добраться до приложения, прежде чем будет выдан редирект, поэтому это медленнее, чем слои выше, и перестает работать, если приложение недоступно.

meta refresh или JavaScript на странице

Последнее средство на случай, если вы не можете тронуть ничего на стороне сервера. Страница загружается, а затем отправляет посетителя дальше с помощью тега <meta http-equiv="refresh"> или скрипта. Это работает, но стоит полной загрузки страницы, зависит от того, выполнит ли ее клиент, и поисковики считают это более слабым сигналом, чем ответ сервера. Используйте это, когда альтернатива - вообще ничего.

управляемая короткая ссылка

Когда перенаправляемая вещь - это ссылка, которую вы опубликовали, а не страница, которой вы владеете, редирект принадлежит менеджеру ссылок. Назначение - это сохраненное значение, которое можно менять, не трогая DNS, серверы или пайплайн деплоя, каждый переход логируется, а ссылка продолжает работать после того, как ее напечатали или ею поделились. Именно в этом вся механика того, что такое сокращатель URL, и именно поэтому напечатанная кампанийная ссылка никогда не должна указывать прямо на лендинг.

Выбор за тридцать секунд

Большая часть решения сводится к двум колонкам: у кого есть доступ и что должно выжить.

МетодКто отдает ответПуть и запрос сохраняютсяЛучше всего для
Переадресация у регистратораСервер регистратораЧасто нет, проверьте сначалаПередача всего домена
Правило веб-сервераВаш originДа, если написано соответствующим образомКанонический хост, реструктуризация
Правило платформыХостинг перед originДаМассовые редиректы при миграции
Плагин CMSВаше приложениеДаКонтент-команда, без деплоев
Meta refresh или JSБраузерДа, но медленноВообще нет доступа к серверу
Управляемая короткая ссылкаСервис ссылокДа, из сохраненного URLОпубликованные и напечатанные ссылки

Сохранение пути и строки запроса

Это тот сбой, который переживает тестирование, потому что все тестируют корень домена, а корень всегда работает.

Направьте oldsite.com на newsite.com с помощью обычной переадресации домена, а затем перейдите по настоящей входящей ссылке oldsite.com/pricing?utm_source=newsletter. При сплющивающем редиректе этот посетитель приземляется на новую главную страницу, путь исчезает, а параметры кампании исчезают вместе с ним. Ничего не выдает ошибку. Ваша аналитика просто показывает прямой трафик на главную страницу, и кажется, будто рассылка не сработала вообще.

Этому мешают две привычки. Тестируйте на глубоком URL, несущем строку запроса, никогда на голом домене. А когда у двух сайтов разная структура, явно сопоставляйте важные пути вместо того, чтобы отправлять все на корень, - это же и удерживает SEO-ценность старых URL при ближайшей подходящей новой странице. Та же дисциплина применяется, когда вы наследуете чужие ссылки, поэтому миграция коротких ссылок без их поломки - это в первую очередь упражнение по сопоставлению, а уже потом техническая задача.

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

Проверьте, прежде чем объявлять

Все решает одна команда:

curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'

В выводе нужно прочитать три вещи. Код статуса должен быть тем, что вы имели в виду: 301 для постоянного и 302, пока что-то еще меняется, а 301 против 302 объясняет, почему этот выбор важнее, чем кажется. Заголовок Location должен нести полный путь и строку запроса, а не голый домен. И редирект должен быть ровно один: цепочка из трех-четырех переходов все еще разрешается, но каждый переход - это задержка и еще один шанс потерять параметры, а повторяющееся имя хоста означает, что вы построили петлю редиректов, а не редирект.

Если вы предпочитаете не открывать терминал, наш чекер ссылок прослеживает цепочку и показывает статус на каждом переходе.

Глубокий URL с UTM-параметрами, сплющенный до главной страницы переадресацией домена, рядом с редиректом, сохраняющим путь и строку запроса

Что с этим делают поисковики

Правильно выполненный редирект не является риском для SEO, и рекомендации на этот счет необычно однозначны. Документация Google о редиректах и поиске рассматривает постоянный серверный редирект как самый сильный сигнал для консолидации URL на его замене, ставит клиентские редиректы ниже и просит держать цепочки короткими.

Две ошибки, которые действительно вам дорого обходятся, - сваливание множества старых URL на главную страницу, что выбрасывает конкретную релевантность, которая была у каждого из них, и оставление цепочки исторических переходов на месте после нескольких миграций. Ни то, ни другое не повод избегать редиректов; и то, и другое - повод их аудировать. Этот аудит - та же еженедельная привычка, что и предотвращение протухания ссылок, а если редирект находится на кастомном коротком домене, кастомные домены для коротких ссылок описывает DNS и сертификатную половину настройки.

Выберите слой, соответствующий тому, кто владеет изменением, сохраните путь, держите один переход - и редирект перестанет быть тем, о чем нужно беспокоиться.

Читайте цикл материалов

Этот материал относится к кластеру туториалов. За кодами статуса и их семантикой обратитесь к материалу типы редиректов URL - это карта, а как работают сокращатели URL описывает, что происходит, когда редирект - это ссылка, а не страница.

Похожие материалы в блоге

Частые вопросы

Как перенаправить один URL на другой?

Пусть то, что обслуживает запрос, вернет 301 или 302 с заголовком Location, указывающим на новый адрес. На практике это значит выбрать слой: переадресацию домена у регистратора, правило в вашем веб-сервере или на хостинговой платформе, плагин в CMS или управляемую короткую ссылку. Способ меняет то, кто отдает ответ, и то, сохранятся ли путь и строка запроса, но не то, что получает браузер.

Можно ли перенаправить URL с помощью DNS?

Нет, и это самое распространенное заблуждение во всей теме. DNS резолвит имя хоста в адрес; он понятия не имеет, какой путь был запрошен, и не может вернуть редирект. Когда регистратор предлагает URL forwarding, он на самом деле указывает имя хоста на свой небольшой веб-сервер, который и выдает HTTP-редирект за вас.

Сохраняет ли редирект путь и строку запроса?

Это целиком зависит от выбранного метода. Переадресация домена у регистратора часто сплющивает все в одно назначение, поэтому /pricing?utm_source=email приземляется на главную страницу, а параметры исчезают. Правило на сервере или платформе может сохранить и то, и другое, если написать его именно так, а управляемая короткая ссылка пересылает сохраненное назначение вместе со строкой запроса. Тестируйте на глубоком URL, а не только на корне домена.

Использовать 301 или 302 редирект?

Используйте 301, когда перемещение постоянное и вы хотите, чтобы поисковики консолидировали сигналы на новом URL, и 302, пока что-то еще меняется. Практическая ловушка в том, что браузеры жестко кешируют 301, поэтому постоянный редирект, о котором вы позже пожалеете, продолжает срабатывать у возвращающихся посетителей еще долго после того, как вы изменили сервер. Тестируйте на 302, повышайте до 301, когда назначение уже устоялось.

Как проверить, что мой редирект работает?

Выполните curl -sIL для URL и прочитайте строки статуса и заголовки Location. Вам нужен один редирект, правильный код статуса и ожидаемое назначение с сохраненными путем и строкой запроса. Цепочка из нескольких переходов все еще работает, но тратит время впустую, а повторяющееся имя хоста означает, что вы построили петлю, а не редирект.

Вредят ли редиректы SEO?

Правильно реализованный редирект - нет. Google рассматривает 301 как сильный сигнал для консолидации ранжирования на назначении, а проблемы вызывают длинные цепочки, а не сами редиректы. Держите один переход, направляйте старые URL на ближайшую подходящую новую страницу вместо того, чтобы сваливать все на главную, и избегайте клиентских редиректов, когда возможен серверный.

Попробуйте Elido

Вставьте URL - получите короткую ссылку

Без регистрации. Ссылка живёт 30 дней. Зарегистрируйтесь, чтобы оставить её навсегда.

Бесплатно, без регистрации · 2 в день

Попробуйте Elido

URL-сокращатель с хостингом в ЕС: собственные домены, глубокая аналитика, открытый API. Бесплатный тариф - без банковской карты.

Теги
how to redirect a url
domain forwarding
url forwarding
301 redirect
redirect a domain
path preserving redirect

Читать дальше