Миграцията е отделен проект, не бутон за импорт
При прехвърляне на онлайн магазин най-скъпите грешки не са във визията. Те са в загубени поръчки, счупен checkout, объркани SKU, нарушени интеграции и органичен трафик, който изчезва след смяната на URL адресите. Затова започваме с инвентар и ясно определен период за промяната.
Няма универсално обещание „нулева SEO загуба“. Дори добре направена миграция може временно да промени видимостта, докато Google обработва редиректите и новите страници. Целта е да минимизираме предотвратимите загуби и да измерваме ефекта по важните landing pages.
Етап 1: карта на стария магазин и целите
Извличаме списък на всички индексируеми URL-и, sitemap-и, категории, продукти, статии и статични страници. От Google Search Console и Analytics отделяме страниците с кликове и продажби, от сървърните логове — активните обходи и критичните 404. Описваме и целите на смяната: нова ERP интеграция, подобрен checkout, по-лесна редакция или намален технически дълг.
След това съпоставяме съдържанието с бъдещата архитектура. Ако стара категория „дамски обувки“ е получавала трафик, не я пренасочваме към началната страница без основание. Търсим най-близкото тематично съответствие; ако категорията се премахва, решаваме какво реално полезно да получи потребителят.
- Пълен crawl и CSV с URL, статус, title, canonical, трафик.
- SEO и бизнес приоритет за всеки тип страница.
- Списък на интеграции: плащане, куриери, ERP, фактуриране.
- План за freeze на съдържанието преди cutover.
Етап 2: инвентар на данните и тяхната съвместимост
Продуктовите данни включват SKU, вариации, атрибути, категории, изображения, склад, цени, данъчни класове и описания. Отделно стоят клиентите, адресите, историята на поръчките, купоните, абонаментите, gift cards и fulfillment статусите. Не всяка платформа съхранява тези данни по еднакъв начин.
Създаваме таблица поле-към-поле и тестов import на представителна извадка: продукти с варианти, липсващи артикули, няколко ставки, нестандартна промоция. При клиенти може да е необходим процес за нова парола. При исторически поръчки проверяваме законовите и счетоводните изисквания за съхранение, без да предполагаме, че всеки record трябва да се премества в новия checkout.
Етап 3: 301 редиректи и канонични URL-и
За всеки стар адрес изграждаме правило към най-релевантния нов URL. Избягваме вериги от няколко пренасочвания, случайно връщане на 200 за премахнати страници и масово насочване към homepage. При филтри и варианти решаваме кои URL-и трябва да се индексират, а кои само да обслужват потребителя.
Нова sitemap се публикува след launch. Каноничните адреси трябва да сочат към действително работещите нови страници. Проверяваме robots.txt, x-robots-tag, staging noindex и случайни блокирания от firewall. След смяната наблюдаваме покритие, статус на пренасочванията и crawl anomalies.
| Проверка | Правилен подход | Риск при пропуск |
|---|---|---|
| Стари категории | 301 към релевантен еквивалент | Загуба на тематичен трафик |
| Продуктови URL-и | 1:1 mapping когато е възможно | 404 за входящи линкове |
| Canonical | Сочи към нов индексируем URL | Дублиране/неиндексиране |
| Sitemap | Само крайните 200 URL-и | Откриване на грешни адреси |
| Staging | Изолирана/неиндексируема среда | Дублирано съдържание |
Етап 4: функционално QA, не само визуален преглед
Тестваме checkout с карти и наложен платеж в безопасен тестов режим, варианти на доставка, генериране на документи, складови движения, уведомления по имейл и обратни синхронизации. Проверяваме поведението на мобилен телефон и при бавна мрежа. Тестовете се изпълняват от реални оператори, а не само от разработчиците.
Особено важно е как се обработват поръчките по време на смяната. Може да е необходим кратък период на read-only режим или синхронизация на последните промени. Всяко решение трябва да е описано в предварителен runbook.
Етап 5: контролирано публикуване и rollback
Преди прехвърлянето запазваме проверено копие на данните и конфигурацията. Създаваме списък с smoke tests и критерии за прекратяване. Нова система не се счита за готова само защото връща HTTP 200: трябва да има работеща покупка, правилна цена, коректна наличност и отчитане на продажбата.
След пускане наблюдаваме ежедневно ключовите landing pages, реални поръчки, грешки, 404, Search Console кликове и конверсии. Ако има критичен проблем, rollback не е просто връщане на файлове — трябва да отчетем новите поръчки, създадени междувременно.
Какво искаме от клиента преди оферта
Изпратете достъп до тестова инсталация или CSV извадка на каталога, списък с integrations, статистика за трафика, основни бизнес сценарии и приоритети. По тази информация изготвяме scope и ценова оценка. Понякога оптимизация на съществуващия магазин е по-добра инвестиция от миграция.
Примери за различни архитектури можете да видите в нашите eCommerce и B2B case studies. Те показват подход към информацията и процесите, без да твърдим, че всяка използвана технология е една и съща.
- Списък с най-важните 20 URL-а и техния трафик.
- 5 примерни продукта с варианти и промоции.
- Един реален workflow за обработка на поръчка.
- Дата на желаното прехвърляне и условия за rollback.
Миграция от OpenCart към WooCommerce или Shopify: контролен избор
Миграцията е отделен продукт, дори когато новият магазин изглежда сходно. Проверяваме старите входящи URL-и, категории, варианти, поръчки, клиенти и интеграции. За всяка платформа съществуват различни ограничения при експорта на данни и вградения checkout.
Ако единственият проблем е стара тема или неработещ модул, сравнете ремонта на текущата система с пълната миграция. Ако причината е стратегическа — нов пазар, ERP, B2B, поддръжка — архитектурата трябва да се избере преди трансфера на данни.