Міграція з Wix на кастомний сайт без втрати SEO

1. Визначте сценарій міграції та що означає “безпечно для SEO” для вашого сайту на Wix

Якщо ви замінюєте Wix кастомним розробленням, перше запитання просте: ви змінюєте дизайн, платформу чи і те, і інше? Відповідь впливає на ризики. Косметичне оновлення — це одне. Повний перехід на іншу платформу — зовсім інше. Ця стаття про те, як перейти з Wix на кастомну розробку сайту без втрати SEO, тобто сайт має зберегти проіндексовані сторінки, відповідність пошуковому наміру та наявну пошукову цінність, поки під капотом усе змінюється. Саме тому ми розглядаємо не просто редизайн, а саме міграцію з Wix без втрати SEO.

Думайте про це як про SEO-міграцію, а не просто про редизайн. Це важливо, бо редизайн може ігнорувати старі URL, а SEO-міграція повинна їх поважати. Якщо сторінка ранжується за запитами на кшталт “ціни”, “зона обслуговування” або назвою продукту, вона виконує свою роль. Вона не повинна зникнути лише тому, що новий макет виглядає охайніше.

Є й практична різниця між “ми хочемо кращий сайт” і “ми хочемо зберегти пошукові показники”. Перше — це бренд-проєкт. Друге — контрольована передача. Якщо нинішній сайт на Wix має 40 проіндексованих сторінок, то для 40 сторінок потрібен план, навіть якщо комерційно важливими є лише 12.

Не починайте зі створення макетів. Почніть із визначення того, що має пережити міграцію: позиції, проіндексовані URL, пошукові сніпети та сторінки, які приносять ліди або продажі. Маленька деталь, великий наслідок. Гарна головна сторінка не допоможе, якщо старі сервісні сторінки зникнуть із Google.

2. Створіть базову SEO-рамку міграції, перш ніж торкатися сайту

Перед будь-якими змінами коду зафіксуйте поточний стан сайту на Wix в одному місці. Складіть список проіндексованих URL, title-тегів, meta description, H1, внутрішніх посилань і сторінок конверсії. Додайте все, що потрібно, щоб міграція була впорядкованою та щоб потім можна було відстежувати зміни. Без цієї бази міграція Wix перетворюється на здогадки, а здогадки дорогі.

Витягніть найкращі сторінки входу з Search Console та аналітики, а потім порівняйте їх зі сторінками, які, на вашу думку, є важливими. Ці два списки часто різні. Блог-публікація, написана два роки тому, може приносити більше пошукового трафіку, ніж головна сторінка. Забута сервісна сторінка може конвертувати краще за новішу. Спочатку цифри, потім думки.

Зафіксуйте також поточні шаблони title і meta description. На Wix часто є повторюваний шаблон для багатьох сторінок, і коли він зникає, показник клікабельності може змінитися. Навіть невелика зміна формулювання має значення, якщо запит вузький. Сторінка про “індивідуальні кухонні шафи” — не місце для поетики. У межах підготовки обов’язково проведіть SEO аудит сайту Wix перед міграцією, щоб не втратити критичні сигнали.

Також зафіксуйте карту внутрішніх посилань. Які сторінки ведуть на сторінку контакту? Які блог-пости посилаються на головну сервісну сторінку? Які сторінки заховані в меню? Ці посилання — частина SEO-міграції, бо вони підказують пошуковим системам, які сторінки найважливіші.

Використовуйте таблицю щонайменше з такими стовпцями: поточний URL, тип сторінки, джерело трафіку, title-тег, meta description, canonical, індексація та новий цільовий URL. Зробіть таблицю читабельною. Якщо інша людина не може розібратися в ній за 10 хвилин, вона надто хаотична.

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

У Wix є шаблони, які легко не помітити під час переробки. Блог-пости можуть бути розміщені в структурованій папці. Системні сторінки можуть жити за шляхами, які ви не обирали. Сторінки, створені застосунками, форми та івент-сторінки також можуть стати індексованими, якщо вони були відкриті для пошукових систем. Саме тут міграція з Wix часто йде не так.

Уважно перевірте поточну структуру URL. Зверніть увагу на кінцеві слеші, відмінності між нижнім і верхнім регістром, параметризовані URL та дивні системні сегменти. Якщо одна стаття знаходиться за /post/, а інша — за /blog/post-title, не припускайте, що нова CMS автоматично відтворить це. Вона цього не зробить.

