Як зберегти SEO-позиції при міграції сайту?

Уявіть: ви переїжджаєте на новий движок, а в день запуску бачите порожні title і 404 на кожній сторінці. Втрата позицій за одним високочастотним запитом може коштувати значних втрат щомісяця. Така ситуація зустрічається на десятках проєктів. Без правильного перенесення SEO-даних і редиректів пошукова видача обнуляється за кілька годин, а відновлення займає місяці. Наш підхід — автоматизація експорту, ручна валідація та детальний чек-лист. Автоматизація скорочує час перенесення в 3-4 рази порівняно з ручним копіюванням, а ручна валідація ключових сторінок виключає помилки маппінгу. Ми вже перенесли SEO-дані для 50+ проєктів — від невеликих блогів до інтернет-магазинів з 15 000 товарів.

Як ми переносимо мета-теги без втрат?

Основні причини втрат — різні формати зберігання мета-полів у старій та новій CMS, відсутність маппінгу URL та «забуті» редиректи плагінів. Наприклад, у WordPress (Yoast) мета-теги лежать у wp_postmeta з ключами _yoast_wpseo_title, а в новій headless CMS — у полі seo.metaTitle JSON-об'єкта. Ми автоматично трансформуємо структуру, зберігаючи всі зв'язки. Для цього пишемо Python-скрипт, який читає стару БД, маппить поля на нову схему та завантажує через REST API. Це виключає людські помилки та прискорює перенесення.

Ключовий момент: ми не просто копіюємо поля, а перевіряємо їх коректність на етапі імпорту. Наприклад, довжина meta description не має перевищувати 160 символів — скрипт автоматично обрізає зайве та зберігає в журнал. Згідно з Google Search Central, canonical URL обов'язковий для уникнення дублювання.

Перелік перенесених даних

Окрім основних мета-тегів, ми переносимо hreflang-атрибути, canonical URL, розмітку Schema.org, а також alt-тексти зображень. Кожен елемент критичний для збереження позицій. Наприклад, відсутність canonical може викликати дублювання сторінок, що веде до штрафів за контент. Ручна перевірка 100 сторінок займає близько 5 годин, автоматизована — 10 хвилин, що в 30 разів швидше.

Чому редиректи критичні для SEO?

Навіть одне «бите» посилання може коштувати кількох позицій. Принцип: кожен старий URL має повертати 301 на релевантний новий. Згідно з HTTP/1.1 specification, 301 редирект передає вагу сторінки. Ми не допускаємо ланцюжків редиректів (301 → 302), глибше одного кроку. Налаштування через nginx map-файл дає нульову затримку і не навантажує CMS. (Приклад конфігурації nginx map для редиректів опущено через технічні обмеження.)

Для порівняння, плагін Redirection у WordPress створює 301 редиректи через PHP, що сповільнює відповідь сервера. nginx map працює на рівні ядра, забезпечуючи мінімальний TTFB.

Як ми перевіряємо результат?

Після імпорту запускаємо скрипт валідації, який обходить всі старі URL з sitemap.xml та перевіряє:

• Код відповіді (301 або 200) — не 404 і не 500.
• Наявність <title> та <meta name="description"> на цільових сторінках.
• Збіг canonical URL з цільовим.
• Відсутність ланцюжків редиректів.

Для найважливіших сторінок (landing, категорії з великим трафіком) проводимо ручну перевірку: порівнюємо старі та нові мета-теги, дивимося індексацію в Search Console. Типові помилки при міграції:

• Використання 302 замість 301 (тимчасові редиректи не передають вагу).
• Забуті редиректи плагінів (наприклад, Redirection не експортує всі правила).
• Відсутність маппінгу для кастомних полів (ACF, Pods).

Всі ці помилки ми виявляємо на етапі аудиту та виправляємо до запуску.

Як ми переносимо SEO-дані: покроково

1. Аудит старої CMS — визначаємо всі джерела SEO-полів: плагіни, кастомні метабокси, ACF.
2. Експорт в універсальний JSON — скрипт на Python вивантажує дані з БД WordPress (або іншої CMS).
3. Трансформація під нову CMS — маппінг полів: _yoast_wpseo_title → seo.metaTitle, _yoast_wpseo_robots → seo.metaRobots.
4. Імпорт через REST API — пакетне завантаження з контролем помилок (таймаути, дублікати).
5. Генерація редиректів — створення CSV-файлу old_url, new_url, 301 та nginx map-конфігу.
6. Валідація — перевірка всіх URL на 404, 301-ланцюжки, наявність мета-тегів та Schema.org.

Кейс: Мігрували інтернет-магазин з 15 000 товарів з WordPress (WooCommerce) на Strapi + Next.js. Старі URL категорій змінили структуру — /category/electronics → /catalog/electronics. Написали маппінг через CSV, завантажили 12 000 редиректів за 2 дні. Результат: позиції за 90% запитів не змінилися, трафік виріс на 3% завдяки прискоренню сайту. Лише за рахунок автоматизації ми заощадили клієнту значний час і кошти.

При перенесенні 10 000 сторінок кожен URL обробляється індивідуально.

Що входить у роботу?

• Повна карта старих та нових URL (всі сторінки, включаючи архівні).
• Експорт усіх SEO-полів (title, description, OG, Schema.org, hreflang).
• Генерація та налаштування 301-редиректів (nginx map або CSV).
• Імпорт даних у нову CMS через API.
• Валідація з автоматичним звітом (статуси, помилки).
• Ручна перевірка топ-20 сторінок за трафіком.
• Документація щодо процесу та передача доступів.

Терміни та умови проведення робіт

Повний перенос SEO-даних (експорт, імпорт, редиректи, валідація) займає від 2 до 5 робочих днів залежно від обсягу та складності. Умови розраховуються індивідуально — залежить від кількості сторінок, числа CMS-полів та необхідності кастомних трансформацій. Зв'яжіться з нами — оцінимо ваш проєкт за один день.

Чому обирають нас?

• Досвід понад 5 років у веб-розробці та міграціях.
• 50+ успішних проєктів із перенесення SEO-даних.
• Гарантія збереження позицій — якщо через нашу помилку позиції впали, виправляємо безкоштовно.
• Сертифіковані інженери з WordPress, Strapi, Next.js.

Хочете уникнути втрати трафіку при міграції? Замовте аудит SEO-перенесення прямо зараз — отримайте консультацію та попередній план робіт протягом дня.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

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

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

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

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти 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%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.