Міграція стека Joomla 3/4 + VirtueMart на Joomla 5: чек-лист для власника магазину

Міграція інтернет-магазину зі стека Joomla 3/4 + VirtueMart на Joomla 5 охоплює п'ять зон ризику для трафіку Google: пре-міграційний аудит, карту 301-редиректів, канонічні теги, мовні версії та збереження розширених сніпетів. Власнику не потрібно знати технічних деталей - достатньо розуміти, які питання поставити підряднику до старту робіт і де може просісти органіка в перші 60 днів після деплою.

Чому міграція Joomla + VirtueMart коштує продажів

Логіка проста. Позиції в Google приводять органічний трафік. Трафік дає заявки. Заявки - виручка. Коли при міграції щось іде не так з адресами сторінок або технічними сигналами - Google переіндексовує сайт заново, і цей процес займає тижні, не дні.

На практиці магазини на VirtueMart після невдалої міграції просідають по органіці на 30-60% і відновлюються від 3 до 6 місяців. Частина - не відновлюється взагалі: конкуренти займають звільнені позиції і не поступаються ними назад.

Тут є важлива асиметрія. Щоб втратити позиції - достатньо кількох днів після невдалого деплою. Щоб їх повернути - потрібні місяці роботи і гроші на SEO, плюс час поки Google переіндексує виправлений сайт. Це не «ризик», це математика.

Ми пройшли через це на власному магазині. Не кажемо що міграція - це небезпечно. Кажемо: міграція без підготовки - небезпечно. Різниця в підході, не в самому факті переїзду. Нам кілька разів телефонували вже після переїзду з питанням «чому впав трафік» - і щоразу причина була в одній з п'яти зон, про які написано нижче.

П'ять зон, де відбувається більшість втрат: URL-структура, карта переадресацій, канонічні теги, мовні версії і мікророзмітка для розширених сніпетів. Кожна з них розкрита нижче. Для розуміння ширшого контексту - чому магазини взагалі втрачають позиції - читайте 8 причин, чому магазин втрачає позиції.

1. Пре-міграційний аудит: що зафіксувати ДО будь-яких змін

Уявіть що переїжджаєте магазин в нове приміщення. Перш за все - інвентаризація. Що де лежить, що найбільше продається, що можна загубити при переїзді. З сайтом - те саме.

До будь-яких технічних робіт потрібно зафіксувати три речі.

Перша - повний список URL з трафіком. Не всіх URL підряд, а тих, на які приходять реальні відвідувачі з Google. Це можна побачити в Google Search Console - звіт про ефективність, фільтр по сторінках.

Друга - які з цих URL дають 80% замовлень. Зазвичай це 10-20% сторінок. Вони - пріоритет захисту при переїзді. Якщо після міграції саме ці сторінки будуть недоступні або перестануть індексуватися - втрати відчуються одразу, вже в перший тиждень.

Третя - базові позиції по 10-20 ключових запитах, на які зараз ранжується магазин. Цей знімок - точка відліку. Без нього не відрізниш нормальну тимчасову просадку від справжньої проблеми після деплою.

Що показати підряднику до початку робіт:

• Знімок поточної індексації з Google Search Console (розділ «Сторінки»)
• Список пріоритетних URL - топ-20 за кліками за останні 3 місяці
• Базові позиції по 10-20 ключових запитах (можна з тієї ж консолі)
• Список URL, які мають зовнішні посилання з інших сайтів - їх втрата найдовше відновлюється

Нас кілька разів питали: «А чи не зробить підрядник цей аудит сам?». Зробить - якщо хороший. Але ви повинні розуміти що саме він зафіксував і на основі чого прийматимуться рішення по редиректах. Аудит, який ви не бачили, не дає вам контролю над ризиком.

Червоний прапор: підрядник готовий стартувати без аудиту і без базового знімку. Після деплою порівнювати «до» і «після» просто нічим. Без старту немає фінішу.

2. Карта переадресацій: куди веде кожна стара адреса

301-редирект - це автоматичне перенаправлення. Людина або Google заходить на стару адресу, а сервер відповідає: «ця сторінка переїхала, ось нова адреса». Google враховує цей сигнал і переносить ранжування на нову сторінку.

