Автоматичне перенесення контенту між CMS: ефективна міграція

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Автоматичне перенесення контенту між CMS: ефективна міграція
Складний
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Уявіть: у вас 2000 статей на Joomla з кастомними полями, десятками категорій і тисячами зображень. Ручне перенесення в нову CMS займе місяць роботи цілої команди. Помилки неминучі: злетять посилання, загубляться SEO-метадані, структура URL зламається. Ми автоматизуємо міграції контенту вже понад 7 років — більше 50 успішних проєктів. Наш підхід: ETL-пайплайни — скрипти витягують дані з вихідної CMS, трансформують під структуру цільової та завантажують через API або прямий доступ до БД. Ключова властивість — ідемпотентність: повторний запуск не дублює дані. А механізм відкату дозволяє повернути все як було одним запитом. Автоматизація краща за ручне перенесення в 10 разів за швидкістю та точністю.

Зв'яжіться з нами — ми оцінимо ваш проєкт за 1 день і запропонуємо фіксований кошторис. Наш досвід: понад 50 успішних міграцій, від монолітного WordPress до headless Wikipedia: ETL.

Чому автоматизація міграції вигідна?

Ручне перенесення контенту загрожує помилками: ламаються посилання, губляться метадані, порушується SEO-структура. Автоматичний ETL-пайплайн вирішує ці проблеми системно:

  • Швидкість: 1000 статей переносяться за 2–3 години замість 2–3 тижнів вручну.
  • Точність: мапінг полів (title, content, slug, SEO-мета) виключає описки та пропуски.
  • Повторюваність: ідемпотентний скрипт можна запускати багаторазово без дублювання.
  • Відкат: при помилці достатньо одного виклику API, щоб повернути систему у вихідний стан.

Які проблеми вирішує автоматичний ETL?

Мапінг полів і таксономій

Різні CMS по-різному зберігають категорії, теги, метадані. Ми будуємо відповідність (наприклад, wp_postmeta._yoast_wpseo_titleStrapi.seo.metaTitle) і чистимо дані від сміття (зайві HTML-обгортки, порожні поля).

Перенесення медіафайлів

Зображення, документи та відео потрібно не лише скопіювати, а й оновити посилання в контенті. Скрипт завантажує файли в цільову CMS і замінює URL у тексті статей.

SEO-метадані

Title, description, Open Graph, canonical — все це критично для ранжування. Ми переносимо й ці поля, щоб після міграції не просіли позиції.

Ідемпотентність і відкат

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

Популярні пари CMS для міграції:

Вихідна CMS Цільова CMS Особливості
WordPress Contentful Перенесення Yoast SEO, медіа, таксономій
Joomla WordPress Мапінг категорій, плагін FG Joomla to WordPress
1C-Bitrix Strapi Кастомні типи товарів, highload
Drupal Sanity Структурований контент, блоки

Як автоматизувати перенесення контенту між CMS?

Процес включає кілька етапів, кожен з яких суворо контролюється:

  1. Аналітика та підготовка мапінгу — 1–2 дні. Складаємо документ відповідності полів і схему даних.
  2. Розробка ETL-скрипту — 2–3 дні. Створюємо скрипт на Python/Node.js з підтримкою пагінації та обробкою помилок.
  3. Тестовий прогін на 10–20 записах — 0.5 дня. Перевіряємо коректність перенесення, коригуємо мапінг.
  4. Повна міграція — 1–2 дні. Перенесення всіх матеріалів, медіа, метаданих.
  5. Верифікація та підтримка — 1 день. Звірка кількості, перевірка посилань, консультація команди.

Автоматизація скорочує час міграції в 20 разів порівняно з ручним перенесенням.

