Міграція домену: де втрачаються позиції та трафік
Міграція домену рідко б'є по позиціях у момент перемикання — просідання приходить через два-чотири тижні, коли пошуковий робот заново обходить уже нову адресу й знаходить розбіжності.
Перша й найчастіша точка відмови — ланцюжки перенаправлень: зі старої адреси на проміжну, з проміжної на нову, окремими правилами для адрес зі слешем і без, для www і без www.
Робот проходить ланцюжком обмежену кількість кроків, далі посилання позначається як бите, і накопичена вага сторінки не переноситься.
Друга причина втрати трафіку — розбіжні канонічні адреси. Якщо в розмітці сторінок усе ще прописаний старий домен, а карта сайту вже віддає новий, сигнали суперечать один одному, і частина розділів продовжує жити в індексі за попередньою адресою або зовсім випадає з нього.
Окремо перевіряємо мовні та регіональні зв'язки: під час перенесення сайту вони ламаються найтихіше й помітні вже за падінням показів у конкретних регіонах.
Третя точка — зовнішні посилання. Прямі посилання на глибокі сторінки не переїжджають разом із доменом, і якщо перенаправлення покриває лише головну та категорії, профіль посилань втрачає найцінніші згадки: їх ставлять на статті, картки, посадкові під запити.
Ми починаємо з інвентаризації всіх відданих адрес і карти відповідностей «старий — новий» до перемикання, а не після: так помилки перенаправлень ловляться на тестовому контурі. Нижче розбираємо, як це закривається на кожному етапі.
Що зберігається під час переїзду: позиції, трафік, індексація
Під час переїзду змінюється лише домен: структура адрес, вміст сторінок і розмітка залишаються попередніми.
Ми будуємо карту відповідностей «стара адреса → нова» рядок за рядком — перенаправлення «все на головну» не використовуємо, бо воно обнуляє накопичену вагу внутрішніх сторінок.
- Збереження позицій. Кожна адреса отримує постійне перенаправлення 1:1, включаючи пагінацію, фільтри та параметри сортування. Орієнтир — усі зіставлені адреси; незіставлені переходять у відповідь 404 і розбираються вручну.
- Індексація нової адреси. Оновлюємо карту сайту та robots.txt, відправляємо домен на переобхід, стежимо за звітом про покриття: сторінки мають перейти з «виключено» в «проіндексовано», а не зависнути в черзі.
- Структура адрес. Протокол, префікс www, завершальний слеш і регістр приводимо до єдиного вигляду: стара й нова версії не повинні відповідати одночасно, інакше пошуковик склеює дзеркала й залишає у видачі не ту адресу.
- Відновлення трафіку. Через Яндекс Вебмастер контролюємо зміну адреси та динаміку показів: зазвичай 80–90% трафіку повертається за 2–4 тижні, залишок — запити, де переїзд збігся зі зміною вмісту.
- Усунений клас відмов. Знімаємо дублі, цикли перенаправлень і розбіжності канонічних адрес — помилки, через які сайт застрягає на старому домені на місяці.
Підсумок перевіряємо за цифрами: частка проіндексованих сторінок нового домену, кількість збережених позицій у топ-10 і строк повернення трафіку до попереднього рівня.
Способи переїзду: перенаправлення, дзеркало, паралельний запуск
Схема переїзду вибирається за двома параметрами: скільки адрес працює одночасно і як швидко потрібно повернути пошуковий трафік.
Наскрізне перенаправлення зі старої адреси на нову — найпередбачуваніший варіант: кожна сторінка отримує постійну відповідь, сигнали та історія переносяться на нову адресу, а користувач не бачить розриву.
Умова одна, але жорстка — карта перенаправлень збирається до перемикання, за логами та індексом, інакше частина адрес віддає помилку й випадає з видачі на місяці.
Дзеркало сайту та паралельний запуск вирішують інше завдання: дати обом адресам працювати одночасно й порівняти поведінку до остаточного перемикання.
Тут критично розвести канонічні адреси та правила індексації, інакше два контури почнуть конкурувати між собою й розмивати позиції.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Наскрізне перенаправлення 1:1 | Зміна домену цілком, один контур, мінімальний простій | Потрібна повна карта перенаправлень; помилка в правилі одразу видна в логах |
| Дзеркало сайту | Потрібно перевірити нову адресу під навантаженням, не гасячи стару | Вимагає ручного налаштування канонічних адрес і карти обходу |
| Паралельний запуск | Поступове виведення нової адреси, порівняння поведінки | Подвійний супровід контурів, ризик розбіжності контенту |
| Поетапне перенесення за розділами | Великий каталог, перенесення частинами з контролем | Розтягнутий строк, обидва контури живуть довго |
Сполучний артефакт для будь-якої схеми один — карта перенаправлень і правила канонізації.
Ми збираємо її з логів, індексу та структури, переносимо розділ за розділом і знімаємо метрики після кожного етапу: частку адрес з коректною відповіддю, динаміку переходів і покриття індексом.
Етапи міграції домену: від аудиту до зняття старого сайту
Порядок робіт будуємо так, щоб кожна наступна операція спиралася на перевірений результат попередньої, а відкат залишався можливим на будь-якому кроці, поки старий домен відповідає. Поки триває підготовка, обидві адреси існують паралельно — це і є страховка від просідання позицій.
-
Аудит структури та інвентаризація адрес. Вивантажуємо карту сайту, логи сервера та звіт із трафіку, збираємо всі адреси: сторінки, пагінацію, фільтри, параметричні та службові. Окремо позначаємо адреси із зовнішніми посиланнями — їх втрата обнуляє накопичену вагу посилань.
-
Схема відповідностей адрес. Кожній старій адресі призначаємо цільову: перенесення один до одного, об'єднання або видалення з коректним кодом відповіді. Схему версіонуємо, щоб розробник, контент-менеджер і замовник працювали за однією таблицею.
-
Налаштування на тестовому контурі. Новий домен піднімаємо в закритому середовищі та проганяємо правила перенаправлення, канонічні посилання, карту сайту й внутрішні зв'язки. Тестовий контур відсікає зовнішні обходи та проміжне зберігання — збої бачимо до публікації.
-
Перевірка перед перемиканням. Автоматично обходимо всю схему: звіряємо коди відповіді, ловимо ланцюжки з кількох перенаправлень і циклічні правила, перевіряємо доступність мобільної та основної версії.
-
Перемикання DNS. Спершу знижуємо час життя записів, потім змінюємо адреси — поширення займає хвилини, а старий сайт продовжує віддавати контент до готовності нового.
-
Спостереження після запуску. Кілька тижнів звіряємо позиції, трафік і коди відповіді за вибіркою адрес, правимо схему за фактичними даними.
-
Зняття старого сайту. Робимо останнім: тримаємо старий домен, поки перенаправлення працюють і статистика стабільна.
Підсумок послідовності — переїзд без провалу трафіку: пошуковик отримує передбачувану карту перенаправлень, а команда — точку відкату на кожному етапі.
Карти перенаправлень, схеми та регламенти після переїзду
Переїзд вважається завершеним не в той момент, коли стара адреса почала відповідати перенаправленням, а коли в команди замовника на руках повний комплект артефактів.
Без них наступне редагування сайту або зміна підрядника перетворюється на відновлення логіки переїзду з пам'яті — і частина адрес знову йде в нікуди.
- Карта перенаправлень — таблиця «стара адреса → нова адреса → код відповіді» з усіма винятками: параметри, різний регістр, зайвий слеш, вкладені шляхи. За нею переїзд відтворюється на тестовому контурі та перевіряється автоматично, а не очима.
- Правила обробки посилань — що робимо з внутрішніми посиланнями, канонічними адресами, картою сайту та зовнішніми згадками, а що навмисно залишаємо без змін і чому.
- Схема обходу — порядок перевірки розділів і груп адрес: що дивимося вручну, що віддаємо пошуковому роботу, де пріоритет у сторінок, що приносять переходи.
- Регламент індексації — строки виведення старої адреси з індексу та момент, коли перенаправлення можна знімати без втрати накопиченої ваги.
- Документація з перенесення — журнали перевірок, звіти про коди відповідей, покриття обходом, список змінених шаблонів і налаштувань сервера.
- Контрольний список приймання — набір перевірок, за яким новий адміністратор за годину розуміє стан переїзду та бачить, що залишилося доробити.
Такий комплект знімає залежність від конкретних виконавців: переїзд перестає бути знанням у чиїйсь голові й стає частиною документації проєкту.
Кейс: переїзд каталогу на нову адресу без просідання
Каталог інтернет-магазину на 19 400 адрес — картки товарів, категорії, сторінки фільтрів — переїжджав на новий домен через зміну юридичної особи та бренду.
Стару адресу зберегти було неможливо, а втратити накопичений пошуковий трафік означало обнулити канал, який приносив понад половину замовлень. Завдання формулювалося жорстко: змінити домен, не зронивши видимість у пошуку.
Як переносили
Карту адрес зняли краулером до переїзду та зіставили один-до-одного — без «складання» каталогу в головну сторінку, що зазвичай і дає обвал. На кожну стару адресу поставили постійне перенаправлення, переписали canonical, оновили карту сайту та всі внутрішні посилання.
Переїзд ішов хвилями за розділами: спочатку категорії, потім товари, і на кожній хвилі звіряли, де саме з'являється просідання. Динаміку знімали в Google Search Console і панелі вебмайстра щодня.
Метрики до та після
| Показник | До переїзду | Нижня точка | Через 10 тижнів |
|---|---|---|---|
| Адреси з коректним перенаправленням | — | 99,4% | 99,4% |
| Видимі запити | 24 300 | 17 900 | 26 800 |
| Переходи з пошуку, % від вихідного | 100% | 61% | 106% |
| Сторінок в індексі | 19 400 | 6 200 | 18 900 |
Провал припав на третю добу — пошук переіндексував нову адресу й тимчасово зняв довіру. Повернення трафіку до вихідного рівня зайняло вісім-дев'ять тижнів, а до дванадцятого видимі запити перевищили стартові.
Решта 0,6% адрес — дублі та параметри фільтрів: їх закрили від індексації свідомо, щоб не розмивати вагу.
Чим відрізняється переїзд на піддомен від зміни основної адреси?
Переїзд на піддомен і зміна основної адреси вирішують різні завдання, і логіка перенесення в них різна. Піддомен — це окремий хост: основний домен залишається в строю та зберігає накопичені сигнали довіри, а нова адреса стартує майже з нуля.
Під час зміни основної адреси переноситься весь сайт — разом з історією та профілем посилань, а попередній домен виводять з індексу, і він поступово втрачає видимість.
Зовнішні посилання обробляються по-різному. Під час переїзду на піддомен посилання на основну адресу продовжують працювати і переписувати їх не потрібно — але й вагу вони віддають основному домену, а не піддомену.
Під час зміни основної адреси кожне зовнішнє посилання потрібно провести через постійне перенаправлення: одна неохоплена сторінка або ланцюжок перенаправлень — і частина ваги посилань втрачається безповоротно.
Структура сайту перебудовується теж неоднаково. На піддомені достатньо віддзеркалити шляхи та замінити хост у канонічних адресах і карті сайту — розділи та внутрішня навігація залишаються недоторканими.
Під час зміни основної адреси безпечніше зберігати адреси сторінок один до одного: одночасна зміна домену та шляхів змішує дві змінні, і потім уже незрозуміло, що саме просадило позиції.
Строки відновлення відрізняються принципово. Піддомен не роняє позиції основного сайту, але просувається самостійно: перші переходи з'являються через тижні, стійкі позиції — через місяці.
Під час зміни основної адреси можливе короткочасне просідання трафіку, а повернення до попередніх позицій займає від двох-шести тижнів за чистої карти перенаправлень до кількох місяців у конкурентних темах.
Перенаправлення, карта сайту та канонічні адреси після переїзду
Перенаправлення вибудовуємо в один крок: стара адреса — нова адреса, без проміжних ланок. Ланцюжок із двох-трьох переходів розмиває передану вагу й витрачає запити робота на проміжні вузли, а частина переходів не доходить до фінальної сторінки.
Тому до перемикання ми збираємо вхідні посилання, правила сервера та перелінковку і схлопуємо ланцюжки до прямих.
Канонічні адреси фіксуємо за шаблонами: одна сутність — одна адреса. Дублі після переїзду — зі слешем і без, в іншому регістрі, з параметрами сортування — закриваємо перенаправленням або канонічним посиланням.
Інакше обхід пошуковими системами розведе сигнали за копіями, і частина позицій піде на сторінки, яких немає в навігації.
Карту сайту перезбираємо одразу після перемикання й тримаємо в ній лише адреси з коректною відповіддю. Звіряємо обхід у Google Search Console і повторюємо перевірку через тиждень і через місяць — поки статистика індексування не повернеться до попередньої.
Що робити, якщо ланцюжок перенаправлень уже накопичився?
Розбираємо його від останньої ланки до першої: визначаємо фінальну адресу й переписуємо правила так, щоб кожна стара адреса вела прямо на неї. Проміжні вузли видаляємо та перевіряємо обхід заново за журналом сервера.
Чому дублі не закривають забороною у файлі для роботів?
Заборона заважає роботу побачити канонічне посилання та склеїти сигнали — копії залишаються в індексі як самостійні сторінки. Надійніше постійне перенаправлення, а для сторінок, які мають існувати, — канонічна адреса.
Обговоримо завдання: схема переїзду, строки, зона відповідальності
На вході нам потрібні доступи до керування доменними записами, акаунта реєстратора, адміністративної частини сайту та вивантаження поточних правил перенаправлення.
Окремо дивимося карту трафіку й точок входу із систем веб-аналітики — за нею видно, які адреси не можна втрачати під час перенесення. Чим повніші ці дані, тим точніші строки перенесення, без запасу «на всякий випадок».
План робіт збираємо до старту: етапи, порядок дій, точки перевірки та момент, після якого стару адресу можна вимикати.
Зона відповідальності ділиться явно — ми відповідаємо за технічну частину переїзду та збереження позицій, ви підтверджуєте рішення щодо контенту й відкриваєте доступи.
- схема переїзду: які адреси куди перенаправляються і в якому порядку;
- план робіт за етапами з точками перевірки після кожного;
- строки перенесення та вікно, коли трафік іде на нову адресу;
- зона відповідальності сторін: що робимо ми, що підтверджуєте ви;
- карта перенаправлень і правила для вкладених сторінок;
- список контрольних адрес, за якими стежимо після перенесення;
- доступи та ролі: хто і що може змінювати в доменних записах і на сервері;
- порядок дій, якщо позиції просіли після переїзду.
Опишіть завдання та поточне розміщення сайту — повернемося з оцінкою, схемою переїзду та строками перенесення. На виході у вас буде план робіт і зрозумілі межі відповідальності сторін.
