Миграция с Shopify на headless означает замену темы на Liquid собственным фронтендом, который обращается к Shopify через Storefront API, а каталог, заказы, платежи, инвентарь и доставка остаются в Shopify без изменений. Типовой проект занимает 8-16 недель и стоит от 80 000 до 150 000+ долларов для полностью кастомной сборки - диапазон сильно зависит от сложности каталога и числа сторонних интеграций. Решение оправдано не для каждого магазина: ниже - конкретные пороги, после которых тема Shopify становится архитектурной проблемой, а не вопросом дизайна.
В проектах веб-разработки Exceltic.dev по e-commerce типовая точка обращения выглядит почти всегда одинаково: магазин на Shopify стабильно рос, каталог перевалил за несколько тысяч SKU, в тему встроено 15-20 приложений - и PageSpeed на карточке товара упал ниже 50 при живом трафике в пиковые часы.
По данным сравнения производительности Liquid и headless от команды Shopify, около 60% Liquid-магазинов проходят все пороги Core Web Vitals - то есть почти половина не проходит, и проблема системная, а не единичная. Allbirds после headless-переезда сообщили о 40% улучшении скорости загрузки, а Staples Canada вышли на LCP ниже секунды на ключевых посадочных страницах.
Дальше в статье: пороги, после которых тема Shopify становится бутылочным горлышком, что теряется при наивном переезде, как устроен аудит, какую архитектуру выбрать - Hydrogen или Next.js - и какие цифры Core Web Vitals обычно дают headless-магазины после миграции.
Проблема не абстрактная. Маркетинг-команда не может добавить новый блок на карточку товара, потому что тема собрана из трёх конструкторов страниц и любое изменение ломает мобильную вёрстку. Разработчик не может ускорить чекаут, потому что логика чекаута зашита в приложения, которые обновляются без предупреждения. А руководитель не может оценить реальную стоимость роста, потому что каждое новое приложение добавляет ежемесячную подписку и десятки килобайт JavaScript, которые никто не убирает.
Headless-коммерция: архитектура, при которой Shopify остаётся коммерческим движком - каталог, заказы, платежи, инвентарь, фулфилмент, - а витрина работает как отдельное приложение, получающее данные через API вместо серверного рендеринга темы на Liquid.
Когда тема Shopify становится архитектурной проблемой
Headless - это не апгрейд по умолчанию, а смена архитектуры с другими компромиссами: дороже, дольше и требует команды разработки на постоянной основе. Стоит переходить, если совпадает несколько порогов ниже, а не один.
- Каталог и фильтрация - от 2000-3000 SKU с многоуровневыми вариантами и фасетным поиском: стандартная тема Liquid начинает тормозить на страницах категорий из-за объёма DOM и клиентских скриптов фильтрации.
- Число приложений - 15+ приложений, каждое из которых внедряет свой JavaScript в тему: суммарный вес скриптов растёт быстрее, чем растёт сам магазин, и никто в команде не отвечает за его сокращение.
- Несколько витрин под один каталог - розничная витрина, B2B-портал и мобильное приложение должны показывать один и тот же каталог, но с разной логикой цен и доступности.
- Кастомный чекаут за пределами тарифа - нужна логика чекаута, которую не даёт Checkout Extensibility даже на Shopify Plus.
- Международные витрины - разные языки, валюты и юридические требования на фронтенде, которые не укладываются в мультивитринную логику темы.
Если ни один порог не пройден, а проблема - в конкретной медленной секции темы, обычно дешевле и быстрее переписать эту секцию или сменить тему, чем запускать headless-проект на 80 000+ долларов.
Что теряется при наивном переезде на headless
Прямой перенос без плана почти всегда ломает часть логики, которая годами держалась на встроенных возможностях темы и приложений.
Приложения, написанные под темы Liquid - виджеты отзывов, попапы, апселлы, - не имеют готовой headless-версии в большинстве случаев. Каждое такое приложение приходится либо заменять API-совместимым аналогом, либо переписывать интеграцию вручную через собственный код.
Логика чекаута, кастомизированная через checkout.liquid на старых тарифах, не переносится на headless напрямую: Checkout Extensibility работает по другой модели расширений, и часть прежней кастомизации нужно пересобирать с нуля.
Метаполя (metafields) и структура данных, специфичные для темы, не всегда совпадают с тем, что удобно забирать через Storefront API - без явного маппинга часть контента карточки товара просто не появляется на новой витрине.
SEO-сигналы страдают без карты редиректов: если URL-паттерны новой витрины отличаются от паттернов темы, часть накопленной видимости в поиске теряется на несколько недель, пока Google не переиндексирует новые адреса.
Аудит перед переездом - чек-лист
Скип аудита - самая частая причина, по которой headless-проекты выходят за бюджет: команды теряют 15-40% реального объёма работ именно потому, что не инвентаризировали магазин перед стартом. Разница ощутима в деньгах: аудит для проекта среднего размера стоит порядка 8 000-12 000 долларов, а его пропуск в среднем удваивает стоимость исправлений на более поздних этапах.
- Каталог и структура вариантов - число SKU, глубина категорий, кастомные фильтры, товары с уникальной логикой цен
- Приложения и их роль - какие 15-20 приложений реально нужны на фронтенде, какие можно заменить логикой на бэкенде
- Кастомный код темы - весь Liquid-код, который меняет поведение по умолчанию: галереи, апселлы, логика доставки
- Чекаут - что именно кастомизировано сейчас и что из этого доступно через Checkout Extensibility
- Интеграции - ERP, PIM, складской учёт, email-маркетинг, аналитика - всё, что дёргает данные из Shopify или пишет в него
- Карта URL и редиректов - полный список текущих адресов, включая пагинацию категорий, фильтры, коллекции
Архитектура: Hydrogen, Next.js или Remix
В 2026 году выбор фреймворка для headless-Shopify сводится к трём вариантам, и решение зависит от того, насколько глубоко бизнес завязан именно на Shopify.
Hydrogen - собственный фреймворк Shopify на базе React Router v7 (бывший Remix), разворачивается на Oxygen - глобальном edge-хостинге Shopify. Даёт готовые коммерческие компоненты, хуки для Storefront API и предсказуемую стоимость владения, потому что хостинг уже включён в тариф.
Next.js работает headless против любого бэкенда с GraphQL или REST API - не только Shopify. Такой выбор оправдан, когда Shopify - не единственная система в архитектуре: рядом стоит отдельная CMS, PIM или аналитика, и нужна независимость от инфраструктуры Shopify.
Практическое правило: если Shopify - 80% и больше коммерческой логики бизнеса, выбирают Hydrogen. Если меньше 50% - Next.js. Промежуточные случаи решаются исходя из состава команды и срока проекта, а не абстрактных предпочтений фреймворка.
Похожий выбор архитектуры проходят и маркетинговые сайты: миграция с WordPress на Next.js сталкивается с той же развилкой - готовая экосистема против гибкости кастомного стека.
Пример запроса к Storefront API
query ProductByHandle($handle: String!) {
product(handle: $handle) {
id
title
variants(first: 10) {
edges {
node {
id
price { amount currencyCode }
availableForSale
}
}
}
}
}Пошаговый процесс миграции с Shopify на headless
1. Аудит и техническое задание
Инвентаризация каталога, приложений, кастомного кода и интеграций по чек-листу выше. Результат - документ с полным объёмом работ и списком рисков, а не просто оценка в неделях.
2. Выбор фреймворка и хостинга
Решение между Hydrogen на Oxygen и Next.js на внешнем хостинге - на основе доли Shopify в общей архитектуре и состава команды разработки.
3. Проектирование модели данных
Маппинг метаполей, вариантов и коллекций Shopify в структуру, удобную для фронтенда: какие данные забираются через Storefront API напрямую, какие нужно денормализовать.
4. Сборка витрины и подключение Storefront API
Разработка каталога, карточки товара, корзины и поиска на выбранном фреймворке с постраничным сравнением против текущей темы по функциональности.
5. Перенос и адаптация приложений
Замена приложений, у которых нет headless-версии, на API-совместимые аналоги или собственный код - самый недооценённый по времени этап проекта.
6. Кастомизация чекаута через Checkout Extensibility
Пересборка логики чекаута под новую модель расширений вместо прямого переноса старого checkout.liquid.
7. Карта редиректов и тестирование SEO-сигналов
Полная карта 301-редиректов со старых URL на новые, проверка структурированных данных, sitemap и canonical-тегов до запуска.
8. Параллельный запуск и мониторинг
Запуск новой витрины на части трафика или в staging-режиме с мониторингом конверсии, скорости и ошибок чекаута перед полным переключением.
Core Web Vitals до и после headless-переезда
По данным сравнения Shopify, headless-магазины при качественной реализации показывают LCP и INP заметно ниже, чем типовая тема на Liquid с полным набором приложений - разрыв особенно заметен на карточках товара и страницах категорий с фильтрами.
В типовом проекте перехода магазина с каталогом от 3000 SKU headless-версия обычно даёт улучшение скорости загрузки в диапазоне 30-50% против прежней темы - разброс большой, потому что итоговый результат сильно зависит от качества реализации, а не только от смены архитектуры.
Важная оговорка: сама по себе смена архитектуры не гарантирует прирост. Headless-витрина, собранная без внимания к размеру бандла и стратегии кэширования, может оказаться медленнее хорошо оптимизированной темы. Разница между «headless» и «headless, сделанный правильно» - это отдельная статья бюджета, которую часто недооценивают на этапе оценки проекта.
Если команда уже разбирается с производительностью на текущей платформе, оптимизация INP - метрика, которая чаще всего проседает на карточках товара с большим числом интерактивных элементов - даёт представление о том, какие проблемы переезд решает архитектурно, а какие нужно чинить в любом случае.
Типичные ошибки при переезде на headless
Пропуск аудита каталога и приложений - самая дорогая ошибка: без него команда узнаёт о критичном приложении без API уже в разгар разработки, когда переделка стоит в разы дороже, чем на этапе планирования.
Недооценка чекаута: логика чекаута кажется второстепенной задачей, но именно она чаще всего срывает сроки запуска, потому что завязана на модель расширений, отличную от старой кастомизации.
Запуск без карты редиректов: часть органического трафика проседает на недели, если 301-редиректы настраиваются постфактум, а не готовятся параллельно с разработкой витрины.
Выбор фреймворка по хайпу, а не по доле Shopify в архитектуре: команда выбирает Next.js «потому что гибче», хотя 90% логики - чисто Shopify, и получает больше кастомного кода для поддержки без реальной выгоды.
Для каких магазинов актуален headless-переезд
Headless-миграция оправдана для магазинов с каталогом от нескольких тысяч SKU, устойчивым ростом трафика и командой, готовой содержать разработку на постоянной основе - не разовый проект, а часть операционных расходов. Для небольших каталогов и ограниченного бюджета маркетинга та же сумма, вложенная в CRO и привлечение трафика на стандартной теме, обычно даёт более быструю отдачу.
Часто задаваемые вопросы
Сколько стоит миграция с Shopify на headless?
Полностью кастомная сборка обычно стоит от 80 000 до 150 000+ долларов, в зависимости от сложности каталога, числа приложений и требований к чекауту. Более простые проекты на готовых компонентах Hydrogen укладываются в диапазон 15 000-50 000 долларов. Точная цифра зависит от результатов аудита, а не от типового прайс-листа.
Сколько времени занимает переход на headless-архитектуру?
Типовой срок - 8-16 недель от старта аудита до запуска. Магазины со сложным каталогом, кастомным чекаутом и большим числом сторонних интеграций чаще выходят к верхней границе диапазона или за неё.
Нужен ли Shopify Plus для headless-магазина?
Для большинства продакшн-сборок с полной кастомизацией чекаута - да: Checkout Extensibility в нужном объёме доступен на тарифе Plus. Часть headless-проектов на базовых тарифах реализуема, но с ограничениями на кастомизацию чекаута.
Что выбрать - Hydrogen или Next.js?
Если Shopify - 80% и больше коммерческой логики бизнеса, обычно выбирают Hydrogen: предсказуемая стоимость владения и готовые компоненты. Если Shopify - лишь часть более широкой архитектуры с отдельной CMS или PIM, чаще оправдан Next.js за счёт независимости от инфраструктуры Shopify.
Можно ли перевести на headless только часть магазина?
Да, частичный переход технически возможен - например, только страницы категорий или конкретная кампания - но он усложняет поддержку из-за двух параллельных систем рендеринга. В большинстве проектов это оправдано только как временный шаг перед полным переездом, а не постоянная архитектура.
Итог
- Переходите на headless, только если совпадает несколько порогов сразу: объём каталога, число приложений, кастомный чекаут или несколько витрин под один каталог - а не потому, что headless звучит современнее.
- Закладывайте аудит как обязательный этап, а не опцию: пропуск - основная причина превышения бюджета в headless-проектах.
- Выбирайте фреймворк по доле Shopify в архитектуре бизнеса, а не по личным предпочтениям команды разработки.
- Ожидайте 8-16 недель и 80 000-150 000+ долларов для полной кастомной сборки, с поправкой на сложность каталога и число интеграций.
Если вы оцениваете переезд каталога с Shopify на headless-архитектуру - опишите команде Exceltic.dev объём каталога, число приложений и требования к чекауту. Разберём архитектуру и дадим честную оценку сроков и бюджета.