Власник магазину відкриває OpenCart, щоб замінити фото товару. Адмінка думає. Ще думає. Потрібний блок знову захований у налаштуваннях, а доопрацювання, яке давно потрібне відділу продажів, не стає в готовий шаблон без чергового модуля. Розробник пропонує перенести сайт, і одразу чуєш занепокоєне: «А раптом після переносу впадуть позиції в Google?». Знайомий страх. Через нього бізнес роками терпить повільний магазин, хоча сама міграція не повинна обнулити SEO. Потрібна не магія, а акуратна карта URL, коректні редіректи і перевірка кожної важливої сторінки. Саме так ми підходимо до розробки та міграції інтернет-магазинів.
Коротко: міграція інтернет-магазину — це перенос каталогу, зображень, контенту й робочих функцій зі старої платформи на новий сайт. Вона потрібна, коли адмінка гальмує, модулі конфліктують, стандартний шаблон стримує розвиток або бізнесу вже замало готових сценаріїв. SEO під час такої міграції можна зберегти. Для цього до розробки складають список старих адрес, кожній важливій сторінці призначають нову адресу і налаштовують постійний 301-редірект. Окремо переносять тексти, метадані, канонічні адреси, внутрішні посилання та мовні версії, після запуску віддають новий sitemap і перевіряють відповіді сервера. Сам факт зміни OpenCart на Next.js не забирає позиції: пошуковику важливо, щоб стара сторінка не зникла без пояснення, а її нова версія зберегла зміст і сигнали. Для ЖНИВ-АГРО ми перенесли каталог парсингом, зв’язали старі URL з новими через 301 і запустили двомовний сайт. Індексація та органічний трафік при цьому не були втрачені. Міграція має сенс, коли нова система розв’язує конкретні проблеми, а не просто міняє технологію на моднішу.
Чому магазин переростає готову платформу
OpenCart нормально закриває типовий старт: товари, категорії, кошик, замовлення, базова адмінка. Якщо бізнес працює за цим сценарієм і сайт не заважає продажам, переписувати його лише заради нового стеку немає сенсу.
Проблеми починаються пізніше. Одному магазину потрібна незвична сумісність товарів, іншому окремі правила для мов, третьому каталог без кошика, але з заявками для менеджерів. Кожне відхилення від стандартного сценарію тягне тему, модуль або правку ядра. З часом розробник спершу розбирається, який модуль що перевизначив, і тільки потім торкається самої задачі. Оновлення теж стають обережною операцією: треба перевірити, чи не розсиплеться тема і чи сумісні розширення між собою.
Швидкість тут залежить не від назви технології на головній. На неї впливають запити до бази, кількість модулів, робота з фото, кешування і те, скільки зайвого коду завантажує кожна сторінка. Готова платформа мусить підтримувати багато універсальних сценаріїв. Власний сайт може робити тільки те, що потрібно конкретному магазину. У випадку ЖНИВ-АГРО це каталог-вітрина з формою «Замовити дзвінок», а не класичний магазин із кошиком.
Коли товарів, фільтрів і джерел даних стає більше, потрібна вже не ще одна латка, а продумана архітектура магазину з великим каталогом. Тоді міграція прибирає накопичені обмеження і дає нормальну основу для наступних змін.
Головний страх: втратити SEO під час міграції
Пошукова видимість не живе всередині OpenCart. Вона прив’язана до сторінок: їхніх URL, змісту, внутрішніх і зовнішніх посилань, мовних версій та технічних сигналів. Небезпека виникає не через Next.js. Вона виникає, коли стара адреса раптом віддає 404, веде на головну або потрапляє в ланцюжок із кількох редіректів.
Тому міграцію починають не з дизайну. Спочатку збирають усі старі адреси товарів, категорій, статей і статичних сторінок. Джерел може бути кілька: старий sitemap, база даних, внутрішній обхід сайту, звіти Search Console та посилання з інших сторінок. Список очищають від технічних дублів і для кожного корисного URL визначають одну нову адресу. Так з’являється карта відповідностей «стара сторінка → нова сторінка».
Далі для кожної пари налаштовують постійний 301-редірект. Не «всі старі товари на новий каталог», а товар на той самий товар, категорія на відповідну категорію, стаття на відповідну статтю. Якщо нова структура дозволяє залишити адресу без змін, це ще простіше. Якщо slug змінився, сервер має одразу віддати одну кінцеву адресу без проміжних стрибків.
Редірект не виправить порожню нову сторінку. Разом з URL треба перенести назву, опис, фото, характеристики, метадані та важливі внутрішні посилання. На новій сторінці ставлять коректний canonical. Для української й англійської версій перевіряють взаємні hreflang, щоб пошуковик не плутав мови. У новий sitemap включають тільки канонічні адреси, які відповідають кодом 200. Старі URL там уже не потрібні.
Google Search Central у своїй інструкції з перенесення сайту прямо радить підготувати карту URL, поставити постійні серверні редіректи, протестувати їх і подати новий sitemap. Там само Google пояснює, що 301 та інші постійні редіректи не спричиняють втрати PageRank. Коливання під час повторного обходу можливі, тому після запуску все одно стежать за індексацією, помилками обходу та органічними посадковими сторінками.
На ЖНИВ-АГРО ми пройшли цей маршрут для всіх старих адрес OpenCart. Кожен старий URL отримав відповідний 301-редірект на нову сторінку. У результаті індексація та органічний трафік не були втрачені. Це не трюк Next.js, а дисципліна під час міграції.
Як проходить міграція крок за кроком
1. Аудит старого магазину
Ми фіксуємо структуру каталогу, мовні версії, типи сторінок, URL, метадані, форми та зв’язки між товарами. Окремо дивимось, що справді використовується, а що залишилось від старих модулів і не повинно переноситись.
2. Карта даних і адрес
Для полів OpenCart визначаємо місце в новій базі. Назви, описи, категорії, фото й характеристики не повинні перетворитись на один великий текст. Паралельно готуємо відповідності старих і нових URL. Це дві частини однієї міграції: товар має потрапити і в правильний запис PostgreSQL, і на правильну вебадресу.
3. Автоматизований перенос
Каталог ЖНИВ-АГРО ми забрали зі старого OpenCart парсером: близько 219 товарів і 471 фотографію. Після такого переносу потрібна перевірка. Скрипт може завантажити файл, але тільки звірка покаже, чи фото належить правильному товару, чи не загубилась категорія і чи заповнені обов’язкові поля.
4. Нова система та CMS
Сайт побудований на Next.js 16 і React 19, дані зберігаються в PostgreSQL, доступ до них організований через Prisma. Карту клієнтів зробили на Leaflet. Замість універсальної адмінки зібрали власну CMS приблизно з 30 розділами: товари, категорії, зображення, блог і статичні сторінки з редактором TipTap, блоки головної, навігація, футер, маркери карти, заявки зі статусами та користувачі з ролями.
5. Мови й контент
Українські та англійські тексти лежать в окремій таблиці перекладів. Якщо англійського значення немає, система підставляє українське, тому інтерфейс не ламається через порожнє поле. Для пошуку це не заміна перекладу, тож перед запуском важливі сторінки все одно перевіряють обома мовами. На сайті налаштовані окремі UA/EN адреси та hreflang.
6. Тест і запуск
До перемикання домену перевіряють сторінки товарів і категорій, мобільну версію, форму зворотного дзвінка, канонічні адреси, hreflang, sitemap і відповіді сервера. Потім вмикають 301-редіректи, ще раз проходять карту URL вже на бойовому домені та дивляться, чи немає 404 або циклів. Старий магазин вимикають лише тоді, коли новий сайт і маршрутизація працюють разом.
Переваги власного магазину на Next.js
Власний код без прив’язки до платформи
Ви не підганяєте процес під те, як автор модуля задумав каталог. Структура товарів, заявки, ролі та редактори будуються навколо реальної роботи команди. Код залишається у власника проєкту. Якщо згодом захочете змінити підрядника, можна найняти будь-якого розробника, який працює з цим стеком.
Немає тарифу платформи
Власний сайт не має щомісячної SaaS-підписки за кількість товарів, мов або користувачів. Хостинг, домен і технічна підтримка все одно коштують грошей, їх чесно треба закладати в бюджет. OpenCart також не вимагає обов’язкової щомісячної оплати сам по собі, але платні розширення й підтримка можуть залишати магазин залежним від конкретної збірки.
Швидкість без зайвого шару
Next.js не робить сайт швидким автоматично. Перевага в тому, що розробник контролює запити, компоненти, зображення і кешування, а сторінка не тягне функції, яких у цьому бізнесі немає. Новий сайт ЖНИВ-АГРО працює швидше за старий магазин саме завдяки такій реалізації.
Команда керує сайтом сама
Близько 30 розділів CMS закривають не тільки товари. Менеджери редагують категорії, фото, сторінки, блог, меню, футер, блоки головної й точки на карті. Заявки з форми «Замовити дзвінок» потрапляють в окрему панель, де їм змінюють статус. Для щоденної роботи не треба просити розробника замінити текст у футері.
Можна рости без нової міграції
До власної архітектури можна додавати нові типи продукції, інтеграції, ролі або ще одну мову без пошуку модуля, який випадково сумісний із поточною темою. Масштабування все одно потребує проєктування й розробки, але межі визначає бізнес, а не каталог розширень. Українська й англійська версії тут закладені в модель даних, а не прикручені поверх готового шаблону.
| Параметр | Готова платформа / OpenCart | Власний Next.js |
|---|---|---|
| Код | Ядро платформи, тема й набір розширень | Проєктний код під процеси магазину |
| Щомісячна підписка | У SaaS є тариф; OpenCart сам по собі без обов’язкової підписки | Немає тарифу платформи, окремо оплачуються інфраструктура й підтримка |
| Кастомізація | У межах ядра, теми та сумісних модулів | Функції проєктуються під конкретний каталог і команду |
| Швидкість | Залежить від теми, модулів, запитів і кешу | Контроль над кожним запитом, компонентом і зображенням |
| Адмінка | Універсальні екрани платформи | Власна CMS приблизно з 30 потрібними розділами |
| Мультимовність | Залежить від налаштувань теми та розширень | UA/EN у моделі даних, окремі URL і hreflang |
| Розвиток | Пошук сумісного модуля або доопрацювання платформи | Нові модулі додаються у власну архітектуру |
Коли міграція ще не потрібна
Маленькому магазину зі стандартним каталогом, кошиком і кількома способами доставки цілком може вистачати готової платформи. Якщо сторінки завантажуються нормально, менеджеру зручно працювати, а потрібні зміни закриваються штатними можливостями, міграція створить витрати без помітної користі.
Не варто переписувати сайт тільки тому, що Next.js новіший або його приємніше показати в технічній презентації. Новий стек не виправить нечітку структуру каталогу, слабкі фото чи порожні описи. Спочатку треба назвати проблему: повільна робота, обмеження адмінки, нестандартні зв’язки між товарами, складна мультимовність, залежність від модулів. Якщо такої проблеми немає, краще підтримувати те, що вже працює.
Міграція виправдана, коли вартість обмежень уже вища за вартість нового рішення. Це бізнес-рішення, а не змагання фреймворків.
Реальний кейс ЖНИВ-АГРО
ЖНИВ-АГРО виробляє жатки для збирання кукурудзи й соняшнику, адаптери, ріпакові столи, транспортні візки та запчастини. Старий сайт працював на OpenCart. Завданням було не просто намалювати нову головну, а перенести каталог на власну систему, зробити його швидшим і не віддати Google роками накопичені адреси.
З OpenCart парсером перенесли близько 219 товарів і 471 фото. У каталозі зберегли важливі для покупця зв’язки, зокрема сумісність із жатками John Greaves: ЖК-80, ЖК-82 та серією ЖНС. Новий сайт працює як каталог-вітрина без кошика. Відвідувач переглядає техніку або запчастини й залишає номер у формі «Замовити дзвінок», а заявка з’являється в панелі лідів зі статусом.
Технічна основа проєкту: Next.js 16, React 19, PostgreSQL і Prisma. Карта клієнтів працює на Leaflet. Для команди зроблена власна CMS приблизно з 30 розділами, від товарів і TipTap-редактора сторінок до навігації, маркерів карти, заявок та ролей користувачів. Українська й англійська версії мають окремі записи перекладів, український fallback і hreflang.
Перед запуском кожну стару адресу зв’язали з відповідною новою сторінкою через 301-редірект. Так каталог перенесли з OpenCart на Next.js без втрати індексації та органічного трафіку. Деталі й екрани адмінки є в кейсі розробки сайту ЖНИВ-АГРО.
Міграція без втрати SEO — почнемо з вашого каталогу
Якщо ваш магазин уже впирається в платформу, можна спочатку розібрати каталог і старі URL, без обіцянок «усе перепишемо заради технологій». Подивіться, як ми робимо власні інтернет-магазини та SEO-міграції, і приходьте з конкретною проблемою. Скажемо чесно, чи потрібна міграція зараз.
Замовити розробкуЧасті питання
Чи втратить інтернет-магазин SEO після переходу з OpenCart на Next.js?
Не через саму зміну платформи. Щоб зберегти SEO, кожну важливу стару адресу треба зіставити з відповідною новою сторінкою, налаштувати прямий 301-редірект, перенести контент і метадані, перевірити canonical, внутрішні посилання та sitemap. Під час повторного обходу можливі коливання, тому після запуску стежать за індексацією і помилками в Search Console.
Як перенести товари та фото з OpenCart на новий сайт?
Дані можна перенести автоматизовано через експорт, базу даних або парсер старого каталогу. Назви, описи, категорії, характеристики й зв’язки записують у нову структуру, а зображення завантажують окремо. Після імпорту каталог обов’язково звіряють: чи всі товари на місці, чи фото належать правильним карткам і чи не загубилися обов’язкові поля.
Які 301-редіректи потрібні під час міграції магазину?
Кожен старий URL має вести одним постійним 301-редіректом на найближчу за змістом нову сторінку: товар на той самий товар, категорія на відповідну категорію, стаття на відповідну статтю. Не слід перенаправляти весь старий каталог на головну або робити ланцюжки з кількох редіректів. У новий sitemap додають уже кінцеві канонічні URL.
Які переваги дає власний магазин на Next.js?
Власний проєкт дає контроль над кодом, каталогом, швидкістю, ролями та CMS. Немає щомісячного тарифу SaaS-платформи, хоча хостинг і підтримка залишаються окремими витратами. Функції можна додавати під процеси бізнесу, а для подальшої роботи найняти будь-якого розробника, який знає стек проєкту.
Як зберегти українську й англійську версії під час міграції?
Для кожної мови потрібні окремі URL, правильні canonical та взаємні hreflang. Старі українські сторінки перенаправляють на нові українські, англійські на англійські. Переклади переносять як структуровані дані, а не змішують в одному полі. Перед запуском обидві версії перевіряють окремо.
