Миграция с MODX на более современную CMS — типовая задача, когда сайт перерастает возможности старой платформы или когда для него сложно найти разработчика с актуальными компетенциями. Техническая часть переноса контента обычно не вызывает сложностей, а вот потеря позиций в поиске после запуска нового сайта — самая частая претензия заказчиков, и почти всегда она вызвана одной и той же причиной: отсутствием плана 301-редиректов.
Каждый URL, который проиндексирован и ранжируется в поиске, накопил определённый вес за счёт внешних и внутренних ссылок, времени нахождения в индексе, поведенческих факторов. При смене CMS структура URL почти всегда меняется — MODX генерирует адреса иначе, чем WordPress или 1С-Битрикс. Если старый URL при заходе отдаёт 404, поисковик со временем убирает его из индекса и начинает ранжировать сайт заново с нуля по новому адресу, как будто это совершенно новая страница без истории. 301-редирект — единственный механизм, который явно сообщает поисковику «это тот же самый документ, он просто переехал», передавая вес со старого URL на новый.
Первый шаг — получить полный список всех проиндексированных URL старого сайта. Самый надёжный источник — таблица ресурсов MODX (modx_site_content), где хранится полная структура страниц с их алиасами и контейнерами; выгрузка через прямой SQL-запрос даёт точную карту URL, в отличие от ручного обхода сайта. Дополнительно сверяю этот список с данными Google Search Console (раздел «Страницы» → «Проиндексировано») — там видно, какие именно URL реально принимают трафик из поиска, и в первую очередь редиректы нужны именно для них, а не для всех технических адресов без исключения.
Вместо того чтобы прописывать соответствия вручную по одному, строю таблицу маппинга «старый URL → новый URL» в виде CSV или отдельной таблицы БД, сопоставляя записи по смысловому соответствию — старая страница услуги на MODX должна вести на новую страницу той же услуги на WordPress/Bitrix, а не просто на главную. Редирект «всё на главную» — частая практика у неопытных исполнителей, которая формально не даёт ошибку 404, но почти не передаёт SEO-вес и создаёт у пользователя ощущение сломанной ссылки, если он искал конкретный товар или статью, а попал на главную страницу.
Есть два основных способа реализации, и выбор зависит от масштаба. Для сайтов с сотнями и тысячами URL эффективнее прописать правила на уровне веб-сервера — в Nginx это блок rewrite или сопоставление по regex, который обрабатывается до того, как запрос вообще доходит до PHP, что быстрее и не нагружает CMS. Для меньшего числа URL или когда доступа к конфигурации сервера нет, используется таблица редиректов на уровне CMS — плагин Redirection для WordPress или модуль в 1С-Битрикс, куда маппинг из пункта 3 загружается массово через импорт CSV, а не вводится вручную по одной строке.
После переключения домена на новый сайт мониторинг не заканчивается в день запуска. В логах веб-сервера в течение первых недель отслеживаю запросы, которые всё ещё приходят на старые URL, но получают 404 — это сигнал, что маппинг из пункта 3 был неполным, и пропущенный адрес нужно добавить в таблицу редиректов. В Google Search Console слежу за разделом «Покрытие» на предмет роста ошибок 404 и за динамикой показов/кликов по запросам, которые раньше вели на старый сайт. Отдельно проверяю, что цепочка редиректов не получилась многоступенчатой (URL A → URL B → URL C) — каждый лишний переход замедляет отдачу страницы и часть поисковых систем хуже передаёт вес через цепочки из трёх и более редиректов подряд.
Использование 302 (временного) редиректа вместо 301 (постоянного) — ошибка, которая не сразу заметна визуально: пользователь одинаково попадает на новую страницу в обоих случаях, но поисковые системы интерпретируют их принципиально по-разному. Временный редирект сообщает «эта страница скоро вернётся на старое место», и поисковик продолжает держать в индексе именно старый URL, не передавая накопленный вес новому адресу — разница в одной цифре кода ответа определяет, сохранится SEO-вес или нет.
Вторая ошибка — редирект без учёта GET-параметров и UTM-меток. Если старый URL с параметрами вида ?utm_source=... редиректится на новый адрес с потерей этих параметров, часть рекламной аналитики и атрибуции переходов из старых кампаний, ссылки на которые могут ещё встречаться во внешних источниках, перестаёт корректно учитываться.
Третья — редирект внутренних якорных ссылок и файлов без общего плана. Помимо HTML-страниц, на старом MODX-сайте могли индексироваться PDF-документы, изображения из галереи, отдельные RSS-фиды — если карта редиректов покрывает только основные текстовые страницы, все второстепенные проиндексированные URL остаются без перенаправления и превращаются в накапливающиеся ошибки 404 в Search Console.
Четвёртая — редиректы, настроенные только на уровне CMS, при том что часть трафика приходит на статические файлы или служебные URL, которые CMS не обрабатывает вовсе (например, прямые ссылки на файлы в assets/ у старого MODX). Для таких адресов правило редиректа нужно прописывать на уровне Nginx, а не полагаться на то, что плагин CMS перехватит абсолютно любой входящий запрос.
