Що насправді змінюється під час перенесення сайту
Для бізнесу міграція може виглядати як заміна CMS, хостингу або дизайну. Для Google це набір змін окремих URL: старий документ зникає, з’являється нова адреса, змінюються внутрішні посилання, canonical, мовні версії, контент і швидкість відповіді сервера.
Якщо пошукова система не бачить однозначної відповідності, накопичені сигнали не зникають миттєво, але можуть довше переоброблятися або розподілитися між неправильними сторінками. Тому перенесення проєктують як роботу з картою URL і даними, а не як останній технічний пункт перед релізом.
Інвентаризація до першої зміни
Спочатку потрібен знімок поточного стану. Без нього після запуску неможливо відрізнити нормальні коливання від реальної втрати сторінок, запитів або конверсій.
Повний список URL
Сторінки із sitemap, внутрішнього обходу, Search Console, аналітики, рекламних кабінетів і зовнішніх посилань.
Цінність кожної сторінки
Покази, кліки, звернення, виручка, зовнішні посилання та роль у користувацькому шляху.
Технічні сигнали
HTTP-статус, canonical, robots, hreflang, schema, метадані й поточна індексованість.
Контент і файли
Тексти, зображення, документи, товари та дані, які не можна втратити під час зміни системи.
Контрольна вибірка
Набір важливих сторінок різних типів для перевірки до та відразу після запуску.
Карта URL — центральний документ міграції
Для кожної старої адреси заздалегідь визначають результат. Якщо зміст зберігається, вона веде на максимально близьку нову сторінку. Якщо кілька матеріалів справді об’єднані, допускається один релевантний підсумковий URL. Якщо заміни немає, сервер має чесно повернути 404 або 410.
Не можна надсилати сотні видалених товарів і статей на головну сторінку лише заради відсутності помилок. Такий редирект не відповідає початковому наміру користувача й може сприйматися як soft 404.
Один старий URL → один новий URL
Базовий сценарій для збереженої сторінки або товару.
Кілька URL → одна сторінка
Допустимо лише за реального об’єднання однакового або близького змісту.
URL без заміни
Повертає 404/410 і видаляється з нових внутрішніх посилань та sitemap.
Незмінний URL
Залишається 200, отримує self-canonical і актуальний контент без зайвого редиректу.
Як мають працювати постійні редиректи
Для постійної зміни адреси Google рекомендує серверний 301 або 308. Редирект має спрацьовувати за один перехід: старий URL одразу веде на остаточний новий, без ланцюжка через проміжні версії, HTTP або інший варіант домену.
Старі редиректи варто зберігати щонайменше рік, а для користувачів і зовнішніх посилань часто розумно залишати довше. Водночас власні внутрішні посилання, профілі, рекламні кампанії та важливі зовнішні згадки потрібно оновлювати на кінцеві адреси.
Canonical, hreflang, sitemap і внутрішні посилання
Редирект — лише один сигнал. На нових сторінках canonical має вказувати на новий індексований URL, RU/UA-версії — взаємно посилатися через hreflang, а sitemap — містити лише кінцеві canonical-сторінки зі статусом 200.
Навігація, хлібні крихти, картки, статті та футер також мають вести одразу на нові URL. Якщо сайт продовжує масово посилатися на старі адреси, обхід стає повільнішим, а архітектура — суперечливою.
Canonical
Self-referencing на кінцевій сторінці без старого домену або тестового середовища.
Hreflang
Взаємні мовні пари з коректними URL і мовними кодами.
Sitemap
Лише індексовані сторінки 200; старі й редиректні адреси виключені.
Robots і noindex
Захист staging не повинен випадково перейти у production.
Schema й метадані
Назва, зображення, автор, товар або послуга відповідають видимому змісту нової сторінки.
Чому перенесення й повний редизайн краще розділяти
Google рекомендує за можливості змінювати по одному великому фактору за раз. Якщо одночасно змінити домен, CMS, URL, структуру та зміст сторінок, під час просідання буде важко визначити причину.
Практичний порядок залежить від проєкту, але принцип один: спочатку зробити зіставлення перевірюваним. Наприклад, зберегти структуру під час зміни домену, дочекатися обробки основних URL, а потім розвивати дизайн і контент. Для великого сайту можна почати зі стабільного розділу й перевірити процес на обмеженій групі сторінок.
Що додатково перевірити в інтернет-магазині
В e-commerce ризик вищий через кількість товарів, категорій, фільтрів і зв’язків із зовнішніми системами. Тут недостатньо перевірити головну та кілька карток.
Товари й варіанти
Стабільні ідентифікатори, URL варіантів, залишки, ціни, зображення та структуровані дані Product.
Категорії й фільтри
Корисні посадкові зберігаються, а нескінченні комбінації параметрів не створюють дублікати.
Видалені товари
Обирається релевантна заміна, збереження інформаційної сторінки або коректний 404/410 — без масового редиректу на категорію.
Фіди й реклама
Merchant Center, товарні фіди, рекламні URL та UTM-шаблони оновлені разом із сайтом.
Замовлення й інтеграції
Кошик, оплата, доставка, CRM, сповіщення та аналітика перевірені наскрізним тестовим замовленням.
Запуск і контроль після міграції
Перед перемиканням нова версія проходить технічний обхід, а контрольні сторінки порівнюються зі старою системою. Після запуску перевіряються статуси старих URL, canonical, robots, мовні пари, sitemap і реальні користувацькі сценарії.
У Search Console відстежуються індексування нових сторінок, помилки, покази, кліки та запити. У власній аналітиці — посадкові сторінки, звернення й замовлення. Тимчасові коливання можливі, поки Google повторно обходить URL, тому оцінювати потрібно не один день, а динаміку за типами сторінок.
Перші години
Критичні URL, форми, замовлення, оплата, редиректи й відсутність production-noindex.
Перші дні
Помилки обходу, серверні відповіді, логи, sitemap і збереження конверсій.
Перші тижні
Індексація, запити, CTR, зовнішні посилання та сторінки, які не переносять сигнали очікуваним чином.
Коли перенесення варто передати виконавцю
Допомога особливо корисна, якщо сайт уже отримує органічний трафік, містить сотні URL, працює двома мовами, змінює домен або платформу та пов’язаний із CRM, оплатою, доставкою чи рекламними фідами.
Хороший результат міграції — не обіцянка «позиції точно не зміняться». Це перевірювана карта відповідностей, технічно коректний запуск, збережені дані й моніторинг, який дозволяє швидко побачити та виправити проблему.