OpenCart - рабочий движок для интернет-магазина: бесплатное ядро, тысячи расширений, привычная админка. Проблемы начинаются позже, когда магазин вырос: половина функций держится на платных модулях, обновляться страшно, а любая доработка упирается в чужой код. Разберём, когда с OpenCart пора уходить, что в таком переезде самое хрупкое и как пройти его без потери страниц и заказов.
Почему магазины уходят с OpenCart
Сразу оговорка: OpenCart не «плохой движок». Для магазина на пару сотен товаров без сложной логики он вполне справляется, и переезжать с него просто так незачем. Речь про момент, когда ограничения начинают стоить денег.
- Магазин держится на расширениях. Нужную функцию проще купить модулем, чем написать. Через пару лет их десяток, они правят одни и те же места движка через ocmod и конфликтуют между собой. Разбираться, какой из них сломал корзину, дороже, чем написать функцию с нуля.
- Обновляться страшно. Переход между мажорными версиями ломает совместимость шаблона и модулей, поэтому многие магазины годами сидят на старой ветке. Это технический долг, который растёт сам: чем дальше, тем дороже прыжок.
- Скорость упирается в архитектуру. Тяжёлый шаблон, лишние запросы к базе и рендер на сервере под каждый клик. Ускорять это можно, но каждый следующий шаг даётся дороже предыдущего.
- Зависимость от того, кто это настраивал. Магазин с десятком ocmod-правок понимает только человек, который их ставил. Смена подрядчика превращается в археологию.
Чем переезд с OpenCart отличается от переезда с платформы
С арендованных платформ вроде InSales магазин переезжает по выгрузке: платформа отдаёт файл, вы его разбираете. С OpenCart всё иначе - и в этом есть плюс, и есть минус.
Плюс: база у вас. OpenCart стоит на вашем хостинге, и MySQL с товарами, заказами и покупателями принадлежит вам. Не нужно ждать милости платформы и упираться в лимиты экспорта - данные можно взять целиком и в исходном виде.
Минус: структура у каждого своя. За годы жизни магазина схему базы правили модули, а часть данных лежит в полях, которые изначально предназначались для другого. Поэтому универсального импортёра «из OpenCart» не существует: перенос всегда пишется под конкретный магазин.
Что самое хрупкое: данные и адреса
Данные. Переносить нужно не таблицы, а связи: товар - категории - атрибуты и опции - остатки - заказы - покупатели. Отдельная боль - товары с вариантами: в OpenCart они собираются из опций, и при переносе легко получить каталог, где половина комбинаций потерялась. Мы пишем перенос как ETL: адаптер под структуру конкретного магазина приводит данные к общему виду, а импорт делается идемпотентным - повторный прогон не создаёт дублей. Это важнее, чем кажется: переносить данные придётся не один раз, а несколько, потому что магазин продолжает работать и продавать, пока идёт переезд.
Адреса. ЧПУ в OpenCart живут в отдельной таблице и часто накапливают историю: у одного товара бывает несколько адресов, оставшихся от прошлых правок. Значит, перед переездом нужно вытащить не тот адрес, который отдаёт витрина сегодня, а все, по которым на страницу могут прийти из поиска и из старых ссылок.
SEO: почему одних редиректов мало
Базовое правило известно всем: каждый старый адрес, который приносил трафик, закрывается 301-редиректом на новый. Карту редиректов мы строим по реальной аналитике, а не по выгрузке каталога - сначала те страницы, которые действительно работали. На нашем собственном магазине так и сделали: старые адреса ведут на новые страницы (301), чтобы не потерять страницы в поиске, а позиции в выдаче мы не гарантируем, они зависят от поисковых систем.
А теперь то, чего в чек-листах обычно нет. Мы сделали редиректы правильно - и всё равно часть страниц выпала из индекса. Причина оказалась не в переезде: на новом сайте распроданные товары не попадали в карту сайта и не выводились в листингах. Формально страницы жили и отдавали 200, фактически к ним не осталось ни одного пути - ни ссылки, ни записи в sitemap. Поисковик не угадывает адреса, он ходит по путям.
Отсюда правило, которое мы теперь проверяем на каждом переезде: 301-редирект переносит вес страницы, но не удерживает её в индексе. У каждой живой страницы должны быть запись в карте сайта и хотя бы одна внутренняя ссылка в исходном HTML - не подгружаемая скриптом. А то, что вы решили не переносить, должно отдавать 410, а не редирект на главную. Разбор этой истории целиком, с цифрами и диагностикой, - в статье SEO при переезде сайта: сколько стоит ошибка.
Как проходит переезд
Старый магазин работает и принимает заказы до последнего дня. Новый собирается на отдельном стенде, туда прогоняется перенос данных - столько раз, сколько нужно, чтобы совпали остатки, цены и заказы. Домен переключается за одно окно, когда всё проверено. Каталог переезжает на «Старте»: от 149 000 ₽ (можно в рассрочку на 6 платежей), 10-14 рабочих дней. Полный переезд с клиентами, историей заказов и 301-редиректами - «Магазин»: от 290 000 ₽, 3-5 недель. Финальная цифра зависит от объёма каталога, числа интеграций и того, сколько уникального оформления вам нужно.
Что вы получаете взамен
Вместо OpenCart с десятком расширений - собственный магазин на Next.js и PostgreSQL, ядро которого обкатано на реальной торговле: каталог с фильтрами, оформление заказа, оплата и доставка, письма покупателям, кэшбэк и бонусы, отзывы, админка, в которой товары и цены меняются без программиста. Функции, за которые в OpenCart платят модулями, здесь часть проекта.
Главное отличие - после запуска сервер, данные и доступы ваши, а развивать магазин можно тремя способами: своими силами через админку, своей командой или другим подрядчиком, либо вместе с нами. Как устроен сам пакет - в разборе переезд магазина на собственный движок. Если вы сравниваете варианты с 1С-Битрикс, есть отдельный чек-лист: когда уходить с 1С-Битрикс на Next.js.
Кому пора, а кому рано
Рано, если магазин небольшой, OpenCart вас устраивает и вы не упираетесь в его ограничения. Переезд стоит денег, и без внятной причины он не окупится - честно скажем об этом на разборе.
Пора, если совпало хотя бы два пункта: расширения конфликтуют и тормозят развитие, обновление версии откладывается годами, скорость витрины стала проблемой, нужные функции упираются в возможности движка, а поддержка зависит от одного человека, который «знает, где там что».
И трезво про деньги: сам по себе новый движок продаж не добавит. Он окупается там, где у вас уже есть покупатели - повторными продажами, работой с базой и тем, что вы перестаёте платить за каждую функцию отдельно. Сколько стоит содержание магазина на дистанции, разбирали в статье про расходы интернет-магазина.
С чего начать
Начните с бесплатного разбора: посмотрим структуру вашего магазина, объём каталога, набор расширений и то, какие страницы приносят трафик, - и скажем, что реально войдёт в переезд и за счёт чего он окупится. Подробности и состав пакета - на странице переезд на собственный движок.