Без редиректів стара адреса повертає помилку 404 - «сторінка не знайдена». Google фіксує 404, прибирає сторінку з індексу. Зазвичай це відбувається за 1-2 тижні після міграції. Позиції, які ця сторінка мала, зникають разом з нею.

Для магазинів на VirtueMart це особливо болісно. За 5-10 років роботи накопичуються тисячі товарних URL: картки, категорії, фільтри, теги. Іноді йдеться про кілька тисяч адрес, кожна з яких потенційно має свій трафік або посилання ззовні. Детальніше про ризики переїзду для магазину - в нашій основній статті про причини втрати позицій.

Деякі старі URL мають посилання з зовнішніх сайтів - постачальники, каталоги, партнери, статті в медіа. Ці посилання - частина SEO-ваги магазину. Якщо URL зникне без редиректу, посилання перестає передавати цю вагу. Відновити її складно: або домовлятись з кожним сайтом, або змиритись з втратою. Карта редиректів закриває обидва ризики одночасно.

Що має зробити команда до деплою: побудувати таблицю «стара адреса - нова адреса» для всіх URL з трафіком. І перевірити, що жоден ланцюжок не довший ніж один крок. Тобто: стара адреса веде одразу на нову, не через проміжні редиректи. Кожен зайвий крок в ланцюжку - це втрата «ваги» для Google і додаткове навантаження на сервер.

Червоний прапор: підрядник каже «у нас все автоматично згенерується». Автоматична генерація URL - це не карта редиректів. Карта - це ручна або напівавтоматична зіставка. Без неї втрата буде. Ми бачили магазини, де підрядник здав роботу, взяв оплату - а клієнт виявив що 40% пріоритетних URL повертають 404, тільки коли через 3 тижні подивився на аналітику.

3. Канонічні теги: чому Google може показати не ту сторінку

Канонічний тег - підказка для Google. Він говорить: «ця адреса - головна версія сторінки, решта - копії, не ранжуйте їх окремо».

Типова ситуація в VirtueMart: один товар знаходиться в кількох категоріях одночасно. Наприклад, «Інформаційний стенд» може бути і в категорії «Стенди для школи», і в «Інформаційні стенди», і в «Стенди для ДНЗ». Кожна категорія генерує свою URL-адресу для одного і того ж товару. Google бачить три різні адреси з однаковим контентом і починає сам вирішувати, яку з них показувати. Іноді він обирає не ту, яка ранжувалась роками. Іноді - не обирає жодну.

Що має зробити команда: переконатися, що для кожного товару Google бачить рівно один канонічний URL - незалежно від того, через яку категорію зайшов користувач. Це налаштовується на рівні компонента керування канонічними тегами. Для огляду ризиків модернізації - читайте основну статтю про втрату позицій.

Через 30 днів після деплою перевірте в Google Search Console звіт «Канонічний URL обраний Google» - якщо там більше 2% розбіжностей між вашим канонічним тегом і тим, що вибрав Google, є проблема.

Питання просте: ви хочете, щоб Google ранжував конкретну адресу товару - ту, яку ви вважаєте головною. Якщо канонічного тегу немає або він неправильний - Google сам вибере «головну» адресу. Іноді він вибирає правильно. Частіше - ні. Не варто покладатись на везіння там, де є технічне рішення.

Перевірити це після деплою можна самостійно: зайдіть у Google Search Console, розділ «Сторінки», відфільтруйте по статусу «Канонічний URL обраний Google». Якщо список великий - є про що говорити з підрядником.

Червоний прапор: підрядник не згадує канонічні теги як окремий пункт роботи. Після міграції з Joomla 3/4 на Joomla 5 поведінка маршрутизатора змінюється - те що працювало раніше, може давати нові дублі.

4. Мовні версії сайту: щоб трафік не «розсипався» між локалізаціями

Якщо магазин має дві (або більше) мовні версії, Google повинен знати про зв'язок між ними. Для цього використовується атрибут hreflang: технічний сигнал «ця сторінка існує також іншою мовою - ось її адреса».

