Міграція з Tilda, Wix або Webflow без втрати SEO: покроковий план

Перенесення сайту з Tilda, Wix, Webflow або іншої платформи часто сприймають як просту технічну задачу: скопіювати дизайн, перенести тексти, переключити домен — готово.

Але якщо сайт уже отримує органічний трафік, має проіндексовані сторінки, зовнішні посилання, рекламні кампанії та історію в Google, міграція стає значно серйознішою.

Потрібно перенести не тільки те, що бачить користувач.

Потрібно зберегти або правильно передати:

• URL сторінок;
• контент;
• title та description;
• canonical;
• внутрішні посилання;
• мовні зв’язки;
• структуровані дані;
• аналітику;
• форми та інтеграції;
• пошукові сигнали старих URL.

Саме тому професійна міграція — це не «перемалювати Tilda на чистому коді».

Це контрольований перехід з однієї технічної системи в іншу з мінімально необхідною кількістю змін для користувачів і пошукових систем.

Коли ця стаття корисна

Окрема стаття TimeKairos уже розбирає, коли бізнес дійсно виріс із конструктора.

Тут питання інше.

Припустимо, рішення про міграцію вже прийнято.

Тоді потрібно зрозуміти:

• як підготувати старий сайт;
• що переносити один в один;
• коли потрібні 301 редиректи;
• чи можна змінювати URL;
• що робити з SEO;
• як перевірити новий сайт до запуску;
• що контролювати після переключення.

Чи можна мігрувати сайт без втрати SEO

Гарантувати абсолютно нульові коливання під час великої міграції некоректно.

Google прямо попереджає, що після значних змін сайт може тимчасово коливатися в пошуку, поки старі та нові URL повторно скануються та обробляються.

Але це не означає, що міграція обов’язково повинна знищити органічний трафік.

Ризик можна значно зменшити, якщо:

• не видаляти цінні сторінки без причини;
• зберігати URL там, де це можливо;
• правильно налаштувати редиректи там, де URL змінюються;
• не блокувати новий сайт від індексації після запуску;
• зберегти важливий контент і метадані;
• перевірити внутрішні посилання;
• контролювати Search Console після запуску.

Тобто правильна мета — не «пообіцяти відсутність будь-яких коливань», а провести міграцію так, щоб пошукова система могла максимально однозначно зрозуміти, куди перемістився старий контент.

Спочатку визначте тип міграції

Не всі переїзди однакові.

1. Платформа змінюється, URL залишаються

Наприклад:

example.com/services залишається example.com/services, але сторінка більше не працює на Tilda.

Це один із найпростіших сценаріїв для SEO, тому що користувацькі URL не змінюються.

2. Платформа і URL змінюються

Наприклад:

example.com/t123456-page перетворюється на example.com/services.

У такому випадку необхідна карта старих і нових URL та постійні редиректи.

3. Змінюється домен

Наприклад:

oldbrand.com → newbrand.com.

Це вже повноцінна доменна міграція, яка потребує додаткової уваги до Search Console, зовнішніх посилань і перенесення всіх URL.

4. Одночасно змінюється все

Новий домен, новий CMS, нова структура URL, новий дизайн і переписаний контент.

Це найбільш ризиковий сценарій, тому що після запуску складніше зрозуміти, яка саме зміна спричинила проблему.

Google рекомендує, де це практично можливо, не поєднувати декілька великих змін одночасно.

Крок 1. Зберіть список усіх старих URL

До початку дизайну нового сайту потрібно знати, що вже існує.

Список URL можна зібрати з декількох джерел:

• sitemap;
• Google Search Console;
• аналітики;
• краулінгу сайту;
• CMS або конструктора;
• списку сторінок, на які ведуть зовнішні посилання.

Не варто орієнтуватися тільки на головне меню.

На сайті можуть існувати старі посадкові сторінки, статті, рекламні URL та інші сторінки, які не видно в навігації, але вони все ще отримують органічний трафік.

Крок 2. Визначте цінність кожної сторінки

Не кожен старий URL потрібно механічно переносити.

Сторінки можна умовно розділити на декілька груп:

• залишаємо без суттєвих змін;
• об’єднуємо з іншою сторінкою;
• переносимо на новий URL;
• видаляємо, тому що контент більше не актуальний.

