Карта старих і нових URL
Перед міграцією зберіть повний список URL старого сайту з краулера, логів і бази даних, потім для кожної важливої сторінки визначте рівно одну цільову адресу на новому сайті.
Пропуски в таблиці призводять до 404 і втрати накопиченого сигналу, тоді як дубльовані цілі створюють канонічний хаос.
Окремо зафіксуйте URL, які дають основний органічний трафік і дохід: саме вони потребують ручної перевірки після переносу, а не лише автоматичного редіректу за шаблоном.
Якщо змінюється CMS, не покладайтеся лише на «візуально схожу» структуру — зіставте типи сторінок і шаблони, інакше частина комерційних URL зникне з внутрішньої перелінковки.
Для великих каталогів додайте правило для пагінації та фільтрів, щоб не створити тисячі тимчасових 302 на тестовий домен.
- Позначте пріоритетні URL для бізнесу.
- Відокремте службові URL, які можна не переносити.
- Перевірте параметри та фасети.
- Узгодьте trailing slash політику.
- Перевірте мовні версії hreflang.
- Переконайтеся, що PDF та медіа мають план переносу.
- Додайте owner для кожного блоку URL у таблиці.
- Перевірте старі кампанії з utm на оновлення.
- Збережіть backup старої карти сайту.
- Перевірте subdomain vs основний домен.
- Зафіксуйте політику верхнього/нижнього регістру в path, якщо старий сайт був чутливий до нього.
- Перевірте старі AMP-URL і їхній перенос або 410.
- Порівняйте списки URL з GSC export і з краулера — різниця часто показує «забуті» розділи.
- Додайте окремий рядок для landing з платної реклами з мітками utm.
Індексація — перевірка в Google та sitemap.
301 і ланцюги редіректів
301 сигналізує про постійне перенесення, але ланцюг A→B→C зменшує ефективність передачі сигналу й уповільнює користувача.
Оновлення внутрішніх посилань на нові URL зменшує навантаження на сервер і покращує UX.
Переконайтеся, що редіректи не конфліктують з canonical: якщо сторінка canonical на X, а 301 веде на Y, ви створюєте сигнал, який важко інтерпретувати.
Для зміни протоколу або www краще єдиний «великий» 301 на цільовий хост, ніж каскад http→https→www.
Після імпорту правил у nginx/Apache зробіть вибіркову перевірку заголовків Cache-Control — інколи агресивний кеш фіксує стару відповідь 301.
- Перевірте редіректи скриптом або краулером.
- Уникайте 302 замість 301 без причини.
- Переконайтеся, що HTTPS коректний.
- Перевірте www vs non-www.
- Оновіть canonical на нові URL.
- Перевірте hreflang після переносу.
- Переконайтеся, що старі sitemap видалені з GSC.
- Перевірте robots на новому домені.
- Перевірте CDN правила.
- Документуйте винятки для API endpoints.
- Перевірте редіректи для зображень і файлів у uploads.
- Переконайтеся, що feed URL для RSS не ламає підписників.
- Перевірте webhook-и інтеграцій на старі домени.
- Додайте моніторинг 5xx під час першої хвилі ботів після DNS cutover.
Crawl budget — огляд.
Після запуску
Після запуску перевірте GSC на предмет стрибків помилок, оновіть sitemap, подайте зміну адреси, якщо змінився домен, і моніторте логи 404.
Перші тижні — критичні для виправлення дрібних дір, поки старі сигнали ще «живі».
Паралельно звірте конверсії в GA4: інколи форми лишаються на старому endpoint або подія не оновилася після зміни шляху thank-you сторінки.
Повідомте партнерів і афіліатів про нові URL для банерів — зовнішні посилання часто оновлюють повільніше за внутрішні.
Зафіксуйте дату cutover і зберігайте доступ до старого хостингу мінімум місяць для відкочування критичних файлів.
- Запитайте індексацію для ключових URL.
- Перевірте ручні дії в GSC.
- Моніторте позиції та кліки в динаміці.
- Перевірте Analytics події на нових URL.
- Переконайтеся, що рекламні посилання оновлені.
- Перевірте email-шаблони зі старими посиланнями.
- Перевірте зовнішні беклінки на 404.
- Оновіть JSON-LD url поля.
- Перевірте соц OG прев’ю.
- Плануйте пост-аудит через місяць.
- Перевірте Search Appearance для ключових запитів уручну.
- Переконайтеся, що старі UTM-лінки з реклами ведуть на 200, а не на ланцюг редіректів.
- Порівняйте server log 404 зі списком URL зі старого сайту.
- Додайте моніторинг позицій для топ-20 non-brand запитів.
Розробка — SEO-Studio web-development.
Висновок
Міграція — це проєкт з таблицею URL і дисципліною редіректів, а не «переключити DNS». Мінімізуйте ланцюги 301, оновіть внутрішні посилання й уважно пройдіть GSC після запуску. Документуйте винятки та тримайте зв’язок між SEO, розробкою і маркетингом. SEO-Studio допоможе провести міграцію з контролем ризиків для органіки та конверсій.
Критичний успіх — коли через 30 днів немає «сліпих зон» у таблиці URL, а бізнес-сторінки віддають 200 з коректним canonical і стабільними конверсіями. Для цього варто тримати єдиний реєстр змін, регулярно звіряти GSC із логами та не закривати старий хостинг, доки не переконаєтеся, що зовнішній світ оновив посилання.