Без цього сигналу Google може почати показувати «не ту» мовну версію відвідувачам з відповідного регіону. Або вирішить, що дві версії - це дублі контенту, і вибере одну з них на свій розсуд. У будь-якому з цих сценаріїв трафік однієї з версій просідає, а інколи зникає взагалі.

У Joomla 3 і Joomla 4 існує архітектурний баг, через який атрибут мовних версій може затирати канонічний тег. Це не теоретична проблема - ми стикались з нею на власному магазині. У Joomla 5 баг частково присутній на рівні ядра і потребує ручного фіксу від технічної команди. Якщо ви мігруєте з Joomla 3 або 4 на Joomla 5 - попросіть підрядника пояснити, як саме він обходить цей баг при переїзді. Це конкретне технічне питання, на яке має бути конкретна відповідь, а не «у нас все працює». Розширений огляд ризиків і технічних проблем при модернізації - в окремій статті.

На практиці власники часто не знають про цей нюанс взагалі. Мовна версія «просто є» - і здається що все налаштоване правильно. Але одна неправильно налаштована пара hreflang може призвести до того, що значна частина цільового трафіку почне потрапляти на «не ту» локалізацію. Google Search Console покаже це у звіті «Мовні версії» - але тільки через 2-4 тижні після деплою.

Питання до підрядника:

• Чи знає підрядник про баг з hreflang у Joomla 3 і Joomla 4?
• Як саме він обробляє маршрутизацію між мовними версіями при переході на Joomla 5?
• Чи буде перевірка після деплою - через Google Search Console, звіт «Мовні версії»?

Червоний прапор: «ми просто скопіюємо налаштування з поточного сайту». Якщо баг є в поточній конфігурації - він переїде разом з налаштуваннями. Хороший підрядник знає різницю між «скопіювати» і «переналаштувати» - і пояснить її без підказки. Особливо обережним треба бути, якщо магазин планує розширення на нові ринки (нову мовну версію поверх існуючої) - архітектура повинна бути готова до цього на момент міграції.

5. Розширені сніпети (зірочки, ціни, FAQ): як не втратити їх при зміні дизайну

Розширені сніпети - це те, що Google показує під посиланням у пошуку: зірочки рейтингу, ціни, наявність товару, питання і відповіді FAQ. Вони підвищують клікабельність результату - часом дуже суттєво. Магазини, які їх мають, отримують більше кліків навіть з нижчої позиції.

Де ховається ризик: розмітка, яка генерує ці сніпети, часто «вшита» безпосередньо в HTML-шаблон сайту. Не в базу даних, не в окремий файл - саме в шаблон. Зміна дизайну = новий шаблон = розмітка зникла. Google перестає бачити сигнали, через кілька тижнів прибирає зірочки з результатів. Без попередження.

Для магазинів на VirtueMart це особливо критично, бо VirtueMart має готову розмітку для товарів (Product), яка часто і дає зірочки рейтингу та ціни у пошуку. При зміні шаблону ця розмітка може зникнути або перестати валідуватись - і Google мовчки прибирає розширені сніпети.

Що має зробити команда: до або під час міграції перенести всю розмітку в JSON-LD формат. Це окремий блок коду, який не залежить від шаблону - він вбудовується в сторінку незалежно від того, яким буде дизайн. Це разова робота, але вона рятує сніпети навіть при подальших редизайнах. Вплив мікророзмітки на органічний трафік детально розібраний в пов'язаній статті.

Ще одна ситуація, яка трапляється частіше ніж здається: підрядник каже «у нас є розмітка», але вона не тестована після деплою. Google має безкоштовний інструмент для перевірки - тест розширених результатів. Попросіть підрядника показати скрін з зеленим статусом після деплою. Не «є розмітка» - а «розмітка валідна і дає правильний тип розширеного результату».

Червоний прапор: «розмітка перенесеться разом з шаблоном». Якщо шаблон новий - стара розмітка туди фізично не переїде. Якщо новий шаблон взагалі не має блоків розмітки, вона просто зникне.

Перші 60 днів після переїзду: що моніторити