Але рішення краще приймати після перевірки даних.

Перед видаленням сторінки варто подивитися:

• чи отримує вона органічний трафік;
• чи має покази в Google;
• чи є на неї зовнішні посилання;
• чи використовують її рекламні кампанії;
• чи ведуть на неї внутрішні посилання;
• чи має вона бізнес-цінність.

Крок 3. По можливості збережіть URL

Якщо сторінка залишається тією самою за змістом і немає бізнес-причини змінювати її адресу, найпростіше зберегти старий URL.

Наприклад, немає необхідності перетворювати:

/services/web-development

на:

/new-services/custom-web-development-2026

тільки тому, що сайт переїхав на іншу технологію.

Стабільні URL полегшують життя:

• користувачам;
• пошуковим роботам;
• рекламним кампаніям;
• аналітиці;
• зовнішнім посиланням.

Крок 4. Створіть карту редиректів

Якщо URL все-таки змінюються, для кожної старої адреси потрібно визначити найбільш релевантну нову.

Наприклад:

/old-web-design → /services/web-design

Але не:

/old-web-design → /

лише тому, що головна сторінка існує.

Масове перенаправлення всіх старих URL на головну може бути незручним для користувачів і не передавати правильний зміст переміщення.

Крок 5. Використовуйте постійні редиректи для постійного перенесення

Якщо стара сторінка назавжди переїхала на нову адресу, зазвичай використовують серверний постійний редирект, наприклад HTTP 301 або 308.

Такий редирект повідомляє користувачу та пошуковій системі, що контент має нову постійну адресу.

Google рекомендує серверні постійні редиректи там, де вони технічно доступні.

Важливо також уникати зайвих ланцюжків:

старий URL → проміжний URL → ще один URL → фінальна сторінка.

Краще, щоб старий URL одразу вів на актуальну фінальну адресу.

Чи втрачається PageRank через 301

Google прямо зазначає, що 301 та інші постійні редиректи самі по собі не спричиняють втрату PageRank.

Це не означає, що будь-яка міграція автоматично збереже всі позиції.

Проблеми можуть виникати, якщо:

• старий URL перенаправляється на нерелевантний контент;
• важлива сторінка повністю зникає;
• новий сайт блокується від сканування;
• змінено значну частину змісту;
• є технічні помилки.

Тому важливий не просто сам факт наявності 301, а правильна карта відповідностей.

Крок 6. Перенесіть контент, який уже працює

Міграція — не найкращий момент для автоматичного переписування всього сайту лише тому, що «потрібен свіжий текст».

Якщо сторінка вже отримує релевантний органічний трафік, значну частину її змісту варто переносити контрольовано.

Після стабілізації міграції контент можна покращувати окремим етапом.

Особливо уважно потрібно переносити:

• H1 та основні заголовки;
• основний текст;
• ціни;
• FAQ;
• зображення;
• alt-тексти;
• внутрішні посилання;
• важливі CTA.

Крок 7. Перевірте title та meta description

Під час редизайну SEO-метадані легко загубити.

Дизайнер їх не бачить, а розробник може не знати, що старі title вже отримують покази в пошуку.

Перед запуском бажано порівняти старий і новий сайт.

Особливо це стосується:

• SEO Title;
• Meta Description;
• robots meta;
• canonical;
• мовних атрибутів.

Крок 8. Перевірте canonical

На staging-версії або під час міграції canonical іноді випадково продовжує вказувати на тестовий домен, стару платформу або неправильну сторінку.

Після запуску canonical повинен відповідати реальній індексованій структурі.

Якщо URL не змінювався, self-referencing canonical зазвичай повинен залишатися на поточній канонічній адресі.

Крок 9. Не забудьте зняти noindex перед запуском

Новий сайт часто розробляють на staging-домені.

Щоб Google не проіндексував тестову копію, на staging логічно використовувати обмеження індексації.

Проблема виникає, коли сайт запускають у production, а noindex випадково залишається.

Тому перед переключенням потрібно перевірити:

• robots.txt;
• meta robots;
• HTTP-заголовки;
• налаштування CMS;
• firewall та антибот-захист.

Крок 10. Оновіть внутрішні посилання

