Гайди
Website migration SEO playbook: redirects, URL mapping і post-launch checks
Покроковий playbook міграції сайту: що ризикує міграція, як зіставити URL і редиректи, чекліст дня запуску і як моніторити відновлення.
Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.
Що насправді ризикує при міграції
Міграція — це будь-яка зміна URL, платформи, домену, протоколу чи шаблонів, які пошуковики вже розуміють. Небезпека не в новому сайті, а в розриві. Google роками накопичував сигнали, привʼязані до твоїх старих URL, і якщо ці URL змінюються без чистого шляху зі старого на нове, ця «вага» опиняється в нікуди.
Майже кожне падіння трафіку після міграції зводиться до тих самих кількох причин: редиректи, яких не було, які утворили ланцюги або вели на не ту сторінку; URL, що тихо зникли; staging-noindex, що потрапив у продакшн; або внутрішні посилання, що досі вказують на стару структуру. Цей playbook про те, як запобігти кожній з них, по порядку.
Перед запуском: зістав і підготуй
- Проскануй поточний сайт і вивантаж кожен indexable URL, а також топ-сторінки за трафіком, посиланнями й конверсіями з аналітики та Search Console.
- Зафіксуй бенчмарк поточного стану: позиції, кількість в індексі, Core Web Vitals і топ-лендінги, щоб потім виміряти відновлення.
- Побудуй нову структуру URL і переконайся, що нові шаблони зберігають title, заголовки, canonical і structured data.
- Перевір, що staging заблокований від індексації (noindex або auth) — і памʼятай, що це треба зняти на запуску.
План URL mapping і редиректів
Карта редиректів — найважливіший результат. Кожен старий URL потребує свідомо обраної цілі.
- Зістав кожен старий URL із найближчим новим еквівалентом — один до одного, де можливо, ніколи не гуртовий редирект на головну.
- Використовуй 301 (постійні) редиректи, щоб сигнали передалися; уникай 302 для постійних переїздів.
- Прибери ланцюги: старий URL має одразу вести на фінальний новий, а не через два-три редиректи.
- Старі URL без нового еквівалента редиректь на найрелевантнішу категорію чи батьківську сторінку, або віддавай 410, якщо контент справді зник.
- Онови внутрішні посилання, canonical і XML sitemap на нові URL — не покладайся на редиректи, щоб приховати старі внутрішні посилання.
Перевірки в день запуску
- Зніми staging-noindex і підтверди, що продакшн-сторінки indexable — це найпоширеніший катастрофічний промах.
- Вибірково перевір редиректи по кожному шаблону: кожен віддає один 301 на живий 200-URL.
- Підтверди, що robots.txt на новому сайті дозволяє crawling і не переніс staging-«Disallow: /».
- Подай новий XML sitemap у Search Console і на короткий час лиши старий доступним, щоб Google знайшов редиректи.
- Переконайся, що canonical, title і structured data коректно рендеряться на живих сторінках.
Помилки, що обвалюють трафік після міграції
- Викотити staging-noindex чи «Disallow: /» у продакшн, деіндексувавши весь сайт за ніч.
- Редиректити все на головну замість page-to-page, що знищує вагу ранжування.
- Лишати ланцюги чи цикли редиректів, що розмивають сигнали й сповільнюють crawling.
- Міняти URL, дизайн, платформу й контент одночасно, тож не зрозуміти, яка зміна спричинила падіння.
Моніторинг після запуску
Очікуй короткого просідання, поки Google переобробляє редиректи; мета — відновлення за тижні, а не постійна втрата. Стеж за crawl stats у Search Console, звітом Page Indexing і покриттям нових URL, і перескановуй сайт, щоб зловити редирект, що зламався, або 404, який ти пропустив.
Проганяй нові URL через DomainLens, щоб підтвердити, що кожна сторінка віддає 200, несе правильний canonical, indexable і тримає Core Web Vitals — ті самі перевірки, що виявляють загублений редирект чи втрачений noindex ще до того, як падіння позицій зʼявиться в аналітиці.