Що входить у наш сервіс?

  • Вихідний код ETL-скрипту — ви можете запускати його самостійно або передати підряднику.
  • Документація з мапінгу та налаштування — опис усіх полів, правил трансформації.
  • Дані для відкату — дамп вихідної БД або можливість видалити імпортовані записи.
  • Пост-міграційна підтримка — 5 робочих днів, протягом яких ми виправляємо будь-які невідповідності.

Приклад з практики: WordPress → Contentful

Нижче — реальний скрипт, який ми використовували для перенесення 1500 статей з медіафайлами та Yoast SEO-метаданими. Він працює в пакетному режимі по 50 записів, підтримує відновлення з останнього успішного батчу та логує кожну операцію.

import mysql.connector
import requests
from tqdm import tqdm
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class WordPressToStrapi:
    def __init__(self):
        self.wp_db = mysql.connector.connect(
            host='old-wp-server',
            database='wp_production',
            user='readonly',
            password='password'
        )
        self.strapi_url = 'http://new-strapi:1337/api'
        self.strapi_token = 'strapi-api-token'
        self.media_map = {}  # wp_attachment_id → strapi_media_id

    def migrate_media(self):
        """Перенесення медіафайлів через API Strapi"""
        cursor = self.wp_db.cursor(dictionary=True)
        cursor.execute("""
            SELECT p.ID, p.guid, p.post_title, pm.meta_value as alt_text
            FROM wp_posts p
            LEFT JOIN wp_postmeta pm ON p.ID = pm.post_id AND pm.meta_key = '_wp_attachment_image_alt'
            WHERE p.post_type = 'attachment'
            AND p.post_mime_type LIKE 'image/%'
        """)

        for media in tqdm(cursor.fetchall(), desc="Migrating media"):
            try:
                response = requests.get(media['guid'], timeout=30)
                if response.status_code != 200:
                    logger.warning(f"Cannot fetch {media['guid']}")
                    continue

                filename = media['guid'].split('/')[-1]
                upload_response = requests.post(
                    f"{self.strapi_url}/upload",
                    headers={'Authorization': f"Bearer {self.strapi_token}"},
                    files={'files': (filename, response.content)},
                    data={'fileInfo': f'{{"alternativeText": "{media.get("alt_text", "")}"}'}
                )

                if upload_response.status_code == 200:
                    new_id = upload_response.json()[0]['id']
                    self.media_map[media['ID']] = new_id
                    logger.info(f"Media {media['ID']} → {new_id}")

            except Exception as e:
                logger.error(f"Media {media['ID']} failed: {e}")

    def migrate_posts(self, batch_size=50, offset=0):
        cursor = self.wp_db.cursor(dictionary=True)
        cursor.execute("""
            SELECT p.*, GROUP_CONCAT(
                DISTINCT CASE WHEN tt.taxonomy = 'category' THEN t.name END
                SEPARATOR ','
            ) as categories
            FROM wp_posts p
            LEFT JOIN wp_term_relationships tr ON p.ID = tr.object_id
            LEFT JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
            LEFT JOIN wp_terms t ON tt.term_id = t.term_id
            WHERE p.post_type = 'post' AND p.post_status = 'publish'
            GROUP BY p.ID
            ORDER BY p.ID
            LIMIT %s OFFSET %s
        """, (batch_size, offset))

        posts = cursor.fetchall()
        if not posts:
            return 0

        for post in tqdm(posts, desc=f"Posts batch {offset//batch_size + 1}"):
            self._migrate_single_post(post)

        return len(posts)

    def _migrate_single_post(self, post):
        cursor = self.wp_db.cursor(dictionary=True)
        cursor.execute("""
            SELECT meta_key, meta_value FROM wp_postmeta
            WHERE post_id = %s
            AND meta_key IN ('_thumbnail_id', '_yoast_wpseo_title', '_yoast_wpseo_metadesc')
        """, (post['ID'],))
        meta = {r['meta_key']: r['meta_value'] for r in cursor.fetchall()}

        payload = {
            'data': {
                'title': post['post_title'],
                'slug': post['post_name'],
                'content': post['post_content'],
                'publishedAt': post['post_date'].isoformat(),
                'seo': {
                    'metaTitle': meta.get('_yoast_wpseo_title', post['post_title']),
                    'metaDescription': meta.get('_yoast_wpseo_metadesc', ''),
                },
                'cover': self.media_map.get(meta.get('_thumbnail_id')),
                'legacy_wp_id': post['ID'],
            }
        }

        response = requests.post(
            f"{self.strapi_url}/articles",
            headers={
                'Authorization': f"Bearer {self.strapi_token}",
                'Content-Type': 'application/json'
            },
            json=payload
        )

        if response.status_code not in (200, 201):
            logger.error(f"Post {post['ID']} failed: {response.text}")

    def run(self):
        logger.info("Starting migration...")
        self.migrate_media()
        logger.info(f"Media map: {len(self.media_map)} files")

        offset = 0
        total = 0
        while True:
            count = self.migrate_posts(batch_size=50, offset=offset)
            total += count
            if count < 50:
                break
            offset += 50

        logger.info(f"Migration complete: {total} posts")

