Редирект - це HTTP-відповідь: статус 301 або 302 із заголовком Location, що каже браузеру, куди йти натомість. Це все, чим він є на дроті, а це означає, що питання насправді не в тому, як редиректити URL-адресу, а в тому, який рівень перед вашим сайтом має відповідати на запит.
Впоратися із завданням можуть шість рівнів, і вони не взаємозамінні. Вони різняться тим, хто обслуговує відповідь, чи виживають шлях і рядок запиту в подорожі, як швидко ви можете передумати і скільки з налаштування належить саме вам. Цей гайд проходить усі шість, таблицю, яка допомагає обрати між ними, і дві перевірки, що відрізняють редирект, який працює, від того, що тихцем з'їдає параметри вашої кампанії. Про самі коди статусу розповідають типи URL-редиректів - це довідник, який лежить в основі цього матеріалу.
Де насправді живе редирект
Почнімо з міфу, бо саме він з'їдає найбільше часу: DNS не може редиректити URL-адресу. DNS-запис зіставляє ім'я хоста з адресою. Він ніколи не бачить шлях, ніколи не бачить рядок запиту і не має механізму сказати "піди натомість кудись-інде". Запис A чи CNAME вказує; він не пересилає.
Тож коли ваш реєстратор пропонує "переспрямування URL-адрес", насправді він указує ім'я хоста на свій невеликий вебсервер, який і повертає HTTP-редирект від вашого імені. Корисно і цілком легітимно, але роботу виконує вебсервер, а не 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 | Так, якщо написано саме так | Канонічний хост, реструктуризація |
| Правило платформи | Хост попереду | Так | Масові редиректи при міграції |
| Плагін 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 має нести повний шлях і рядок запиту, а не голий домен. І редирект має бути рівно один: ланцюжок із трьох чи чотирьох стрибків усе ще резолвиться, але кожен стрибок - це затримка і ще один шанс загубити параметри, а ім'я хоста, що повторюється, означає, що ви побудували цикл редиректів, а не редирект.
Якщо вам не хочеться відкривати термінал, наш перевіряч посилань простежує ланцюжок і показує статус на кожному стрибку.
Що з цим роблять пошукові системи
Правильно зроблений редирект не є SEO-ризиком, і настанови на цей рахунок незвично чіткі. Документація Google про редиректи та пошук трактує постійний серверний редирект як найсильніший сигнал для об'єднання URL-адреси з її заміною, ставить клієнтські редиректи нижче і просить тримати ланцюжки короткими.
Дві помилки, які справді коштують вам, - це згортання багатьох старих URL-адрес на головну сторінку, що викидає ту конкретну релевантність, яку мала кожна з них, і залишення ланцюжка історичних стрибків на місці після кількох міграцій. Жодна з них не є причиною уникати редиректів; обидві - причина їх аудитувати. Цей аудит - та сама щотижнева звичка, що й запобігання протуханню посилань, а якщо редирект на кастомному короткому домені, кастомні домени для коротких посилань розглядає половину налаштування, що стосується DNS і сертифікатів.
Оберіть рівень, що відповідає тому, хто володіє зміною, зберігайте шлях, тримайте це в межах одного стрибка - і редирект перестає бути тим, про що варто хвилюватися.
Читайте серію ключових матеріалів
Цей матеріал належить до кластера туторіалів. Про коди статусу та їхню семантику розповідають типи URL-редиректів - це карта, а як працюють скорочувачі URL-адрес розглядає, що відбувається, коли редирект - це посилання, а не сторінка.
Ще в блозі
- Типи URL-редиректів: 301, 302, 307, 308 та інші
- Редиректи 301 проти 302: який використовувати для коротких посилань
- Цикл редиректів: як знайти і виправити ERR_TOO_MANY_REDIRECTS
- Короткі посилання на кастомному домені: DNS, TLS і межа мережі
- Міграція з Bitly без поламаних посилань
- Чи шкодять скорочувачі URL-адрес SEO? Механіка, яка має значення
Поширені запитання
Як редиректити URL-адресу на іншу URL-адресу?
Зробіть так, щоб те, що обслуговує запит, повертало 301 або 302 із заголовком Location, який вказує на нову адресу. На практиці це означає обрати рівень: переспрямування домену в реєстратора, правило у вашому вебсервері чи хостинговій платформі, плагін у CMS або кероване коротке посилання. Метод змінює те, хто обслуговує відповідь і чи виживають шлях та рядок запиту, а не те, що отримує браузер.
Чи можна редиректити URL-адресу через DNS?
Ні, і це найпоширеніше непорозуміння в усій темі. DNS резолвить ім'я хоста в адресу; він не має жодного уявлення, який шлях було запитано, і не може повернути редирект. Коли реєстратор пропонує переспрямування URL-адрес, він насправді вказує ім'я хоста на свій невеликий вебсервер, який видає 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 на день