Перенесення сайту без втрати SEO — це не просто копіювання файлів і бази даних. Потрібно зберегти зв’язок між старими та новими URL, доступність контенту для пошукових систем, внутрішню перелінковку, canonical, hreflang, структуровані дані та інші сигнали, які сайт накопичував до переїзду.
Рівень ризику залежить від сценарію. Заміна хостингу без зміни URL зазвичай простіша за перехід на інший домен. Найскладніший варіант — одночасно змінити домен, CMS, дизайн, структуру адрес і контент. Повністю гарантувати відсутність короткострокових коливань позицій після великої міграції не можна. Мета SEO migration plan — мінімізувати ризик і не створити технічних причин для довгострокового падіння органічного трафіку.
Які зміни вважаються міграцією сайту
- Зміна хостингу без зміни URL. Основні ризики пов’язані з DNS, SSL, конфігурацією сервера, помилками 5xx, швидкістю та випадковим блокуванням роботів.
- Перенесення сайту на новий домен. Змінюються всі адреси, тому потрібні точні постійні редиректи, нові canonical, sitemap і налаштування Search Console.
- Зміна CMS або framework. URL можуть залишитися старими, але змінюються шаблони, HTML, рендеринг, метадані, статус-коди та внутрішні посилання.
- Зміна структури URL. Навіть на тому самому домені адреси стають новими та потребують мапінгу один до одного.
- Редизайн зі збереженням URL. Ризик виникає, якщо нові шаблони прибирають важливий контент, заголовки, навігацію або SEO-атрибути.
- Повна заміна старого сайту новим. Потрібно зіставити не лише сторінки, а й функції, категорії, фільтри, мовні версії та медіафайли.
- Одночасна зміна домену, CMS, структури й дизайну. Це найскладніший сценарій: після запуску важче визначити, яка саме зміна спричинила проблему.
Практичний принцип із рекомендацій Google Search Central: за можливості не поєднувати всі великі зміни в один запуск. Наприклад, спочатку перенести домен зі збереженням структури та контенту, стабілізувати індексацію, а вже потім проводити редизайн або перебудову каталогу.
SEO-міграція сайту: що зібрати до перенесення
До розробки редиректів зафіксуйте baseline — стан, з яким порівнюватимете новий сайт. Повний список URL не можна отримати лише з XML sitemap: у ньому можуть бути відсутні старі матеріали, сторінки з параметрами, осиротілі URL або адреси, які досі отримують переходи.
Для великого проєкту об’єднайте дані sitemap, SEO-краулера, CMS, Google Search Console, вебаналітики та server logs. Для кожного доступного URL бажано зберегти:
- status code, indexability, meta robots і X-Robots-Tag;
- title, description, H1, важливі H2 та основний контент;
- canonical, hreflang і structured data;
- вхідні й вихідні внутрішні посилання;
- органічні кліки, покази, позиції та посадкові сторінки;
- сторінки з відвідуваннями за даними аналітики;
- URL, на які ведуть важливі зовнішні посилання;
- медіафайли, зображення та їхні alt-описи.
Окремо зробіть резервну копію файлів, бази даних, серверних конфігурацій і чинних правил редиректів. Це не замінює SEO-аудит, але дає можливість відновити попередній стан у разі критичної технічної помилки.
Як створити URL mapping
URL mapping — центральний документ міграції. Для кожної важливої старої адреси вкажіть найбільш релевантну нову. Відповідність має враховувати зміст і намір користувача, а не лише схожість слів у slug.
| Старий URL | Новий URL | Старий статус | Новий статус | Redirect | Canonical | Трафік | Backlinks | Перевірено |
|---|---|---|---|---|---|---|---|---|
| example.com/old-page | newdomain.com/new-page | 200 | 200 | 301 | На новий URL | Є | Є | Після запуску |
| example.com/old-category | newdomain.com/category | 200 | 200 | 308 | На новий URL | Є | Немає | Після запуску |
| example.com/outdated-page | Немає заміни | 200 | 410 | Немає | Немає | Немає | Немає | Після запуску |
Не перенаправляйте сотні різних матеріалів на головну сторінку. Якщо нова сторінка справді об’єднує та замінює кілька старих, редирект на неї може бути логічним. Якщо еквівалента немає і контент видалено без заміни, коректніше повернути справжній 404 або 410.
301 і 308 редиректи під час міграції
Постійні та тимчасові перенаправлення
Для постійного перенесення використовуйте server-side редирект 301 або 308. Обидва повідомляють про постійну зміну адреси; 308 додатково зберігає HTTP-метод запиту. Для звичайних сторінок із GET-запитами вибір часто залежить від серверної конфігурації. Редиректи 302 і 307 призначені для тимчасових змін, тому не варто використовувати їх як стандартне рішення для постійного переїзду.
Правильна схема виглядає так: example.com/old-page → 301 → newdomain.com/new-page. Перевіряйте не лише наявність правила, а й кінцевий статус 200, правильний протокол, домен, регістр, слеші та параметри URL.
Ланцюжки та цикли редиректів
Стара адреса має вести одразу на фінальну: old URL → final URL. Ланцюжки через проміжні версії збільшують кількість запитів і ускладнюють діагностику. Цикли роблять сторінку недоступною. Постійні редиректи не слід прибирати одразу після переіндексації: зберігайте їх максимально довго, особливо для URL із зовнішніми посиланнями та прямими переходами.
Що зберегти на нових сторінках
Якщо переоптимізація не є окремою метою проєкту, нова сторінка повинна максимально зберегти пошуковий намір, основний контент, title, H1, важливі H2, внутрішні посилання, structured data, alt, canonical, hreflang, медіафайли, CTA та ключові UX-функції.
Не скорочуйте сильну органічну сторінку в кілька разів лише тому, що макет краще виглядає з коротким текстом. Спочатку перенесіть цінний зміст і функціональність, а зміни перевіряйте окремо. Під час переходу з WordPress на Next.js або інший JavaScript framework переконайтеся, що SEO-критичний контент, посилання й метадані доступні в HTML, а сервер повертає реальні статус-коди.
Canonical, robots.txt і XML sitemap
Canonical на нових URL
Кожна нова indexable сторінка зазвичай повинна мати self-referencing canonical на свою актуальну адресу. Після деплою перевірте, чи не залишилися canonical на staging, старому домені, HTTP-версії або попередній структурі URL. Редирект і canonical мають узгоджено вказувати на фінальну сторінку.
Небезпечні блокування після staging
Одна з найкритичніших помилок — перенести на production заборону, якою тестове середовище закривали від індексації. Перед запуском і відразу після нього перевірте robots.txt, meta robots, X-Robots-Tag та фактичну доступність сторінок для Googlebot. Закритий у robots.txt URL не стає надійно деіндексованим лише через цю заборону, а noindex не спрацює, якщо робот не може прочитати сторінку.
Новий XML sitemap
Sitemap після міграції має містити лише актуальні canonical URL зі статусом 200 на новому домені або в новій структурі. Не залишайте в ньому адреси з 301, 404, 410 чи noindex. Для мультимовного сайту перевірте актуальність hreflang URL. Після запуску подайте sitemap у відповідну властивість Google Search Console.
Внутрішні посилання, hreflang і structured data
Внутрішні посилання повинні вести безпосередньо на фінальні URL, а не проходити через редиректи. Проскануйте меню, breadcrumbs, footer, блог, пов’язані матеріали, CTA, картки товарів, категорії та HTML sitemap.
Для структури з мовними версіями на кшталт /ua/ та /en/ оновіть усі hreflang-анотації та перевірте взаємність: українська сторінка посилається на відповідну англійську, а англійська — назад. Canonical кожної мовної сторінки не повинен помилково вести на іншу мову.
У розмітці Organization, BreadcrumbList, Article, Product, Service та інших доречних типів schema.org замініть старі URL. FAQ-розмітку використовуйте лише там, де питання й відповіді видимі користувачеві та відповідають актуальним правилам Google.
Перенесення на інший хостинг без зміни домену
Якщо адреси не змінюються, масова карта 301 не потрібна, але технічна підготовка залишається обов’язковою:
- створіть backup файлів і бази даних та перевірте можливість відновлення;
- підніміть копію на новому сервері й протестуйте її до перемикання DNS;
- звірте версії PHP або Node.js, бази даних, бібліотек і системних залежностей;
- перенесіть environment variables, cron-задачі, email-конфігурацію та файлові права;
- налаштуйте SSL, редиректи між HTTP і HTTPS, www та non-www;
- перевірте кеш, CDN, завантаження медіа, форми, авторизацію та інтеграції;
- контролюйте 4xx, 5xx, DNS і server logs після перемикання.
Стару інфраструктуру не вимикайте до завершення перемикання та перевірки нового сервера. Change of Address у Search Console для такого сценарію не потрібний, адже публічні URL не змінюються.
Порядок запуску нової версії
- Завершіть інвентаризацію URL і погодьте mapping між SEO, розробкою та контент-командою.
- Проскануйте staging і порівняйте його з baseline: контент, статуси, метадані, canonical, hreflang, schema та посилання.
- Перед релізом зафіксуйте зміни контенту, щоб нові сторінки не загубили останні оновлення старого сайту.
- Розгорніть production, активуйте редиректи та приберіть staging-блокування.
- Перевірте пріоритетні URL вручну й автоматичним краулером, включно з мобільними шаблонами та мовними версіями.
- Оновіть XML sitemap, Search Console, аналітику, рекламні посадкові сторінки й системи моніторингу.
Для зміни домену заздалегідь підтвердьте права на стару та нову властивості Search Console. Інструмент Change of Address використовують для реального переїзду між доменами або субдоменами після налаштування редиректів. Він не замінює URL mapping і не потрібний для звичайної зміни хостингу, переходу HTTP → HTTPS або перебудови шляхів у межах того самого домену.
Зовнішні посилання та контроль після запуску
301 або 308 допомагає пошуковим системам пов’язати стару сторінку з новою, але для найцінніших backlinks варто, де це можливо, попросити власника ресурсу оновити посилання безпосередньо. Це прибирає залежність від редиректу та зменшує ризик втрати переходів у майбутньому.
Після запуску порівнюйте з baseline органічні кліки, покази, посадкові сторінки, статус індексації, помилки сканування та серверні відповіді. Враховуйте сезонність, попит і паралельні зміни сайту. Окремо контролюйте сторінки з найбільшим трафіком і зовнішніми посиланнями.
- Якщо старі URL залишаються в пошуку, перевірте редиректи, canonical і sitemap.
- Якщо просідає лише один шаблон, порівняйте контент, HTML, метадані, рендеринг і перелінковку.
- Якщо проблеми охопили весь сайт, перевірте robots, noindex, DNS, SSL, 5xx і продуктивність сервера.
- Якщо плутаються мовні сторінки, перевірте hreflang, canonical та взаємні мовні посилання.
Міграційні роботи варто відокремлювати від подальшого розвитку органічного каналу. Під час планування наступного бюджету матеріал про те, скільки коштує просування сайту, допоможе розділити разові витрати на переїзд і регулярні SEO-роботи.
Коли міграцію можна вважати технічно завершеною
Реліз не завершується в момент перемикання домену або DNS. Технічно контрольована міграція означає, що важливі старі URL ведуть прямо на релевантні нові сторінки, indexable URL повертають 200, внутрішні посилання та SEO-атрибути оновлені, блокувань немає, а команда регулярно перевіряє дані Search Console, аналітики, краулера й серверних логів.
Найкращий спосіб зберегти позиції — не шукати одну чарівну настройку, а керувати міграцією як окремим проєктом із baseline, відповідальними людьми, URL mapping, передрелізним тестуванням і післярелізним моніторингом.
