Як користуватися переліком
Перевіряйте магазин до перемикання домену, одразу після запуску та через кілька днів на реальних даних. Для кожного пункту запишіть відповідального, статус і доказ: URL, номер замовлення, знімок екрана або звіт.
Не обмежуйтеся головною сторінкою. Виберіть товари з простими й складними варіантами, кілька колекцій, сторінки різними мовами та ринки з іншою валютою або доставкою. Така вибірка перевіряє різні шаблони й правила, тоді як десять схожих товарів можуть повторити одну й ту саму непомічену помилку.
Зробіть повну тестову покупку від посадкової сторінки до службового листа, виконання замовлення, скасування та повернення оплати. Паралельно порівняйте кількість перенесених записів і основні поля з контрольним експортом WooCommerce. Для кожної перевірки збережіть доказ — URL, номер замовлення, знімок екрана або звіт. Після перемикання домену повторіть короткий сценарій, тому що частина інтеграцій, редиректів і тегів починає працювати лише на робочій адресі.
Не перемикайте домен, якщо не проходить оплата, неправильно списуються залишки, замовлення губиться в інтеграції або немає перевіреного способу повернути магазин до попереднього стану.
Продажі
Пройдіть шлях покупця для основних країн, валют, пристроїв і способів доставки. Shopify включає тестові замовлення до офіційної послідовності міграції.[1]
Почніть із кошика й оформлення замовлення. Товар має додаватися у вибраному варіанті, контактні дані — зберігатися, а форма оформлення — відкриватися без помилок. Перевірте основні способи оплати реальним або тестовим платежем і звірте статус замовлення в Shopify. Сам факт переходу на сторінку подяки недостатній: платіж міг залишитися в очікуванні або створити два замовлення.
Доставку тестуйте адресами з різних зон, включно з межею безкоштовної доставки та самовивозом. Тариф має залежати від правильної адреси, ваги й складу кошика. Разом із ним звірте податок, спосіб показу ціни з податком або без нього та документи для відповідного ринку. Помилка тут може не зупинити оформлення замовлення, але змінить суму, яку сплачує клієнт або отримує облік.
Окремі сценарії потрібні для купонів, залишків і варіантів. Перевірте відсоткову та фіксовану знижку, безкоштовну доставку, мінімальну суму й правила сумісності. Після покупки кількість має зменшитися в правильній локації, а продаж понад залишок — залишитися тільки для визначених товарів. Для кожного варіанта звірте ціну, SKU, зображення й наявність, бо помилка зіставлення часто стосується лише однієї комбінації.
Службові листи перевіряйте після замовлення, відправлення, скасування та повернення. У них мають збігатися мова, сума, товари, адреса, оформлення й посилання на робочий домен. Лист, що успішно відправився, все одно може вести на тестову адресу або показувати старі умови повернення.
Після покупки скасуйте замовлення або поверніть оплату. Перевірте, як змінилися залишки та записи в бухгалтерській інтеграції. Успішний платіж не показує, чи правильно працюють скасування й повернення.
Дані
Після звірки кількості записів перевірте поля та зв’язки на складних прикладах: популярний товар, товар із багатьма варіантами, відсутній товар, гостьове замовлення, клієнт із кількома адресами та замовлення з поверненням.
| Дані | Що звірити |
|---|---|
| Товари | Назви, описи, ціни, ціни до знижки, SKU, статус, виробник, теги й колекції |
| Зображення | Головне й додаткові фото, порядок, alt і збільшення; файли не залежать від старого сервера WordPress |
| Клієнти | Електронна пошта, телефон, адреса, теги й згода; передбачений спосіб активації акаунта |
| Замовлення | Номер, дата, клієнт, позиції, податок, знижка, доставка, сума, статус і повернення |
| Відгуки | Зв’язок із товаром, рейтинг, автор, дата, текст, зображення й статус публікації |
| Метаполя | Простір назв, ключ, тип, значення та використання темою або застосунком |
| Підписки | Активні договори, дата наступного списання, план, спосіб оплати й повідомлення клієнту |
Екран налаштування міграції підтверджує, які типи записів були вибрані, але не доводить повноту результату. Після імпорту звірте контрольні кількості, а потім відкрийте складні приклади з таблиці вище. Так можна знайти помилки зв’язків, які не видно у загальній кількості товарів, клієнтів або замовлень.

