301 редирект в 1С-Битрикс: де втрачається трафік під час переїзду
Переїзд сайту на новий домен, зміна ЧПУ або перенесення каталогу в іншу гілку структури — це завжди розрив між старими адресами та новими. Пошуковий робот приходить за посиланням із видачі, отримує 404 і через кілька обходів викидає сторінку з індексу.
Якщо 301 редирект не налаштований, разом зі сторінкою йдуть накопичені позиції, посилкова вага та поведінкові сигнали, а на відновлення йдуть місяці. Розбираємо, де саме втрачається трафік і як це закривається.
Перший сценарій — зміна домену без наскрізного правила. У 1С-Битрикс адреси живуть у трьох місцях: правила обробки адрес у налаштуваннях модуля, файли .htaccess на рівні веб-сервера та фізична структура каталогів.
Якщо правило додано лише в одному шарі, частина старих адрес віддає 404, а частина — 200 з дублем контенту. Дублі розмивають вагу між копіями, і у видачі закріплюється не та версія, яку ви просували.
Другий сценарій — склейка дзеркал. Коли сайт доступний і з www, і без, і за обома протоколами, пошуковик бачить чотири копії одного контенту. Канонічна адреса має бути одна, а всі інші — віддавати 301 на неї.
Без цього robots.txt і карта сайту вказують на різні версії, обхід іде врозбрід, і сторінки конкурують самі з собою.
Третій сценарій — зміна структури каталогу або розділу. Старі адреси товарів і статей залишаються в чужих закладках і зовнішніх посиланнях, а нові з'являються лише у внутрішній навігації.
Тут важлива карта відповідностей: для кожної старої адреси — свій цільовий, а не звалище всього на головну. Масовий редирект «все на головну» пошуковик читає як м'який 404 і обнуляє вагу сторінки.
Окремо варто виділити переїзд зі збереженням параметрів. Адреси з UTM-мітками, фільтрами та пагінацією не можна редиректити наосліп — інакше склеяться сторінки видачі фільтра і загубиться довгий хвіст. Правило має спрацьовувати на шлях без параметрів, а query-рядок переносити окремо.
Кожен із цих сценаріїв діагностується за логами веб-сервера та звітами про помилки обходу: видно, які старі адреси ще отримують запити і що вони віддають у відповідь. Далі — питання акуратної карти редиректів і порядку її застосування.
Що дає коректне налаштування редиректів
Коректний редирект — це не «перенаправлення заради перенаправлення», а спосіб зберегти накопичену вагу сторінки при зміні її адреси.
Коли правило віддає постійний код замість тимчасового, пошукова система переносить сигнали зі старого URL на новий: позиції, зовнішні посилання, історію показів.
Якщо код тимчасовий, вага залишається на старій адресі, а новий місяцями не може вийти в топ — трафік просідає, хоча контент не змінювався.
Друге завдання — склейка адрес і боротьба з дублями. Один і той самий товар доступний за адресою з www і без, зі слешем і без, з параметрами фільтра й сортування — для пошуковика це різні сторінки, які конкурують між собою і розмивають релевантність.
Правила приводять усі варіанти до однієї канонічної адреси, і в індекс потрапляє одна сторінка замість п'яти. Це напряму впливає на позиції: вага не ділиться між копіями, а працює на один URL.
Третій ефект — передбачуваність при зміні структури. Переїзд на новий розділ, зміна ЧПУ, об'єднання каталогів — усе це ламає старі посилання, якщо не підготувати карту перенаправлень заздалегідь.
Коли правила описані й перевірені до релізу, відвідувачі та роботи потрапляють на актуальну сторінку, а не на помилку. Зовнішні посилання та закладки продовжують працювати, поведінкові фактори не падають, а індексація перебудовується плавно, без випадіння розділів з видачі.
На практиці це виглядає так: до правок фіксуємо поточні позиції та трафік за ключовими адресами, після — звіряємо, що жоден URL не віддає помилку і не веде в ланцюжок із кількох переходів.
Ланцюжки та петлі — окремий клас проблем: браузер і робот ходять по колу, сторінка не відкривається, а причина не видна в інтерфейсі. Тому правила збираються в одному місці, тестуються на повному списку адрес і тільки потім публікуються.
Способи налаштування редиректів: порівняння підходів
Редиректи в 1С-Битрикс можна реалізувати на трьох рівнях — і вибір рівня визначає, хто і як швидко зможе правити правила далі. Налаштування сервера дає мінімальну затримку на віддачу відповіді, але кожна правка вимагає доступу до конфігурації та перезавантаження.
Модуль Битрикс зберігає карту редиректів у базі, тому правила додаються через адмінку без викату. Змішаний варіант — коли статичні правила живуть на сервері, а ті, що часто змінюються, у модулі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Налаштування сервера | Масові технічні редиректи: зміна домену, склейка дзеркал, зняття дублів зі слешем | Правки лише через конфіг, немає історії змін, при великому обсязі правил зростає час обробки запиту |
| Модуль Битрикс | Правила, що регулярно змінюються, прив'язка до розділів і товарів, робота контент-менеджера | Правило спрацьовує після ініціалізації ядра — трохи повільніше за серверне, частина запитів до статики обробляється раніше |
| Карта редиректів у файлі | Перенесення великого масиву старих адрес при міграції, разове заливання | Файл потрібно версіонувати вручну, при конфлікті з серверними правилами порядок спрацьовування неочевидний |
| Правила в шаблоні | Точкові випадки, зав'язані на логіку сторінки | Змішується з версткою, складно віддати на підтримку, легко втратити при оновленні шаблону |
На практиці найчастіше комбінують: сервер закриває інфраструктурні перенаправлення, модуль — контентні, а карта редиректів використовується як разовий інструмент міграції.
Важливо вибудувати порядок спрацьовування: спочатку серверні правила, потім модуль, інакше одна й та сама адреса може піти двома ланцюжками й отримати петлю. Перед викатом карту перевіряють на конфлікти та цикли — після релізу налагодження коштує дорожче.
Якщо на сайті вже накопичені правила з різних джерел, ми спочатку збираємо їх у єдину карту, прибираємо дублі й лише потім розкладаємо за рівнями.
Порядок робіт: від аудиту адрес до перевірки
Роботу будуємо так, щоб жодна стара адреса не загубилася і не перетворилася на ланцюжок із кількох перенаправлень. Спочатку збираємо повну картину: вивантаження адрес із логів, карти сайту, пошукових систем і внутрішніх посилань, звірка зі структурою нового сайту.
На цьому етапі важливо зловити адреси з параметрами, регістром і слешем у кінці — саме вони найчастіше дають дублі та «м'які» помилки.
Далі проєктуємо правила: зіставляємо стару адресу новій один до одного, прибираємо проміжні ланки, окремо описуємо шаблонні перенаправлення для розділів і пагінації. Після узгодження карти перенаправлень переходимо до впровадження та перевірки.
- Аудит адрес — вивантажуємо всі старі URL із логів, карти сайту та зовнішніх джерел, відзначаємо сторінки з трафіком і вхідними посиланнями.
- Звірка зі структурою — зіставляємо кожну стару адресу з новою, фіксуємо адреси без прямого аналога і вирішуємо, куди їх вести.
- Проєктування правил — описуємо карту перенаправлень: точкові пари, шаблони для розділів, обробку параметрів і регістру.
- Впровадження — налаштовуємо правила на рівні сервера і в самому рушії, щоб перенаправлення спрацьовувало до віддачі сторінки.
- Тестування редиректів — проганяємо весь список, перевіряємо код відповіді, відсутність ланцюжків і циклів, збереження параметрів.
- Контроль після запуску — звіряємо індексацію та логи, прибираємо залишкові помилки, за потреби коригуємо правила.
- Передача — віддаємо карту перенаправлень та інструкцію щодо додавання нових правил вашій команді.
Кожен етап закінчується перевірюваним результатом, тому на виході ви отримуєте не набір розрізнених правил, а керовану карту, яку можна доповнювати без ризику зламати наявні адреси.
Що замовник отримує за підсумками робіт
Роботи закінчуються не фактом «редиректи налаштовані», а набором артефактів, за якими система живе далі без нас. Кожен пункт нижче — те, що залишається у вашої команди: його можна передати новому підряднику, перевірити на рев'ю або підняти під час розбору просідання трафіку.
- Карта редиректів — таблиця «стара адреса → нова адреса → тип правила → джерело» на всі зняті з публікації сторінки, розділи та старі адреси після зміни структури. Збирається з логів відвідувань і карти сайту, а не «на пам'ять»: так до неї потрапляють адреси, про які ніхто не пам'ятає, але за якими ще ходять із пошуку та зовнішніх посилань.
- Конфігурація правил — самі правила, розкладені за рівнями: постійні адреси в конфігурації сервера, масові шаблони в модулі редиректів, поодинокі винятки — окремо. Розділення потрібне, щоб правка однієї сторінки не зачіпала решту й не перетворювалася на правку всього файлу.
- Регламент обробки адрес — порядок дій при знятті сторінки з публікації, зміні адреси розділу, склеюванні дублів і перенесенні каталогу. З ним новий контент-менеджер не створює битих посилань, бо маршрут «зняв сторінку → додав правило → перевірив» описаний до того, як це знадобилося.
- Документація з підтримки — де лежать правила, як додати нове, як відкотити помилкове, які перевірки прогнати після викладки. Окремим блоком — типові помилки: ланцюжки з кількох переходів, правила на неіснуючу адресу, конфлікт шаблону та винятку.
- Звіт перевірки — перелік адрес, за якими пройшла перевірка кодів відповіді, і список знайдених ланцюжків з їхнім усуненням. Це доказ, що правила працюють, а не просто записані.
- Доступи та точки контролю — де дивитися логи переходів, які звіти показують частку помилок, до кого йти при розходженні. Щоб діагностика не починалася з пошуку того, хто останній торкався конфігурації.
Усе перелічене передаємо у вашому контурі: правила, регламент і документація залишаються в репозиторії проєкту та в базі знань, а не в листуванні. Опишіть задачу — повернемося з оцінкою та планом, у якому порядку збирати ці артефакти під вашу структуру сайту.
Кейс: відновлення позицій після зміни структури
Проєкт — інтернет-магазин на 1С-Бітрікс з каталогом на кілька тисяч товарних позицій.
Під час перенесення на нову структуру розділів і перейменування категорій змінилися адреси карток і лістингів, а карта редіректів залишилася від попередньої міграції: частина правил вела на биті сторінки, частина — на загальні розділи замість конкретних товарів.
Через два тижні після релізу пошукові системи вже показували просідання за комерційними запитами, а трафік з органіки падав помітніше, ніж очікувалося.
Що зробили
Спочатку зняли повний зріз поточних адрес і зіставили з історичними з логів сервера та вивантаження систем аналітики. За кожною парою «стара адреса → нова адреса» визначили цільову відповідність: картка веде на картку, розділ — на розділ, а не на головну.
Правила зібрали в одному місці, перевірили на конфлікти й зациклення, окремо обробили ланцюжки з двох і більше переходів — їх згорнули в один крок, щоб не втрачати вагу посилання.
Далі налаштували віддачу постійного перенаправлення на рівні сервера, а не через скрипти — так відповідь приходить швидше і не залежить від завантаження застосунку.
Для адрес, у яких не знайшлося прямої відповідності, прописали правила зі збереженням структури URL: категорія і параметри фільтра переносяться в нову адресу автоматично.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка адрес з коректним перенаправленням | 41% | 96% |
| Сторінки в індексі з помилкою | ~1 800 | < 60 |
| Відновлення позицій за топ-запитами | — | 3-5 тижнів |
| Органічний трафік | падіння | повернення до попереднього рівня і зростання |
Через три тижні після правок основна маса комерційних запитів повернулася на попередні позиції, а частина — вище вихідних: старі адреси більше не конкурували з новими, і вага посилань перестала розсіюватися.
Окремо зафіксували правило на майбутнє: будь-яка зміна структури проходить через карту перенаправлень до релізу, а не після.
Чим відрізняється 301 редирект від 302 і коли це важливо
301 редирект — це постійне перенаправлення: сервер повідомляє пошуковій системі, що сторінка переїхала назавжди, і весь накопичений вага адреси потрібно перенести на нову. 302 редирект — тимчасовий: стара адреса залишається основною, нова вважається проміжною.
Різниця в одному коді відповіді, але саме від нього залежить, яка сторінка потрапить в індекс і чи збережеться у неї колишній трафік.
Механіка проста: при 301 пошуковик за кілька обходів закріплює нову адресу як канонічну, а стару поступово прибирає з видачі.
При 302 стара адреса зберігає статус основної, і нова може взагалі не індексуватися — система продовжує ходити за колишнім URL, очікуючи, що «тимчасовість» закінчиться.
Якщо 302 висить місяцями, це виглядає як помилка конфігурації: позиції просідають, тому що обидві сторінки конкурують між собою, а вага не консолідується.
На практиці вибір коду диктує сценарій. Переїзд на новий домен, зміна структури каталогу, склейка дублів з www і без, перехід з http на https, об'єднання карток товарів — це постійні зміни, і тут потрібен тільки 301.
Тимчасовий 302 доречний, коли адреса повернеться: технічні роботи, A/B-тест посадкової, сезонна акція, обмеження доступу для частини аудиторії. Як тільки причина зникла, редирект знімають.
Окремо варто розглянути ланцюжок редиректів. Коли 301 веде на адресу, яка сама віддає 301, пошуковик витрачає обходи марно і може не дійти до фінальної сторінки. Правильне налаштування — один перехід одразу на кінцевий URL, без проміжних ланок.
Те саме стосується циклів: якщо A перенаправляє на B, а B назад на A, обидві сторінки випадають з індексу.
У 1С-Бітрікс коди задаються в правилах обробки адрес, у налаштуваннях редиректів і через модуль SEO — важливо, щоб код відповідав реальному наміру, а не проставлявся «про всяк випадок». Помилка у виборі тут коштує не косметики, а втрачених позицій, які відновлюються місяцями.
Часті технічні сумніви при налаштуванні
Перед тим як узгоджувати карту редіректів, замовники зазвичай ставлять одні й ті самі запитання — про ланцюжки, конфлікти з модулями та поведінку при зміні домену. Нижче — відповіді, які знімають більшість сумнівів ще до старту робіт.
Що буде, якщо на сайті вже накопичилися ланцюжки редіректів?
Ланцюжок із двох-трьох переходів — це зайві кола для пошукового робота та втрата частини посилальної ваги на кожному кроці. Ми збираємо всі правила з налаштувань сервера, модуля та файлу .htaccess, зводимо їх в одну таблицю та схлопуємо в прямі переходи «стара адреса → кінцева».
На виході — одна відповідь замість трьох, передбачувана поведінка та зрозуміла карта, яку видно повністю.
Чи можуть правила конфліктувати з модулями та компонентами?
Так, і це найчастіша причина «редірект налаштований, а не працює». Правила на рівні сервера спрацьовують раніше, ніж модуль встигає обробити адресу, тому частина переходів просто не доходить до застосунку.
Ми перевіряємо порядок обробки та розводимо правила так, щоб серверні й внутрішні не перекривали одне одного. Після цього переходи спрацьовують стабільно на всіх типах адрес.
Що відбувається з редіректами при зміні домену?
Старий домен продовжує отримувати трафік, і його не можна просто вимкнути — інакше переходи обірвуться. Ми налаштовуємо правила так, щоб кожна адреса старого домену вела на відповідну їй адресу нового, включно з вкладеними розділами та параметрами.
Окремо перевіряємо, що переходи не зациклюються і не втрачають адреси з нестандартними закінченнями.
Як переконатися, що налаштування не зламало наявні адреси?
Перед викладкою ми проганяємо список ключових адрес і дивимося код відповіді на кожній: де має бути прямий перехід — він є, де сторінка жива — вона віддається як раніше. Якщо правило зачіпає робочий розділ, це видно до публікації, а не за просіданням трафіку через тиждень. Правки вносимо по одній, щоб завжди можна було повернути попередній стан.
Обговоримо ваше завдання щодо редиректів
Редиректи майже ніколи не існують у вакуумі: вони з'являються при зміні структури каталогу, перенесенні розділів, склеюванні дублів після ребрендингу або переїзді на новий шаблон.
Тому розмову починаємо не з прайсу, а з вашої поточної карти адрес: які URL змінюються, скільки їх, чи є вже накопичена історія переходів і що з індексацією зараз.
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум ввідних. Опишіть завдання у вільній формі — далі уточнимо деталі самі.
- Поточна ситуація: що змінюється — структура каталогу, домен, шаблон, розділ або окремі сторінки.
- Список адрес: чи є вивантаження старих і нових URL, у якому вигляді — таблиця, лог сервера, карта сайту.
- Причина: переїзд, склеювання дублів, зміна ЧПУ, видалення розділу або відновлення після помилки.
- Обмеження: дедлайн, вікно простою, вимоги до збереження позицій і трафіку.
- Що вже зроблено: чи пробували налаштовувати правила самостійно, які помилки бачите.
- Доступи та оточення: редакція продукту, хостинг, чи є тестовий контур для перевірки ланцюжків.
- Критерій готовності: що для вас вважається результатом — відсутність битих переходів, збереження позицій, чистий лог.
За цими ввідними ми зберемо план робіт: аудит поточних адрес, проєктування карти переходів, налаштування правил на рівні сервера та в панелі управління, перевірка ланцюжків і кодів відповіді, контроль індексації після впровадження. Оцінку даємо за обсягом — від точкової правки до повної міграції структури.
Якщо ситуація термінова і сайт уже втрачає трафік — так і напишіть, розберемо пріоритети в першу чергу. Опишіть завдання, і ми повернемося з оцінкою та планом робіт.