URL зображень також мають значення. Кастомна збірка може змінити шляхи до зображень, але якщо ці файли індексуються або вбудовані на багатьох сторінках, биті посилання на зображення можуть створити шум і сповільнити відновлення. Те саме стосується PDF, файлів для завантаження та галерейних ресурсів. Один битий файл може вплинути одразу на кілька сторінок.

Wix також дозволяє функції, які виглядають дрібними, але поводяться як справжні сторінки. Подумайте про віджети бронювання, відгуки, списки подій або сторінки зони для учасників. Якщо будь-що з цього було індексоване, для нового сайту потрібно ухвалити рішення щодо кожного елемента: залишити, об’єднати чи прибрати. Без проміжних варіантів.

Це міст між плануванням і виконанням. Чистий аудит URL показує, які частини міграції Wix є звичайними, а які — пастками. Якщо цей крок пропустити, першою ознакою проблеми може стати падіння трафіку через два тижні після запуску.

4. Прив’яжіть кожну важливу сторінку Wix до її заміни на кастомному сайті

Кожна важлива сторінка Wix потребує плану заміни один до одного. Не один до багатьох. Не “розберемося пізніше”. Для кожної сторінки має бути цільовий URL, відповідність контенту, відповідність метаданих і план внутрішніх посилань. Якщо стара сторінка ранжувалася, нова має мати чітку наступницю.

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

Деякі сторінки слід об’єднати. Набір слабких сервісних сторінок може стати однією сильнішою сторінкою на новому сайті. Деякі, навпаки, слід розділити. Широка сторінка “послуги” може перетворитися на три сфокусовані сторінки. Рішення залежить від пошукового наміру, а не від смаку в дизайні.

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

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

5. Збережіть on-page SEO-сигнали під час кастомної розробки

Кастомна розробка має перенести сигнали, які вже працюють: заголовки, структуру тексту, schema, alt-тексти та контекст внутрішніх посилань. Якщо стара сторінка Wix мала чітку структуру H2 і корисний блок FAQ, нова сторінка не повинна замінювати це шістьма загальними маркетинговими абзацами. Пошукові системи читають структуру, а не настрій.

Зберігайте логіку заголовків близькою до початкового наміру. Якщо сторінка на Wix відповідала на конкретний запит у перших 100 словах, нова сторінка має робити те саме. Якщо на сторінці була таблиця порівняння продуктів, збережіть її або замініть рівноцінним за користю форматом. Одне слабке рішення може знизити релевантність.

Schema потребує окремої уваги. Кастомний сайт спрощує додавання структурованих даних, але це не означає, що стару розмітку слід бездумно викидати. Якщо сторінка Wix використовувала schema для Article, LocalBusiness, Product або FAQ, порівняйте нову реалізацію перед запуском. Зміни шаблону можуть вплинути на те, як пошукові системи інтерпретують сторінку.

Alt-текст не слід перетворювати на набір ключових слів. Він має бути описовим, конкретним і пов’язаним із зображенням. Якщо на зображенні фасад магазину або фото команди, скажіть про це прямо. Суть у доступності та контексті, а не в нашаруванні фраз у кожне ім’я файлу.

Контекст внутрішніх посилань важливіший, ніж думає більшість команд. Якщо сервісна сторінка раніше посилалася на дві пов’язані статті та одну сторінку контакту, збережіть ці посилання в новому кастомному шаблоні. Пошукові системи йдуть цими шляхами. Користувачі також. Два кліки можуть вирішити, чи буде ліда, чи буде відскок.

6. Обробіть редиректи, canonical і індексацію під час запуску

Етап запуску — це момент, коли більшість помилок SEO-міграції стають помітними. Кожен старий URL Wix, який змінюється, потребує 301-редиректу на найкращу нову адресу. Не 302. Не загальний редирект на головну. Справжній редирект на рівні сторінки. Якщо для сторінки немає еквівалента, перенаправте її на найближчу релевантну сторінку або свідомо приберіть.

Canonical-теги мають вказувати на переважну версію кожної сторінки, особливо якщо новий сайт створює альтернативні шляхи, фільтровані перегляди або залишки staging-версії. Дублікати URL — звична річ під час міграції Wix, бо старі й нові шляхи деякий час можуть існувати паралельно. Якщо не контролювати canonical, ви створюєте дубльовані сигнали.

