A garments brand replaced its stock Shopify theme with a custom Next.js storefront. Shopify continued to handle catalog, inventory, orders, and PCI-compliant checkout via Storefront APIs. SEO metadata and CMS lived directly in Next.js — no external CMS. All marketing pixels (ads, attribution, analytics) were preserved during the cutover. Result: 90+ Core Web Vitals scores and a stack the brand will not have to migrate off.
The client
A garments brand running ecommerce as a primary channel. Catalog spans men’s and adjacent apparel categories, with strong content alongside the storefront — lookbooks, editorial, and brand storytelling. The brand had been running on a stock Shopify theme; this engagement was the migration to headless. (Client name held back at their request.)
The brief: faster storefront, better SEO, no commerce risk
Three constraints shaped the engagement:
- Faster time-to-market on new content and pages. The stock theme made every new editorial or campaign page a templating exercise inside Liquid.
- Real Core Web Vitals headroom and SEO control. Stock themes ship with ceilings on speed and per-page SEO control. Going past those ceilings means going headless.
- Zero risk to commerce, checkout, or attribution. Catalog, inventory, orders, and PCI-compliant checkout had to stay where they were. So did every marketing pixel currently driving paid performance.
Headless Shopify is the configuration that lets all three of those things happen at once — keep what Shopify is great at, replace only what stock themes cannot deliver.
“The mistake brands make is treating the storefront and the commerce engine as one decision. They are not. Headless lets you upgrade the storefront without touching anything that processes a payment.”
The architecture we built
| Layer | Where it runs | Why |
|---|---|---|
| Storefront UI | Custom Next.js frontend | Full control over rendering, performance, SEO metadata |
| Product / inventory / order data | Shopify (source of truth) | Shopify is operationally proven; ops team works in Shopify admin |
| Catalog and customer reads | Shopify Storefront API | Standard, low-latency API designed for headless |
| Checkout | Shopify native checkout | PCI-DSS compliant, maintained by Shopify, no security surface for the brand to own |
| CMS / content / SEO meta | Built directly in Next.js | No external CMS — fewer moving parts, no extra subscription, unified tooling |
| Marketing pixels / analytics | Ported and validated on Next.js frontend | Attribution continuity preserved through cutover |
| Hosting (frontend) | Edge / serverless | Fast global delivery; ISR for catalog freshness |
Why we built the CMS layer inside Next.js — not on top of an external CMS
Most headless Shopify guides assume an external CMS like Sanity or Contentful sits next to the frontend. For this client, that would have added a subscription, an extra integration, a second editorial workflow, and another vendor to maintain. None of those costs were justified by the content scope.
We built the CMS layer directly in Next.js — content blocks, editorial pages, SEO metadata, lookbooks, and campaign routes — backed by structured data files and Shopify metafields where product-linked content was needed. Trade-offs we accepted, with eyes open: editorial workflow is engineer-adjacent rather than fully self-serve for non-technical content editors. For this team’s rhythm, that was acceptable. For other teams, it would not be.
How we handled the pixel migration
The riskiest part of any storefront replatform is not the storefront. It is the marketing stack that drives traffic to it. Break a pixel and paid media starts flying blind. Break a conversion event and attribution dies for weeks until the platforms re-train.
Before cutover, we did a full inventory of every pixel and tag firing on the stock theme — ad pixels (Meta, Google, TikTok), attribution platforms, analytics, conversion APIs, server- side events. Each one was ported to the headless frontend and validated against live events from the existing site. Cutover happened with attribution intact.
The Core Web Vitals outcome
What this configuration trades off — honestly
- Some Shopify apps that ship as theme components do not work on a custom frontend without adaptation. They are replaced with API-driven equivalents or rebuilt as small custom features.
- The brand owns more frontend engineering work than a stock theme would require. Worth it when speed and SEO are differentiating; not worth it for a brand that does not need either.
- Editorial workflow is engineer-adjacent (CMS lives in Next.js, content updates are code commits). Acceptable when content cadence is moderate and the team is comfortable with engineering touchpoints.
| Brand profile | Right choice |
|---|---|
| Launching fast, basic catalog, paid media only | Stock Shopify theme |
| Heavy organic / content strategy, performance is differentiating | Headless Shopify (this engagement’s shape) |
| Need control over data layer, custom AI features, fully bespoke ops | Custom platform (rare — most brands do not need this) |
What changed for the client
- 90+ Core Web Vitals. Storefront speed and SEO control of the kind stock themes cannot reach.
- Editorial flexibility. Lookbooks, content, and product pages share a rendering pipeline — not a theme blog grafted onto a storefront.
- No new CMS subscription, no external CMS to maintain. Content lives where the frontend lives.
- Attribution intact through cutover. Paid media continued to perform with no pixel-related drop.
- Shopify still does the operational heavy lifting. Catalog, inventory, orders, payments, and checkout security remain Shopify’s responsibility.
Why this matters for your storefront
If your brand cares about organic traffic, storefront speed, and editorial flexibility, the question is not Shopify versus custom. It is stock theme versus headless. Headless gives you the storefront you want without giving up the commerce engine you need — and the migration can be done without breaking attribution if the partner respects the marketing stack.
Outgrowing your stock Shopify theme?
If your storefront speed, SEO, or editorial flexibility is capped by your theme, headless is usually the right next step. We’ll give you a straight read on whether it is — and what the migration looks like for your specific stack.