Навіть якщо старі URL мають 301, внутрішні посилання краще одразу вести на фінальні адреси.

Не варто будувати структуру:

нова сторінка → старий URL → 301 → новий URL.

Правильніше оновити:

• меню;
• footer;
• тексти статей;
• CTA;
• breadcrumb;
• related posts;
• посилання в картках.

Крок 11. Збережіть мультимовність

Для сайту з UA, RU та EN міграція стає складнішою.

Потрібно перевірити відповідність між мовними URL.

Наприклад:

/services

/ru/services

/en/services

повинні залишатися логічно пов’язаними між собою.

Під час перенесення перевіряються:

• lang;
• hreflang;
• canonical;
• language switcher;
• редиректи;
• метадані кожної мови.

Крок 12. Перенесіть структуровані дані

Якщо старий сайт використовував коректні структуровані дані, їх не варто випадково втрачати при переході.

Залежно від сайту це можуть бути:

• Organization;
• Article;
• BreadcrumbList;
• Product;
• LocalBusiness;
• інші релевантні типи Schema.org.

Але міграція також є хорошим моментом, щоб видалити дублікати та застарілу schema, яку генерували старі плагіни або платформа.

Крок 13. Перевірте аналітику

Новий сайт може чудово працювати для користувача, але після запуску бізнес раптом «втрачає всі конверсії» в аналітиці.

Насправді просто забули перенести tracking.

До запуску потрібно перевірити:

• Google Analytics;
• Google Tag Manager;
• Meta Pixel;
• рекламні конверсії;
• CRM;
• call tracking;
• інші необхідні події.

Особливо важливо перевірити не тільки завантаження скрипта, а й конкретні події: відправку форми, покупку, дзвінок або іншу ціль.

Крок 14. Перевірте форми та інтеграції

Форма може візуально виглядати правильно і навіть показувати повідомлення «Успішно», але заявка при цьому не потрапляє в CRM.

До запуску потрібно пройти ключові сценарії вручну:

• заявка;
• email;
• CRM;
• Telegram;
• оплата;
• бронювання;
• завантаження файлу;
• інші бізнес-критичні інтеграції.

Крок 15. Створіть актуальний sitemap

Новий sitemap повинен містити актуальні канонічні URL нового сайту.

Після запуску його можна подати через Google Search Console.

Sitemap не гарантує індексацію всіх сторінок, але допомагає пошуковій системі швидше дізнатися про актуальну структуру.

Крок 16. Використовуйте Search Console після запуску

Після міграції важливо не просто закрити задачу й забути про сайт.

У Search Console варто контролювати:

• індексацію;
• 404;
• redirect errors;
• canonical;
• Core Web Vitals;
• sitemap;
• покази та кліки;
• сторінки, які раптово зникли з пошуку.

Для критичних URL можна використовувати URL Inspection.

Коли потрібен Change of Address

Інструмент Change of Address у Google Search Console потрібен не для будь-якої міграції.

Він актуальний, коли сайт переїжджає на інший домен або субдомен.

Якщо ви просто перейшли з Tilda на іншу технологію, але залишили той самий домен і URL, Change of Address не потрібен.

Як довго тримати 301 редиректи

Google рекомендує зберігати редиректи після зміни URL якомога довше і загалом щонайменше один рік.

З точки зору користувача часто є сенс залишати важливі редиректи й довше, особливо якщо старі адреси продовжують зустрічатися у зовнішніх джерелах.

При цьому власні внутрішні посилання краще оновити на фінальні URL, щоб користувачі не проходили через зайві перенаправлення.

Чи потрібно змінювати домен при переході з конструктора

Ні.

Технологія сайту і домен — різні речі.

У більшості міграцій бізнес може залишити свій поточний домен і просто направити його на нову інфраструктуру.

Якщо бренд не змінюється, немає SEO-причини купувати новий домен лише тому, що сайт більше не працює на Tilda або Wix.

Чи потрібно змінювати дизайн під час міграції

Не обов’язково.

Існують щонайменше три сценарії:

Перенести дизайн максимально близько до оригіналу

Підходить, якщо проблема лише в технічній платформі.

Зробити контрольований редизайн

Оновити окремі компоненти, mobile UX або структуру, не змінюючи все одночасно.

