Як переїхати на нову платформу інтернет-магазину, не втративши трафік і дані

Міграція інтернет-магазину — це перенесення каталогу, клієнтів, замовлень і адрес сторінок на нову платформу так, щоб покупці й Google не помітили розриву. Головні ризики дві: втратити пошуковий трафік (змінилися адреси, і старі не перенаправлені) та втратити дані (клієнти, історія замовлень, відгуки, налаштування аналітики).

Стаття не радить жодної платформи. Вона про процес, який однаковий для будь-якого переїзду. Пошукові правила взято з документації Google Search Central, решта — практична логіка, яку позначено.

Спершу визначте, який у вас тип переїзду

Google розрізняє два випадки, і від цього залежить обсяг роботи:

1. Адреси сторінок змінюються (нова платформа інакше будує URL, змінюється домен чи протокол): це «site move with URL changes», потрібні редиректи й акуратне відображення старих адрес на нові (Google Search Central).
2. Адреси лишаються тими самими, змінюється лише хостинг чи платформа під ними: це переїзд без зміни URL, де головна задача — перемкнути DNS і не втратити доступ Googlebot (Google Search Central).

Практичний висновок: якщо нова платформа вміє зберегти ваші адреси (товарів, категорій, статей), зробіть це. Кожна збережена адреса — це редирект, який не треба підтримувати, і ризик, якого немає. Якщо ні, готуйте повну карту відповідностей.

Підготовка (за 2–6 тижнів до переїзду)

1. Зберіть інвентаризацію

• Адреси. Згідно з Google, старі URL збирайте з sitemap, серверних логів, аналітики, CMS і звіту про посилання в Search Console. Враховуйте також зображення, відео, JavaScript і CSS (Google).
• Трафік і замовлення. Зафіксуйте базу: сеанси за джерелами, органічний трафік за сторінками, виручка за каналами, конверсія за останні 3–6 місяців. Без цього ви не відрізните сезонність від втрат.
• Найважливіші сторінки. Окремо виділіть топ-сторінки за доходом від органіки й посилальною масою: їх перевіряють вручну першими.
• Налаштування. Фіди товарів, акаунти реклами й Merchant Center, піксели, інтеграції з обліком і доставкою, поштові шаблони.

2. Складіть карту редиректів

Для кожної старої адреси визначте нову. За Google:

• використовуйте серверні постійні редиректи (301 чи 308); клієнтські (JavaScript, meta refresh) — лише як останній засіб;
• перенаправляйте кожну стару адресу одразу на кінцеву, без ланцюжків: Googlebot здатний пройти до 10 переходів, але Google радить тримати ланцюжок не довшим за 3 і бажано менше 5;
• не відправляйте багато старих адрес на недоречну одну сторінку, наприклад головну;
• для контенту, який ви не переносите, віддавайте 404 чи 410 (Google).

Сторінка Google про редиректи уточнює різницю: постійні (301/308) повідомляють, що нова адреса має стати канонічною й показуватись у результатах, а тимчасові (302/303/307) лишають у видачі стару (Google Search Central). Для переїзду потрібні постійні.

Приклад (умовний). Було: `/category/zhinochyi-odyag/dress-123`. Стало: `/zhinky/sukni/dress-123`. У карті це один рядок, а в налаштуваннях платформи — правило, яке можна застосувати масово за шаблоном, але винятки (товари без пари) треба обробити вручну.

3. Підготуйте нову платформу

• Каталог. Перенесіть і перевірте атрибути, варіанти, фото, відгуки; упорядкуйте структуру (структура каталогу). Дані з PIM чи таблиць зручно спершу очистити.
• Клієнти й замовлення. Імпортуйте їх, перевірте на вибірці: суми, статуси, адреси, історія. Окремо з'ясуйте, чи можна перенести облікові записи покупців. Паролі зазвичай зберігаються у вигляді хешів, і не кожна платформа їх приймає, тому клієнтам може знадобитися скинути пароль. Це загальна практична обережність, а не дані дослідження: перевірте в документації обох платформ.
• Закон і приватність. Персональні дані покупців при переносі лишаються під вашою відповідальністю: перевірте договір із новим провайдером і політику (GDPR, cookies).
• Технічне SEO. Self-canonical, hreflang, внутрішні посилання, sitemap і структуровані дані мають вказувати на нові адреси (Google). Короткий аудит — технічний аудит.
• Закрита копія. Тестовий сайт закрийте від індексації (`noindex` або доступ за паролем), а перед запуском зніміть блокування.

4. Налаштуйте аналітику й вимірювання

• Перенесіть теги й події (`view_item`, `add_to_cart`, `purchase`) і перевірте на тестових замовленнях, що звіт «Ecommerce purchases» у Google Analytics показує дохід, перегляди й додавання в кошик (Google Analytics Help).
• Підготуйте звіт «до і після» за вашою базою з кроку 1.
• Google радить налаштувати аналітику на обох сайтах і пересвідчитись, що сервер витримає посилений обхід Googlebot після переїзду.

5. Виберіть час

