Автоматический перенос контента между 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 — всё это критично для ранжирования. Мы переносим и эти поля, чтобы после миграции не просели позиции.

Idempotent и rollback

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

Популярные пары 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 месяца и обошлось в потерю выручки около 2 млн рублей за квартал. Наш опыт — более 7 лет и 80+ успешных миграций, гарантируем сохранение позиций при правильном подходе.

Почему миграции ломают 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-кэш для динамического поиска. Подробнее в Wikipedia: HTTP 301.

Миграция контента из разных 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
1C-Битрикс 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 недели.

Стоимость рассчитывается индивидуально по объёму. Средняя экономия клиента за счёт сохранения трафика после миграции — от 300 000 до 500 000 рублей в год.

Получите консультацию по вашему проекту — мы ответим в течение дня. Закажите предмиграционный аудит вашего сайта и получите точную смету с планом редиректов. Свяжитесь с нами, чтобы обсудить детали.