Самое обидное в таких историях в том, что внешне всё может звучать очень разумно. «Сайт тормозит». «Мобильная версия неудобная». «На WordPress проще». «Плагинов много». «Шаблон уже адаптивный». На словах это выглядит как шаг вперёд. На деле иногда получается классическое: решили поменять шторы, а снесли дом.
Как всё начиналось
Изначально это был рабочий сайт в строительной нише. Не идеальный, не новый, не модный, но живой и результативный. Он работал на ModX и при всех своих недостатках приносил бизнесу клиентов.
Да, у сайта были проблемы: не самая удачная мобильная версия, устаревшие JavaScript-скрипты, не самая удобная работа с шаблоном, сложность точечных доработок. Но есть важная разница между «сайт неидеален» и «сайт надо срочно пересаживать на другую CMS». И вот эту разницу тогда, к сожалению, не уловили.
До просадки ИКС сайта был 220. После переезда он упал до 60. Вернуть удалось только до 120.
Посещаемость просела примерно на 50%, а количество клиентов на строительство домов снизилось с 20 в год до 2. Почти в десять раз. Это уже не история про «временное снижение позиций», а история про то, как одно неверное техническое решение может добить вполне успешный бизнес.
Почему сам переезд был ошибкой
Главный вывод, который я сделала из этого кейса: изначальные проблемы сайта не требовали обязательной смены CMS.
Если сайт плохо работал на мобильных устройствах, в первую очередь нужно было смотреть в сторону шаблона, сетки, верстки и CSS. Если сайт был медленным, нужно было разбирать скрипты, оптимизировать изображения, настраивать кеширование и серверную часть. Если была слабая конверсия, нужно было дорабатывать формы, офферы, первый экран, коммерческие блоки и доверительные элементы.
То есть проблему можно было решать локально, аккуратно и без разрушения SEO-фундамента. Не обязательно менять двигатель, если у машины просто спустило колесо.
Что можно было сделать без смены CMS
- Подправить мобильную верстку и адаптив через CSS.
- Переписать или убрать старые JavaScript-скрипты, которые тормозили загрузку.
- Оптимизировать изображения и статику.
- Настроить кеширование на уровне CMS и сервера.
- Доработать формы заявок и коммерческие элементы без слома структуры сайта.
- Обновить шаблон на ModX, не ломая URL, индексацию и накопленный вес страниц.
Именно поэтому я сейчас очень осторожно отношусь к советам в духе «давайте просто переедем на WordPress, там удобнее». Удобнее кому? Разработчику — возможно. Бизнесу — далеко не всегда.
Что произошло после миграции
Новый сайт был запущен не как полноценная, выверенная и безопасная миграция, а скорее как упрощённая версия с расчётом на то, что потом всё постепенно доработают.
Перенесли не все страницы. Не вся структура была сохранена. Редиректы сделали только на часть URL. Часть старого контента и часть внутренней логики сайта были потеряны. А в SEO история «потом доделаем» часто читается поисковиками как «спасибо, мы уже всё поняли».
В результате поисковые системы получили классический набор тревожных сигналов:
- изменилась структура сайта;
- часть старых страниц исчезла;
- не все URL были корректно перенаправлены;
- часть накопленного веса и релевантности была утрачена;
- внутренняя перелинковка и логика сайта оказались нарушены.
С этого момента сайт начал терять позиции, а бизнес — клиентов.
Когда я подключилась к проекту
Когда проект попал ко мне, он уже был после миграции. Все сливки предыдущий разработчик к этому моменту уже снял: удобное для себя решение принял, сайт перевёз, а разгребать последствия пришлось уже на следующем этапе.
Мне достался проект, в котором нужно было не развивать сильную площадку, а буквально собирать обломки и пытаться понять, что ещё можно спасти. И да, именно это я называю работой на выжженной земле.
На этом этапе у нас с заказчиком было два варианта:
- Пробовать возвращаться на ModX.
- Оставаться на WordPress и пытаться восстановить позиции уже на нём.
Мы выбрали второй вариант. Это решение тогда казалось логичным: деньги уже потрачены, сайт уже перенесён, хотелось верить, что ситуацию можно вытянуть техническими и SEO-доработками. Но по факту это решение оказалось ошибочным. Вернуть сайт к его прежнему уровню не удалось.
С чем пришлось работать
По сути, это был типичный проект после неаккуратной миграции:
- частично потерянная структура сайта;
- неполный перенос страниц;
- редиректы только с части старых адресов;
- технические дубли и мусорные страницы;
- неполное сохранение накопленного SEO-потенциала.
В такой ситуации ты работаешь не с сильным фундаментом, а с последствиями чужих решений. Это уже не история про нормальное развитие сайта. Это история про антикризисную терапию, где сначала нужно остановить кровотечение, а потом уже думать о росте.
Что удалось, а что — нет
Удалось частично стабилизировать проект. ИКС вырос с 60 до 120. Но это всё равно было далеко от исходных 220.
То есть восстановление получилось только частичным. Прежние позиции сайт так и не вернул. Прежний уровень трафика — тоже. А если говорить языком бизнеса, то самое главное — не вернул прежний поток клиентов.
Когда у компании количество клиентов на строительство домов падает с 20 в год до 2, это уже не «SEO-просадка». Это диагноз.
Именно поэтому этот кейс для меня не просто технический. Он про ответственность. Про то, что иногда решение, принятое под соусом «так будет современнее и удобнее», на деле разрушает то, что годами работало и приносило деньги.
Какие выводы я сделала после этого кейса
После этой истории у меня сформировались очень жёсткие правила безопасности для любых переездов с одной CMS на другую.
1. Сначала определить настоящую проблему
Если проблема в мобильной версии, нужно смотреть шаблон, адаптив и CSS. Если проблема в скорости — разбирать скрипты, сервер и кеширование. Если проблема в конверсии — работать с UX, оффером, первым экраном, текстами и формами.
Смена CMS не должна быть автоматическим ответом на любой дискомфорт в работе сайта.
2. Не путать удобство разработчика с интересами бизнеса
Фраза «мне так удобнее работать» вообще не должна быть достаточным основанием для миграции. CMS выбирают не под настроение подрядчика, а под устойчивость бизнеса, текущий SEO-фундамент и реальные задачи проекта.
3. Не менять CMS, если задачу можно решить внутри текущей системы
Если проблема решается через доработку шаблона, CSS, оптимизацию скриптов и улучшение UX, то это почти всегда безопаснее, дешевле и разумнее, чем полная пересадка сайта на другой движок.
4. Если миграция всё же неизбежна — готовить её как операцию
- Собрать все существующие URL.
- Подготовить карту соответствия старых и новых страниц.
- Настроить 301-редиректы на всё важное, а не только на часть страниц.
- Перенести контент, мета-теги, заголовки, перелинковку и коммерческие блоки.
- Проверить canonical, robots.txt, sitemap и индексацию.
- Проводить запуск только после полного тестирования.
5. Всегда считать последствия в деньгах
Потому что «просадка трафика» звучит абстрактно, а «клиентов стало не 20, а 2» звучит уже как очень конкретная цена ошибки.
Главный вывод
Этот кейс для меня — печальное, но важное напоминание: не всякую проблему сайта нужно решать сменой CMS.
В этой истории сайт не обязательно было переводить с ModX на WordPress. Проблему с мобильной версией можно было решать через шаблон и CSS. Проблему со скоростью — через техническую оптимизацию. Проблему с конверсией — через UX и коммерческие доработки.
Но вместо этого бизнес пошёл в рискованную миграцию, потерял позиции, не восстановил лиды и в итоге закрылся.
Иногда самое профессиональное решение — не «сделать заново», а не разрушить то, что уже работает.