Headless Shopify (Hydrogen) + Google Ads API

Headless Shopify позволяет отделить пользовательскую витрину от стандартной темы Shopify.

Каталог, корзина и commerce-данные остаются в Shopify, а интерфейс магазина разрабатывается отдельно на Hydrogen и получает данные через Storefront API.

Это даёт разработчикам значительно больше контроля над:

• UX;
• производительностью;
• SEO-шаблонами;
• каталогом;
• контентом;
• интеграциями;
• экспериментами.

Когда headless Shopify действительно имеет смысл

Hydrogen стоит рассматривать, когда типовая storefront-тема начинает ограничивать проект.

Например:

Когда headless может быть лишним

Для небольшого магазина с простым каталогом и стандартным checkout переход на Hydrogen способен только увеличить стоимость разработки.

Headless не обязательно нужен, если:

• каталог небольшой;
• типовая тема Shopify закрывает UX;
• нет команды разработки;
• не требуется сложная интеграционная логика;
• нет реальной проблемы производительности.

Базовая архитектура Hydrogen-магазина

Рядом работают:

И отдельный слой аналитики:

Hydrogen

Hydrogen — официальный React-based framework Shopify для headless storefront.

Витрина может получать через Storefront API:

• товары;
• коллекции;
• варианты;
• цены;
• корзину;
• контент;
• часть данных магазина.

Storefront API

Storefront API работает через GraphQL.

Для headless это основной интерфейс между собственной витриной и Shopify.

Важно разделять:

• данные, доступные публичной витрине;
• приватные административные интеграции;
• платёжный и checkout-сценарий.

Hydrogen не отменяет Shopify checkout

Headless storefront не означает, что можно автоматически обойти платёжную архитектуру Shopify.

До начала разработки необходимо определить:

• как создаётся корзина;
• куда пользователь переходит для оплаты;
• какой платёжный провайдер используется;
• какие способы оплаты реально доступны бизнесу.

Oxygen или Vercel

Штатная связка Shopify:

Oxygen предназначен для размещения Hydrogen storefront и edge/serverless выполнения приложения.

При необходимости Hydrogen можно self-host'ить и на других JavaScript runtime, включая Vercel.

Выбор hosting зависит от:

• инфраструктуры команды;
• CI/CD;
• edge-функций;
• наблюдаемости;
• стоимости;
• дополнительных сервисов.

Контент: отдельная CMS не обязательна

Headless CMS полезна крупным контентным проектам, но Hydrogen не требует обязательного подключения Contentful, Sanity или другой внешней CMS.

Часть контента можно хранить непосредственно в Shopify:

• pages;
• articles;
• metaobjects;
• metafields.

Отдельный content backend появляется тогда, когда этого действительно требует редакционный процесс.

Критический вопрос для Казахстана: оплата

Это нужно решить до разработки checkout-пути.

Для бизнеса, зарегистрированного в Казахстане, нельзя строить проект с предположением, что Shopify Payments будет доступен по умолчанию.

Нужно заранее проверить:

• подходящего внешнего payment provider;
• поддержку KZT;
• карточный эквайринг;
• Kaspi-сценарий;
• возвраты;
• комиссии;
• совместимость с Shopify checkout.

Kaspi Pay и Kaspi QR

Нельзя просто записать «Kaspi Pay встроен в Shopify» как стандартную функцию.

В конкретном проекте нужно определить:

• какой именно Kaspi-сценарий требуется;
• существует ли совместимый модуль или provider;
• нужна ли кастомная интеграция;
• как будет выглядеть checkout;
• как статус оплаты попадёт в заказ.

KZT и Казахстан

Для казахстанского магазина логично проектировать каталог и Merchant Center с корректной валютой KZT.

Но storefront, checkout и Merchant Center должны показывать согласованную информацию:

• цену;
• наличие;
• условия доставки;
• валюту.

ru/kk-архитектура

Для русской и казахской версии лучше использовать отдельные стабильные URL.

Например:

И связать эквивалентные страницы через hreflang.

Для Казахстана могут использоваться региональные комбинации:

• ru-KZ;
• kk-KZ.

Не нужно добавлять валюту в URL без необходимости