Google рекомендує переїжджати в період низького трафіку, адже позиції тимчасово можуть коливатися. Для магазину це означає не запускатися перед піком сезону (Чорна п'ятниця, Новий рік, 8 Березня), а перед ним лишити запас часу на виправлення помилок.

День переїзду

Послідовність, яку описує Google для переїзду з новими адресами (Google):

1. Увімкніть редиректи.
2. Перевірте, що canonical вказують на нові адреси, і приберіть тимчасові `noindex`.
3. Протестуйте редиректи через URL Inspection Tool чи скриптом.
4. Якщо змінюється домен чи піддомен, подайте в Search Console інструмент «Зміна адреси» для кожного підтвердженого варіанта старого домену. Для переходу HTTP→HTTPS, www чи зміни шляху він не застосовується.
5. Надішліть новий sitemap, видаліть старий.
6. Оновіть посилання в соцмережах, профілях, рекламних кампаніях і на сайтах партнерів, які посилаються на вас.

Для переїзду без зміни адрес процедура інша (Google): задовго до переїзду, щонайменше за тиждень, знизьте TTL у DNS-записах до кількох годин, щоб зміна швидше поширилась; переконайтеся, що брандмауер чи захист від DDoS не блокує Googlebot; перемкніть DNS; після зникнення трафіку зі старого сервера вимкніть його.

Для магазину додайте: перевірте оформлення замовлення й оплату на реальних картках, спрацювання пошти й SMS, статуси замовлень, експорти у склад і доставку (Нова пошта чи інші), робочий фід для реклами.

Після переїзду: що перевіряти

• Search Console. За документацією Google кількість проіндексованих адрес у старому sitemap має зменшуватися, а в новому зростати; попередження про редиректи в старому sitemap очікувані.
• Логи сервера. Візити Googlebot, неочікувані коди відповіді, трафік користувачів.
• Аналітика. Трафік падає на старих адресах і росте на нових. Порівняйте органіку й виручку з базою.
• 404 і редиректи. Щодня в перший тиждень шукайте адреси, які дають 404, але мали пару в карті.
• Конверсія й воронка. Швидше за SEO просідає оформлення замовлення, якщо щось зламалося (ключові метрики, відмова від кошика).

Скільки чекати. Google не дає календарних дат: для сайтів середнього розміру перехід може тривати кілька тижнів і більше, великі сайти потребують довше, а переїзд завершується, коли Googlebot відвідає всі старі й нові адреси принаймні один раз. Позиції можуть тимчасово коливатися (Google). Тому перші 2–4 тижні не робіть інших великих змін на сайті, щоб не змішувати причини.

Скільки тримати редиректи. Згідно з поточним керівництвом Google, не менше року, а то й довше, якщо вони ще отримують трафік. Вимкнути їх раніше — це ризик втратити сигнали (Google).

Хто що робить

Це типовий розподіл, а не вимога з джерел.

План відкату

Перш ніж перемикати, домовтеся, що робити, якщо щось піде не так: старий сайт лишається працювати на тимчасовій адресі, редиректи можна швидко вимкнути, а замовлення за ці дні не загубляться. Для коротких проблем із доступністю Google радить використовувати тимчасові редиректи, які лишають у видачі стару адресу (Google).

Типові помилки

• Відправити всі старі адреси на головну.
• Забути картинки, PDF, фільтровані сторінки й статті блогу.
• Вимкнути блокування `noindex` на новому сайті занадто пізно (чи не вимкнути).
• Зробити ланцюжки редиректів із трьох-п'яти переходів.
• Переїжджати перед сезоном.
• Не зберегти базу «до» й потім сперечатися, чи був провал.
• Не перевірити оплату й відправлення на реальних замовленнях.
• Змінити структуру й дизайн одночасно з платформою, коли кожна зміна ускладнює пошук причини.

FAQ

Чи втрачу я позиції в Google при зміні платформи? Тимчасові коливання можливі: Google прямо це попереджає. Мінімізують втрати збережені адреси або чіткі постійні редиректи, нова карта, правильні canonical і контроль після запуску.

Скільки тримати редиректи після переїзду? За чинним керівництвом Google, щонайменше рік, довше — якщо трафік через них ще є.

Чи потрібен 301 редирект, якщо адреси не змінилися? Ні, але потрібна перевірка DNS, доступності для Googlebot і закритого тестового середовища.

Що робити з клієнтами й паролями? Імпортувати їх і перевірити вибірку; щодо паролів заздалегідь з'ясувати, чи підтримує нова платформа їх перенесення, інакше підготуйте лист зі скиданням.

Як довго триває переїзд? Технічна частина залежить від каталогу, а пошукове «влягання» за Google може тривати кілька тижнів і більше.

Пов'язані терміни

• Структура каталогу інтернет-магазину
• SaaS-платформа, власний магазин чи вайб-кодинг: що обрати
• Технічний аудит сайту: що це і що перевіряють
• Із чого складається технічне завдання для створення інтернет-магазину?
• PIM-система
• Ключові метрики інтернет-магазину: що дивитися щодня, щотижня й щомісяця

Джерела

• Google Search Central, How to move a site (with URL changes) — developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central, Moving a site with no URL changes — developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes
• Google Search Central, Redirects and Google Search — developers.google.com/search/docs/crawling-indexing/301-redirects
• Google Analytics Help, Ecommerce purchases report — support.google.com/analytics/answer/12924131