Повністю перебудувати продукт

Потрібно, якщо сайт морально, структурно й технічно застарів.

Але в третьому сценарії це вже не просто міграція, а повноцінний redesign або rebuild.

Коли міграція перетворюється на нову розробку

Не все можна коректно назвати «перенесенням».

Наприклад, сайт може містити:

• великий товарний каталог;
• складний checkout;
• особистий кабінет;
• ролі користувачів;
• базу даних;
• booking engine;
• ERP;
• marketplace-функціональність;
• складні API.

У такій ситуації бізнес-логіку часто потрібно проєктувати й реалізовувати заново.

Це не означає, що такий сайт неможливо перенести.

Це означає, що оцінювати його як «копіювання десяти сторінок з конструктора» буде неправильно.

Чи завжди custom-сайт дешевший за конструктор

Ні.

У конструктора є підписка, але у власної розробки також є витрати:

• хостинг;
• домен;
• підтримка;
• оновлення;
• доробки;
• моніторинг;
• робота розробника.

Для простого лендингу конструктор може залишатися дешевшим роками.

Індивідуальна технічна основа стає економічно цікавішою тоді, коли бізнесу потрібні контроль, нестандартні функції, масштабування або інша архітектура.

Тому міграцію краще обґрунтовувати бізнес-потребою, а не універсальною математикою «підписка завжди дорожча».

Чи завжди конструктор повільніший

Теж ні.

Добре зібрана сторінка на конструкторі може працювати швидше за погано розроблений custom-сайт.

Індивідуальна розробка дає більше контролю над ресурсами, JavaScript, завантаженням, компонентами та серверною частиною.

Але сам контроль не є гарантією якості.

Тому рішення про міграцію має базуватися на аудиті конкретного сайту, а не на назві платформи.

Що перевірити за день до запуску

1. Усі важливі старі URL враховані.
2. Карта редиректів готова.
3. 301/308 ведуть на релевантні сторінки.
4. На production немає випадкового noindex.
5. robots.txt не блокує важливі сторінки.
6. Canonical правильні.
7. Title та description перенесені або свідомо оновлені.
8. Hreflang працює.
9. Форми надсилають заявки.
10. Аналітика записує події.
11. Основні сторінки працюють на mobile.
12. 404 перевірені.
13. Sitemap містить актуальні URL.
14. Є резервний план на випадок критичної помилки.

Що перевірити після запуску

У перші дні та тижні потрібно контролювати не тільки дизайн.

Важливі показники:

• органічні кліки;
• покази;
• індексація;
• 404;
• робота редиректів;
• серверні помилки;
• заявки;
• рекламні конверсії;
• швидкість;
• Core Web Vitals.

Невеликі коливання пошукової видимості під час великого переходу можливі.

Але різке зникнення великої частини сторінок або трафіку — це привід перевірити технічну реалізацію, а не просто чекати.

Підхід TimeKairos

У TimeKairos ми не починаємо міграцію з твердження, що Tilda, Wix або Webflow «погані».

Спочатку потрібно зрозуміти, що саме бізнес хоче змінити і чи потрібен для цього повний переїзд.

Якщо міграція виправдана, ми розглядаємо її як роботу з двома шарами одночасно:

• новою технічною реалізацією;
• збереженням цінних сигналів і структури старого сайту.

Тому до запуску важливі не тільки дизайн і код, а й URL mapping, редиректи, метадані, canonical, sitemap, мультимовність, аналітика та ручне тестування ключових сценаріїв.

Для простого презентаційного сайту це може бути відносно компактна задача.

Для e-commerce, кабінету або сервісу з серверною логікою правильніше говорити вже про replatforming або нову розробку.

Висновок

Міграція з Tilda, Wix, Webflow або іншого конструктора не повинна починатися з копіювання дизайну.

Вона повинна починатися з інвентаризації того, що сайт уже має: URL, контент, пошуковий трафік, зовнішні посилання, метадані, інтеграції та бізнес-логіку.

Технологію можна змінити.

Але накопичені роками сигнали не варто випадково викидати разом зі старою платформою.

Хороша міграція — це коли користувач бачить кращий сайт, а пошукова система максимально чітко розуміє, що старий контент не зник, а правильно переїхав.