Если магазин работает только в Казахстане и использует KZT, структура вроде:

/ru-kzt/

обычно не даёт дополнительной SEO-ценности и усложняет архитектуру.

URL лучше проектировать вокруг языка, рынка и контента, а не технических переключателей интерфейса.

Hydrogen и Core Web Vitals

Headless даёт команде хороший технический контроль, но сам факт использования Hydrogen не гарантирует «зелёные» метрики.

Производительность можно ухудшить:

• тяжёлым JavaScript;
• неоптимизированными изображениями;
• сторонними виджетами;
• неправильным caching;
• клиентским waterfall запросов.

Какие показатели ориентировочно считаются хорошими

Для Core Web Vitals используются:

Оцениваются реальные пользовательские данные, в том числе на 75-м перцентиле.

SEO в headless начинается с server rendering

Ключевые SEO-элементы должны быть доступны поисковому роботу без необходимости ждать сложную client-side цепочку.

На шаблонах нужно контролировать:

• title;
• description;
• H1;
• canonical;
• hreflang;
• robots;
• sitemap;
• structured data;
• статусные коды.

Категории и коллекции

До разработки желательно спроектировать SEO-архитектуру каталога.

А также определить:

• какие фильтры индексируются;
• какие параметры закрываются;
• как обрабатываются варианты;
• что происходит с отсутствующими товарами.

Structured Data

Для товарной страницы прежде всего важны корректные Product / Offer данные.

Также могут использоваться:

• BreadcrumbList;
• Organization;
• shipping / return-related данные там, где они применимы.

AggregateRating — только при реальных рейтингах

Не нужно автоматически генерировать рейтинг 5.0 для каждого товара.

Если на странице нет реального рейтинга и соответствующих данных, markup добавлять нельзя просто ради звёзд в выдаче.

LocalBusiness нужен не каждому Shopify-магазину

Если бизнес полностью онлайн, Organization может быть логичнее.

LocalBusiness имеет смысл при реальном физическом объекте:

• магазине;
• шоуруме;
• пункте;
• другой локальной точке.

Merchant Center: два основных подхода

Для headless-магазина можно рассматривать разные источники товарных данных.

Website crawl

Если product pages содержат корректные structured data, Merchant Center может использовать website crawl для создания product data source.

Это особенно удобно как более простой сценарий.

Merchant API

Для управляемой технической интеграции можно передавать каталог программно.

Это даёт больше контроля над:

• product data;
• обновлениями;
• статусами;
• инвентарём;
• диагностикой.

Почему больше не Content API

В новых проектах нужно использовать Merchant API.

Старая Content API for Shopping уже не должна становиться фундаментом новой интеграции.

Website crawl не заменяет контроль каталога

Structured data помогает Google получать актуальную информацию о товаре.

Но автоматические обновления не должны становиться единственным механизмом управления большим каталогом.

Особенно когда:

• цены меняются часто;
• остатки динамические;
• много SKU;
• несколько рынков;
• есть акции.

Как синхронизировать Shopify и Merchant Center

Для крупного каталога можно построить событийную схему.

Например, изменились:

• цена;
• availability;
• название;
• изображение;
• вариант.

Интеграционный слой обновляет соответствующие product inputs в Merchant Center.

Почему нужен queue, а не прямой запрос из webhook

При реальной эксплуатации нужно учитывать:

• повторные webhook;
• ошибки сети;
• rate limits;
• retry;
• очередность событий;
• логирование.

Поэтому интеграция должна быть устойчивой к сбоям.

Что передавать в Merchant Center

Набор зависит от товара, но обычно важны:

• id;
• title;
• description;
• link;
• image;
• price;
• availability;
• brand;
• GTIN — когда он существует;
• shipping-related данные, если требуются.

Product schema и Merchant feed должны совпадать

Особенно критичны:

• цена;
• валюта;
• наличие.

Если на странице одна цена, а Merchant Center получает другую, появляются проблемы с товарными данными.

Performance Max для e-commerce

После подключения Merchant Center каталог можно использовать в Performance Max.

Для retail PMax товарный фид становится одним из ключевых источников информации о продукте.

Не ограничивайтесь только товарным фидом