Поточні можливості застосунку наведено на сторінці MigrationPro у Shopify App Store.
Пароль клієнта не переноситься як звичайне поле. Перевірте запрошення до активації або інший обраний у Shopify спосіб входу. Службі підтримки потрібна коротка інструкція на випадок, якщо клієнт не зможе ввійти після запуску.[2]
SEO
Починайте SEO-перевірку зі старих адрес, які мали переходи, зовнішні посилання та пошукову видимість. Заголовок нової головної сторінки не покаже, чи збережені ці URL.
Пройдіть старі адреси пріоритетних товарів, категорій і статей. Кожна має вести одним постійним редиректом на відповідну нову сторінку, без циклу, ланцюжка або проміжної головної. Звіт про 404 не повинен містити хвилі старих URL із трафіком чи посиланнями. Сторінки без заміни, навпаки, мають повертати справжній 404, щоб пошукова система не сприйняла нерелевантний редирект як soft 404.
Потім перевірте правила для типових шаблонів: товару, колекції, звичайної сторінки та статті. Їхні canonical мають вказувати на робочий домен і потрібну версію URL. Robots.txt не повинен блокувати важливі шаблони, а тимчасовий noindex або захист паролем потрібно прибрати до відкриття. Одна помилка в шаблоні зачіпає відразу всі сторінки цього типу, тому вибіркової перевірки одного товару недостатньо.
Відкрийте `/sitemap.xml`, переконайтеся, що в ньому є доступні canonical URL, і подайте файл у Search Console. Проінспектуйте кілька пріоритетних сторінок кожного типу та спостерігайте, чи не з’явилося системного виключення цілого шаблону. Кліки й індексація оновлюються із затримкою, тому в перші дні їх потрібно зіставляти з фактичними кодами відповіді та результатами сканування.
Shopify автоматично створює sitemap, але пошукові системи не можуть отримати його, поки магазин захищений паролем. Після відкриття перевірте файл самостійно й подайте його в Search Console.[3]
Якщо таблицю старих і нових URL ще не перевірено, поверніться до докладного матеріалу про SEO-міграцію з WooCommerce на Shopify.
Маркетинг і відстеження
Після зміни платформи аналітика може показати падіння за стабільної кількості замовлень. Для кожного каналу перевірте весь ланцюжок подій: перегляд сторінки, взаємодію з товаром, початок оформлення, покупку, згоду та передавання даних у рекламну систему.
У GA4 перевірте, що події `page_view` і `purchase` не дублюються, а параметри `revenue`, `currency`, `transaction_id` та `items` заповнюються даними тестового замовлення. У Google Ads дія-конверсія має отримати ту саму суму й валюту. Розбіжність між Shopify та аналітикою вказує на налаштування події або передавання даних, а не на проблему з продажем.
Для Meta звірте Pixel і Conversions API: браузерна й серверна події не повинні дублюватися, якщо мають спільний ідентифікатор. Домен і пріоритетні події мають відповідати новому магазину. Банер згоди тестують разом із тегами в регіонах із різними правилами. Видимий банер ще не підтверджує, що сигнал згоди фактично змінив поведінку Google, Meta або платформи розсилок.
У Merchant Center перевірте підтверджений домен, оновлений фід, доступність посадкових URL і причини відхилення товарів. Платформа розсилок має отримувати профіль, згоду та події перегляду, кошика й оформлення, а автоматичні листи — запускатися один раз. У CRM простежте одне тестове замовлення від контакту до потрібного етапу процесу: так видно дублікати, втрату полів і неправильне зіставлення статусів.
Google описує окреме перенесення тегів у Shopify через Google & YouTube і попереджає, що власні налаштування тегів можуть не перенестися автоматично. Після підключення застосунку зробіть тестову покупку й перевірте події у звітах.[4]
Зручність і доступність
Перевірте магазин на реальних розмірах мобільного екрана та повільнішому з’єднанні, а не лише в попередньому перегляді на комп’ютері. Основні сценарії — знайти товар, вибрати варіант, додати його в кошик і почати оформлення.
На мобільному екрані перевірте шапку, банер згоди на файли cookie, вибір варіанта й закріплену кнопку кошика. Вони не повинні перекривати ціну, повідомлення про помилку або кнопку покупки. На сторінці товару мають залишатися читабельними галерея, наявність, доставка, повернення й відгуки; особливо перевірте довгі назви та варіанти, яких немає в наявності.
Навігація має вести до основних категорій без порожніх колекцій і зайвих рівнів. Пошук перевіряйте за назвою, SKU, брендом та поширеними варіантами написання, а фільтри — на дублікати значень і несподівані порожні результати. Якщо дані атрибутів перенесені нерівномірно, проблема проявиться лише в окремій категорії, тому використовуйте кілька різних груп товарів.
У кошику змініть кількість, видаліть товар, застосуйте знижку та звірте проміжну суму. Якщо тема підтримує висувний, повносторінковий і швидкий кошик, повторіть сценарій у кожному варіанті: вони можуть використовувати різні шаблони й події. Додаткові пропозиції не повинні непомітно змінювати варіант, кількість або умови знижки.
Окремо перевірте навігацію клавіатурою, видимий індикатор фокусу, підписи полів форми й альтернативні описи змістовних зображень. Ці помилки можуть зробити оформлення недоступним для частини клієнтів.
Перші 72 години після запуску
У перші години стежте за замовленнями, невдалими платежами, синхронізацією залишків, 404, помилками оформлення, аналітикою та зверненнями до підтримки. Щотижневий звіт покаже ці проблеми запізно.
| Коли | Що переглянути |
|---|---|
| 0–2 години | Короткий тест робочого сайту, тестова покупка, редиректи, події аналітики, домен і SSL |
| Перший день | Замовлення, оплата, доставка, залишки, листи, 404 і рекламні посадкові сторінки |
| 2–3-й день | Інспекція в GSC, sitemap, Merchant Center, атрибуція каналів і звернення клієнтів |
| 1–2 тижні | Органічні посадкові сторінки, індексація, конверсія, повернення й помилки інтеграцій |
Якщо після переходу трафік уже впав, скористайтеся окремою інструкцією з діагностики падіння після міграції.
Якщо магазин уже перенесено, зафіксуйте симптом, час появи та сторінки, яких він стосується. Ці дані допоможуть відрізнити помилку SEO, аналітики або функцій магазину.
Можна замовити технічну SEO-перевірку після міграції — із пріоритетом проблем, що впливають на продажі та органічний пошук.
Коротка версія
- Перевірте покупку від вибору товару до скасування або повернення оплати.
- Звіряйте кількість записів, основні поля та зв’язки на складних прикладах.
- Старі URL, редиректи, canonical, sitemap і robots перевіряйте на робочому сайті після запуску.
- Для GA4, реклами, Merchant Center, email, CRM і згоди потрібна тестова покупка з перевіркою подій.
- Повторіть основні перевірки в перші години, дні та тижні на реальних даних.
Джерела
- [1]Shopify Help Center
Офіційний порядок перевірки товарів, доставки, податків, оплати, тестових замовлень і домену.
- [2]Matrixify documentation
Перенесення облікових записів клієнтів, повторна активація та створення нових паролів.
- [3]Shopify Help Center
Робота автоматичного sitemap, захисту паролем і редиректів після переходу з WooCommerce.
- [4]Google Merchant Center Help
Перенесення тегів Google у Shopify за допомогою застосунку Google & YouTube.
- [5]Shopify App Store
Офіційна картка MigrationPro та зображення вибору даних для міграції.
Поширені запитання
Коли проходити перелік перевірок?
Основні пункти перевіряють до перемикання домену, повторюють одразу після запуску на робочому сайті й ще раз через кілька днів, коли з’явилися реальні замовлення, дані аналітики та Search Console.
Скільки тестових замовлень потрібно?
Кількість визначає не каталог, а набір різних сценаріїв. Потрібна щонайменше одна повна покупка для кожного критичного поєднання способу оплати, зони доставки, ринку або підписки. Окремо перевірте скасування й повернення оплати.
Що перевіряти першим, якщо часу мало?
Оформлення й оплату, залишки, службові листи, редиректи пріоритетних URL, подію purchase в аналітиці та основні інтеграції. Декоративні недоліки можна виправити після помилок, що блокують продажі або спотворюють дані.
