SEO-міграція сайту: як змінити CMS, дизайн чи домен і не втратити трафік

Коротко: сайт втрачає трафік після міграції не через саму зміну CMS чи дизайну, а через втрачені URL, відсутні редиректи, випадковий noindex і зламану перелінковку. Безпечна міграція — це бенчмарк до запуску, карта редиректів 301, перевірка на staging, чекліст у день запуску й моніторинг після нього.

Чому міграції ламають трафік?

Для пошуковика сторінка — це URL з історією: індексація, посилання, поведінкові сигнали. Якщо адреса змінилася без редиректу, пошуковик бачить нову порожню сторінку і стару, що зникла. Якщо змінився шаблон, змінилися заголовки, структура, внутрішні посилання і швидкість, то сигнали переоцінюються. Тимчасові коливання після великих змін можливі навіть при ідеальному виконанні, але системні помилки призводять до довгих провалів.

Найчастіші причини втрат:

• старі URL повертають 404 або ведуть усі на головну;
• на продакшені залишився noindex або Disallow: / зі staging;
• змінилися title, H1 і текст важливих сторінок;
• зникли сторінки, що приносили трафік;
• зламані внутрішні посилання та ланцюжки редиректів;
• не перенесено розмітку, hreflang і canonical;
• аналітика не працює, і наслідки видно із запізненням.

Які бувають міграції?

Чим більше змін об'єднано в одному релізі, тим складніше знайти причину просідання. Якщо можна розділити (наприклад, спершу CMS, потім редизайн), розділяйте.

Етап 1. Бенчмарк до запуску

Зафіксуйте стан «до», бо без нього неможливо оцінити втрати.

1. Список усіх URL старого сайту: краулер плюс sitemap плюс сторінки з Search Console.
2. Топ-сторінки за кліками й показами за останні 12 місяців.
3. Позиції за ключовими запитами.
4. Конверсії з органіки в GA4: заявки, замовлення.
5. Зворотні посилання: які сторінки мають зовнішні посилання, їх не можна втрачати.
6. Мета-дані й розмітку старих сторінок: title, description, H1, JSON-LD.
7. Швидкість ключових шаблонів (Core Web Vitals), щоб новий сайт не був повільнішим.

Етап 2. Карта редиректів 301

Це найважливіша частина міграції. Для кожного старого URL, що мав трафік, посилання чи позиції, визначте нову адресу.

Правила:

• відповідник має бути найближчим за змістом, а не «усе на головну»;
• один крок редиректу, без ланцюжків A → B → C;
• не використовуйте 302 для постійного переїзду;
• зберігайте редиректи щонайменше рік, а за наявності сильних зовнішніх посилань — довше;
• якщо відповідної сторінки немає, краще повернути 404 або 410, ніж перенаправити на нерелевантну.

Приклад для Apache:

RewriteEngine On
RewriteRule ^old/service-seo/?$ /uk/services/seo [R=301,L]

Приклад для nginx:

location = /old/service-seo {
    return 301 /uk/services/seo;
}

Для великих карт використовуйте map у nginx або таблицю редиректів у CMS (у Laravel — middleware з таблицею БД).

Етап 3. Staging: перевірка до запуску

Розробляйте на тестовому домені, закритому від індексації (авторизація або noindex; сам лише robots.txt не гарантує, що сторінки не потраплять в індекс). Перевірте:

• 301 працюють для всієї карти, без ланцюжків;
• title, description, H1, canonical, hreflang на місці;
• JSON-LD не втрачено;
• внутрішні посилання ведуть на нові адреси, а не через редиректи;
• sitemap містить лише нові канонічні URL;
• швидкість і Core Web Vitals не гірші, ніж на старому сайті;
• форми, цілі й події GA4 працюють.

Етап 4. Запуск: чекліст дня X

1. Видаліть noindex і ослабте блокування в robots.txt, що були на staging.
2. Увімкніть редиректи 301.
3. Відправте новий sitemap у Search Console.
4. Перевірте, що canonical, hreflang і розмітка на живому домені коректні.
5. Переконайтеся, що працює аналітика й відстеження заявок.
6. Для зміни домену використайте інструмент зміни адреси в Search Console і додайте обидва ресурси.
7. Перевірте 10–20 ключових URL вручну: статус, редирект, вміст.
8. Запустіть краулінг нового сайту й перевірте на 404 і ланцюжки.

Запускайте у будній день і в період низького трафіку, коли розробник доступний для швидких виправлень.

Етап 5. Після запуску: моніторинг 2–4 тижні

• Search Console: звіт «Сторінки» (індексація, нові помилки), «Ефективність» (покази й кліки порівняно з бенчмарком), статистика сканування.
• Журнали сервера: чи сканує Googlebot нові URL і чи не впирається у 404.
• GA4: органічний трафік і конверсії по групах сторінок.
• Позиції за ключовими запитами.

Тимчасове просідання можливе. Тривожні сигнали: масові 404, зростання «Виявлено, наразі не проіндексовано», зникнення топ-сторінок із видачі, падіння конверсій без падіння трафіку (проблеми з формами).

Особливості міграції MODX, WordPress і Laravel

• З MODX: зберігайте алиаси ресурсів або формуйте відповідники для кожного ресурсу. Дані контенту, TV-поля та мета-дані експортуйте до міграції.
• З WordPress: перенесіть структуру постійних посилань (permalinks) або підготуйте карту; не забудьте про сторінки тегів, архівів і вкладень, які можуть мати посилання.
• На Laravel: маршрути замість файлової структури, тому редиректи, sitemap і canonical треба реалізувати явно. Таблиця редиректів у БД з адмінкою зручна для супроводу.

Типові помилки

• Не зроблено бенчмарк, і ніхто не знає, що було «до».
• Редиректи тільки для головних сторінок.
• Усі старі URL ведуть на головну.
• Стейджинг відкритий для індексації, а в продакшені залишився noindex.
• Одночасно змінено URL, контент, структуру й домен.
• Забули про зображення, PDF та інші файли з посиланнями.
• Не перенесено hreflang на мультимовному сайті.

FAQ

Скільки триває відновлення трафіку після міграції?

Залежить від масштабу змін, якості редиректів і розміру сайту. Для невеликих сайтів з правильним виконанням — зазвичай тижні, для великих — довше. Гарантувати терміни неможливо.

Чи потрібні редиректи при простому редизайні?

Якщо URL не змінюються, редиректи не потрібні. Але перевірте, що шаблони не змінили title, H1, canonical і внутрішні посилання.

Чи можна мігрувати без зміни URL?

Так, і це найбезпечніший варіант. Зберігайте адреси, коли немає вагомої причини їх змінювати.

Коли видаляти старі редиректи?

Не раніше, ніж через рік, і лише коли на старі URL немає зовнішніх посилань і трафіку.

Чи потрібен інструмент зміни адреси в Search Console?

Лише при зміні домену. Для інших міграцій достатньо редиректів і нового sitemap.

Плануєте змінити CMS або дизайн? Замовте безкоштовний аудит Kyivan — розробник складе карту редиректів, перевірить staging і підготує чекліст запуску.