Сам факт переїзду сайту на інший сервер, CMS або домен ще не створює SEO-проблеми. Проблеми починаються тоді, коли після змін пошукова система перестає правильно співвідносити старі сторінки з новими.
URL, який роками отримував органічний трафік, зовнішні посилання та стабільно ранжувався за потрібними запитами, після невдалої міграції може перетворитися на 404. Або отримати redirect на сторінку зовсім іншої тематики. Або залишитися доступним, але втратити контент, internal links чи правильний canonical. Технічно новий сайт при цьому може працювати бездоганно — проблема проявиться вже у пошуку.
Саме тому site migration SEO — це не стільки перенесення сайту, скільки контрольоване передавання накопичених сигналів зі старої структури до нової. Потрібно зберегти зв’язок між URL, контентом, search intent, внутрішніми посиланнями, backlinks, canonical та іншими сигналами, за якими Google уже розуміє сторінки.
Якщо цей зв’язок продуманий до запуску, міграцією можна керувати. Якщо SEO підключається вже після того, як нова версія пішла в production, команда часто переходить від планового перенесення до пошуку того, що було втрачено.
Міграція сайту — це суттєва технічна зміна, яка впливає на домен, URL, платформу, інфраструктуру або спосіб, у який пошукові системи знаходять та індексують сторінки.
Рівень SEO-ризику залежить не від слова «міграція», а від того, що саме змінюється.
Наприклад, перенесення сайту на новий хостинг без зміни URL насамперед створює інфраструктурні ризики: downtime, проблеми з DNS, server responses, CDN або доступом crawler. Під час переходу на новий домен пошуковій системі вже потрібно зіставити стару й нову версії великої кількості сторінок. А зміна CMS може одночасно зачепити URL, metadata, canonical, internal linking, sitemap, schema та rendering.
До website migration зазвичай належать:
зміна домену;
зміна структури URL;
перехід із HTTP на HTTPS;
зміна CMS або ecommerce-платформи;
зміна хостингу;
об’єднання кількох сайтів;
суттєва перебудова архітектури.
Наприклад, стара адреса /catalog/product.php?id=123 після переходу на іншу платформу може стати /products/product-name/. Для людини це все ще той самий товар. Для пошукової системи це вже інший URL, і зв’язок між ними потрібно правильно показати.
Редизайн передусім змінює інтерфейс, UX, візуальне оформлення або шаблони сторінок. Він може пройти без будь-якої зміни URL.
Міграція працює з технічною або адресною структурою сайту й може взагалі не бути помітною користувачеві. Наприклад, сайт переходить на іншу CMS, але зовні майже не змінюється.
Складнішим стає сценарій, коли обидва процеси відбуваються одночасно. Разом із новим дизайном команда змінює домен, URL-структуру, CMS, навігацію, контент та інформаційну архітектуру. Якщо після запуску просідає органічна видимість, доводиться перевіряти одразу багато потенційних причин.
Тому масштабні зміни варто розділяти там, де це дозволяє проєкт. Це не тільки зменшує ризик, а й робить подальшу діагностику значно зрозумілішою.
Пошукова система не знає внутрішньої логіки вашого проєкту. Для команди очевидно, що стара сторінка послуги та її нова версія — одна сутність. Google потрібно отримати достатньо сигналів, щоб дійти такого самого висновку.
Зв’язок може розірватися, якщо старі URL почали повертати 404, redirects ведуть не туди, важливий контент не перенесли або нова сторінка перестала відповідати search intent старої.
До цього додаються менш помітні технічні проблеми: canonical на старий домен, noindex із тестового середовища, sitemap із неправильними URL, заблоковані через robots.txt сторінки, зламаний hreflang, зникла schema або internal links, які продовжують вести на старі адреси.
Ще один ризик — зовнішні посилання. Старий URL може давно не бути важливим для внутрішньої навігації, але мати backlinks із сильних ресурсів. Якщо під час міграції про нього забути, частина накопиченої цінності просто не отримає логічного продовження.
Тому SEO migration потрібно планувати як систему пов’язаних змін, а не як окреме завдання «налаштувати 301».
Починати перенесення без SEO baseline ризиковано. Якщо після запуску щось зміниться, команді буде нічого порівнювати з новими показниками.
Перед міграцією потрібно зафіксувати не тільки загальний organic traffic, а й структуру старого сайту.
Перший крок — повний crawl. Варто зберегти URL, status codes, canonical, title, H1, meta robots, hreflang, internal links і structured data. Цей файл стане контрольним знімком, з яким можна порівнювати новий сайт.
У Search Console потрібно зафіксувати clicks, impressions, ключові landing pages, запити, дані про індексацію та наявні проблеми. В Analytics особливо важливі organic landing pages, conversions, revenue та ecommerce data.
Для стратегічних комерційних сторінок корисно окремо зберегти позиції. Ще один шар даних — backlinks, насамперед для URL, які мають сильні зовнішні посилання.
Такий baseline потрібен не для красивого звіту «до/після». Він дозволяє після запуску швидко відрізнити реальну втрату SEO від природних коливань, сезонності або, наприклад, поламаного tracking.
Одна з типових помилок — будувати redirect map зі сторінок, які зараз видно в меню.
Так легко загубити старі landing pages, товари, категорії, статті, сторінки попередніх кампаній або URL, які давно зникли з навігації, але все ще отримують трафік чи мають backlinks.
Тому URL inventory збирають із кількох джерел: crawl, sitemap, Search Console, Analytics, backlink data, CMS або database. Для великих і складних сайтів до цього можна додати server logs.
Різні джерела майже завжди дають різні набори адрес. У crawl може не бути orphan page, у sitemap — давно видаленої сторінки, а в Analytics — URL без актуального трафіку, на який усе ще ведуть сильні зовнішні посилання.
Завдання цього етапу не в тому, щоб зберегти абсолютно кожну адресу. Спочатку потрібно побачити весь старий сайт, а вже потім вирішувати, що саме має перейти в нову структуру.
Після інвентаризації для кожного старого URL визначається його подальша доля.
Базова логіка виглядає так:
Old URL → New URL → Action
Наприклад:
/old-service/ → /services/new-service/ → permanent redirect
Якщо сторінку остаточно видаляють і релевантної заміни немає:
/old-page/ → немає нового аналога → 404 або 410
Саме URL mapping є одним із центральних етапів SEO-міграції. Тут вирішується, чи отримає стара сторінка логічне продовження в новій структурі.
Destination потрібно вибирати не за принципом «куди можна перекинути цей URL», а за максимально близьким змістом і search intent.
Якщо стара сторінка була присвячена SEO-аудиту, головна сторінка агентства не стає її повноцінною заміною лише тому, що обидві належать одному домену. Значно сильнішим рішенням буде нова сторінка SEO-аудиту або найближча за змістом послуга.
Саме тому схема «1000 старих сторінок → homepage» не є нормальною стратегією міграції.
Для постійного перенесення URL використовують server-side permanent redirects, зокрема 301 або 308.
Немає сенсу будувати весь процес навколо старого твердження, що «тільки 301 передає SEO-вагу». Для міграції важливіше інше: перенаправлення має бути постійним, прямим, технічно коректним і вести на релевантний новий URL.
Окремо потрібно перевірити redirect chains.
Замість:
A → B → C → D
краще:
A → D
Довгі ланцюжки створюють зайві запити, сповільнюють перехід і ускладнюють діагностику. Особливо часто вони накопичуються на доменах, які вже проходили кілька великих змін.
Ще одна критична помилка — redirect loop, наприклад A → B → A. У такому випадку сторінка фактично стає недоступною і для користувача, і для crawler.
Водночас redirect потрібен не завжди. Якщо стара сторінка остаточно видалена, не має релевантної заміни й не повинна існувати на новому сайті, 404 або 410 може бути цілком правильним результатом.
Не кожен 404 — SEO-помилка. Помилка — втратити цінний URL, для якого насправді існує логічне продовження.
Навіть ідеальний redirect не врятує сторінку, якщо після міграції змінився її зміст.
Припустімо, стара /seo-audit/ стабільно ранжувалася за запитами, пов’язаними з SEO-аудитом. У новій структурі її перенаправили на сторінку з абстрактним описом «комплексного цифрового розвитку», де аудит згаданий побіжно.
Технічне перенаправлення працює. Тематичне продовження — ні.
Тому разом з URL mapping потрібно робити content mapping. Для важливих сторінок перевіряють основну тему, search intent, ключовий зміст, metadata та структуровані елементи.
Це не означає, що під час website migration потрібно назавжди заморозити старий контент. Його можна покращувати, об’єднувати або перебудовувати. Просто такі зміни вже є окремим фактором, і їх потрібно враховувати під час оцінки результату.
Redirects повідомляють, куди переїхали старі URL. Але новий сайт повинен і сам послідовно використовувати нову структуру.
На нових сторінках canonical має вести на актуальні canonical URL.
Після запуску потрібно перевірити, чи не залишилися canonical на старий домен або staging, чи не ведуть HTTPS-сторінки на HTTP і чи не канонікалізується велика кількість нових URL на одну випадкову адресу.
Ці помилки легко розмножуються на сотні сторінок, якщо проблема закладена в шаблон CMS.
Внутрішні посилання після міграції повинні вести безпосередньо на нові URL.
Схема:
internal link → old URL → redirect → new URL
технічно працює, але залишає в структурі сайту непотрібний проміжний крок.
Після migration краще отримати:
internal link → new URL.
Так сайт швидше переходить на нову адресну систему, а crawler не витрачає зайві запити на старі сторінки.
Новий sitemap має відображати актуальну структуру сайту: canonical, indexable URL зі статусом 200.
Redirects, 404, noindex і старі неактуальні адреси не повинні залишатися в основному sitemap.
Для великих переїздів старий sitemap іноді можна використовувати тимчасово як додатковий спосіб спостереження за старими URL. Але це не змінює головної вимоги: актуальний sitemap повинен правильно описувати новий сайт.
Проблеми з indexability особливо неприємні тим, що користувач може їх узагалі не помітити.
Сайт відкривається. Форми працюють. Сторінки виглядають правильно. Але production успадкував правила staging, які обмежують crawling або індексацію.
Перед launch потрібно перевірити robots.txt: важливі каталоги не повинні бути заблоковані, потрібні для rendering CSS і JS мають залишатися доступними, а sitemap reference — вести на актуальний файл.
Окремої перевірки потребує noindex.
Для тестового середовища ця директива може бути нормальною. Для production — критичною помилкою, якщо indexable сторінки випадково залишилися закритими.
Саме тому перевірка indexability повинна входити в launch checklist, а не виконуватися через кілька днів після запуску.
Мультимовні сайти мають ще один рівень залежностей — hreflang.
Після зміни домену або URL потрібно перевірити всі мовні версії, reciprocal references, canonical, нові paths та x-default, якщо він використовується.
Проблема з hreflang не завжди виглядає як очевидна технічна помилка. Сторінки залишаються доступними й можуть індексуватися, але пошукова система отримує неправильні сигнали щодо регіональних або мовних відповідностей.
Після CMS migration також варто повторно перевірити structured data. Organization, Product, Breadcrumb, Article, LocalBusiness, Video та інші типи schema нерідко зникають не через окреме рішення, а просто тому, що новий шаблон їх більше не генерує.
Переїзд на інший домен — один із сценаріїв, де недостатньо просто зв’язати дві головні сторінки.
Якщо старий сайт мав:
oldsite.ua/services/seo/
а новий отримав:
newsite.ua/seo/
потрібно створити відповідність саме між цими сторінками.
Так само опрацьовуються категорії, товари, статті та інші URL, які мають продовження на новому домені.
Після запуску та перевірки redirects для відповідного типу доменного переїзду використовується Change of Address у Search Console. Стару й нову properties при цьому продовжують контролювати паралельно.
Change of Address не є універсальним інструментом для будь-якої міграції. Він не потрібен для переходу HTTP → HTTPS або звичайної зміни шляхів у межах того самого домену.
Під час доменного переїзду також потрібно врахувати всі фактичні варіанти домену, зокрема www і non-www, щоб у схемі перенесення не залишилося неврахованих версій.
HTTP → HTTPS теж є зміною URL, хоча в адресі змінюється лише протокол.
Потрібно перевірити SSL certificate, HTTPS redirects, canonical, internal links, sitemap і hreflang. Окрема зона ризику — mixed content, коли сама сторінка вже працює через HTTPS, але частина зображень, JS, CSS або інших ресурсів продовжує завантажуватися через HTTP.
Change of Address для такого переходу не використовується.
Якщо домен і адреси сторінок залишаються незмінними, URL-сигнали переносити не потрібно. Проте виникають інші ризики.
Сайт може бути недоступним під час DNS-перемикання, новий сервер може повільно відповідати або некоректно обробляти окремі статуси. CDN чи WAF іноді випадково обмежують доступ crawler, а частину ресурсів можуть просто не перенести.
Тому під час hosting migration основна задача — забезпечити стабільність:
мінімізувати downtime;
правильно налаштувати DNS;
перевірити server responses;
зберегти HTTPS;
перевірити CDN і WAF;
переконатися, що Googlebot не заблокований;
протестувати навантаження.
Це простіший сценарій із погляду URL migration, але він усе одно може впливати на crawling і доступність сайту.
WordPress, Shopify, Magento, WooCommerce чи custom CMS самі по собі не визначають SEO-результат.
Наслідки виникають через те, що разом із платформою можуть змінитися правила генерації URL, metadata, pagination, filters, canonical, hreflang, structured data, sitemap, internal linking або спосіб rendering.
Наприклад, стара CMS могла створювати одну indexable сторінку категорії, а нова — десятки URL з параметрами фільтрації. Або після переходу на інший шаблон може зникнути Product schema, хоча самі товарні сторінки зовні майже не змінилися.
Тому перед CMS migration потрібно порівнювати не бренди платформ, а конкретну SEO-поведінку старої та нової систем.
Інтернет-магазин має значно більше типів сторінок і технічних взаємозв’язків, ніж типовий корпоративний сайт.
Окрім категорій та product URLs, потрібно контролювати discontinued products, variants, filters, faceted navigation, pagination, inventory, reviews і product schema. Не менш важливо протестувати checkout та ecommerce tracking.
Особливу увагу варто приділити фільтрам. Нова платформа може непомітно створити тисячі indexable комбінацій або, навпаки, закрити сторінки, які раніше збирали органічний попит.
Тому ecommerce migration не варто зводити до таблиці redirects. Це одночасно робота зі структурою каталогу, indexation, crawling, товарними даними та аналітикою.
Більшість технічних помилок дешевше знайти до запуску.
Новий сайт потрібно протестувати на staging, але саме середовище не повинно потрапляти в індекс. Для його захисту надійніше використовувати authentication або password protection, а не сподіватися лише на directives для crawler.
Перед launch варто зробити crawl нової версії та порівняти його зі старим сайтом.
Особливо дивимося на:
кількість і типи URL;
indexability;
status codes;
redirects;
title та H1;
canonical;
noindex;
internal links;
hreflang.
Саме на цьому етапі часто видно, що частина важливих сторінок не потрапила в нову структуру, змінилася логіка canonical або CMS генерує не ті URL, які очікувала SEO-команда.
У день launch не повинні вперше вирішуватися питання URL mapping або структури redirects. Ці рішення мають бути підготовлені й протестовані раніше.
Перед перемиканням команда перевіряє наявність backup, фінального URL mapping, redirect rules, коректних налаштувань analytics, Search Console, sitemap, robots.txt, DNS та SSL.
Після запуску важливо якомога швидше зробити production crawl. Саме він покаже реальну версію сайту, а не те, що планувалося на staging.
Потрібно перевірити redirects, robots.txt, indexability, canonical, sitemap, analytics, ключові форми, checkout та основні комерційні URL.
Пріоритетні сторінки краще визначити заздалегідь. Якщо сайт великий, немає сенсу в перші години вручну відкривати тисячі URL, поки найважливіші категорії або landing pages залишаються неперевіреними.
Після launch починається етап monitoring.
У Search Console потрібно стежити не лише за загальними clicks та impressions, а й за тим, що відбувається зі сторінками.
Корисно контролювати:
indexing;
помилки сторінок;
обробку sitemap;
URL Inspection для критичних URL;
clicks та impressions;
запити;
основні organic landing pages.
Під час domain migration особливо важливо не забувати про стару property. Вона допомагає побачити, як змінюється активність старих URL і чи переходить видимість до нового домену.
Загальні цифри також можуть приховувати проблему. Якщо одна група сторінок різко втратила impressions, а інша виросла, загальний графік домену може виглядати відносно стабільно. Тому стратегічні кластери краще аналізувати окремо.
Нові 404 після launch можуть допомогти знайти прогалини в mapping.
Серед них можуть бути старі URL, які команда не врахувала, broken internal links, неправильні redirects або зовнішні посилання на сторінки без нового аналога.
Але пріоритет визначається не кількістю 404, а цінністю конкретних адрес.
404 на технічному URL, який ніколи не мав трафіку й не повинен існувати, та 404 на старій landing page з backlinks і стабільними organic clicks — зовсім різні задачі.
Тому аудит 404 після міграції краще поєднувати з даними Search Console, Analytics і backlinks.
Для великих сайтів server logs можуть дати додатковий рівень контролю.
За ними видно, чи продовжує Googlebot регулярно звертатися до старих URL, чи проходить через redirects, які частини нового сайту він уже активно crawl-ить і де отримує server errors.
На великому ecommerce-сайті це допомагає швидше зрозуміти, як фактично відбувається перехід між структурами, особливо якщо кількість URL вимірюється десятками або сотнями тисяч.
Для невеликого корпоративного сайту log analysis може бути зайвим. Там ті самі проблеми часто можна знайти простішими інструментами.
Так, після великої міграції можливі коливання, особливо якщо змінюється домен або значна частина URL.
Але тут важливо не створювати штучних нормативів. Не існує універсального правила, що «падіння на 10–20% є нормальним» або що видимість обов’язково повинна повністю повернутися через конкретну кількість тижнів.
Результат залежить від масштабу сайту, типу migration, кількості змінених URL, якості mapping і redirects, crawl frequency та того, наскільки сильно разом із технічною частиною змінився контент.
Тому дивитися потрібно на процес: чи знаходить Google нові сторінки, чи працюють redirects, чи індексуються потрібні URL, як переміщуються impressions і clicks та що відбувається з пріоритетними landing pages.
Невелике коливання й системна проблема мають різні ознаки.
Детальна діагностика потрібна, якщо після запуску одночасно з’являються такі сигнали:
різке падіння organic traffic;
зникнення важливих URL з індексу;
проблеми з індексацією нових сторінок;
велика кількість redirect errors;
зростання 404 на цінних URL;
неправильні Google-selected canonical;
падіння impressions старої версії без відповідного переходу на нову;
зникнення conversions після перенесення.
Останній пункт особливо важливий. Падіння конверсій ще не доводить, що міграція пошкодила SEO. Спочатку потрібно переконатися, що сама система вимірювання продовжує працювати.
Після domain migration стара версія продовжує виконувати важливу функцію.
На старі URL можуть приходити користувачі з bookmarks, переходи з зовнішніх ресурсів та Googlebot. Саме через старий домен працюють redirects, які спрямовують ці запити на нові адреси.
Якщо домен вимкнути занадто рано, разом із ним перестане працювати й цей міст між старою та новою структурою.
Не варто підміняти це правило випадковим строком на кшталт «залишити домен на 30 днів». Тривалість підтримки залежить від конкретного переїзду й того, як довго старі адреси залишаються частиною реального вебу.
Permanent redirects залишаються необхідними незалежно від того, чи вдалося оновити зовнішнє посилання.
Водночас для найцінніших backlinks є сенс звернутися до власників ресурсів і попросити замінити стару адресу на нову. Насамперед це стосується сильних медіа, партнерських сайтів, профільних каталогів та інших джерел, які мають значення для проєкту.
Не потрібно перетворювати це на кампанію з ручного оновлення кожного старого посилання. Пріоритет — ресурси, де пряме посилання справді має цінність.
Найважчий для контролю сценарій виглядає приблизно так:
новий домен + нова CMS + нова URL-структура + новий дизайн + новий контент + нова архітектура.
Іноді бізнесові причини справді змушують об’єднати ці зміни. Але кожна з них додає окремий шар ризику.
Якщо після launch падає видимість, потрібно зрозуміти: проблема в redirects, новому контенті, internal linking, indexation, CMS чи повністю перебудованій структурі?
Чим менше незалежних параметрів змінюється одночасно, тим легше контролювати результат, діагностувати проблему та за потреби виконати rollback.
SEO може пройти правильно, але звітність покаже катастрофу, якщо після запуску перестали працювати події або інтеграції.
Тому після міграції окремо перевіряють GA4, GTM, Google Ads conversions, ecommerce events, форми, call tracking, CRM integrations, referral exclusions і cross-domain tracking, якщо він використовується.
Особливо часто measurement змінюється разом із CMS, checkout або логікою форм.
Якщо раніше замовлення відправляло ecommerce event, а після запуску воно перестало це робити, Analytics покаже зникнення revenue навіть за стабільного трафіку й реальних продажів.
Без цього контролю команда може кілька днів шукати SEO-проблему, якої насправді немає.
Щоб не тримати всі залежності в голові, процес варто розділити на три етапи.
зробити crawl старого сайту;
зафіксувати Search Console та Analytics baseline;
зберегти важливі rankings;
зібрати backlinks;
сформувати повний URL inventory;
підготувати URL mapping;
визначити redirect plan;
зробити content mapping;
сформувати технічні SEO-вимоги до нового сайту.
зробити crawl staging;
протестувати redirects;
перевірити canonical та indexability;
перевірити robots.txt і sitemap;
протестувати hreflang;
перевірити structured data;
перевірити analytics;
протестувати mobile version і performance.
зробити production crawl;
провести redirect audit;
перевірити Search Console;
проконтролювати sitemap;
аналізувати 404 і server errors;
відстежувати indexing;
порівнювати rankings та organic traffic;
контролювати conversions.
Це не просто список технічних задач. Етапи мають виконуватися саме в такій логіці, тому що кожен наступний спирається на дані попереднього.
Більшість проблем після website migration виникає не через одну екзотичну технічну помилку. Частіше накопичується кілька простіших недоліків.
Команда не збирає повний список старих URL, а потім налаштовує redirects лише для сторінок із меню. Старі сторінки масово ведуть на homepage. Частина важливого контенту не переноситься. З’являються redirect chains. Canonical залишаються на старий домен, у sitemap потрапляють redirects, а internal links продовжують вести на попередні URL.
Після зміни CMS можуть зникнути hreflang або structured data. Після staging на production іноді потрапляє noindex. А якщо паралельно не перевірити Analytics і conversions, до реальної SEO-проблеми додається ще й недостовірна звітність.
Окрема категорія ризику — передчасне вимкнення старого домену та одночасна зміна надто великої кількості елементів без потреби.
Хороший migration checklist потрібен саме для того, щоб ці невеликі рішення не перетворилися разом на одну велику проблему.
Міграцію не можна вважати завершеною лише тому, що новий сайт відкривається, SSL працює, а старі сторінки кудись перенаправляються.
SEO migration має зберегти логічне продовження того, що вже було створено на старому сайті: релевантність сторінок, зв’язки між URL, internal linking, canonical signals, backlinks і зрозумілу пошуковій системі структуру.
Тому нормальний процес виглядає так:
інвентаризація → URL mapping → redirects → технічна перевірка → launch → monitoring.
І найбезпечніший момент для SEO-фахівця приєднатися до міграції — не після падіння трафіку, а до того, як структура нового сайту остаточно затверджена.
Міграція сайту — це суттєва технічна зміна домену, URL, CMS, інфраструктури або іншої частини сайту, яка може вплинути на crawling та індексацію. З погляду SEO важливо не тільки перенести сам сайт, а й правильно пов’язати старі сторінки з новими.
Ризик можна суттєво зменшити завдяки правильній підготовці: зібрати всі старі URL, зафіксувати baseline, створити URL mapping, налаштувати релевантні permanent redirects і перевірити новий сайт до та після launch. Але гарантувати повну відсутність будь-яких коливань після великої міграції некоректно.
Потрібно зіставити старі URL з новими, налаштувати permanent redirects, оновити canonical, internal links і sitemap, перевірити обидві properties у Search Console та контролювати індексацію після запуску. Для відповідного типу доменного переїзду також використовується Change of Address.
Ні. Permanent redirect потрібен, коли для старої сторінки існує релевантна нова адреса. Якщо контент остаточно видалено й відповідного аналога немає, 404 або 410 може бути правильнішим рішенням, ніж штучне перенаправлення.
Масове перенаправлення на homepage не створює коректної відповідності між старим і новим контентом. Для кожного цінного URL краще знайти найближчий за змістом та intent новий аналог.
Так. Основний актуальний sitemap повинен містити нові canonical indexable URL зі статусом 200. Старі сторінки, redirects, 404 та noindex не повинні залишатися в ньому як частина актуальної структури.
Інструмент використовується для відповідних сценаріїв переїзду між доменами або субдоменами після того, як новий сайт уже працює й налаштовано redirects. Для переходу HTTP → HTTPS або звичайної зміни URL усередині того самого домену він не потрібен.
Єдиного строку немає. На швидкість впливають розмір сайту, кількість URL, тип міграції, частота crawling, redirects та масштаб інших змін. Тому краще відстежувати реальний перехід indexing, impressions і clicks, а не чекати на умовний день, коли «міграція повинна завершитися».
Певні коливання можливі, особливо під час масштабної зміни URL або домену. Проте універсального «нормального відсотка падіння» немає. Різке зникнення важливих сторінок, проблеми з індексацією або тривала втрата видимості потребують діагностики.
Потрібно порівняти старий і новий crawl, перевірити redirects, canonical, indexability, sitemap, 404, Search Console, organic landing pages, rankings і conversions. Для великого сайту також корисний аналіз server logs.
Універсального короткого строку немає. Старий домен має залишатися доступним достатньо довго, щоб redirects продовжували працювати для пошукових систем, користувачів, backlinks та старих bookmarks. Вимикати його одразу після запуску нової версії не варто.
