Перенос между CMS: сохранение контента и SEO-позиций

WordPress с 10 000 записей, headless-архитектура для мультиканальной публикации — типичный сценарий, где прямой экспорт-импорт ломает SEO и структуру. Схемы данных несовместимы, медиафайлы в привязках, Rich Text теряет форматирование. Мы решаем эту задачу через ETL-пайплайн с батчингом и повторной обработкой. За 5 лет провели 30+ миграций — от WP→Strapi до Drupal→Contentful. Экономия бюджета достигает 40% (до 200 000 руб. на проекте с 5000 записей) за счёт автоматизации в сравнении с ручной миграцией. Наша команда имеет 10+ лет опыта в веб-разработке, что гарантирует надёжность переноса.

Обычный дамп базы не работает: 60% времени уходит на трансформацию. Маппинг типов контента, перестройка таксономий, конвертация Rich Text — каждый этап требует своего подхода.

Как подготовить данные к миграции?

Первый шаг — инвентаризация. Собираем схему: типы контента, поля, таксономии, метаданные. Для WordPress это посты, страницы, пользователи, шорткоды; для Contentful — модели и локали. Маппинг делаем вручную с участием вашей команды — это гарантирует 100% перенос.

Маппинг типов контента

Такой маппинг ложится в основу скриптов трансформации.

Почему ETL-пайплайн быстрее ручного переноса?

ETL — Extract–Transform–Load — позволяет автоматизировать даже сложные преобразования. Батчинг по 50 записей с задержкой 500 мс ускоряет процесс в 3 раза по сравнению с поштучной обработкой. Пример скрипта:

// scripts/cms-migration.ts
interface MigrationConfig {
  source: 'wordpress' | 'contentful' | 'ghost';
  target: 'strapi' | 'contentful' | 'sanity';
  contentTypes: ContentTypeMapping[];
}

async function migrate(config: MigrationConfig) {
  const extractor = getExtractor(config.source);
  const transformer = getTransformer(config.source, config.target);
  const loader = getLoader(config.target);

  for (const mapping of config.contentTypes) {
    console.log(`Migrating: ${mapping.sourceName} → ${mapping.targetName}`);
    const items = await extractor.extract(mapping.sourceName);
    const transformed = items.map(item => transformer.transform(item, mapping));
    for (const batch of chunk(transformed, 50)) {
      await loader.load(mapping.targetName, batch);
      await delay(500);
    }
  }
}

Миграция Rich Text

Самый сложный этап — трансформация форматов. HTML → Portable Text (Sanity) или Markdown (Contentful) требует рекурсивного парсинга DOM. Блоки изображений, встраиваемые шорткоды — каждый элемент обрабатывается по правилу. Например, для переноса 15 000 изображений из WordPress в Strapi потребовалось 2 дня на батчинг и перелинковку.

// WordPress HTML → Portable Text
import { htmlToPortableText } from '@portabletext/html';

function transformWpContent(html: string) {
  return htmlToPortableText(html, {
    rules: [
      {
        deserialize(el, next, block) {
          if (el.tagName === 'IMG') {
            return block({
              _type: 'image',
              _key: Math.random().toString(36).slice(2),
              src: el.getAttribute('src'),
              alt: el.getAttribute('alt'),
            });
          }
        },
      },
    ],
  });
}

После загрузки контента генерируем маппинг редиректов и настраиваем 301 редиректы.

const redirects = oldPosts.map(old => ({
  source: old.url,
  destination: newPosts.find(n => n.slug === old.slug)?.url ?? '/blog',
  permanent: true,
}));

Что делать с SEO-структурой после миграции?

Старые URL, мета-теги, карты сайта — всё переносится без потери позиций. Используем 301 редиректы и лог ошибок. Как указано в документации WordPress, корректные редиректы критичны для сохранения PageRank. Если вы планируете миграцию, свяжитесь с нами — мы поможем спланировать бюджет и сроки.

Основные сложности миграции

Rich Text с вложениями

В WordPress контент хранится как HTML с встроенными шорткодами. В Contentful — на Markdown, в Sanity — Portable Text. Алгоритм рекурсивно парсит DOM и собирает блоки.

SEO-структура

Переносим мета-теги, заголовки, карты сайта. Настраиваем 301 редиректы для сохранения позиций. Настройка редиректов в Strapi описана в официальном плагине Redirects.

Даунтайм

Минимизируем простой до 15 минут за счёт параллельной записи и переключения DNS.

Пользователи и права

Импортируем аккаунты, роли и подписки, обеспечивая бесшовную аутентификацию.

Процесс работы

1. Аудит — инвентаризируем контент, схему, SEO-теги, медиа.
2. Маппинг — составляем соответствия типов контента и полей.
3. Разработка скриптов — пишем ETL-пайплайн под вашу пару CMS.
4. Тестовая миграция — прогоняем на копии, проверяем целостность данных и метаданных.
5. Боевой запуск — выполняем перенос в окно с минимальным трафиком.
6. Пост-миграция — мониторинг ошибок 404, корректировка редиректов, передача документации.

Сроки

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

Чек-лист постмиграции

• Проверить 301 редиректы для топ-100 страниц
• Сверить количество записей в старой и новой CMS (count)
• Протестировать формы, поиск, фильтры
• Загрузить карту сайта в Search Console
• Настроить мониторинг 404

Что входит в работу

• План миграции и маппинг.
• Скрипты ETL с учётом вашей CMS.
• Настройка 301 редиректов и карты сайта.
• Тестирование на staging и мониторинг после запуска.
• Документация (список редиректов, схема данных, инструкция).
• Поддержка 30 дней после миграции.

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

Редизайн и миграция сайта: смена 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. Вот типичные поломки:

Как восстановить трафик после неудачной миграции?

Если трафик упал — действуйте немедленно:

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-кэш для динамического поиска. Подробнее в 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) с ручной проверкой проблемных страниц.

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 недели.

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

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