Для PMax полезно подготовить разнообразные creative assets:

• заголовки;
• описания;
• изображения;
• логотипы;
• видео;

Нет универсального правила «ровно 5–7 ассетов».

Задача — дать системе достаточное количество качественных вариантов, соответствующих бренду и товарной группе.

Asset Groups

Asset Groups лучше проектировать вокруг понятной коммерческой логики.

Например:

• категории;
• маржинальной группы;
• бренда;
• сезонного ассортимента.

Но не нужно создавать сотни asset groups без необходимости.

Audience Signals

В качестве сигналов можно использовать релевантные first-party и другие допустимые аудитории.

Например:

• покупатели;
• посетители магазина;
• собственные Customer Match списки;
• custom segments.

Audience Signal — не жёсткий targeting

Это важное отличие.

Если добавить аудиторию «просматривали товар», Performance Max не будет показываться исключительно этим людям.

Сигнал помогает алгоритму обучаться и находить подходящих пользователей.

GA4 audiences

При необходимости можно создавать собственные аудитории на основе поведения:

• просматривали определённую категорию;
• добавили товар в корзину;
• не совершили покупку;
• являются существующими клиентами.

Но аудитория должна иметь бизнес-смысл и достаточный объём.

Стратегии ставок Performance Max

Для PMax поддерживается два основных направления:

Портфельный tROAS для PMax — не тот сценарий

Performance Max не поддерживает portfolio bidding strategies.

Поэтому схема:

«объединить PMax в портфель и каждый час менять tROAS через API»

технически и стратегически неверна.

Не меняйте tROAS каждый час

Google Ads API позволяет менять настройки кампании, но это не означает, что каждое изменение полезно.

Частое автоматическое вмешательство может создавать нестабильность и усложнять анализ.

Что действительно автоматизировать через Google Ads API

Полезные сценарии:

• регулярное получение статистики;
• контроль расходов;
• анализ кампаний;
• проверка конверсий;
• алерты по аномалиям;
• контроль статусов;
• управляемые изменения после проверки условий.

Пример безопасного алерта

Вместо:

Что делать, если товар закончился

Главный источник правды должен корректно изменить наличие товара.

После обновления availability товарные рекламные системы получают актуальное состояние каталога.

Не нужно строить отдельную систему, которая пытается вручную «поставить на паузу SKU» только на уровне Google Ads, оставляя неправильный фид.

Google Ads API и отчётность

API удобно использовать для собственной data-layer.

Например:

В отчёте можно сравнивать:

• категории;
• товары;
• кампании;
• выручку;
• ROAS;
• новых покупателей;
• географию.

Looker Studio, BigQuery или Metabase

Конкретный стек зависит от объёма данных.

Для небольшого проекта может хватить простого dashboard.

Для крупного e-commerce имеет смысл централизовать данные в warehouse и уже оттуда строить BI.

GA4 ecommerce

Минимально полезные события e-commerce включают:

• просмотр товара;
• добавление в корзину;
• начало checkout;
• purchase.

Особенно внимательно нужно передавать:

• transaction ID;
• value;
• currency;
• item data.

Дубли purchase

Для headless-приложения это критичная проверка.

Если purchase отправляется повторно после refresh или возврата на confirmation page, рекламная система получает завышенную выручку.

В итоге Smart Bidding оптимизируется на неправильных данных.

Enhanced Conversions

Enhanced Conversions могут дополнять обычное conversion tracking first-party данными, которые передаются Google в хешированном виде.

Настройка требует:

• корректного источника данных;
• правильного tagging;
• соблюдения требований к данным;
• учёта пользовательского consent там, где это необходимо.

Server-side GTM обязателен?

Нет.

Он может быть полезным элементом сложной measurement architecture, но не является обязательным условием запуска Hydrogen-магазина.

Сначала нужно корректно настроить базовые события и только затем усложнять инфраструктуру.

SEO + Merchant Center + Ads должны использовать одну товарную модель

Хорошая архитектура избегает ситуации, когда:

• Shopify хранит одну цену;
• сайт показывает другую;
• Merchant Center получает третью;
• аналитика считает четвёртую.

