Чому зміна платформи впливає на SEO
Google індексує URL із їхнім вмістом, внутрішніми й зовнішніми посиланнями та накопиченою історією. Після міграції той самий товар може отримати іншу адресу, шаблон, навігацію, canonical і структуровані дані.
У WooCommerce шлях товару можна налаштувати довільно. Shopify додає до товарів `/products/`, до колекцій — `/collections/`, а до звичайних сторінок — `/pages/`. Домен можна залишити, але старі шляхи автоматично не збережуться.[1]
WooCommerce:
/product/black-shoes/
Shopify:
/products/black-shoesСтарий URL може бути в індексі Google, отримувати кліки, мати зовнішні посилання й приносити продажі. Постійний редирект має вести з нього на найближчу за змістом сторінку Shopify.
Якщо ви ще визначаєте обсяг усього переїзду, спочатку перегляньте основний гайд із міграції WooCommerce на Shopify.
За допомогою таблиці URL і технічної перевірки можна знайти втрачені сторінки, помилкові редиректи, закриту індексацію та розірвані внутрішні посилання. Незмінних позицій така робота не гарантує.
Таблиця старих і нових URL
У таблиці кожній старій адресі призначають нову ціль або статус видалення. Одного списку товарів недостатньо: у ньому не буде категорій, дописів, посадкових сторінок, вкладень, старих рекламних URL і редиректів, створених до міграції.
Початковий список складають із кількох джерел, бо жодне з них не містить усіх адрес. Sitemap показує заявлені сторінки, а сканування — фактично доступні внутрішні посилання. Search Console і GA4 додають посадкові сторінки, які отримували переходи, навіть якщо вони вже випали з навігації. Звіти про зовнішні посилання, рекламні кампанії та Merchant Center знаходять URL, на які досі ведуть інші системи.
Окремо експортуйте чинні редиректи з WordPress або SEO-плагіна. Інакше адреса, для якої вже діє переспрямування, може загубитися під час другого переїзду або утворити ланцюжок із двох чи трьох переходів. У підсумковій таблиці для кожного старого URL запишіть тип сторінки, кліки, дохід, зовнішні посилання, нову ціль і рішення: перенести, об’єднати чи видалити.
Міжнародні версії, URL із параметрами та давно видалені сторінки перевіряйте окремими групами. Підпапка країни може потребувати іншої цілі, параметр фільтра — canonical на основну колекцію, а старий товар без заміни — справжню сторінку 404. Код 410 доречний лише тоді, коли обрана реалізація Shopify дає змогу повернути його. Одне правило для всіх цих випадків створить нерелевантні редиректи.
Сторінка товару без кліків за останній місяць може мати сезонний попит, зовнішні посилання або використовуватися в листах і рекламі. Через це дані Search Console, GA4, рекламних кабінетів і звітів про посилання потрібно зіставити.
| Стара сторінка | Нова ситуація | Рішення |
|---|---|---|
| Товар має прямий еквівалент | Той самий товар у Shopify | 301 на новий URL товару |
| Категорія збережена | Є відповідна колекція | 301 на колекцію |
| Кілька сторінок об’єднані | Є одна повна сторінка | 301 кожної старої адреси на спільну релевантну ціль |
| Товар знято, є близька заміна | Збігається потреба користувача | 301 на заміну або вузьку колекцію |
| Сторінку видалено без заміни | Немає релевантної цілі | Справжній 404 замість редиректу на головну |
Якщо дані або редиректи завантажують через застосунок, збережіть використаний файл і звіт про результат. Інтерфейс імпорту показує вибрані колонки, але не визначає релевантність нової цілі. Після завершення окремо перевірте вибірку старих URL у браузері або сканером.
Актуальна інформація про застосунок доступна на сторінці Matrixify у Shopify App Store.
Як працює постійний редирект
Редирект із кодом 301 повідомляє браузеру й пошуковій системі, що сторінка переїхала назавжди. У Shopify редиректи створюють по одному або імпортують із CSV. Правило спрацьовує лише для неактивної старої адреси; зарезервовані шляхи, параметри запиту та підкаталоги ринків мають окремі обмеження.[2]
Редирект має вести одразу на кінцевий canonical URL. Ланцюжок зі старої адреси через проміжну до нової додає зайвий запит і ускладнює перевірку. Якщо у WordPress уже був редирект, у Shopify вкажіть його кінцеву ціль.
Google радить не переспрямовувати багато видалених товарів і категорій на головну сторінку. Такий редирект не відповідає початковому запиту користувача й може бути розпізнаний як soft 404.[3]
Приклад контролю великого набору редиректів є в кейсі про міграцію з WordPress на Shopify.
Які сторінки захищати насамперед
Спочатку перевіряють URL з органічними кліками, доходом, позиціями за комерційними запитами, зовнішніми посиланнями, сезонним попитом, активною рекламою або прямими переходами. Помилка на таких сторінках впливає на продажі або вже оплачені кампанії.
До першої групи входять товари з продажами або зовнішніми посиланнями та категорії, які ранжуються за запитами товарних груп. Для них помилкова ціль редиректу може одночасно прибрати органічну посадкову сторінку, зламати старе посилання й направити відвідувача на невідповідний асортимент. Перевіряйте не тільки код 301, а й те, чи нова сторінка зберігає товар, категорію та намір старого запиту.
Друга група — інструкції, порівняння, сторінки брендів, доставки, повернення, магазинів і контактів. Вони можуть не приносити пряму покупку в останньому кліку, але відповідати на запит перед замовленням або отримувати сталі зовнішні переходи. URL з Merchant Center, активних Google Ads, а також мовні й регіональні версії перевіряють для кожного ринку: доступна сторінка ще не означає, що у фіді, рекламі та hreflang вказана правильна адреса.
Search Console показує кліки, покази, запити й посадкові сторінки в Google. GA4 записує дії після переходу на сайт, але не замінює пошукові дані. Експорт зовнішніх посилань додає URL, які могли не отримати кліків у вибраному періоді.
Якщо команда бачить графік, але не може відрізнити сигнал від причини, корисний матеріал чому SEO-дашборди неефективні без процесу діагностики.
Canonical, robots, sitemap і структуровані дані
Canonical
Кожна нова сторінка для індексації повинна вказувати canonical на правильний URL Shopify. Після міграції в коді не мають залишитися canonical на тестовий домен, myshopify.com, стару адресу WooCommerce або інший варіант тієї самої сторінки. Google радить оновити canonical разом із таблицею URL.[3]
Robots і noindex
Закритий магазин Shopify зазвичай захищений паролем, а тестові шаблони можуть містити noindex. Перед запуском відкрийте робочий сайт для Googlebot, перевірте важливі шаблони й приберіть тимчасові noindex. Google називає залишене блокування однією з типових помилок під час переїзду.[3]
Sitemap
Shopify автоматично створює `sitemap.xml` для товарів, колекцій, сторінок, дописів і основних зображень. Після зняття захисту паролем відкрийте файл, перевірте його склад і подайте в Search Console. URL у sitemap може залишитися неіндексованим, але файл повідомляє Google про нові адреси.[1]
Structured data
Тема та застосунки можуть одночасно генерувати розмітку Product, Breadcrumb, Organization та інші типи структурованих даних. Після запуску звірте ціну, наявність, валюту, варіанти й рейтинг у розмітці з видимими даними. Дві розмітки Product від теми та застосунку можуть містити різні значення.
Внутрішні посилання та вміст
Редиректи приймають переходи на старі адреси, але посилання всередині нового магазину мають вести прямо на нові canonical URL. Оновіть меню, колекції, рекомендації товарів, навігаційні ланцюжки, дописи, підвал та HTML-описи за таблицею URL.[3]
Під час імпорту в текстах і зображеннях можуть залишитися абсолютні URL WordPress. Після вимкнення старого сервера такі зображення або файли перестануть відкриватися. Matrixify описує перенесення зображень з описів у Shopify Files; результат потрібно перевірити скануванням сайту та в браузері.[4]
Збережіть тексти категорій, FAQ, інструкції з вибору та характеристики товарів, якщо вони відповідали запитам і використовувалися на сторінках із продажами. Одночасна зміна URL і вмісту ускладнить пошук причини, якщо показники після запуску знизяться.
Не змінюйте все одночасно
Якщо одночасно змінити CMS, URL, структуру категорій, вміст, навігацію, дизайн і товарну класифікацію, після падіння буде складно відокремити вплив кожної зміни. Частину робіт краще відкласти до стабілізації індексації.
Google радить за можливості розділяти великі зміни в часі. Окремі етапи дають змогу порівняти показники до й після кожного з них.[3]
| Зміна | Обережніший підхід |
|---|---|
| CMS і дизайн | На момент запуску зберегти корисний вміст, ієрархію та основні сценарії користування |
| URL і класифікація | Спочатку створити відповідні цільові сторінки; класифікацію змінювати після стабілізації |
| Навігація | Не прибирати посилання на важливі колекції без даних і заміни |
| Описи товарів | Перенести чинні тексти, а масове переписування зробити окремим проєктом |
| Домен | За можливості не поєднувати зміну платформи зі зміною домену |
Після одночасної зміни кількох частин сайту складніше встановити, що вплинуло на кліки, позиції або коефіцієнт конверсії.
Перевірка в Search Console і Merchant Center
До запуску збережіть початкові дані за порівнянні періоди: кліки, покази, запити, посадкові й індексовані сторінки, 404, коефіцієнт конверсії та дохід. Після запуску розділяйте органічний трафік за типом сторінки, країною, пристроєм і старими чи новими URL.
Після відкриття магазину подайте новий sitemap у Search Console й переглядайте звіт Page indexing. Для пріоритетних товарів і колекцій використовуйте URL Inspection: він показує, чи Google може отримати сторінку, який canonical бачить і чи дозволена індексація. Ця вибіркова перевірка швидше знаходить помилку шаблону, ніж очікування загального звіту.
404 і ланцюжки редиректів шукайте повторним скануванням старого списку URL та, якщо доступно, у журналах сервера або CDN. Search Console показує не всі звернення й оновлюється із затримкою. Для кожної проблемної адреси зафіксуйте код першої відповіді, кінцевий URL, кількість переходів і відповідність сторінки старому змісту.
Кліки й покази порівнюйте за посадковою сторінкою та запитом, а дані GA4, Google Ads і події конверсії — окремо від GSC. Так можна відрізнити втрату пошукової видимості від помилки аналітики. У Merchant Center паралельно перевіряйте підтвердження домену, URL у фіді, доступність товарів та причини відхилень: старі адреси у фіді можуть зупинити показ товарів навіть тоді, коли органічна індексація працює.
Якщо домен або URL товарів у Merchant Center змінилися, підтвердьте актуальний домен і оновіть джерело даних. Після підключення Google & YouTube перевірте, який домен заявив застосунок і чи збігається він з адресами товарів.[5]
Google попереджає про тимчасові коливання під час повторного сканування та індексації. Водночас масова поява 404 або випадіння цілого шаблону з індексу вказує на конкретну технічну проблему, яку потрібно перевірити.[3]
Одразу після запуску використовуйте перелік перевірок після міграції. Якщо кліки вже знизилися, переходьте до діагностики за сторінками й запитами.
Коли потрібен технічний SEO-супровід
Для магазину з органічним трафіком, довгою історією URL, тисячами товарів, кількома мовами або великою кількістю старих редиректів SEO-перевірку починають до затвердження структури нової теми. Інакше для важливих старих сторінок може не виявитися відповідних нових цілей.
Технічний SEO-супровід охоплює перелік URL, пріоритет посадкових сторінок, правила зіставлення, а також перевірку редиректів, canonical, robots, sitemap, структурованих даних і внутрішніх посилань після запуску. Перевірка не гарантує позицій, але показує конкретні помилки та сторінки, яких вони стосуються.
Для сайту з історією органічних переходів план URL і критерії перевірки потрібно підготувати до перемикання домену. Після запуску відновлювати втрачений перелік адрес складніше.
Щоб оцінити технічну SEO-частину переходу, можна зв’язатися зі мною.
Повний commercial scope описано на сторінці міграції сайту на Shopify.
Також доступний окремий опис послуги технічний SEO-аудит.
Коротка версія
- Зберіть старі URL із sitemap, результатів сканування, GSC, аналітики, зовнішніх посилань і реклами.
- Для кожної цінної старої сторінки виберіть одну релевантну нову адресу.
- Не переспрямовуйте видалені сторінки масово на головну.
- До запуску перевірте canonical, robots/noindex, sitemap, структуровані дані та внутрішні посилання.
- Після запуску окремо аналізуйте кліки, відстеження та конверсію.
Джерела
- [1]Shopify Help Center
Особливості домену й структури URL після переходу з WooCommerce, робота редиректів і автоматичного sitemap Shopify.
- [2]Shopify Help Center
Створення та імпорт редиректів, зарезервовані шляхи й інші актуальні обмеження Shopify.
- [3]Google Search Central
Рекомендації Google щодо зіставлення URL, постійних редиректів, canonical, внутрішніх посилань, sitemap і перевірки переїзду.
- [4]Matrixify documentation
Перенесення зображень з описів, редиректів та інших даних під час міграції з WooCommerce на Shopify.
- [5]Google Merchant Center Help
Перенесення тегів Google у Shopify, підтвердження домену, URL товарів і перевірка вимірювання.
- [6]Shopify App Store
Офіційна картка Matrixify та зображення інтерфейсу імпорту.
Поширені запитання
Чи можна повністю уникнути коливань трафіку?
Ні. Google може тимчасово змінювати покази й позиції, поки перескановує нові URL. Поєднання повної таблиці адрес, редиректів і технічної перевірки зменшує кількість помилок, але не гарантує незмінних позицій.
Скільки часу зберігати редиректи?
Google рекомендує зберігати постійні редиректи якомога довше, загалом щонайменше рік. Для старих зовнішніх посилань їх можна залишити безстроково, а внутрішні посилання потрібно оновити на прямі нові URL.
Що робити з товаром, якого більше немає?
Якщо є близька заміна або релевантна колекція з тим самим наміром, використовуйте постійний редирект. Якщо відповідної цілі немає, повертайте справжній 404 замість переспрямування на головну.
Чи потрібен Change of Address у Search Console?
Якщо домен не змінюється, ні. Інструмент Change of Address стосується переїзду на інший домен. Зміни шляхів на тому самому домені передаються через редиректи, внутрішні посилання, sitemap і повторне сканування.