Міграція сайту не завершується в момент, коли відкрилася нова головна. Вона завершується тоді, коли кожна цінна стара адреса має обґрунтоване рішення, клієнти можуть замовити товар або надіслати заявку, пошукові системи отримують узгоджені сигнали, а команда бачить і пояснює всі втрати.
Безпечний принцип: змінюйте лише те, чого справді потребує проєкт; до запуску призначте рішення кожній важливій адресі; приймайте сторінку разом із її редиректом; домовтеся про умови відкату, поки відкат іще можливий. Коливання позицій під час переобходу нормальні. Масові 404, заблоковані сторінки та суперечливі canonical — ні.
Спочатку назвіть, що саме переїжджає
Під словами «новий сайт» можуть ховатися заміна хостингу без зміни адрес, перехід на іншу CMS, редизайн, новий домен або повна перебудова каталогу. Ризики різні. Google радить, де це можливо, розділяти великі зміни в часі. Коли одночасно змінюються домен, платформа, тексти, навігація й аналітика, причину просідання майже неможливо швидко встановити.
Складіть короткий паспорт міграції: бізнес-причина, сайти й мовні версії в периметрі, вікно запуску, відповідальні за бізнес, розробку, SEO та аналітику, критичні сценарії клієнта, час заморожування змін, право зупинити реліз і крайній момент безпечного відкату. Окремо зафіксуйте те, що не змінюється. Для переїзду між хостингами нові URL зазвичай не потрібні.
До перемикання DNS збережіть базову картину: органічні входи й конверсії за сторінками, кліки та покази в Search Console, проіндексовані шаблони, важливі зовнішні посилання, рекламні посадкові, завершення форм і оформлення замовлення, швидкість, серверні помилки та повне сканування. Де вистачає даних, розділіть їх за пристроями, країнами й типом пошуку. Це не обіцянка незмінного трафіку, а точка порівняння.
Один реєстр URL замість таблиць по відділах
Зберіть адреси з XML sitemap, CMS або товарної бази, аналітики, Search Console, серверних логів, звітів про backlinks, рекламних кабінетів і довідкових матеріалів. Google рекомендує поєднувати джерела: кожне бачить лише частину сайту. Додайте зображення, PDF, сторінки кампаній, субдомени, параметри та старі URL, на які досі приходять люди.
| Поле | Рішення | Доказ приймання |
|---|---|---|
| Старий URL | Зберегти, перенаправити, об’єднати, 404 або 410 | Записані поточний статус і джерело цінності |
| Новий URL | Один найближчий відповідник або жодного | Фінальна сторінка віддає 200 та індексується |
| Контракт | Намір, контент, метадані, мова, функція | Відповідальний прийняв результат |
| Редирект | 301 або 308 для постійного переїзду | Один перехід до фінального canonical URL |
| Бізнес-сценарій | Форма, кошик, оплата, вхід, файл | Контрольна транзакція успішна |
| Виняток | Власник, критичність, строк | Немає критичних рядків без рішення |
Не ведіть усі видалені сторінки на головну. Google попереджає: масове нерелевантне перенаправлення може сприйматися як soft 404. Редирект доречний, якщо нова сторінка задовольняє той самий намір. Якщо чесного відповідника немає, поверніть справжній 404 або 410, приберіть URL із внутрішніх посилань і sitemap, а сторінку помилки зробіть корисною для людини.
Пріоритезуйте не за кількістю адрес, а за ризиком для бізнесу. Забута сторінка тарифів, адреса зворотного виклику платіжної системи, URL у товарному фіді або українська посадкова можуть бути важливішими за тисячі сторінок фільтрів. Для найвищого рівня встановіть правило: до запуску немає жодного невирішеного рядка.
Збережіть контракт сторінки
Статус 200 ще не означає, що сторінка пережила переїзд. Порівняйте намір, основний текст, title і description, заголовки, canonical, indexability, структуровані дані, внутрішні посилання, зображення, файли, мовні альтернативи та головну дію. Для магазину додайте артикул або GTIN, варіанти, ціну, наявність, валюту, доставку, повернення, відгуки, URL у Merchant Center і весь шлях від картки товару до підтвердження оплати.
Перевіряйте HTML, який отримує робот, а не лише скриншот у браузері. Основний контент і посилання мають бути доступні для обходу, структуровані дані — відповідати видимим фактам, robots.txt — пропускати бойові сторінки, а тимчасовий noindex із тестового середовища не повинен потрапити в реліз. До запуску тестове середовище закривайте, але фінальні правила підготуйте заздалегідь.
Canonical, sitemap, внутрішні посилання, hreflang, фіди й редиректи мають вказувати на ту саму бажану адресу. Якщо редирект веде на один URL, а canonical називає інший, пошуковик мусить сам розв’язувати суперечність. Внутрішні посилання оновлюйте одразу до фінальних адрес: редирект має страхувати старий вхід, а не працювати як постійний елемент навігації.
Редирект — частина функціональності, а не файл «на потім»
Для постійних змін використовуйте серверні 301 або 308. Стара адреса має вести одразу на фінальну, без ланцюгів і циклів. Google зазначає, що permanent redirects не втрачають PageRank, і радить тримати їх щонайменше рік. Для користувачів, закладок і довгоживучих backlinks доцільно зберігати цінні правила довше.
Генеруйте правила з погодженого реєстру та тестуйте весь список у середовищі, максимально схожому на бойове. Перевірте код відповіді, фінальну адресу, параметри запиту, кількість переходів, регістр, слеш наприкінці, кодування кирилиці, мовні префікси, файли й типові фільтри. Шаблонне правило безпечне лише тоді, коли стара та нова структури справді збігаються.
Зробіть помилку редиректу умовою блокування релізу: важлива адреса повертає 404, веде на нерелевантну сторінку, створює цикл, зайвий ланцюг або потрапляє на noindex. Після цього окремо проскануйте новий сайт і знайдіть внутрішні посилання через редирект. Їх треба замінити фінальними URL.
Запуск із воротами якості та готовим відкатом
Обирайте час із нижчим ризиком, але тільки коли доступні люди, здатні змінити застосунок, CDN, DNS, аналітику й платежі. Нічний реліз без команди не стає безпечним через низький трафік. Якщо змінюється домен або хостинг, завчасно зменште DNS TTL, перевірте сертифікати, збережіть старе середовище та запишіть точну послідовність відкату.
Заздалегідь визначте умови зупинки: не працює оформлення замовлення чи форма; критичні маршрути повертають помилки; бойовий сайт лишився під noindex; robots блокує важливі розділи; редиректи масово відсутні; canonical посилається на тестове середовище або старий домен; аналітика мовчить; команда не відрізняє контрольні операції від реальних. Відкат — це нормальний інструмент керування ризиком.
При зміні домену підтвердьте старі й нові ресурси в Search Console. У чинній інструкції Google сказано подати Change of Address для всіх релевантних підтверджених варіантів, зокрема потрібних субдоменів та www/non-www. Надішліть новий sitemap. Інші пошукові системи повідомте через їхні інструменти; Bing також рекомендує permanent redirects і коректне оновлення переміщених та видалених URL.
Дивіться на когорти сторінок, а не на одну цифру
У першу добу стежте за помилками застосунку й CDN, невдалими редиректами, доступом ботів, завантаженням sitemap, структурованими даними, формами, платежами та верхівкою реєстру. Упродовж тижня порівнюйте старі й нові когорти в Search Console та логах. Шукайте старі URL із показами без валідного призначення, нові сторінки, виключені через canonical або noindex, soft 404 та важливі шаблони без обходу.
Повторіть огляд на 30-й, 60-й і 90-й день. Розділіть branded і non-branded запити, типи сторінок, мови, пристрої й ринки. Трафік на старі адреси має спадати, а на відповідні нові — зростати. За оцінкою Google, перенесення більшості сторінок малого чи середнього сайту може тривати кілька тижнів, великого — довше. Один слабкий день нічого не доводить; стабільна проблема в конкретному шаблоні — доводить.
Критерії мають бути вимірюваними: жодного зламаного ключового сценарію; жодного індексованого URL тестового середовища; усі пріоритетні редиректи справні; sitemap доступний; частка обійдених нових сторінок зростає; органічні конверсії оцінюються з урахуванням сезонності. Не оголошуйте успіх лише за позиціями, якщо перестали вимірюватися заявки або замовлення.
Що додати магазину та багатомовному сайту
Для ecommerce одночасно переїжджають сайт, структуровані дані й товарний фід. URL, ідентифікатори, ціна, наявність, валюта, доставка й повернення мають збігатися в усіх трьох джерелах. Де можливо, збережіть товарні ID та зв’язки варіантів. Перевірте кошик, промокоди, податки, способи доставки, зворотні виклики платіжної системи, сторінку підтвердження, листи, списання залишків і повернення коштів.
У багатомовній міграції кожна локаль потребує окремого рядка. Не перенаправляйте всі українські чи російські сторінки на англійську головну. Локалізована сторінка має вести на відповідний переклад, містити self-referencing canonical та входити до повного взаємного набору hreflang. Google вимагає, щоб кожна версія зазначала себе й усі альтернативи. Перевірте перемикач мови, перекладені метадані та навігацію.
Жоден чекліст не гарантує незмінних позицій: алгоритми, конкуренти, сезонність, зміни контенту й час обходу не контролюються командою. Добрий план прибирає зайву неоднозначність, прискорює діагностику та захищає шлях клієнта, поки пошук опрацьовує переїзд.
Поширені запитання
Чи можна перенести сайт без втрати SEO-трафіку?
Гарантувати незмінні позиції не можна. Проте збереження корисних сторінок, карта URL один до одного, permanent redirects, узгоджені canonical і sitemap та когортний моніторинг суттєво зменшують ризик технічної втрати.
Скільки тримати 301 редиректи?
Google радить щонайменше рік. Цінні редиректи варто зберігати довше, якщо старими адресами користуються закладки, кампанії, клієнти або зовнішні сайти.
Чи варто одночасно запускати редизайн і новий домен?
Лише якщо бізнес-обмеження важливіше за ризик діагностики. Розділені зміни дозволяють швидше зрозуміти, що саме спричинило проблему.
Коли треба відкочувати міграцію?
Коли не працюють критичні транзакції, бойовий сайт закритий від індексації, немає значної частини важливих редиректів, основні сигнали вказують на хибний домен або команда втратила спостережуваність.
Джерела та дата перевірки
Перевірено 9 вересня 2026 року за офіційними матеріалами Google Search Central про міграцію сайту, локалізовані сторінки та структуровані дані ecommerce, а також за офіційними Bing Webmaster Guidelines. Швидкість відновлення залежить від масштабу сайту, попиту, доступних ресурсів для обходу та кількості змін.
Плануєте редизайн, нову CMS або домен? Rendframe допоможе скласти реєстр URL, автоматизувати перевірки, налаштувати редиректи, спостережуваність і план відкату. Дізнайтеся про розробку цифрових продуктів або замовте оцінку ризиків міграції.