Миграция MODX Evolution → Revolution: контент, шаблоны, API

Мы часто сталкиваемся с ситуацией, когда владельцы сайтов на MODX Evolution жалуются на устаревшую архитектуру: PHP 5.6, отсутствие PSR-совместимости, незакрытые уязвимости. Evolution использует процедурный подход, глобальные объекты $modx, а Revolution — современный ООП с xPDO ORM. Прямой апгрейд невозможен — требуется полноценная миграция с переработкой кода. Evolution не поддерживает современные стандарты кэширования и автозагрузки, что приводит к медленной работе и проблемам с масштабированием. Revolution предоставляет встроенное кэширование, PSR-совместимые классы и гибкую систему событий. Например, в Evolution для вывода списка документов приходилось писать прямые SQL-запросы, что увеличивало риск SQL-инъекций. В Revolution эта задача решается через xPDO с автоматической экранизацией.

Зачем мигрировать с MODX Evolution на Revolution?

Переход на Revolution даёт измеримые выгоды: среднее время загрузки страницы сокращается вдвое за счёт встроенного кэширования, устраняются уязвимости старой архитектуры, появляется доступ к современным пакетам и автозагрузке. Экономия на хостинге может достигать 30% — это до 20 000 ₽ в год для типового проекта. Кроме того, Revolution поддерживает PHP 8.x, что продлевает жизненный цикл сайта. Снижение затрат на поддержку и доработки достигает 40%, что экономит около 50 000 ₽ ежегодно.

Что переносится при миграции

Структура папок изображений обычно идентична, но пути в контенте могут измениться. Мы автоматизируем замену через regex или ручной маппинг.

Как проходит миграция?

Анализ текущего сайта

Перед миграцией проводим аудит: собираем данные по шаблонам, TV-параметрам, сниппетам и плагинам. Пример SQL-запроса для оценки объёма работы:

-- Количество документов по шаблонам
SELECT t.templatename, COUNT(d.id) as count
FROM site_content d
JOIN site_templates t ON t.id = d.template
GROUP BY t.templatename;

-- TV-параметры
SELECT tv.caption, tv.type, COUNT(tvv.id) as used
FROM site_tmplvars tv
LEFT JOIN site_tmplvar_contentvalues tvv ON tv.id = tvv.tmplvarid
GROUP BY tv.id;

-- Кастомные сниппеты
SELECT name, LENGTH(snippet) as size FROM site_snippets;

-- Плагины
SELECT name, plugincode FROM site_plugins WHERE disabled = 0;

Как перенести TV-параметры?

TV-параметры маппятся по имени. Если в Evolution поле называлось color, в Revolution оно остаётся color. Важно проверить типы: в Evolution тип TV может отличаться от Revolution (например, текстовое поле против текстовой области). Мы корректируем типы вручную. Дополнительно настраиваем доступ к TV через системные настройки Revolution.

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

Сниппеты Evolution написаны в процедурном стиле с глобальным $modx. В Revolution API другой. Например:

// Evolution (старый API)
$docs = $modx->getDocuments($parents = [5], $published = 1);

// Revolution (правильный API)
$c = $modx->newQuery('modResource');
$c->where(['parent' => 5, 'published' => 1]);
$docs = $modx->getCollection('modResource', $c);

Сниппеты нужно переписывать. Для типовых задач (вывод списков, меню, форм) — использовать готовые Revolution Extra: pdoResources, pdoMenu, FormIt. Это ускоряет разработку и снижает вероятность ошибок.

Миграция изображений и файлов

# Структура изображений идентична (assets/images/)
rsync -avz old-server:/var/www/evo-site/assets/images/ \
    /var/www/revo-site/assets/images/

Реальный кейс: интернет-магазин за 4 недели

Наш клиент — интернет-магазин на Evolution с 300 ресурсами, 20 сниппетами и 10 TV. Мы выполнили миграцию за 4 недели. Ключевые проблемы:

• Сниппет корзины использовал прямые SQL-запросы — переписали на xPDO.
• Шаблоны содержали устаревшие теги [+...+] — заменены на [[+...]] Revolution.
• Изменена структура URL, настроены редиректы .htaccess.

Клиент отметил: «Скорость загрузки выросла на 40%, а нагрузка на сервер снизилась в два раза».

Результат: скорость загрузки выросла на 40% за счёт кэширования Revolution, устранены уязвимости, снижена нагрузка на сервер. Экономия на хостинге составила до 30%. Хотите так же? Закажите аудит своего сайта на Evolution бесплатно.

Сравнение производительности: Evolution vs Revolution

Revolution быстрее в 2 раза по времени загрузки, а кэширование снижает нагрузку на сервер.

Сроки и стоимость

Стоимость рассчитывается индивидуально после анализа кодовой базы.

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

• Аудит текущего сайта: анализ шаблонов, сниппетов, TV, плагинов.
• Экспорт всех данных с сохранением структуры.
• Установка и конфигурация Revolution с настройкой кэширования.
• Импорт контента с рефакторингом шаблонов и сниппетов под xPDO.
• Миграция изображений и файлов с автоматической заменой путей.
• Настройка 301 редиректов для сохранения URL.
• Тестирование на staging-окружении.
• Документация по новому сайту и обучение администраторов.
• Пост-релизная поддержка: бесплатное исправление багов в течение 30 дней.

Почему нам доверяют

• 10+ лет опыта с MODX обеих версий.
• Более 50 реализованных проектов по миграции.
• Сертифицированные инженеры по MODX Revolution.
• Гарантия качества: бесплатное исправление багов в течение 30 дней.

Свяжитесь с нами для бесплатной оценки объема работ. Закажите миграцию — и забудьте о проблемах Evolution. Получите консультацию в течение 2 рабочих дней.

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

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