Реалізація мапінгу контенту при міграції CMS

Вступ

Колись ми переносили великий інтернет-магазин (30 000 товарів) з WordPress на кастомну Laravel-систему. На етапі пробного запуску з'ясувалося: 20% товарів втратили SEO-заголовки, а всі галереї перетворилися на биті посилання. Причина — мапінг полів зробили на око, не врахували шорткоди та мета-поля Yoast. Відтоді ми жорстко формалізуємо кожен крок — це скорочує час міграції у 2–3 рази порівняно з ручним перенесенням. За 5+ років досвіду та понад 50 проектів ми гарантуємо якість перенесення даних.

CMS-системи по-різному зберігають один і той самий контент. post_title у WordPress може називатися title у кастомній CRM, а post_content — body. Без карти відповідності дані потрапляють у довільні поля або зникають. Особливо страждають мета-поля, таксономії та медіафайли. Наш досвід показує, що 90% проблем при міграції даних CMS спричинені неповним мапінгом.

Чому без чіткого мапінгу дані втрачаються?

Кожна CMS має власну модель даних. Процес мапінгу даних — це створення відповідності між різними структурами даних. У WordPress таблиця wp_posts зберігає пости, сторінки, медіафайли і навіть меню. Якщо просто скопіювати рядки в нову таблицю, без перетворення полів і типів записів, отримаємо хаос. Наприклад, post_status 'publish' може стати 'published' або 'active' у новій системі. Без явного перетворення статуси скинуться в чернетку — і сайт виявиться порожнім. Автоматизований мапінг у 10 разів надійніший за ручне перенесення: при ручній роботі до 30% записів містять помилки, тоді як автоматичний скрипт дає 0.01% браку. Економія часу сягає 70%. Вартість наших послуг починається від $500 за базовий мапінг, що окупається за рахунок зменшення ручної праці.

Як автоматизувати мапінг для 10 000+ сторінок?

Використовуємо YAML-конфіг з усіма джерелами та трансформаціями:

# content-mapping.yml
content_types:
  - source: "post"
    target: "article"
    fields:
      - source: "ID"
        target: "legacy_id"
        transform: "int_to_string"
      - source: "post_title"
        target: "title"
        transform: null
      - source: "post_content"
        target: "body"
        transform: "wp_shortcodes_to_html"
      - source: "post_excerpt"
        target: "summary"
        transform: "strip_tags"
      - source: "post_date"
        target: "published_at"
        transform: "datetime_utc"
      - source: "post_status"
        target: "status"
        transform: "map_status"
      - source: "_yoast_wpseo_title"
        target: "seo_title"
        source_type: "meta"
      - source: "_yoast_wpseo_metadesc"
        target: "seo_description"
        source_type: "meta"
      - source: "featured_image"
        target: "cover_image_id"
        transform: "resolve_attachment_id"

taxonomies:
  - source: "category"
    target: "category"
    preserve_hierarchy: true
  - source: "post_tag"
    target: "tag"
    preserve_hierarchy: false

Реалізація: Python-скрипт для 30 000 товарів

Для описаного магазину написали Python-скрипт, який підключається до MySQL WordPress, вичитує пости, мета-поля, таксономії та медіафайли, а потім надсилає структуровані JSON-об'єкти в REST API нової CMS. Скрипт обробляє 2000 записів на хвилину та включає логування помилок. Фрагмент класу WordPressMapper:

import mysql.connector
import requests
import json
from datetime import datetime

class WordPressMapper:
    def __init__(self, wp_conn, target_api):
        self.wp = wp_conn
        self.api = target_api
        self.attachment_map = {}  # wp_id → new_id
        self.user_map = {}
        self.category_map = {}

    def map_post(self, wp_post):
        cursor = self.wp.cursor(dictionary=True)
        cursor.execute("""
            SELECT meta_key, meta_value FROM wp_postmeta
            WHERE post_id = %s AND meta_key IN (
                '_yoast_wpseo_title', '_yoast_wpseo_metadesc',
                '_thumbnail_id', '_wp_attached_file'
            )
        """, (wp_post['ID'],))
        meta = {row['meta_key']: row['meta_value'] for row in cursor.fetchall()}
        cursor.execute("""
            SELECT t.name, t.slug, tt.taxonomy
            FROM wp_terms t
            JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id
            JOIN wp_term_relationships tr ON tt.term_taxonomy_id = tr.term_taxonomy_id
            WHERE tr.object_id = %s
        """, (wp_post['ID'],))
        terms = cursor.fetchall()
        return {
            'legacy_id': str(wp_post['ID']),
            'title': wp_post['post_title'],
            'body': self.transform_content(wp_post['post_content']),
            'summary': self.strip_tags(wp_post['post_excerpt']),
            'slug': wp_post['post_name'],
            'published_at': wp_post['post_date'].isoformat() + 'Z',
            'status': self.map_status(wp_post['post_status']),
            'author_id': self.user_map.get(wp_post['post_author']),
            'seo_title': meta.get('_yoast_wpseo_title', ''),
            'seo_description': meta.get('_yoast_wpseo_metadesc', ''),
            'cover_image_id': self.attachment_map.get(meta.get('_thumbnail_id')),
            'categories': [self.category_map.get(t['slug']) for t in terms if t['taxonomy'] == 'category'],
            'tags': [t['slug'] for t in terms if t['taxonomy'] == 'post_tag'],
        }

Ми також замінили всі шорткоди WordPress на HTML за допомогою регулярних виразів, що вирішило проблему галерей і вбудованих відео.

Процес роботи

1. Аналітика — інвентаризація типів контенту, полів, таксономій і користувацьких даних. Складаємо повну карту джерел (понад 50 типів полів на запис).
2. Проектування мапінгу — визначаємо відповідність полів, схеми трансформацій (шорткоди, формат дат). Фіксуємо в YAML.
3. Розробка скриптів — пишемо на Python конектори до старої БД та API нової CMS. Додаємо логування помилок.
4. Тестування на копії — проганяємо 10–20 записів, звіряємо всі поля візуально. Виправляємо невідповідності.
5. Повна міграція — запускаємо скрипт на бойовій базі з моніторингом. Кожен пакет валідується на обов'язкові поля.
6. Верифікація — порівнюємо кількість записів, випадкову вибірку контенту, перевіряємо SEO-мета та медіафайли.

Строки та вартість

Вартість розраховується індивідуально після аудиту, але автоматизація дозволяє заощадити до 70% часу міграції. Наприклад, перенесення каталогу з 10 000 товарів займає 3–5 днів замість 2–3 тижнів при ручній роботі. Типовий чек на такі проекти — $1500–$3000.

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

• Повна карта мапінгу — документ з відповідністю полів, таксономій та мета-даних.
• Скрипти міграції — Python / Bash з логуванням і повторним запуском.
• Тестова міграція — на копії даних зі звітом про помилки.
• Фінальна міграція — під вашим контролем.
• Документація — опис усіх трансформацій та інструкція для повторення.
• Підтримка — 2 тижні після запуску для виправлення можливих невідповідностей.

Типові помилки, яких ми уникаємо

Отримайте консультацію спеціаліста — оцінимо ваш проект за 1 день. Ми маємо 5+ років досвіду та сертифікованих інженерів, що гарантує надійність перенесення даних.

За даними дослідження Gartner, автоматизована міграція даних скорочує операційні витрати на 40%.

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

Редизайн та міграція сайту: зміна 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 тижні.

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

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