Что учитывать для Казахстана

KZT

Цена на сайте и в product data должна быть согласована.

Доставка

Укажите реальные условия доставки по Казахстану.

ru/kk

Делайте отдельные локализованные страницы там, где бизнес действительно поддерживает оба языка.

Kaspi

Показывайте доступные способы оплаты только после проверки реальной интеграции.

Алматы и Астана

Отдельные городские страницы нужны только при реальной разнице в:

• наличии;
• доставке;
• самовывозе;
• филиалах;
• условиях.

Не создавайте SEO-страницы городов без содержания

Страница:

«купить ноутбук Шымкент»

не становится полезной только потому, что в шаблоне поменяли название города.

Региональная посадочная должна отражать реальное предложение для этого региона.

Google Business Profile

Для чистого интернет-магазина без физической точки это не центральный элемент архитектуры.

Для реального магазина, шоурума или точки самовывоза локальное присутствие может развиваться отдельно.

План запуска headless-магазина

Что измерять после запуска

Технические показатели:

• LCP;
• INP;
• CLS;
• ошибки storefront;
• checkout errors.

Merchant Center:

• approved products;
• disapproved products;
• price mismatch;
• availability mismatch;
• актуальность каталога.

Маркетинг:

• CPA;
• ROAS;
• conversion value;
• new customers;
• результат по категориям.

Не ставьте универсальные KPI

В старой версии материала использовались цели:

• CPA снизится на 10–15%;
• органика вырастет на 20%;
• Shopping запустится за 48 часов.

Такие цифры нельзя обещать заранее.

Целевой ROAS и CPA определяются экономикой конкретного магазина, а SEO-рост зависит от:

• исходной видимости;
• спроса;
• каталога;
• конкуренции;
• индексации;
• качества контента.

Headless не гарантирует SEO-рост

Hydrogen может создать очень хорошую техническую базу.

Но если:

• нет спроса;
• категории построены неправильно;
• контент дублируется;
• фильтры создают тысячи URL;
• нет внутренних ссылок,

сам React-фреймворк не приведёт органический трафик.

Headless не гарантирует высокий ROAS

То же самое с Google Ads.

На результат влияют:

• продукт;
• цена;
• фид;
• конкуренция;
• маржа;
• креативы;
• конверсия магазина;
• качество measurement.

Главные ошибки такой архитектуры

Делать headless ради headless

Команда получает дорогую разработку без бизнес-преимущества.

Начать разработку до проверки оплаты

На финальном этапе выясняется, что нужный KZ checkout-сценарий не работает так, как ожидалось.

Использовать устаревшую Content API

Новые интеграции нужно строить на Merchant API.

Считать headless гарантией Core Web Vitals

Плохо написанный Hydrogen-магазин тоже может быть медленным.

Синхронизировать цену с задержкой

Merchant Center и storefront начинают показывать разные данные.

Подделывать AggregateRating

Structured Data должна отражать фактическое содержимое страницы.

Каждый час менять Smart Bidding

API превращается из инструмента контроля в источник нестабильности.

Считать Audience Signals строгим таргетингом

Performance Max может искать пользователей шире переданных сигналов.

Как выглядит зрелая архитектура

Для какого бизнеса это имеет смысл

В первую очередь для e-commerce, где:

• магазин является серьёзным каналом продаж;
• каталог постоянно обновляется;
• важен собственный UX;
• есть SEO-стратегия;
• есть Merchant Center;
• Google Ads занимает заметную часть продаж;
• есть техническая команда или поддержка.

Итог

Связка Shopify + Hydrogen + Merchant Center + Performance Max + Google Ads API действительно может стать сильной архитектурой для e-commerce.

Но современная версия этой схемы выглядит иначе, чем несколько лет назад.

Для нового проекта важно:

• использовать Hydrogen там, где headless реально оправдан;
• заранее решить вопрос оплаты в Казахстане;
• использовать Merchant API вместо legacy Content API;
• держать Shopify источником актуальных товарных данных;
• не путать Audience Signals с жёстким targeting;
• не использовать Google Ads API для постоянного ручного вмешательства в Smart Bidding;
• измерять результат до фактической покупки и выручки.