WebMannaЯк перенести сайт або інтернет-магазин і не втратити SEO?
Перенести сайт технічно можна за кілька дій: скопіювати файли, базу даних, підключити новий домен або CMS і відкрити нову версію для користувачів.
І саме тут часто починаються проблеми.
Бо для Google сайт — це не тільки дизайн і файли. Пошукова система вже знає його сторінки, URL, внутрішні зв’язки, контент, canonical, зовнішні посилання та історію індексації.
Тому завдання правильної міграції звучить трохи інакше:
не просто перенести сайт, а зберегти зв’язок між тим, що Google знав раніше, і тим, що з’явиться після запуску.
У WebManna Studio ми саме так дивимося на переїзд сайту: спочатку визначаємо, що вже працює, а потім вирішуємо, що можна змінити без зайвого ризику для органічної видимості.
Міграція починається ще до створення нового сайту
Найгірший момент для аналізу старого сайту — після того, як його вже вимкнули.
До перенесення потрібно зафіксувати поточний стан.
Які сторінки існують?
Які з них бачить Google?
На які URL приходить органічний трафік?
Які категорії магазину отримують покази?
На які сторінки ведуть зовнішні посилання?
Які Title, Description, H1 і canonical використовуються зараз?
Які сторінки давно не потрібні?
На цьому етапі стає видно важливу річ: не всі сторінки старого сайту мають однакову цінність.
У великого магазину можуть бути тисячі товарів, але основна органічна видимість тримається на кількох категоріях.
На корпоративному сайті може бути десяток послуг, але Google стабільно показує лише чотири.
А стара стаття, яку вже давно ніхто не відкривав через меню, може мати хороші зовнішні посилання.
Без такого аналізу міграція перетворюється на перенесення навмання.
Зберігайте старий URL, якщо немає причини його змінювати
Оновлення сайту не означає, що потрібно обов’язково переписати всі адреси.
Припустимо, сторінка вже має нормальний URL:
/service/seo-audyt/
Вона індексується, має внутрішні посилання і зрозумілу структуру.
Якщо новий сайт може використовувати ту саму адресу, навіщо створювати іншу?
Кожна зміна URL запускає додаткову роботу:
потрібен редирект;
Google має побачити нову адресу;
потрібно оновити внутрішні посилання;
перевірити canonical;
оновити sitemap.
Тому під час міграції ми не виходимо з принципу «новий сайт — нові URL».
Навпаки: те, що добре працює, краще не змінювати без причини.
А якщо структура URL справді має змінитися?
Таке буває часто.
Особливо коли сайт переходить на іншу CMS або інтернет-магазин переноситься на нову платформу.
Стара адреса:
/catalog/category/product/
може перетворитися на:
/product/product-name/
Або змінюється сама логіка категорій.
У такому випадку потрібна карта перенесення URL.
Її суть проста:
старий URL → новий URL
Але ця таблиця повинна будуватися не автоматично «за схожими словами», а за змістом.
Стара сторінка послуги переходить на нову сторінку цієї ж послуги.
Стара категорія товарів — на відповідну нову категорію.
Товар — на нову сторінку цього товару.
Якщо дві старі сторінки об’єднали в одну, вони можуть вести на нову спільну сторінку, якщо вона справді замінює обидві.
Це набагато важливіше, ніж просто прибрати всі 404.
Чому не можна направити всі старі URL на головну
Так роблять, коли хочеться швидко закрити питання редиректів.
Стара сторінка більше не існує?
Ведемо на головну.
Стара категорія змінилася?
На головну.
Товар видалили?
Теж на головну.
З технічного боку користувач не бачить помилки. Але логіка зникає.
Людина відкрила посилання на конкретний товар, а отримала головну сторінку магазину.
Пошукова система теж не отримала нормальної відповіді на питання, куди переїхав старий контент.
У деяких ситуаціях масові нерелевантні перенаправлення Google може сприймати майже як відсутність потрібної сторінки.
Тому правило просте:
редирект повинен вести не кудись, а на найбільш релевантну нову адресу.
Для постійного переїзду потрібен постійний редирект
Якщо URL змінився назавжди, стару адресу потрібно зв’язати з новою через постійний серверний редирект.
Зазвичай це 301 або 308.
Наприклад:
старий URL → 301 → новий URL
Важливо уникати зайвих ланцюжків.
Погано:
сторінка A → сторінка B → сторінка C → нова сторінка
Краще:
сторінка A → нова сторінка
Це простіше і для користувача, і для пошукового робота.
Інтернет-магазин потребує окремої уваги
Перенесення звичайного корпоративного сайту і великого магазину — різні задачі.
У магазині потрібно врахувати не тільки сторінки.
Є:
товари;
категорії;
характеристики;
варіації;
фотографії;
описи;
залишки;
замовлення;
клієнтські дані;
оплата;
доставка;
CRM;
аналітика;
фільтри та параметри URL.
Причому з погляду SEO 5 000 товарів не обов’язково означають 5 000 однаково важливих сторінок.
У конкретного магазину сильними можуть бути категорії, сторінки брендів або певна група товарів.
Тому перед міграцією інтернет-магазину потрібно побачити, які частини каталогу вже мають пошукову видимість, і не втратити їх під час зміни платформи.
Особливо обережно з фільтрами магазину
Це місце, про яке легко забути.
На старому магазині фільтри могли створювати сотні або тисячі URL:
колір;
розмір;
бренд;
ціна;
матеріал;
комбінації параметрів.
Частина таких сторінок могла бути закрита від індексації. Частина — канонікалізована. А окремі фільтровані сторінки могли, навпаки, використовуватися як повноцінні SEO-посадкові.
Після переходу на нову CMS логіка фільтрів часто змінюється.
Якщо просто ввімкнути стандартні налаштування нової платформи, можна отримати зовсім іншу індексацію каталогу.
Тому фільтри перевіряють не тільки на те, чи вони працюють для покупця.
Потрібно подивитися, які URL вони генерують і що з цими URL робить Google.
Не змінюйте одночасно все, якщо цього можна уникнути
Нова CMS.
Новий домен.
Повністю інший дизайн.
Інша структура.
Переписані тексти.
Нові URL.
Нова аналітика.
Якщо запустити все це в один день, а потім побачити падіння органічної видимості, знайти причину буде складніше.
Іноді повний перезапуск справді необхідний. Але робити кілька великих змін одночасно просто тому, що «вже все одно переносимо», не завжди розумно.
Якщо бізнес має сайт, який уже працює в пошуку, корисніше розділити технічно можливі етапи.
Спочатку стабільний переїзд.
Потім — зміни, які не обов’язково запускати того самого дня.
Не переписуйте сторінки тільки заради міграції
Нова версія сайту часто провокує бажання оновити весь контент.
Це нормально, якщо старі сторінки справді слабкі.
Але якщо конкретна сторінка вже отримує потрібний органічний трафік, не обов’язково одночасно міняти:
URL;
Title;
H1;
основний текст;
структуру блоків;
внутрішні посилання.
Спочатку варто зрозуміти, чому ця сторінка працює зараз.
А потім уже вирішувати, що можна покращити.
Якщо старий сайт має багато структурних і SEO-проблем, перед великим переїздом корисно провести SEO-аудит сайту. Тоді на нову платформу не доведеться акуратно переносити старі помилки разом із хорошими сторінками.
Перевірте canonical після запуску
Це одна з тих речей, які користувач взагалі не бачить.
Сторінка може чудово виглядати.
Форма працює.
Дизайн правильний.
А canonical веде на старий домен.
Або на staging-версію.
Або всі товари нової категорії отримали canonical на одну сторінку.
Такі проблеми трапляються після перенесення CMS, зміни SEO-плагіна або копіювання налаштувань із тестового середовища.
Тому canonical потрібно перевіряти вже на фінальному сайті.
Особливо на:
головній;
основних послугах;
категоріях;
товарах;
статтях, що отримують трафік.
Переконайтеся, що новий сайт не залишився noindex
Поки сайт розробляється, його нормально закривати від індексації.
Але перед запуском це обмеження потрібно зняти.
На практиці варто перевірити не лише кнопку в WordPress.
Подивіться на реальний код сторінки, HTTP-заголовки та robots.txt.
Google повинен мати доступ до сторінки й можливість побачити її інструкції щодо індексації.
Якщо сайт випадково залишився закритим після запуску, інші SEO-налаштування вже не врятують ситуацію.
Sitemap повинен показувати новий сайт, а не його історію
Після перенесення XML sitemap має містити актуальні канонічні сторінки.
Старі URL, адреси staging-сайту, сторінки з редиректом або технічні дублі не повинні залишатися там просто через старі налаштування.
Після запуску sitemap варто подати або повторно перевірити в Google Search Console.
Для невеликого сайту це корисно.
Для магазину з тисячами сторінок — практично обов’язковий контрольний елемент.
Внутрішні посилання теж потрібно перенести
Навіть якщо 301 налаштовані ідеально, новий сайт не повинен постійно ходити через них усередині себе.
Припустимо, меню веде на:
/old-service/
Далі спрацьовує 301 і користувач потрапляє на:
/services/new-service/
Все відкривається.
Але навіщо робити зайвий перехід, якщо можна одразу поставити фінальну адресу?
Після міграції потрібно пройти:
меню;
футер;
хлібні крихти;
статті;
CTA;
банери;
схожі товари;
блоки послуг.
Усі внутрішні посилання повинні вести безпосередньо на актуальні сторінки.
При зміні домену робота виходить за межі самого сайту
Новий домен потрібно оновити всюди, де бізнес контролює посилання.
На сайті.
У Google Business Profile.
В офіційних соціальних профілях.
У рекламних кабінетах.
У каталогах.
У партнерських профілях.
У документах і підписах, якщо там використовується старий URL.
Зовнішні посилання на чужих сайтах змінити вдасться не завжди. Саме тому старі редиректи повинні продовжувати працювати.
Якщо змінюється сам домен, окремо перевіряється переїзд у Google Search Console та налаштування Change of Address там, де цей інструмент застосовується.
Для локального бізнесу є ще Google Business Profile
Якщо компанія отримує клієнтів із Google Maps або локального пошуку, після зміни домену не можна забути про профіль компанії.
Посилання на сайт у Google Business Profile має вести на актуальну адресу.
Те саме стосується основних каталогів і офіційних сторінок бренду.
Це особливо важливо для локального бізнесу, де користувач може побачити компанію спочатку в Maps, а вже потім перейти на сайт.
Тут локальне SEO під час міграції — не повторення назви міста в текстах.
Це збереження нормального шляху:
пошук → профіль компанії → правильний сайт → потрібна сторінка.
Не забудьте про GA4, GTM та конверсії
Міграція успішна не тоді, коли новий сайт красиво відкрився.
Вона успішна тоді, коли після запуску бізнес усе ще бачить, що відбувається.
Тому потрібно перевірити:
чи працює GA4;
чи завантажується Google Tag Manager;
чи рахуються форми;
чи фіксуються кліки по важливих контактах;
чи працює e-commerce tracking магазину;
чи не змінилися назви або логіка подій.
Інакше може виникнути дивна ситуація: трафік фактично є, а аналітика після міграції показує різкий обвал просто тому, що частина відстеження не перенеслася.
Для магазину після запуску потрібно пройти весь шлях покупця
Не тільки SEO.
Відкрийте категорію.
Знайдіть товар.
Додайте його в кошик.
Перейдіть до оформлення.
Перевірте спосіб доставки.
Перевірте оплату.
Подивіться, чи створилося замовлення.
Перевірте, чи отримала його потрібна система або менеджер.
Якщо магазин використовує товарні фіди чи зовнішні рекламні системи, їхні URL також потрібно перевірити після зміни домену або структури.
Тому міграція інтернет-магазину — це значно більше, ніж імпорт CSV із товарами.
Що перевірити безпосередньо перед перемиканням
Перед запуском варто мати один контрольний список:
- Збережений список важливих старих URL.
- Підготовлений URL mapping.
- Перевірені 301/308.
- Важливі Title, H1 та контент перенесені або свідомо змінені.
- Canonical ведуть на правильні адреси.
noindexзнятий із публічних сторінок.- robots.txt не блокує потрібні розділи.
- Sitemap містить актуальні URL.
- Внутрішні посилання ведуть на фінальні сторінки.
- GA4, GTM і конверсії працюють.
- Форми та контакти протестовані.
- Для магазину перевірені кошик, оплата, доставка та замовлення.
- Зроблений резервний бекап старого сайту.
Такий список не виглядає складно.
Але пропуск одного критичного пункту іноді створює більше роботи, ніж вся підготовка до міграції.
Що дивитися після запуску
У перший день немає сенсу судити про SEO лише за одним графіком.
Google потрібен час, щоб повторно обійти старі URL, побачити редиректи й обробити нові сторінки.
Тому дивитися краще на конкретні сигнали.
Чи бачить Search Console нові URL?
Чи продовжує Google активно обходити старі?
Чи доходять старі сторінки через редиректи саме туди, куди треба?
Чи не з’явилося багато нових 404?
Чи залишилися в індексі важливі категорії та послуги?
Що відбувається з показами й кліками на сторінках, які до переїзду були сильними?
І окремо — чи працюють заявки та покупки.
Це набагато інформативніше, ніж просто дивитися на загальну кількість відвідувачів.
Не вимикайте старий домен одразу
Якщо змінився домен, старий ще довго виконує важливу роботу.
На нього можуть вести:
старі закладки;
зовнішні посилання;
каталоги;
старі публікації;
документи;
листування;
пошуковий індекс.
Редиректи повинні залишатися доступними достатньо довго.
Тому старий домен після переїзду краще не сприймати як непотрібний актив, який можна відключити наступного дня.
Чи можна перенести сайт зовсім без зміни позицій
Це неправильна обіцянка.
Навіть при добре підготовленій міграції пошуковим системам потрібен час на обробку змін. Короткі коливання можливі.
Нормальна мета інша:
не втратити те, що можна було зберегти технічно.
Не загубити сильні сторінки.
Не зламати URL.
Не залишити неправильний canonical.
Не забути редирект.
Не перенести сайт із noindex.
Не втратити аналітику.
Не розірвати зв’язок із локальними профілями.
Це вже не питання удачі. Це питання підготовки.
Коли міграцію можна вважати завершеною
Не тоді, коли змінився дизайн.
І навіть не тоді, коли DNS уже веде на новий сервер.
Переїзд можна вважати стабільним, коли новий сайт нормально працює для користувачів, пошукові системи бачать основні сторінки, старі URL ведуть на правильні нові, аналітика не має розривів, а важливі комерційні сторінки продовжують отримувати органічну видимість.
Після цього можна переходити до наступного етапу: розширювати структуру, покращувати слабкі сторінки, створювати контент і продовжувати SEO-просування сайту.
Головна думка
Під час міграції потрібно переносити не тільки файли.
Потрібно зберегти маршрут.
Від старого URL до нового.
Від пошукового запиту до потрібної сторінки.
Від Google Business Profile до актуального домену.
Від реклами до правильної посадкової.
Від заявки до аналітики та CRM.
Коли ці зв’язки збережені, новий сайт стає продовженням уже накопиченої цифрової присутності бізнесу, а не окремим проєктом, який починає все з нуля.
Якщо плануєте переносити сайт або магазин, можна обговорити міграцію з WebManna Studio. Спочатку перевіримо поточну структуру та критичні URL, а вже потім визначимо, що потрібно перенести без змін, що можна покращити і де знадобляться редиректи.