Чому 60 днів, а не 7 чи 14? Google не переіндексовує весь сайт одразу після деплою. Краулер обходить сторінки поступово, за своїм розкладом - часом тижнями. Рішення про ранжування приймаються після обходу, не до нього.

Великий магазин з тисячами сторінок Google може обходити кілька тижнів. Маленький - кілька днів. Швидкість залежить від авторитетності домену, технічної доступності сервера і налаштувань файлу robots.txt. Якщо технічна команда не налаштувала robots.txt коректно після міграції - Google може взагалі зупинити обхід деяких розділів.

Ми бачили ситуації, коли через 2 тижні після міграції власник радів - «все добре, позиції є». А на 35-й день картина різко змінювалась: Google дообійшов сайт, знайшов канонічні конфлікти і почав переранжовувати. До 60-го дня ситуація стабілізувалась - але вже на нижчих позиціях.

До 60-го дня об'єктивна оцінка неможлива. Це не привід не реагувати - це привід не панікувати передчасно і не робити поспішних змін, які можуть ускладнити діагностику.

Нижче - чотири контрольні точки, на які орієнтується наша команда при моніторингу після деплою.

Зверніть увагу на День 30 - він проявляє проблеми, які були непомітні одразу після деплою. Саме тут ми кілька разів знаходили канонічні конфлікти, які сховались за «зеленим» першим тижнем.

Є одна помилка, яку ми бачили у власній практиці не один раз: власник бачить просадку на 15-й день і починає міняти контент, структуру, плагіни - «щоб виправити». Google на 15-й день ще просто не завершив переіндексацію. Кожна нова зміна скидає таймер для обхідника. В результаті сайт стає «рухомою мішенню» і повноцінна оцінка зсувається на невизначений термін.

Якщо є серйозна підозра на проблему і вона не є критичною помилкою (не 404 на головних товарах, не повний збій редиректів) - фіксуйте, чекайте до контрольної точки, потім оцінюйте системно.

Якщо ви вже пройшли міграцію і відчуваєте просадку - залиште заявку на аудит. Ми розберемось по кожній з 5 зон.

З досвіду власного магазину: понад 15 років на Joomla+VirtueMart

Ми пройшли всі великі переходи Joomla на власному магазині. Найскладнішою була міграція з 2.5 на 3.0 - у 2014 році Joomla переписала систему маршрутизації і генерацію URL. Не функціонал ламався - функціонал переїздив без проблем. Ламалось саме SEO: канонічні теги перебудовувались, частина старих адрес у Google переставала вести на потрібні сторінки, з'являлись дублі, які Google починав ранжувати замість основних. Тоді ми не знали половини того, про що написали в цій статті. Відновлювали позиції місяцями.

Пам'ятаємо конкретно: один із наших розділів каталогу просів по позиціях на кілька місяців після того переходу. Не тому що зламалась функціональність - товари відкривались, кошик працював. Просто Google отримав плутанину в канонічних тегах і вирішив ранжувати не ту версію URL.

Непомітно зсередини магазину. Дуже помітно в аналітиці трафіку.

Кожна наступна міграція була простішою. І не тому, що Joomla стала прощати помилки, а тому, що ми навчились складати чек-листи з зон ризику до старту робіт. Перехід з 3 на 4, а потім з 4 на 5 - це вже не імпровізація, а робочий регламент. Знаєш що шукати - знаходиш до деплою, а не після.

Регламент 60 днів моніторингу після деплою - не теоретичний. Це робочий стандарт нашої команди: у власній практиці ми бачили скільки коштує одна забута зона перевірки. Тому переказали в цій статті простими словами те, що технічна команда повинна знати - щоб ви, як власник, могли проконтролювати готовність свого підрядника.

Чи означає це що треба ставати SEO-фахівцем? Ні. Достатньо знати п'ять зон ризику і три артефакти, які підрядник повинен показати до початку робіт. Решта - його робота.

Одне спостереження з практики: магазини, власники яких розуміли ці п'ять зон до старту, набагато рідше телефонували нам по факту просадки. Не тому що у них були кращі підрядники. Тому що вони ставили правильні питання ще до підписання договору - і підрядник знав, що його роботу перевіряють по конкретних точках.