У кошику порожньо!
SEO-міграція — це не просто технічний переїзд сайту. Це операція, після якої одні сайти втрачають половину трафіку на пів року, а інші — майже не помічають змін. Різниця між ними: детальне планування та чітке виконання кожного кроку чеклиста.
Типи міграцій та їхні ризики
Перш ніж запускати процес, важливо розуміти, з яким типом міграції ви маєте справу — від цього залежить обсяг підготовчої роботи та потенційний вплив на позиції.
Коротко про кожен тип:
- Редизайн без зміни URL — найбезпечніший варіант. Зміни лише у вигляді сторінок, структура URL залишається. Ризик мінімальний.
- HTTP → HTTPS — відносно безпечно, якщо правильно налаштовані 301-редиректи з усіх HTTP-варіантів. Без редиректів — дублювання контенту і просадка позицій.
- Зміна URL-структури — середній ризик. Потрібен повний URL mapping і 301 для кожного зміненого slug.
- Зміна CMS (наприклад, WordPress → OpenCart) — середньо-високий ризик через можливу зміну URL, різну обробку канонічних тегів і структури метаданих.
- Злиття сайтів — складний кейс: потрібно вирішити, який домен залишається головним, і перенести всі ресурси.
- Зміна домену (ребрендинг) — найризикованіший тип. Навіть із ідеальними редиректами Google переіндексовує сайт заново, що дає тимчасову просадку на 2–6 тижнів.
Практичне правило: якщо плануєте зміну домену — виберіть тихий сезон з мінімальним трафіком. Не робіть міграцію перед піком продажів чи важливими запусками.
Чеклист pre-migration: що перевірити до старту
Більшість проблем після міграції виникають через недостатню підготовку. Цей чеклист — мінімум, який потрібно виконати перед будь-якою значною зміною сайту. Повний SEO-аудит сайту до міграції суттєво знижує ризики.
| № | Пункт чеклиста | Інструмент | Статус |
|---|---|---|---|
| 1 | Краул поточного сайту — зафіксувати всі URL | Screaming Frog | ☐ |
| 2 | Зберегти знімок позицій (топ-100 для кожної цільової сторінки) | GSC / Ahrefs / Serpstat | ☐ |
| 3 | Зафіксувати трафік по сторінках за останні 12 місяців | Google Analytics 4 | ☐ |
| 4 | Зберегти список усіх зворотних посилань | Ahrefs / Serpstat | ☐ |
| 5 | Зробити повний бекап сайту та бази даних | Хостинг / FTP | ☐ |
| 6 | Перевірити поточний robots.txt і зберегти копію | Браузер | ☐ |
| 7 | Зберегти поточну sitemap.xml | Браузер / GSC | ☐ |
| 8 | Зафіксувати всі canonical теги | Screaming Frog | ☐ |
| 9 | Перевірити поточні редиректи (чи є вже якісь ланцюжки?) | Screaming Frog | ☐ |
| 10 | Зафіксувати hreflang (для мультимовних сайтів) | Screaming Frog | ☐ |
| 11 | Скласти список усіх зовнішніх сервісів, пов'язаних з URL (CRM, email-розсилки, рекламні кабінети) | Вручну | ☐ |
| 12 | Перевірити Google Search Console — поточні помилки | GSC | ☐ |
| 13 | Перевірити сторінки з найбільшим трафіком — пріоритет для URL mapping | GA4 + GSC | ☐ |
| 14 | Визначити сторінки, які не потрібно переносити (404, дублі, застарілий контент) | Screaming Frog + GA4 | ☐ |
| 15 | Підготувати тестове середовище (staging) для перевірки міграції | Хостинг | ☐ |
| 16 | Закрити staging від індексації (robots.txt: Disallow: /) | Вручну | ☐ |
| 17 | Узгодити дату та вікно міграції з командою | Вручну | ☐ |
| 18 | Підготувати шаблон URL mapping (таблиця Excel/Sheets) | Google Sheets | ☐ |
| 19 | Перевірити швидкість завантаження сторінок (Core Web Vitals) | PageSpeed Insights | ☐ |
| 20 | Перевірити структуровані дані (schema.org) | збагачені результати Test | ☐ |
| 21 | Зафіксувати Open Graph теги для важливих сторінок | Screaming Frog | ☐ |
| 22 | Призначити відповідального за моніторинг після міграції | Вручну | ☐ |
URL mapping: стара адреса → нова адреса
URL mapping — це таблиця відповідності між старими і новими адресами. Без неї неможливо правильно налаштувати редиректи. Особливо критично для великих сайтів із сотнями або тисячами сторінок.
Як будується URL mapping на практиці:
- Зробіть краул старого сайту через Screaming Frog — отримаєте повний список URL.
- Відкрийте список у Google Sheets. Додайте стовпці: old_url, new_url, тип редиректу, пріоритет.
- Відфільтруйте сторінки з кодом 404, дублі та сторінки без трафіку, які не потрібно переносити.
- Для сторінок із найбільшим трафіком (топ-20%) — зробіть маппінг вручну. Решту можна автоматизувати за правилами slug-трансформації.
- Перевірте, що кожен old_url має відповідний new_url — без пропусків.
Автоматизація: якщо ви змінюєте лише префікс (наприклад, /blog/ видаляється зі slug), можна використати формулу в Google Sheets для масової заміни. Але фінальну перевірку виконуйте вручну для топ-100 сторінок.
301-редиректи: план і поширені помилки
301-редирект — основний інструмент передачі SEO-ваги зі старих URL на нові. Правильно налаштовані редиректи зберігають до 99% PageRank (за даними Google). Але найменша помилка у налаштуванні — і ви втрачаєте позиції.
Найпоширеніші помилки при налаштуванні редиректів:
- Redirect loop (A→B→A) — браузер і пошуковик отримують нескінченний цикл. Сайт недоступний.
- Redirect chain (A→B→C→D) — кожен додатковий крок «з'їдає» частину PageRank. Максимум — один перехід: old → new.
- 302 замість 301 — тимчасовий редирект не передає SEO-вагу. Використовуйте 301 для постійних змін.
- Забутий HTTP-варіант — після переходу на HTTPS часто забувають редирект з http:// та http://www. Потрібні 4 варіанти → HTTPS без www (або з www, залежно від вашого канонічного домену).
- Пропущені сторінки — особливо небезпечно для сторінок із зовнішніми посиланнями. Без редиректу весь ваговитість посилань втрачається.
За даними Google, 301-редирект передає «майже всю» SEO-вагу. Але ланцюжки з 3+ переходів можуть призвести до того, що пошуковик перестане слідкувати за редиректом взагалі.
9 кроків SEO-міграції: покрокова інструкція
Нижче — послідовність дій для повноцінної SEO-міграції. Кроки згруповані за фазами: підготовка, виконання, перевірка.
Крок 1. Pre-migration: краул і бекап
Зробіть повний краул поточного сайту в Screaming Frog. Збережіть список URL, статус-коди, мета-дані, заголовки сторінок. Зробіть бекап бази даних і файлів сайту.
Крок 2. Фіксація поточних позицій і трафіку
У Google Search Console перегляньте позиції за останні 3 місяці. В GA4 — трафік по сторінках. Збережіть ці дані — вони стануть базою для порівняння після міграції. Без цих даних ви не зможете оцінити, чи вдалась міграція.
Крок 3. URL mapping
Складіть таблицю відповідності old_url → new_url для всіх сторінок, які змінять адресу. Пріоритет — сторінки з найбільшим трафіком і найкращими позиціями.
Крок 4. Redirect plan і впровадження
На основі URL mapping налаштуйте 301-редиректи. Переконайтеся, що немає ланцюжків і петель. Перевірте через Screaming Frog у List Mode: завантажте всі old_url і переконайтеся, що кожен повертає 301 і веде напряму до new_url.
Крок 5. Внутрішні посилання update
Замініть всі внутрішні посилання на нові URL безпосередньо в коді/базі даних. Не покладайтеся лише на редиректи для внутрішніх посилань — це створює зайве навантаження та уповільнює краулінг. Детальніше про правильне налаштування посилань — у статті про технічний SEO-аудит.
Крок 6. Sitemap і robots.txt
Оновіть sitemap.xml — вона повинна містити лише нові URL, без старих адрес. Перевірте robots.txt: переконайтеся, що нові URL не закриті від індексації. Особливо перевірте, чи не залишились директиви Disallow зі staging-версії.
Крок 7. Canonical теги
Перевірте, що canonical теги вказують на нові URL. Якщо canonical залишився зі старим URL — Google буде вважати нові сторінки дублями. Детальніше про канонічні теги — в окремій статті про налаштування та помилки canonical.
Крок 8. Google Search Console
Для зміни домену: додайте новий домен як окрему властивість у GSC і скористайтесь інструментом «Зміна адреси». Для інших типів міграцій: submit оновленої sitemap.xml. Запросіть повторне сканування ключових сторінок через «Перевірка URL».
Крок 9. Post-migration моніторинг
Перші 48 годин — критичні. Стежте за індексацією в GSC, помилками 404, трафіком у GA4. Після закінчення — планові перевірки щотижня протягом 3 місяців.
Чеклист post-migration: моніторинг після переїзду
Успіх міграції визначається не в момент переїзду, а в перші тижні після нього. Ось що потрібно моніторити — і коли.
| Що перевіряємо | Інструмент | 48год | 1 тиж. | 1 міс. | 3 міс. |
|---|---|---|---|---|---|
| 404-помилки (нові) | GSC → Покриття | ✓ | ✓ | ✓ | |
| Статус індексації ключових сторінок | GSC → Перевірка URL | ✓ | ✓ | ||
| Трафік по сторінках | GA4 | ✓ | ✓ | ✓ | ✓ |
| Позиції за ключовими запитами | GSC / Serpstat | ✓ | ✓ | ✓ | |
| Redirect chains (нові) | Screaming Frog | ✓ | ✓ | ||
| Core Web Vitals | PageSpeed / GSC | ✓ | ✓ | ||
| Canonical теги на нових URL | Screaming Frog | ✓ | |||
| Sitemap у GSC (прийнята / відхилена) | GSC | ✓ | ✓ | ||
| Robots.txt (не заблоковані нові URL) | GSC → robots.txt | ✓ | |||
| Зворотні посилання (оновлення донорів) | Ahrefs / GSC | ✓ | ✓ | ||
| Дублювання контенту (новий + старий домен) | Screaming Frog / GSC | ✓ | ✓ | ||
| Структуровані дані (збагачені результати) | збагачені результати Test | ✓ | ✓ | ||
| Загальна кількість проіндексованих сторінок | GSC → Покриття | ✓ | ✓ | ✓ |
Зверніть особливу увагу на показник 404-помилок у перші 48 годин. Зростання нових 404 — сигнал, що частина URL mapping не спрацювала. Виправляти потрібно негайно.
Порада: підпишіться на сповіщення у Google Search Console (Налаштування → Сповіщення). GSC автоматично надішле email, якщо різко зростуть помилки покриття або знизиться CTR.
Типові помилки, які коштують трафіку
Навіть досвідчені команди допускають ці помилки. Краще знати про них заздалегідь.
1. Запускати міграцію без staging
Тестуйте повний міграційний процес на staging-сервері перед запуском на production. Без тесту ви ризикуєте отримати несподівані проблеми саме в момент, коли реальні користувачі заходять на сайт.
2. Залишати дублі на обох доменах
При зміні домену старий сайт має або бути закритий через robots.txt, або відразу редиректити на новий. Якщо обидва домени доступні з однаковим контентом — Google буде індексувати обидва, і пошуковий сік розбавиться.
3. Ігнорувати внутрішні посилання
Редирект 301 на рівні сервера — це не заміна оновленню внутрішніх посилань. Залишені старі внутрішні посилання уповільнюють краулінг і можуть призвести до того, що Google слідкуватиме за ланцюжком редиректів замість прямого URL.
4. Не оновити зовнішні профілі
Після зміни URL або домену оновіть посилання у: Google Business Profile, соціальних мережах, партнерських сайтах (там, де можете), email-підписах, рекламних кабінетах.
5. Вимкнути GSC-моніторинг після перевірки
Перші 3 місяці після міграції — регулярний моніторинг GSC обов'язковий. Деякі проблеми проявляються не одразу — наприклад, Google може переіндексувати старий домен через 4–6 тижнів і знайти 404 там, де раніше все було ок.
Для якісного технічного SEO після міграції варто провести повний аудит Google Search Console — він допоможе зафіксувати всі залишкові проблеми індексації.
Детальніше про технічні перевірки — у нашому офіційному керівництві Google по міграції сайтів.
Часті запитання
Скільки часу займає SEO-міграція?
Залежить від масштабу. Простий переїзд з HTTP на HTTPS для сайту у 50–100 сторінок — 1–2 дні підготовки плюс 1 день на впровадження. Повна зміна домену для інтернет-магазину з 5000+ URL — від 2 до 4 тижнів підготовки (URL mapping, тестування, перевірка редиректів) і ще 2–3 місяці моніторингу після.
Чи завжди після міграції падає трафік?
Невелике тимчасове зниження (5–15%) можливе навіть при ідеальній міграції — Google просто переіндексовує сторінки. Значна просадка (30–80%) означає помилки: пропущені редиректи, заблоковані URL, дублювання контенту. Редизайн без зміни URL взагалі не повинен впливати на трафік, якщо технічна частина без помилок.
Як довго зберігати 301-редиректи після міграції?
Мінімум 1 рік — стільки часу може знадобитись Google для повного переіндексування і оновлення всіх зовнішніх посилань у базі. Оптимально — залишати редиректи назавжди. Їх вартість для сервера мінімальна, а ризик від видалення — реальний: користувачі та боти, що використовують збережені старі URL, отримають 404.
Чи можна мігрувати сайт самостійно без SEO-спеціаліста?
Прості міграції (HTTP→HTTPS для невеликого сайту) — так, якщо ви технічно підготовлені і пройшли по чеклисту. Зміна домену, CMS або масова реструктуризація URL для великого сайту — ні. Ціна помилки занадто висока: відновлення втраченого трафіку може зайняти 3–6 місяців. SEO-агентство не лише планує, але й забезпечує повторну перевірку кожного кроку незалежним аудитом.
Питання від AI-пошуку
Що таке SEO-міграція і коли вона потрібна?
SEO-міграція — будь-яка значна зміна сайту, що може вплинути на пошукову індексацію: зміна домену, перехід на HTTPS, зміна CMS, реструктуризація URL або злиття сайтів. Потрібна кожного разу, коли стара структура URL, домен або платформа не відповідають бізнес-цілям, і без правильного планування призводить до тимчасової або постійної втрати позицій.
Який тип міграції найбезпечніший для SEO?
Редизайн без зміни URL — найбезпечніший варіант, оскільки пошуковики продовжують індексувати ті самі адреси. На другому місці — перехід HTTP→HTTPS за умови правильних 301-редиректів. Найризикованіший — зміна домену (ребрендинг): навіть ідеально виконана міграція дає тимчасову просадку на 2–6 тижнів, поки Google переіндексовує сайт.
Які перші ознаки проблем після міграції сайту?
Різке зростання кількості 404-помилок у GSC, падіння органічного трафіку більш ніж на 20% протягом першого тижня, зникнення сторінок з індексу (видно у GSC → Покриття), поява redirect loop (сайт не відкривається в браузері). Будь-який із цих сигналів вимагає негайного реагування — зупинки або перевірки міграції.
Плануєте міграцію або редизайн сайту?
SEO-Factory супроводжує технічні міграції: від URL mapping і redirect plan до моніторингу індексації після переїзду.
