Перенаправлення URL у Shopify: обмеження, перевірені.

Кращий довідковий документ

Написано і підтримується для брендів та агенцій, які проводять міграцію сайту. Особливо якщо ви невелика команда, якій треба, щоб кожна година рахувалася. Цей посібник допомагає побудувати стратегію, щоб точно виконати перенаправлення 301, якщо ви мігруєте на Shopify. Зокрема, цей документ стане в пригоді, якщо ви:

• Мігруєте з Wordpress
• Мігруєте з Magento
• Мігруєте з Salesforce
• Мігруєте з Sitecore
• Мігруєте з BigCommerce
• Мігруєте з Webflow
• Мігруєте з саморобного сайту на PHP

Якщо ви беретеся за проєкт зі складними зіставленнями перенаправлень 301 і вам потрібна команда, яка живе саме цим типом роботи, зв’яжіться з нами.

Логіка перенаправлень URL у Shopify: огляд

Офіційний довідковий документ Shopify про перенаправлення URL лежить тут. Це стислий документ із загальними настановами, до яких може звернутися менеджер магазину на Shopify, щоб додати окремі та масові перенаправлення 301. У ньому бракує конкретики про типи адрес, які магазин на Shopify підтримує нативно, і цей звіт покликаний заповнити прогалини.

Стислі висновки про функціональність перенаправлень URL у Shopify

• Логіка перенаправлень URL у Shopify дуже надійна.
• З нашої перевірки 100 різних форматів рядків URL Shopify функціонально підтримав 99 зі 100 типів.
• Справжній маршрут вітрини завжди перемагає перенаправлення, і робить це мовчки.
• Нативна система не підтримує символи підстановки для перенаправлень URL.
• Оновлювати наявні шляхи перенаправлень було легко за допомогою інструмента імпорту, якщо дотримуватися незадокументованих правил Shopify
• Існують обмеження на загальну кількість перенаправлень, якими керуватимуть магазини Shopify та ShopifyPlus.
• Існують обмеження на загальну кількість символів у рядку перенаправлення URL.
• Запобігання ланцюжкам часткове. Shopify блокує один напрямок, а порядок створення все одно може залишити живий ланцюжок.
• Для адрес із параметрами існує багато винятків і правил.
• Інтерфейс керування перенаправленнями URL зручний, але йому не завадило б більше деталей.
• Тести не розглядали варіанти перенаправлень, доступні для Hydrogen і Oxygen.
• Ми даємо нинішній системі перенаправлень URL у Shopify оцінку корисності 85%.

Оцінку знижено на 5% за відсутність підтримки символів підстановки, на 1% за єдиний тип рядка URL, який не підтримується, на 2% за обмеження довжини адреси в символах, на 3% за дивну поведінку з адресами, що містять параметри, і на 4% за важливі відомості про керування даними, яких бракує в інтерфейсі перенаправлень.

Уперше перевірено 19 червня 2024 року. Повторно перевірено 27 липня 2026 року на живому магазині Shopify на стандартному тарифі, через Admin GraphQL API і через живі запити до вітрини. Що змінилося між цими двома проходами, перелічено в журналі змін.

Наша методологія перевірки перенаправлень

Своїми тестами ми хотіли відповісти на кілька питань, щоб допомогти обійти підводні камені правил перенаправлень 301 у Shopify:

• Яких символів або комбінацій рядків система перенаправлень URL не підтримує?
• Чи є обмеження на довжину рядка адреси?
• Чи є максимальна кількість записів для масового імпорту?
• Чи підтримує система перенаправлення із символами підстановки?
• Чи є якесь автоматичне форматування або перетворення рядків після імпорту, що змінює вихідні дані?

Для довідки, ось наш повний перелік адрес, який ми використали для перевірки цих різних умов. Тести проводилися на стандартному тарифі Shopify, не на ShopifyPlus.

11 висновків на допомогу з перенаправленнями в Shopify

Shopify погано ладнає з такими типами рядків URL