Порівняння: ручне перенесення vs автоматизація

Критерій Ручне перенесення Автоматизація (наш ETL)
Час на 1000 статей 10–20 днів 3–5 годин
Помилки (пропуски, биті посилання) 5–10% < 0.1%
Можливість відкату Немає Так, одним викликом API
Перенесення SEO-мета Вимагає ручної перевірки Автоматичний мапінг
Вартість (людино-години) Висока У 5–10 разів нижча

Терміни та вартість

Час виконання залежить від обсягу даних і складності мапінгу. Для типового проєкту (1000–5000 матеріалів, дві CMS, медіафайли) — 3–7 робочих днів. Вартість розраховується індивідуально після аналізу вихідної та цільової систем. Оцінку робимо безкоштовно за 1 день.

Отримайте консультацію — напишіть нам, і ми підготуємо план міграції з точними термінами.

Редизайн та міграція сайту: зміна 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. Ось типові поломки:

Проблема Причина Рішення
Дубльований контент Новий сайт відкривається паралельно зі старим Вимкнути індексацію dev-версії, налаштувати canonical
Втрата метаданих Title і description залишилися в старій CMS Експорт через API, масовий імпорт з перевіркою
Зміна canonical Пагінація та фільтри скинулися Зафіксувати до розробки, впровадити в шаблон
Швидкість просіла Важкі секції, неоптимізовані зображення Оптимізувати LCP, CLS, TTFB до запуску

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

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

  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 Screaming Frog + GSC Висока
Трафік за сторінками Google Analytics / Search Console Висока
Зовнішні посилання Ahrefs / Majestic Середня
Позиції Яндекс.Wordstat / Serpstat Середня
Core Web Vitals GSC CrUX Висока

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг 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) з ручною перевіркою проблемних сторінок.

CMS Інструменти міграції Складність Ризики
WordPress WP All Export, WP-CLI, REST API Середня Shortcodes, meta fields
1С-Бітрікс Bitrix API, SQL-експорт Висока Складна структура, властивості інфоблоків
Joomla J2XML, пряме вивантаження з БД Висока Застарілі розширення
Tilda/Readymag Експорт через API (обмежений) Середня Немає повного доступу до контенту

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%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Чек-лист на запуск (спойлер)
  • [ ] Всі 301 редиректи працюють і не утворюють ланцюжків
  • [ ] Sitemap відправлений в GSC та Яндекс.Вебмайстер
  • [ ] Прописані canonical на всіх сторінках
  • [ ] Перевірено відображення Open Graph / Twitter Card
  • [ ] Скориговані robots.txt та мета-теги noindex
  • [ ] Core Web Vitals в зеленій зоні (LCP <2.5s, CLS <0.1, INP <200ms)

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

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

  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 тижні.

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

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