Правила robots потребують такої самої уваги. Тег noindex, залишений на live-сторінці після staging, може блокувати індексацію на кілька днів. Пропущене правило disallow може дозволити пошуковим системам сканувати сміттєві шляхи. Маленька помилка — велика затримка. Чеклист запуску має включати оновлення sitemap, перевірку canonical і валідацію редиректів перед запуском.

Оновіть XML sitemap так, щоб у ньому були лише фінальні live-URL. Якщо sitemap досі містить старі сторінки Wix, пошукові системи можуть продовжувати повертатися до мертвих шляхів. Це уповільнює виявлення нових сторінок і робить перехід неохайним.

Запуск без редиректів — це не міграція. Це інцидент із поломкою. Якщо стара сторінка мала позиції, трафік або зворотні посилання, редирект — це міст. Приберіть цей міст, і решту роботи буде складніше відновити.

7. Перевіряйте живу міграцію за допомогою краулера, а не лише браузера

Після запуску тестуйте сайт за допомогою краулера, а не тільки в Chrome. Браузери приховують проблеми. Краулери їх знаходять. Сторінка може виглядати ідеально для людини, але все одно повертати неправильний статус-код, проходити через два редиректи або віддавати дублікат canonical.

Почніть із найцінніших URL із вашої базової вибірки. Переконайтеся, що кожен із них повертає 200, за можливості відкривається в один крок і містить правильні метадані. Потім перевірте 404, 500, цикли редиректів і сторінки, заблоковані правилами robots. Саме тут у міграції Wix невеликий промах у QA може залишатися прихованим тижнями.

Перевірте також відповідність метаданих. Title і description мають бути на пріоритетних сторінках, а не порожні або скопійовані з головної. Попередній перегляд у браузері не покаже, що meta description не додано. Краулер покаже.

Також перевірте внутрішні посилання після запуску. Якщо старий футер Wix і далі веде на прибрані шляхи, користувачі потраплятимуть на биті сторінки, а краулери витрачатимуть час даремно. Те саме стосується кнопок, посилань у зображеннях і модулів пов’язаних публікацій. Кастомна збірка часто додає нові шаблони, і кожен шаблон потребує щонайменше одного проходу краулера.

Якщо можливо, порівняйте до- та післязапускові експорти краулу поруч. Мета — не ідеальність у перший день. Мета — швидке виявлення. Звіт про краул із 5 битими шляхами корисний. Чекати, поки їх індексується 50, — ні.

8. Відстежуйте відновлення SEO після запуску та швидко виправляйте слабкі місця

Перші тижні після запуску вирішують, чи перехід стабілізується швидко, чи буде “плавати”. Спочатку щодня, а потім рідше, коли картина стабілізується, відстежуйте індексацію, покази, позиції та трафік на сторінки входу. Якщо ключова сторінка втрачає видимість, спочатку перевірте редиректи, canonical і контент сторінки, а вже потім щось інше.

Биті внутрішні посилання після редизайну — часта проблема, особливо коли стара навігація Wix замінюється новою бібліотекою компонентів. Перевірте меню, футери, блоки пов’язаного контенту та кнопки на відсутні посилання. Одне відсутнє посилання на сторінці з високим трафіком може зменшити crawl flow на решту сайту.

Слідкуйте також за помилками noindex. Правило staging, умова шаблону або скопійований header можуть вивести важливі сторінки з індексу. Такі помилки трапляються частіше, ніж команди визнають. На їх створення потрібні хвилини, на виявлення — дні.

Слідкуйте за змінами метаданих, які здаються нешкідливими. Переписаний title-тег може змінити поведінку кліків. Більш короткий вступ може послабити релевантність. Видалений FAQ може зменшити охоплення long-tail запитів. Усе це не означає, що кастомний сайт поганий. Це означає, що SEO-міграція потребує коригування.

У певний момент сайт перестає змінюватися, а дані стабілізуються. Тоді можна вважати SEO-міграцію завершеною. До того часу робота ще триває. Новий кастомний сайт вважається готовим лише тоді, коли старі URL Wix, нові сторінки та пошукові дані погоджуються, де саме має бути кожна сторінка.