Один формат рядка зі ста, які ми перевірили, неможливо перенаправити надійно. Shopify приймає запис і зберігає його, але браузер, який його запитує, отримує 404. Це рядок із крапкою з комою після оператора рівності, наприклад:

/page?param=;semicolon

Прикметно в цьому рядку те, що система Shopify перетворює спеціальний символ крапки з комою на закодоване значення адреси, і в таблиці перенаправлень воно виглядає так:

/page?param=%3Bsemicolon

Коли ви вводите незакодований рядок адреси в адресний рядок браузера, він поверне помилку 404.

Ця поведінка відрізняється від обробки інших спеціальних символів. Якщо в адресний рядок ввести рядок адреси з незакодованими символами, наприклад із правою фігурною дужкою:

/page?param=}

Shopify автоматично закодує її, коли отримає запит адреси, і жодної помилки 404 не буде.

/page%7Drightbrace

Також прикметно, що інші варіації рядка адреси з незакодованою крапкою з комою проходять перевірку в системі перенаправлень Shopify, наприклад:

Помилка 404 спрацьовує лише тоді, коли незакодована крапка з комою стоїть після оператора рівності, і збій стається під час запиту, а не під час імпорту. Shopify зберігає запис із крапкою з комою у відсотковому кодуванні як %3b, і вхідна адреса із сирою крапкою з комою ніколи не збігається із закодованим записом. Запит закодованої форми повертає 301 як звичайно, тож там, де ви контролюєте вхідні посилання, відсоткове кодування крапки з комою вирішує проблему. Там, де сира крапка з комою приходить із зовнішніх посилань, які ви не контролюєте, цей формат неможливо перенаправити надійно.

Shopify не підтримує перенаправлення із символами підстановки

Перенаправлення із символами підстановки досі в списку побажань багатьох користувачів Shopify. Форуми підтримки завалені запитами на цю можливість. Досі Shopify зберігає мовчання щодо того, де це стоїть у продуктовій дорожній карті.

Наразі власникам сайтів, які планують перехід на Shopify, варто розуміти, що нативні Shopify та ShopifyPlus такої опції не пропонують.

Що таке перенаправлення із символами підстановки?

Перенаправлення із символами підстановки це тип перенаправлення адрес, який дозволяє відправляти кілька адрес, що відповідають певному шаблону, на одне призначення. Це особливо корисно під час міграції сайту, реорганізації контенту або керування великою кількістю схожих адрес. Замість того щоб налаштовувати окреме перенаправлення для кожної адреси, ви використовуєте символ підстановки (зазвичай *), який позначає будь-яку послідовність символів.

Припустімо, ви перебудовуєте свій блог і переносите всі публікації з каталогу /blog/ у /articles/. Замість того щоб налаштовувати окремі перенаправлення для кожної публікації, ви можете використати перенаправлення із символом підстановки:

From: /blog/*
To: /articles/*

This wildcard redirect will automatically map:

/blog/post1 to /articles/post1
/blog/post2 to /articles/post2
/blog/post3 to /articles/post3

Це спрощує процес перенаправлення і гарантує, що всі адреси під /blog/ безшовно потраплять на нове місце під /articles/. Стандартні магазини Shopify та ShopifyPlus такої можливості без застосунків не мають.

Частина, яка коштує людям трафіку, полягає в тому, що Shopify приймає синтаксис із символом підстановки без жодних заперечень. Запис, створений як /old-blog/*, зберігається, з’являється в таблиці перенаправлень і не повідомляє про помилку. Зірочка зберігається як буквальний символ, тож єдина адреса, з якою вона колись збіжиться, це та, що буквально містить зірочку. Це гірше за відверту відмову, бо ніщо не сигналізує про збій, доки реальний трафік не почне повертати 404. Розгорніть будь-які символи підстановки у своєму файлі перенаправлень у явні шляхи, перш ніж імпортувати його.

Shopify намагається уникати створення ланцюжків перенаправлень

У Shopify є захист від ланцюжків, і варто розуміти його межі, перш ніж на нього покладатися. Він відхиляє перенаправлення, призначення якого вже є джерелом іншого перенаправлення, з повідомленням Target can't redirect to another redirect. Він відхиляє перенаправлення, що вказує саме на себе, з повідомленням Target can't be the same as path, і блокує прямі двосторонні петлі.

У цьому тесті ми намагалися створити такі записи адрес, і це не було дозволено:

Чого захист не робить, так це не перевіряє зворотного напрямку. Створіть /a на /b, поки на /b нічого немає, потім згодом створіть /b на /c, і обидва будуть прийняті. Shopify більше ніколи не повертається до першого запису, і у вас живий ланцюжок:

GET /a
  301 to /b
  301 to /
  final: 200, 2 hops

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

curl -sIL https://yourstore.com/old-path -o /dev/null -w "hops: %{num_redirects}
"

Будь-що більше за 1 це ланцюжок.

Що таке ланцюжки перенаправлень?

Ланцюжки перенаправлень виникають, коли одна адреса перенаправляє на іншу, яка своєю чергою перенаправляє ще на одну, утворюючи послідовність, або “ланцюжок”, перенаправлень. Це може статися ненавмисно, коли з часом налаштовується кілька перенаправлень без належного керування.

Ланцюжки перенаправлень проблемні, бо можуть уповільнювати завантаження сторінок, шкодити SEO і псувати досвід користувача. Кожне додаткове перенаправлення додає затримку, бо браузер має пройти кожен крок ланцюжка, перш ніж дійти до кінцевого призначення.

Наприклад, якщо у вас налаштовано такі перенаправлення:

/old-page redirects to /new-page
/new-page redirects to /latest-page

Коли користувач відвідує /old-page, його спершу перенаправляє на /new-page, а потім одразу знову на /latest-page, і виходить ланцюжок перенаправлень.

Нові правила, яких варто дотримуватися, налаштовуючи перенаправлення в Shopify

Наше найбільше відкриття в тестах полягає в тому, що документація Shopify застаріла, а правило, яке лежить в її основі, простіше за задокументований перелік зарезервованих префіксів.

Справжній маршрут вітрини завжди перемагає перенаправлення. Там, де за адресою справді існує сторінка, Shopify віддає сторінку та ігнорує перенаправлення. Запис приймається, лежить у вашій таблиці перенаправлень і нічого не робить. Ні помилки, ні попередження. Змінна тут не префікс. Змінна це існування маршруту:

/products/ai-skillset-package-001  ->  200, the product page
/products/zz20260727               ->  301, the redirect fires

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

За словами Shopify, якщо ви намагаєтеся перенаправити щось, що починається з цих зарезервованих префіксів, ваші правила перенаправлення не будуть створені:

/apps
/application
/cart
/carts
/orders
/services
/products
/collections
/collections/all

Ми з’ясували, що це не так.

/services це виняток у цій групі, і він поводиться протилежно до решти. Перенаправлення на самому /services повертає 301. Перенаправлення на будь-чому під ним, наприклад /services/consulting, повертає 404, хоча запис зберігається без нарікань. Ми перевірили це чотири рази протягом приблизно 45 секунд, щоб виключити затримку поширення, і запис увесь час був у таблиці. Кожен інший префікс у цій групі працював із підкаталогами.

Ймовірна причина в тому, що Shopify маршрутизує /services/* внутрішньо для проксі застосунків і системних кінцевих точок, тож ці запити ніколи не доходять до таблиці перенаправлень, хоча самого механізму ми напряму не перевіряли. Якщо ви мігруєте сайт із розділом /services/, жодне з тих перенаправлень не спрацює. Перенесіть їх на іншу структуру шляхів або обробіть на рівні DNS чи проксі.

Створювати й оновлювати перенаправлення URL у Shopify легко

Створення нового перенаправлення в Shopify просте. Користувачам дають два варіанти:

• Створення окремого перенаправлення URL, по одному за раз
• Масове створення перенаправлень через файл CSV, ось найновіший шаблон для цього імпорту.

Додаючи адреси в систему Shopify, користувачі можуть вводити відносні шляхи, без домену верхнього рівня, для джерела (from), і абсолютні або відносні шляхи для призначення (to). Приклад:

/example_product.php

Створення окремих перенаправлень URL

Правила перенаправлень, які має Shopify, не дозволять створити те саме перенаправлення URL двічі, якщо користуватися інтерфейсом окремих перенаправлень.

Щойно адреса потрапила в перелік таблиці ‘Redirect from’, спроба додати її знову дасть помилку.

Якщо ви хочете оновити окремий запис адреси, вам потрібно знайти його в таблиці перенаправлень або скористатися методом масового імпорту. Якщо адреса, яка вже існує, потрапить у файл масового імпорту, поле ‘Redirect to’ цього запису буде оновлено значенням із файлу CSV.

Наша порада: завжди імпортуйте перенаправлення керованими, ефективними партіями. Наприклад, якщо у вас 10 000 перенаправлень URL, імпортуйте по 1 000 за раз і перевіряйте їх, якщо маєте час. Краще ловити помилки в менших наборах даних, ніж вишукувати їх у більших.

Будьте уважні з масовими перенаправленнями URL у Shopify

Щоб створити масові перенаправлення, заповніть файл CSV заголовками, яких вимагає Shopify, зробіть зіставлення один до одного і переконайтеся, що всі адреси відформатовані як відносні шляхи. Якщо ви створите файл з абсолютними шляхами в полі ‘Redirect from’ або ‘Redirect to’, Shopify візьме справу у свої руки. Ось кілька сценаріїв:

Висновок: двічі перевіряйте свій файл імпорту, перш ніж його використати. Інакше ви створите правила перенаправлення URL, які працюватимуть не так, як вам потрібно.

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

Shopify не накладає стелі на кількість рядків у файлі. Один імпорт на 1 051 рядок пройшов без жодної помилки за 48 секунд, що дає приблизно 1 300 рядків за хвилину.

Партії приблизно по 1 000 усе одно варто використовувати, але з іншої причини, ніж жорсткий ліміт. Менші файли збоять зрозуміліше. Якщо імпорт на 20 000 рядків піде не так, ви матимете набагато менше уявлення, які рядки це спричинили, ніж якби прогнали двадцять файлів і стежили за лічильниками. Читайте createdCount, updatedCount і failedCount після кожного імпорту, бо ненульовий failedCount це єдиний сигнал, який ви отримаєте про те, що рядки було відкинуто.

Шлях, який уже є в таблиці перенаправлень, отримує перезаписане призначення і потрапляє в updatedCount, зберігаючи початковий ідентифікатор запису. Завдяки цьому імпорт CSV безпечно повторювати, що корисно посеред міграції. Це також означає, що застарілий файл тихо перезапише виправлення, які ви зробили вручну від часу останнього імпорту.

Обмеження Shopify на кількість записів перенаправлень URL

Усе хороше має свою межу, і правила перенаправлень у Shopify не виняток. Для перенаправлень URL є два пороги.

Тарифи Shopify (не Plus):

Максимум 100 000 перенаправлень URL

Тарифи ShopifyPlus:

Максимум 20 000 000 перенаправлень

Ми не перевіряли цих меж, це було б божевіллям! Це чинні задокументовані специфікації платформи. Тримайте їх на думці, плануючи свої перенаправлення і розставляючи пріоритети для найважливіших адрес за трафіком і доходом. Наскільки нам відомо, Shopify не збільшує ці ліміти, попри постійні благання на форумах підтримки.

Обмеження Shopify на кількість символів в адресах

Ось тут із системою перенаправлень Shopify стає найгостріше. Офіційні настанови Shopify не вказують суворих обмежень на символи.

Щоб перевірити межі кількості символів адреси для перенаправлення, ми спершу побудували і спробували імпортувати дуже довгі рядки. Ми почали з адреси завдовжки 2 000 символів, оскільки браузери витримують запити URI до 2 083 символів. Ось ця красуня в усій своїй красі:

/2000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBcccccccccccccccccccccccccccccccccccccccccccccccccccDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

Спершу ми спробували імпортувати адресу на 2 000 символів через шаблон масових перенаправлень, і саме тоді спрацювала сигналізація Shopify. Поріг, який ми офіційно виявили, це обмеження в 1 024 символи для рядків перенаправлення URL, включно з початковою похилою рискою ‘/’.

• Passed адреса на 300 символів
• Passed адреса на 600 символів
• Passed адреса на 1 000 символів
• Failed адреса на 2 000 символів

Кілька важливих і незадокументованих правил перенаправлень, які варто знати про Shopify

Shopify нормалізує літери у ваших рядках адрес. Це означає, що незалежно від того, велику чи малу літеру ви поставите, він обслуговуватиме запити цих різних варіантів однаково. Усі наведені адреси потраплять на одну сторінку, навіть якщо існують окремі записи:

/CASE/TEST.html
/case/test.html
/Case/Test.html

Рядок у нижньому регістрі матиме пріоритет над рештою:

/case/test.html

У наших тестах, попри те що для “Redirect from” є два унікальні записи з різними значеннями “Redirect to”, для обох записів завжди віддавалася сторінка /about.html:

#1
/Case/Test.html [redirect to] /homepage

#2
/case/test.html [redirect to] /about.html

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

Для перенаправлень у Shopify можна використовувати абсолютні шляхи

Абсолютні шляхи адрес для ваших перенаправлень допустимі, як показав наш тест, якщо вони в полі “Redirects to”. Вони можуть вести на будь-яку адресу, яку забажаєте. Ось приклад, де шлях адреси на запит перенаправляє на профіль у LinkedIn:

[Redirect from]
/Case/Test.html

[Redirect to]
https://www.linkedin.com/wislr

Крім того, у полі “Redirect to” Shopify не прибирає домени верхнього рівня, навіть якщо це домен вашого власного магазину на Shopify.

Адреси з параметрами

У наших тестах Shopify зберігав адреси з параметрами, з деякими винятками. Якщо у вас є адреси, проіндексовані з багатьма унікальними рядками параметрів, то ці унікальні рядки можна додати в таблиці перенаправлень Shopify і відправити на унікальні призначення. Ми зробили цей тест зі звичною таксономією для таких адрес, параметрами UTM. Наприклад:

Цей рядок адреси стоїть у полі “Redirect from” таблиці перенаправлень і потрапив за призначенням:

/how-is-pkl?utm_campaign=301s+in+2024&utm_content=blue&utm_id=3012024&utm_medium=display&utm_source=google&utm_term=redirects

Ми змінили рядок адреси і прибрали останній параметр ‘&utm_term=redirects’, що дало 404:

/how-is-pkl?utm_campaign=301s+in+2024&utm_content=blue&utm_id=3012024&utm_medium=display&utm_source=google

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

Щоб підтвердити це далі, ми спрямували адресу саму на себе, чого Shopify за замовчуванням не дозволяє. Ви отримали б таке повідомлення:

Цей запис дозволений, коли параметри стоять у полі “Redirect from”. Він не становить петлі перенаправлення, але, судячи з поведінки в браузері, наш тест показав, що Shopify ігнорує цей запис. Коли адресу з “Redirect from” запитують, Shopify віддає повний рядок адреси з параметрами, а не кореневу сторінку, як очікується з таблиці:

Цей запис дозволений, але Shopify не додасть параметри до сторінки, яка завантажується, як того чекає правило. Завантажиться лише коренева адреса.

Це справджується для шляхів джерела з параметрами. Там, де шлях джерела перенаправлення не має власних параметрів, усе, що приходить із запитом, переноситься до призначення:

GET /old-page              ->  301 to /new-page
GET /old-page?utm_source=x ->  301 to /new-page?utm_source=x

Перенаправлення не прибиратимуть параметри замість вас. Прибирання має відбуватися в шарі над Shopify.

Зіставлення теж не є буквальним порівнянням рядків. Shopify нормалізує і збережений запис, і вхідний запит, перш ніж їх порівняти, тож регістр і порядок параметрів не мають значення. Для запису, збереженого як /page?doe&name=john, усі варіанти ?name=John&Doe, ?Doe&name=John і ?name=john&doe повертають 301. Що справді має значення, так це які параметри присутні: кожен параметр зі збереженого шляху має з’явитися в запиті, а якщо один прибрати, повернеться 404, а не часткове збігання.

Наше останнє спостереження про адреси з параметрами полягає в тому, що Shopify у деяких випадках переписує дані, які ви йому даєте. Так, Shopify переписує дані адрес, які ви даєте, для деяких параметрів.

Ось приклади, де наші тести виявили цю закономірність.

Вихідні дані перенаправлення, прийняті Shopify:

/test?name=John&Doe

Shopify переписав рядок так, щоб ‘doe’ стояло першим, і перевів його в нижній регістр:

/test?doe&name=john

Значення переводяться в нижній регістр разом із ключами, тож таблиця перенаправлень у порівнянні з файлом, з якого вона взялася, виглядатиме так, ніби імпорт зіпсував дані.

Вихідні дані перенаправлення, прийняті Shopify:

/user?name=John&age=30&active=true

Shopify переписав рядок так, щоб параметри йшли в новому порядку:

/user?active=true&age=30&name=John

Проведені нами тести підказують, що Shopify намагається розставити параметри в алфавітному порядку. Ми замислилися, чи це не помилка, адже ми встановили, що Shopify трактує адреси з параметрами як буквальні рядки, то навіщо підривати це правило, переписуючи порядок параметрів. Наразі ви ніколи не змусите рядки адрес із кількома значеннями параметрів зберегти свою структуру. Це може мати серйозні наслідки для деяких систем керування контентом.

Інтерфейсу перенаправлень URL у Shopify потрібне оновлення

За час нашого інтенсивного користування інструментом перенаправлень Shopify ми зрозуміли, що одні елементи цінуємо, а інших нам бракує.

Ми цінуємо ці можливості:

• Кнопки та функціональність масового імпорту перенаправлень
• Фільтрація і швидкий пошук по таксономії адрес
• Експорт адрес
• Легкість створення однієї адреси

Ми виявили, що інструменту бракує таких даних і функцій:

• Загальна кількість імпортованих адрес
• Простіший спосіб скопіювати і вставити більше однієї адреси в систему. Якщо ви додаєте більше однієї адреси за раз, доводиться користуватися документом імпорту. Один зі сценаріїв, де копіювання і вставлення були б корисні, це коли набір адрес має вести на одне й те саме призначення.

Імпортувати швидко, скасувати імпорт ні

Створювати перенаправлення масово швидко. Видаляти їх масово ні, і розрив достатньо великий, щоб змінити те, як ви плануєте імпорт.

Швидкі мутації масового видалення закриті. urlRedirectBulkDeleteBySearch, urlRedirectBulkDeleteByIds і urlRedirectBulkDeleteAll усі потребують області write_online_store_navigation і активної сесії користувача. Застосунок, який автентифікується через облікові дані клієнта, а саме так працює більшість міграційних скриптів, не може їх викликати, і йому лишається видаляти по одному запису.

Плануйте свої імпорти так, ніби їх важко відкотити, бо так і є. Спершу перевірте файл на тестовому магазині або імпортуйте траншами, які ви готові розібрати вручну. Не заливайте файл на 50 000 рядків, який ви не перевірили, у припущенні, що зможете швидко його відкотити.

Імпорт CSV і Admin API по-різному обробляють дублікати

Цей посібник написано навколо робочого процесу з CSV, де дубльований шлях оновлює наявний запис. API робить навпаки:

create /existing-path -> /pages/about
(where /existing-path already redirects to /)

REJECTED: "Path has already been taken"

Тому, хто переносить робочий процес із CSV на Admin API, доводиться запитувати наявний запис і викликати urlRedirectUpdate або видаляти й створювати заново. Прямий перенос логіки імпорту зазнає невдачі на кожному шляху, який уже існує.

Як перевірити свої перенаправлення в Shopify після запуску

Усе вище описує, що Shopify прийме. Ніщо з цього не каже, чи справді працюють імпортовані вами перенаправлення на живому магазині, а це вже інше питання. Перенаправлення може імпортуватися чисто, з’явитися в адмінці і все одно робити не те, чого ви чекали, щойно на шляху опиниться тема, застосунок або проксі.

Перевіряйте ззовні магазину, а не клацанням у браузері, бо браузер приховує саме те, що вам треба побачити: код статусу. Запитайте стару адресу і прочитайте заголовки відповіді.

curl -sIL https://yourstore.example/old-product-url

Читайте у виводі три речі:

• Код статусу на першому переході. Вам потрібен 301. 302 тимчасовий і передає вагу інакше, а це важливо, коли вся суть у постійному переїзді.
• Кількість переходів. Кожен рядок HTTP/ у виводі це один перехід. Два чи більше означає, що ви побудували ланцюжок, і виправлення полягає в тому, щоб перенаправити початкове джерело одразу на кінцеве призначення, а не лишати проміжний крок.
• Фінальний статус. Останній рядок має бути 200. Перенаправлення, яке закінчується на 404, гірше за відсутність перенаправлення взагалі, бо у вашій таблиці воно виглядає опрацьованим.

Потім перевірте форми, про які легко забути. Виконайте ту саму перевірку на адресі з параметром відстеження, щоб підтвердити, що рядок запиту доходить до призначення, на кореневому домені так само, як і на www, і через звичайний http, а не лише https. Ми перевірили саме це на живому магазині, і параметр дійшов до цілі неушкодженим, але суть у тому, щоб перевірити це на своєму магазині, а не довіряти загальній відповіді, бо тема чи застосунок можуть змінити результат.

Одна поведінка, про яку варто знати, перш ніж панікувати: після того як ви змінили або видалили перенаправлення, вузол на краю мережі Shopify може ще близько тридцяти секунд віддавати стару відповідь, тоді як версія тієї самої адреси з обходом кешу вже повертає нову. Дайте хвилину і перевірте ще раз з доданим унікальним рядком запиту, перш ніж робити висновок, що перенаправлення не застосувалося.

Щодо повної послідовності дій навколо міграції, а не одного перенаправлення, пройдіться чеклістом міграції сайту, який охоплює зіставлення, день запуску і моніторинг після запуску, у які це все вбудовується.

Підсумок

Система, яку Shopify має для керування перенаправленнями 301, добра для більшості бізнесів, але ще не корпоративного рівня. З часом ми сподіваємося, що вона розвинеться до перенаправлень із символами підстановки і більшої кількості записів перенаправлень для стандартних тарифів і Plus. Можливість користуватися їхньою системою перенаправлень і різноманіття форматів адрес, які вона підтримує, дають нам підстави поставити високу оцінку корисності.

Якщо ви беретеся за проєкт зі складними зіставленнями перенаправлень 301 і вам потрібна команда, яка живе саме цим типом роботи, зв’яжіться з нами.

Журнал змін

Цей посібник уперше опубліковано за результатами тестування 19 червня 2024 року і повторно перевірено 27 липня 2026 року на живому магазині Shopify на стандартному тарифі, через Admin GraphQL API і через живі запити до вітрини. Більшість початкових висновків витримали. Дев’ять ні. Текст вище описує, що Shopify робить тепер, а ось що зрушило.

Обмеження на кількість записів, 100 000 на стандартних тарифах і 20 000 000 на Plus, не перезапускалися. Дійти до них тепер механічно можливо, коли конвеєр імпорту виміряний, але видалення йде зі швидкістю приблизно 280 записів за хвилину без скриптового масового відкоту, тож підтвердження задокументованого числа лишило б живий магазин зі сміттєвими перенаправленнями на шість годин або більше.

Часті питання

Кому призначена база знань WISLR про перенаправлення URL у Shopify?

Наша база знань насамперед допомагає брендам і агенціям, які проводять міграції сайтів на Shopify. Вона особливо цінна для невеликих команд, яким потрібно, щоб кожна година рахувалася, і допомагає клієнтам зіставити та виконати до 100 000 перенаправлень URL ефективно.

Чи має Shopify офіційний документ підтримки про перенаправлення URL?

Так, Shopify підтримує офіційний довідковий документ про перенаправлення URL на help.shopify.com. Він дає загальні настанови щодо додавання окремих і масових перенаправлень 301, а наш посібник доповнює його докладними специфікаціями про типи адрес та обмеження платформи.

Які рядки URL Shopify не підтримує?

Shopify має лише один непідтримуваний формат рядка адреси: рядки з незакодованою крапкою з комою після оператора рівності (наприклад, /page?param=;semicolon). Усі інші формати адрес, включно із закодованими крапками з комою і крапками з комою в інших позиціях, підтримуються.

Чи підтримує Shopify перенаправлення із символами підстановки або регулярними виразами?

Ні, Shopify наразі не підтримує перенаправлень із символами підстановки або шаблонами регулярних виразів у своїй нативній системі перенаправлень. Це обмеження діє і для стандартних магазинів Shopify, і для Shopify Plus.

Що таке перенаправлення із символами підстановки?

Перенаправлення із символами підстановки дозволяють відправляти кілька адрес, що відповідають певному шаблону, на одне призначення. Наприклад, перенаправлення всіх адрес під /blog/* на /articles/*. Хоча цю можливість часто просять, наразі вона недоступна у власній функціональності Shopify.

Чи може Shopify уникнути створення ланцюжків перенаправлень?

Так, у Shopify є вбудований захист, щоб запобігти ланцюжкам перенаправлень. Система не дозволить створити перенаправлення на адресу, яка вже перенаправляється кудись інде.

Що таке ланцюжки перенаправлень?

Ланцюжки перенаправлень виникають, коли адреси перенаправляють через кілька кроків, перш ніж дійти до кінцевого призначення (наприклад, A на B на C). Такі ланцюжки можуть уповільнювати завантаження сторінок і шкодити результатам SEO. Система Shopify за задумом допомагає їм запобігти.

Чи легко створювати й оновлювати перенаправлення URL у Shopify?

Так, Shopify надає два прості способи: створення окремого перенаправлення URL через інтерфейс і масовий імпорт через файл CSV. Обидва способи підтримують відносні та абсолютні шляхи адрес.

Як створити масові перенаправлення URL у Shopify?

Масові перенаправлення можна створити за допомогою інструмента імпорту CSV від Shopify. Ми радимо імпортувати партіями по 1 000 для простішої перевірки помилок і керування. Шаблон для імпорту доступний тут.

Чи має Shopify максимальне обмеження на кількість записів перенаправлень URL?

Так. Стандартні тарифи Shopify обмежені 100 000 перенаправлень URL, тоді як магазини на Shopify Plus можуть тримати до 20 000 000 перенаправлень. Ці обмеження фіксовані, і їх неможливо збільшити.

Чи має Shopify обмеження на кількість символів у перенаправленні?

Так, Shopify накладає обмеження в 1 024 символи для рядків перенаправлення URL, включно з початковою похилою рискою (’/’). Адреси, довші за це, система не прийме.

Чи є інструмент для перевірки адрес на сумісність із Shopify?

Хоча Shopify не надає офіційного інструмента перевірки, наше ґрунтовне тестування показало, що 99% стандартних форматів адрес підтримуються. Головне, про що треба пам’ятати, це обмеження в 1 024 символи та уникнення незакодованих крапок з комою після оператора рівності.