301 редирект не працює: де ламається переїзд і зникає трафік
Під час переїзду сайту адреси змінюються, і редирект стає єдиним мостом між старою та новою структурою. Якщо він не працює, сервер віддає 404: сторінка випадає з індексу, а накопичена вага не переходить на заміну.
Втрата трафіку під час міграції майже завжди починається не з контенту, а з обірваного ланцюжка перенаправлень.
Механіка проста: відповідь 301 веде на кінцеву адресу за один перехід. Коли правило вказує на проміжну сторінку, яка редиректить далі, ланцюжок подовжується і частина переходів обривається.
Якщо замість постійної відповіді сервер віддає тимчасову, пошукові системи зберігають стару адресу в індексі, і на сайті живуть копії однієї сторінки.
Розрізнені правила — головне джерело обривів. Частина редиректів прописана в конфігурації сервера, частина — на рівні застосунку, частина заведена вручну; при злитті вони конфліктують, а розділи й адреси з параметрами залишаються без правил.
Окремо ламається склеювання адрес: версії з www і без, різні протоколи та завершальний слеш мають сходитися до одного канонічного вигляду, інакше дублі ділять між собою вагу.
Є й мовчазні збої: сервер віддає код успіху на сторінці-заглушці «нічого не знайдено». Звіти Search Console за картою перенаправлень, ланцюжками та внутрішніми посиланнями показують такі місця до того, як вони з'їдять позиції.
Розбираємо, як це закривається — від інвентаризації адрес до єдиної точки правил і контролю після запуску.
Що дає коректне налаштування: результат у цифрах і термінах
Коректно побудована карта 301-редиректів дає вимірюваний ефект одразу на вході: 98-99% переходів за старими адресами потрапляють на цільову сторінку з першого кроку, а не на проміжну відповідь.
Користувач бачить потрібний контент, а не заглушку, і не втрачає секунди на зайвий круг запитів — для розділів із високим трафіком це помітна частка утримання.
Збереження позицій залежить від того, як пошукові системи переносять сигнали зі старих адрес на нові.
Якщо кожна адреса віддає рівно одну постійну відповідь і не бере участі в ланцюжку, індекс перебудовується передбачувано: просідання видимості обмежується першими днями й повертається до попередніх значень за один-три тижні.
При розірваних зв'язках, відповідях-заглушках і пересічних правилах той самий шлях розтягується на місяці, а частина сторінок випадає з індексу безповоротно.
Моніторинг після переїзду закриває це вікно ризику. Зіставлення журналів веб-сервера зі звітами пошукових систем показує, які адреси ще віддають помилку і де утворився ланцюжок із трьох і більше переходів.
Помилки в ланцюжках перенаправлень виявляються в першу добу — до того, як сторінка втратить накопичену вагу.
Окремий ефект — обсяг ручної роботи. Карта переходів збирається з вивантаження адрес і правил на рівні конфігурації, а не правиться по одній адресі в інтерфейсі.
Додавання нового розділу або зміна структури каталогу перетворюється на оновлення одного файлу, і ручних правок стає в рази менше — міграція без втрат перестає бути разовим героїчним заходом.
Способи перенаправлення: коли який режим доречний
Код відповіді та рівень налаштування вирішують різне: код визначає, як пошук перерозподілить вагу сторінки, рівень — чи встигне правило спрацювати до звернення до застосунку. Промах в будь-якому з параметрів дає або просівші позиції, або зайве навантаження на застосунок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Постійне перенаправлення (301) | Завершений переїзд домену або структури, склеювання дублікатів | Браузер і пошук запам'ятовують відповідь; відкат потребує скидання кешу |
| Тимчасове перенаправлення (302/307) | Тести, сезонні розділи, поетапне перенесення | Вага залишається на старій адресі |
| Правила на стороні сервера | Шаблонні випадки: схема, слеш, регістр | Порядок правил критичний, легко отримати ланцюжок або петлю |
| Карта адрес на прикладному рівні | Тисячі унікальних пар «старий → новий» | Потрібна відповідь застосунку, без кешу зростає час відгуку |
| Перенаправлення на рівні розподільника | Єдина точка входу, кілька майданчиків | Умов мало, великий список адрес вести незручно |
Постійне перенаправлення ставлять на завершений переїзд — зміну домену, склеювання дублікатів, нову структуру розділів. Тимчасове — на тести й поетапне перенесення, коли стара адреса має повернутися.
Якщо тимчасова відповідь висить місяцями, пошук продовжує вважати основною стару сторінку, і новий розділ не набирає ваги.
Правила на стороні сервера дешевші за часом відповіді, але погано переносять тисячі унікальних пар: шаблони плутаються, з'являються ланцюжки з двох-трьох переходів.
Карта адрес на прикладному рівні читається з версіонованого списку й правиться без перезапуску, зате потребує відповіді застосунку.
Перенаправлення на рівні розподільника зручне як єдина точка входу і для аварійних перемикань між майданчиками, але умови там обмежені — великий список адрес у ньому не ведуть.
Порядок міграції: від інвентаризації адрес до перевірки
Міграцію ламає не перенесення контенту, а адреси: пошукові системи та зовнішні посилання продовжують ходити на старі URL ще місяцями після перемикання.
Тому схему перенаправлень проєктують до зміни структури, а не за фактом просідання трафіку — інакше частина переходів іде в нікуди за перші години.
- Аудит адрес. Збираємо повну карту входів: логи веб-сервера за кілька місяців, карта сайту, звіти про індексацію, зовнішні посилання. До неї потрапляють адреси з параметрами, хвостовим слешем і в різному регістрі — саме вони найчастіше залишаються без пари.
- Проєктуємо схему перенаправлень. Кожна стара адреса отримує рівно одну цільову, без ланцюжків і проміжних ланок: кілька переходів підряд з'їдають вагу й час відповіді. Для сторінок без аналога ставимо чесний код «видалено» замість відправлення на головну.
- Збираємо тестовий контур. Копія структури й правил на окремому стенді: проганяємо карту адрес скриптом і звіряємо коди відповідей, заголовки та підсумкові точки призначення.
- Налаштовуємо перенаправлення. На рівні веб-сервера або балансувальника, а не в розмітці сторінки — так правило спрацьовує до віддачі контенту й не залежить від рушія.
- Перевірка охоплення. Звіряємо список з аудиту з реальними відповідями: рахуємо частку адрес, що віддають коректний код, і переконуємося, що нових ланцюжків не з'явилося.
- Перемикання й спостереження. Після запуску відстежуємо коди відповідей на колишніх адресах і динаміку входів за ними; розбіжності закриваємо точково.
- План відкату. Конфігурація правил версіонується поряд із проєктом: якщо структуру прийнято невдало, повернення до попередньої схеми займає хвилини, без ручної правки бойового середовища.
Карта перенаправлень, журнали й регламенти оновлення
Після міграції в команди замовника залишається не звіт «роботи виконано», а робочий набір артефактів. Без них перша ж зміна платформи або новий розділ перетворюють історію адрес на нагромадження винятків, яке ніхто не наважується зачепити. Передаємо все в репозиторій замовника й фіксуємо, хто і за яким правилом вносить правки далі.
- Карта перенаправлень — таблиця «стара адреса → цільова → тип переходу → відповідальний», включаючи згорнуті ланцюжки, де кілька посилань ведуть на одну сторінку за один перехід.
- Документація з міграції — що і чому перенесли, які адреси залишили навмисно, які розділи закрили і куди тепер ведуть їхні відвідувачі.
- Журнал змін адрес — дата, автор, причина правки та попереднє правило: за ним видно, коли з'явилося задвоєння і що саме відкочувати.
- Регламент оновлення — де заводяться нові правила, у якому порядку вони застосовуються і як перевіряються до публікації на робочому контурі.
- Інструкція для підтримки — сценарії на типові випадки: перейменували розділ, склеїли каталог, видалили сторінку без заміни.
- Конфігурації правил — файли веб-сервера й налаштування на рівні застосунку з коментарями, щоб правку вніс інженер, який не брав участі в перенесенні.
- Набір перевірок — обхід карти адрес, який ловить «сторінка не знайдена» і зайві ланцюжки раніше, ніж їх побачать відвідувачі та пошукові роботи.
Усе це лежить поряд із проєктом, а не в листуванні. Новому інженеру не доводиться відновлювати логіку переходів за непрямими ознаками.
Міграція інтернет-магазину: трафік і позиції до та після
Каталог на 1С-Битрикс жив у пласкій структурі: 12 тисяч адрес, розділи в один рівень, частина карток — за службовими шляхами фільтрів. Переходи з пошуку приносили більше половини замовлень, тому зміна структури розділів означала ризик разом втратити видимість і виручку.
Зібрали карту відповідностей за всіма старими адресами: звірили дані з пошукових систем, карту сайту й логи веб-сервера, розмітили кожну картку, розділ і сторінку блогу.
Без такої карти переїзд каталогу перетворюється на вгадування, і частина сторінок просто не знаходить нової адреси.
Як налаштовували переходи
На її основі розгорнули 301 редиректи — строго по одному переходу, без ланцюжків «старий — проміжний — новий»: кожен зайвий крок втрачає вагу посилання і збільшує час відповіді.
Службові адреси фільтрів і сортувань закрили від індексації, для сторінок посторінкової навігації прописали окремі правила, щоб пошукові системи не забирали порожні лістинги.
Усе, що не вдалося зіставити, віддали під чесну відмову — вона краща, ніж наскрізний редирект на головну, який розмиває релевантність.
Що вийшло
Перший тиждень після перемикання частка переходів із пошуку просла на 12% — очікувана реакція на зміну адрес. До третього тижня видимість відновилася до 95% від попередньої, через два місяці — до 104%: нова структура розділів додала охоплення завдяки точнішим запитам.
Помилки 404 залишилися на 0,4% від усіх звернень замість 6% у перші дні — їх зняли точковими правилами за логами.
Чим відрізняється 301 редирект від тимчасового перенаправлення?
301 — постійне перенесення: пошукова система замінює стару адресу на нову в індексі й переносить на неї накопичені сигнали.
Тимчасове перенаправлення (302 і 307) говорить протилежне — адреса повернеться, тому вихідний URL залишається основним, а новий ранжується як окрема сторінка. Звідси й різниця: при 301 вага сторінки переїжджає, при тимчасовому — залишається на місці.
На практиці вибір диктує сценарій. Склеювання дублікатів — зі слешем і без, з www і без, старий і новий шаблон — завжди через 301: усі версії сходяться на одну канонічну адресу, і сигнали не розмазуються між копіями.
Тимчасовий режим доречний для тестових лендінгів, геоперемикань і технічних робіт: Google продовжує віддавати покази вихідній адресі, а після зняття редиректу відкочувати нічого не потрібно.
Повторний переїзд — окремий ризик. Ланцюжок 301 → 301 → 301 розмиває сигнали: робот проходить кілька переходів, і частина ваги губиться дорогою.
Тому при другому перенесенні редирект ставимо відразу на фінальну адресу, а внутрішні посилання, карту сайту й канонічні адреси оновлюємо тим самим релізом — щоб ланцюжків і петель не залишалося взагалі.
Перевіряємо результат за заголовками відповіді, а не на око: код, число переходів, відсутність петлі на себе, покриття всіх старих адрес. Тоді переїзд зберігає позиції та трафік, а не скидає історію сторінок.
Технічні сумніви: питання про перенаправлення та склеювання
Частина заперечень щодо перенаправлень повторюється від проєкту до проєкту: скільки живуть правила, що робити з уже переїхавшим сайтом, як переконатися, що пошукові системи побачили нові адреси.
Принцип один: правило вважається робочим не коли воно створене, а коли перевірені код відповіді та кінцева адреса. Тому перевірку ланцюжків і карту відповідності старих і нових адрес ми закладаємо в план міграції відразу, а не після здачі.
Скільки часу потрібно тримати правила перенаправлення?
Безстроково, а не «на період переїзду». Зовнішні посилання, закладки й документи живуть роками, а пошукові системи обходять старі адреси заново місяцями — якщо зняти правила раніше, трафік піде в помилку.
Адресу, на яку не залишилося вхідних посилань, можна закрити кодом 410: сторінка випаде з видачі швидше, ніж при нескінченному очікуванні.
Сайт уже переїхав, але частина адрес віддає помилку — що робити?
Спочатку джерело: помилки відповіді сервера на потрібних адресах зазвичай означають, що правило не спрацювало, перекрите іншим або вказує на проміжну адресу.
Далі — повторна міграція лише проблемного сегмента: звіряємо журнал звернень із картою адрес, згортаємо ланцюжки виду A→B→C у пряме A→C і ведемо на фінальну сторінку.
Як переконатися, що нові адреси проіндексувалися?
Пакетно проганяємо список старих адрес і дивимося три речі: код відповіді, кінцеву адресу та відсутність зайвих переходів між ними. Потім звіряємо результат із картою сайту та звітом про сканування. Відповідь 200 на сторінці-заглушці або довгий ланцюжок — привід переписати правила в цьому розділі.
Ми знову змінюємо структуру — правила доведеться переписувати?
Ні. Ми тримаємо шаблонні правила за розділами, а не порядково, тому нова структура каталогу перекривається зміною кількох шаблонів. Винятки — поодинокі сторінки зі старими зовнішніми посиланнями: їх перевіряємо окремо.
Обговоримо вашу міграцію: що надіслати для оцінки та плану
Щоб повернутися з оцінкою міграції та планом робіт, не потрібен увесь проєкт цілком — достатньо вихідних даних за адресами.
Чим повніший список, тим точніші терміни налаштування: за логами одразу видно, які сторінки збирають трафік, а які можна закрити без ризику втратити переходи.
- Вивантаження поточних адрес: карта сайту, лог сервера за один-два місяці, таблиця адрес із частотою звернень.
- Структура нового сайту: перелік розділів і адрес, щоб зіставити старі та нові один до одного і не залишити «висячих» сторінок.
- Чинні правила: редиректи на рівні веб-сервера та зворотного проксі, robots.txt, канонічні адреси, налаштування пагінації й параметрів у посиланнях.
- Особливі випадки: мовні версії, закриті розділи, документи й файли, адреси із завершальним слешем і у верхньому регістрі.
- Доступи: тестовий контур, панель хостингу, репозиторій із конфігурацією — перевіримо коди відповідей і ланцюжки редиректів до перемикання, а не після.
- Дати: бажане вікно перемикання та періоди, коли бойовий сайт чіпати не можна.
Натомість віддаємо карту редиректів, звіт за кодами відповідей і регламент супроводу після перемикання. Передача проєкту включає правила, за якими ви або ваша команда зможете додавати нові адреси самостійно. Опишіть завдання — повернемося з оцінкою обсягу робіт, планом і термінами.
