Редизайн та міграція сайту: зміна CMS, збереження SEO
Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік упав на 70%». Відкриваю Google Search Console — 847 сторінок отримують 404, URL-структура повністю змінилась, не було жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції рухнули. Відновлення зайняло 4 місяці.
Чому міграції ломають SEO
Поскільки рушії індексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 став /products/nike-air-max-270 без 301-редиректу — весь ссилочний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google говорить, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.
Найчастіше SEO ломають не з злого умислу, а тому що розробник не думає про URL-структуру як про публічний API.
Типові поломки при міграції:
Дублювання контенту. Новий сайт відкривається на старому домені і новому під час розробки. Googlebot індексує обидва — дубліката.
Втрата метаданих. Title та description були у кастомних полях WordPress, у новій CMS їх забули перенести для 500+ сторінок. Google підставляє що попало.
Зміна canonical. Сторінки пагінації, фільтри каталогу — canonical посилання скинулись на новий формат.
Падіння швидкості. Tilda з важкими секціями, без оптимізації зображень: LCP 6.8s замість 2.1s на старому сайті. Core Web Vitals у червоній зоні впливають на ранжування.
Предміграційний аудит: що нельзя пропустити
До початку розробки нового сайту потрібно:
- Зробити повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексується URL з трафіком з Google Search Console.
- Виписати всі сторінки з органічним трафіком > 0 за останні 6 місяців — це пріоритет для редиректів.
- Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
- Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
- Зберегти Core Web Vitals з Search Console за попередні 90 днів.
Маппінг URL та редиректи
Для проекту з 200+ сторінками створюємо таблицю маппінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: реально контент переїхав саме сюди.
У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та управляємо. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних.
Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.
Міграція контенту з різних CMS
WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перегружаємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes у контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація на новий формат.
1С-Бітрикс → сучасний стек:
Бітрикс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрикса.
Важкі WYSIWYG → структурований контент: Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, сломані атрибути. HTML sanitize + трансформація у Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.
SEO-збереження технічних елементів
Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути й на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.
Sitemap XML: генерується автоматично, відправляється у GSC через день після запуску. Старий sitemap залишається до повної переіндексації.
hreflang для багатомовних сайтів: якщо теги втрачені при міграції, через кілька тижнів почнуться конфлікти між мовними версіями у видачі.
Open Graph та Twitter Card мета-теги — часто забувають при смені шаблону, сторінки перестають коректно відображатися при шерингу у соцмережах.
Запуск та моніторинг перших тижнів
DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск з запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.
Після запуску щодня моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулинг сайту на 404-помилки.
Перші 2 тижні — критичний період. Якщо трафік упав на 30%+ — негайний аудит редиректів та порівняння з предміграційним краулом.
Процес роботи
Предміграційний аудит → маппінг URL → розробка нового сайту паралельно зі старим → фінальний аудит перед запуском → запуск з моніторингом → постміграційний моніторинг 4–8 тижнів.
Строки
Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів. Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів. Тільки технічна частина міграції (редиректи, метаданих) без редизайну: 1–3 тижні.