Headless Shopify vs Standard Shopify: When Does Headless Make Sense?

Headless Shopify means keeping Shopify as the commerce engine (products, inventory, carts, checkout, orders and customers) while replacing the theme-based storefront with a custom front end that talks to Shopify through its APIs. Standard Shopify means the store runs on a theme built in Liquid, hosted and rendered by Shopify, edited in the theme editor and extended with apps from the App Store. Both sell the same products through the same checkout. What differs is who builds and runs the part customers see.

The short answer first. Headless suits businesses whose storefront has outgrown what a theme can do: content-heavy brands that want editorial and commerce woven together, companies selling through several front ends from one catalog, stores with unusual product experiences or URL requirements, and teams that already employ front-end engineers. It does not suit most stores that simply want to look distinctive, load quickly or rank well, because a well-built theme does all three, and headless adds a permanent engineering responsibility that many businesses underestimate.

This guide is for founders, e-commerce managers and technical leads weighing that choice. It compares the two on build and maintenance responsibility, cost structure, performance, content flexibility, app compatibility, checkout, SEO and rendering, team skills and total cost of ownership, then works through illustrative scenarios, a decision checklist and what a move to headless, or back, involves.

The short answer: who headless Shopify suits and who it does not

Most decisions about headless Shopify come down to one question: is there something specific your storefront must do that a theme cannot do, and is it worth owning a software product to get it? If you cannot name that thing in a sentence, standard Shopify is almost certainly the right answer for now.

Headless is usually a good fit when

• Content and commerce are equally important, and you want long-form editorial, lookbooks or guides built from a dedicated content management system with shoppable products inside them.
• You sell from one catalog into several front ends: a main store, a mobile app, in-store screens, a B2B portal or a set of regional sites with genuinely different experiences.
• The product experience is unusual: configurators, bundles built step by step, 3D or interactive tools, or complex option logic that fights the theme model.
• You need control over URLs, rendering and page structure that the fixed theme routes do not give you.
• You already have, or are committed to hiring, front-end engineers who will own the storefront long after launch.

Standard Shopify is usually the better fit when

• The storefront is a catalog, product pages, a cart and some marketing pages, however polished.
• Merchandisers and marketers need to change pages themselves, daily, without a developer.
• The business relies on App Store apps for reviews, subscriptions, loyalty, upsells or search.
• There is no in-house engineering team, and no budget for retained engineering every month.
• The main goal is speed or SEO, both of which a well-built theme can deliver.

If you are still deciding whether Shopify is the right platform at all, start with our comparisons of Shopify vs WooCommerce and Shopify vs Shopify Plus; the headless question only makes sense once the platform is settled.

What headless actually changes in the architecture

On standard Shopify, a request for a product page goes to Shopify, which renders the theme's Liquid templates with the product data and returns HTML. The theme, the data and the hosting are one system that Shopify runs. Apps plug into that system through theme app extensions and app embeds, and the theme editor lets non-developers rearrange sections and blocks.

On headless Shopify, the request goes to your own front-end application. That application, commonly built with Shopify's React-based Hydrogen framework or a general framework such as Next.js, asks Shopify's Storefront API for product, collection and cart data, often asks a separate content management system for editorial content, renders the page, and returns it. The front end runs on hosting you choose, whether Shopify's Oxygen hosting for Hydrogen or another platform. When the shopper checks out, the cart is handed to Shopify's checkout.

Three consequences follow from that diagram, and they drive most of the comparison below.

1. You now own a web application. Its code, dependencies, hosting, monitoring, security updates and bugs are your responsibility, not Shopify's.
2. Anything that relied on the theme stops working automatically. Theme sections, the theme editor and app blocks that inject into the theme do not exist in a custom front end unless you rebuild their equivalent.
3. Checkout does not change. The checkout is still Shopify's, with the same customization rules as on a theme-based store.

Our practical guide to headless commerce covers the architecture across platforms; the rest of this article stays specific to Shopify.

Build and maintenance responsibility, and the skills your team needs

The biggest difference between the two options is not visible on launch day. It is who is responsible for the storefront every month afterward.

Standard Shopify: Shopify runs the storefront, you configure it

With a theme, Shopify hosts and serves the storefront, handles scaling for traffic spikes, and maintains the platform features the theme relies on. Your team, or an agency, maintains the theme code and its customizations. Theme updates and app updates still need care, especially on heavily customized themes, but the surface area is small and well understood. The skills needed are Liquid, HTML, CSS and some JavaScript, plus comfort with metafields and theme sections. Many agencies and freelancers have them.

For a deeper look at what a theme can do before you conclude it cannot, read our guide to Shopify theme sections and metafields. A surprising number of "we need headless" requirements turn out to be solvable with well-designed sections, metaobjects and a disciplined content model.

Headless Shopify: you run a software product

With headless, the storefront is an application your team builds and operates. That brings everything a software product needs: a code repository, a deployment pipeline, environments for testing, error monitoring, uptime alerts, dependency updates, framework upgrades, security patches, and someone on call when the storefront breaks on a sale day. Shopify still runs checkout and the commerce back end, but the front end's availability is on you and your hosting provider.

The skills change as well. You need engineers comfortable with a modern JavaScript framework, GraphQL, server-side rendering and caching, plus someone who understands Shopify's data model and API versioning. Shopify releases Storefront API versions on a regular schedule and retires old ones, so the integration needs periodic upgrades even if nothing on the site changes. If the headless build also uses a separate content management system, someone must model the content, maintain its schemas and keep editors trained.

Whether to keep that capability in-house or retain it from an agency is a real decision. Our retained engineering starts from $145 per hour: a developer on your stack for an agreed share of each month, and work can start within 2 weeks. That is a starting price, and the right number of hours depends on how often the storefront changes.

Cost structure and total cost of ownership

The two options do not just cost different amounts; they cost in different ways. Comparing only the build quote is the most common mistake in this decision. This section describes the cost types without quoting platform, hosting or app prices, which change often and vary by plan.

Cost types on standard Shopify

• Platform subscription for the Shopify plan, plus payment processing fees.
• Theme: a purchased theme, a customized theme or a custom-built theme.
• Apps: usually monthly subscriptions, sometimes usage-based.
• Build: design, theme customization, catalog setup, integrations and migration.
• Ongoing changes: occasional developer time for new sections, campaigns and fixes.

Cost types on headless Shopify

• Platform subscription and payment processing, as on standard Shopify.
• Front-end hosting, whether Shopify's Oxygen or a third-party host, with its own pricing model.
• Content management system, if you use one, usually with its own subscription.
• Replacement for theme apps: API-based versions of apps, custom rebuilds of app features, or both.
• Build: a fully custom front end, the CMS content model, integrations and migration.
• Ongoing engineering: upgrades, monitoring, API version changes, bug fixes and new features, every month.

What the market charges, and our starting rates

Typical US market ranges give a sense of scale. A themed store on a hosted platform typically costs $8,000 – $30,000, covering a customized theme, catalog setup, payments, shipping and basic integrations. A custom store build typically costs $30,000 – $150,000, covering a bespoke front end, real integrations, migration and complex catalog logic. Headless storefronts fall in the custom store build category because the whole front end is bespoke. Conversion and optimization work on an existing store typically runs $2,000 – $10,000 per month.

Our own published starting rates cover adjacent work: a landing page or microsite from $4,800 per project (one page or a handful, built accessible and fast, on a CMS you can actually edit, with a turnaround of 3–5 weeks); a marketing site from $18,000 per project (a set of templates, real content, real integrations and a migration, with a turnaround of 8–12 weeks); and retained engineering from $145 per hour. These are starting prices, not totals, and a headless storefront is scoped as its own project. Our article on how much a Shopify store costs breaks the numbers down further.

Total cost of ownership over several years

Total cost of ownership is the build plus everything you pay to keep the store running and improving, over the life of the storefront. On standard Shopify, the build dominates and ongoing costs are mostly subscriptions and occasional changes. On headless Shopify, ongoing engineering is a permanent line that often matters more than the build over a few years. The honest comparison is build plus the monthly run cost multiplied by the number of months you expect to keep the storefront, before any rebuild.

Performance, rendering and SEO controls

Speed is the most common reason given for going headless, and the weakest on its own. A headless storefront can be very fast. So can a lean theme. Both can be slow.

Where performance comes from

On a theme, the main performance risks are heavy themes, large unoptimized images, and app scripts that accumulate over time, each adding JavaScript to every page. Governing apps, trimming theme code and serving properly sized images solves most of it. On a headless build, performance depends on rendering strategy, caching, how much JavaScript the framework ships to the browser, and how quickly the Storefront API and the CMS respond. A headless storefront that renders everything in the browser, or that fetches data from three systems on every request without caching, can be slower than the theme it replaced.

What headless does give you is control: you can choose server-side rendering, static generation for content pages, streaming, edge caching, and exactly which scripts load. That control helps a team that measures Core Web Vitals and knows how to act on them. It does nothing for a team that does not.

Rendering and search engines

Liquid themes are rendered on the server, so search engines receive complete HTML. A headless storefront must be built to do the same, through server-side rendering or static generation, rather than rendering product content only in the browser. Hydrogen and Next.js both support server rendering; the risk comes from builds that skip it.

SEO controls you gain and lose

Standard Shopify handles a lot of SEO plumbing automatically: sitemaps, canonical tags, a robots.txt you can customize, URL redirects managed in the admin, and basic structured data in most themes. Its limits are well known, chiefly the fixed URL patterns for products, collections and pages.

Headless gives you full control over URLs, metadata, structured data and internal linking, but every one of those features must be built. The redirects stored in Shopify's admin do not apply to a custom front end on their own; your application has to read and apply them. Sitemaps, canonical tags, hreflang for international sites, pagination and faceted-navigation handling all become your code. A headless launch without an SEO requirements list is one of the most reliable ways to lose search traffic in a replatform.

Content flexibility and who can edit the store

Content is where headless earns its keep, and also where it most often disappoints marketers.

On standard Shopify, the theme editor lets non-developers compose pages from sections and blocks, preview them and publish. Metafields and metaobjects let you model structured content such as ingredient lists, size guides or designer profiles and surface it in templates. For most stores, that is enough, and it keeps marketing independent of developers.

On headless Shopify, the theme editor is gone. Editorial content usually moves into a separate content management system, where editors build pages from components the developers have defined. Done well, this is more flexible than a theme: editors get structured content that can be reused across web, app and email, previews that show the real front end, and page types designed for long-form storytelling. Done badly, editors lose the visual page building they had, every new layout needs a developer, and product data and content drift apart across two systems.

The deciding factor is whether you will invest in the content model. A headless build needs someone to define the components, the fields, the validation rules and the preview setup, and to keep evolving them as marketing asks for new things. If that work is not scoped, a theme with good sections is more flexible in practice. For the broader question of whether your content or your store should lead, see WordPress vs Shopify: content site or store first.

Apps and checkout: where headless loses ground

App compatibility

Much of the Shopify App Store is built for theme-based stores. Many apps render their features on the storefront by injecting blocks or scripts into the theme: review widgets, upsell carousels, loyalty panels, subscription selectors, size charts, search and filtering, pop-ups. On a headless front end none of those appear automatically.

For each app you rely on, there are three possibilities. The app offers an API or front-end SDK you can call from your own code, which works but needs development. The app's back-end features still work (for example, it processes subscriptions or syncs to your ERP) but the storefront widget must be rebuilt by your team. Or the app only works inside a theme, and you need a different app or custom functionality. An app audit is therefore one of the first tasks in any headless discovery, and it frequently changes the cost estimate.

Checkout: the same rules either way

A headless storefront does not give you a custom checkout. The cart built in your front end is handed to Shopify's checkout, which follows the same customization rules as on a theme-based store. Checkout customization happens through Shopify's checkout extensibility, and the deeper options are reserved for Shopify Plus. If your reason for going headless is to control checkout, headless will not deliver it; the question is what your plan allows. Our guide to Shopify checkout extensibility explains what can and cannot be changed, and how to use it well.

There is one practical upside. Because checkout stays with Shopify, headless stores keep Shopify's payment methods, fraud checks, tax calculation and order flow without rebuilding them. The integration seam is the cart handoff, and it needs careful testing: discount codes, gift cards, customer accounts, markets and currencies must all carry through correctly from your front end to checkout.

Headless vs standard Shopify: the scorecard

The table below summarizes the comparison. It is a qualitative guide, not a scoring model; weight each row by how much it matters to your business.

Illustrative scenarios

The scenarios below are illustrative, built to show how the factors combine. They are not client projects, and the figures are examples for the arithmetic, not quotes.

Scenario one: a growing apparel brand

A brand sells a few hundred products, runs frequent campaigns and relies on apps for reviews, loyalty and a size finder. Its marketing team changes the home page weekly. Its complaint is that the store feels slow and looks like other stores in its category. There is no in-house developer. This brand should stay on standard Shopify: a custom-designed theme, a review of apps and scripts, and image optimization will address speed and distinctiveness, and the marketing team keeps the theme editor. In market terms this sits in the themed store range of $8,000 – $30,000 rather than a custom build.

Scenario two: a content-led food and kitchen brand

A brand publishes recipes, technique guides and video, and wants every ingredient and tool in that content to be shoppable. It sells through a website and a mobile app, and it has two front-end engineers on staff. Here headless is a strong candidate: a CMS can model recipes and guides as structured content, the same catalog and content feed both web and app, and the engineers can own the storefront. The brand must still plan an app audit and an SEO requirements list, and budget for the engineering team's time every month.

Scenario three: the ongoing cost, worked through

Suppose a mid-sized store without in-house engineers is considering headless and plans to retain engineering for upkeep. At a starting rate of $145 per hour, an illustrative 16 hours a month of maintenance (upgrades, monitoring, API version changes and small fixes) comes to at least $2,320 a month, because 16 × $145 = $2,320. If the store also wants new features each month and the allocation rises to an illustrative 40 hours, the floor becomes $5,800 a month, because 40 × $145 = $5,800. Those figures are before hosting, CMS and app costs, and they recur for as long as the storefront exists. On standard Shopify, the same store might need developer time only around campaigns. The difference, multiplied over several years, is the real price of headless, and it only makes sense if the extra control produces more than it costs.

Scenario four: a multi-region B2B and retail seller

A manufacturer sells to trade customers and consumers in several countries, with different catalogs, price logic and content per region, and integrations with an ERP and a warehouse system. Its needs may be met by Shopify's native markets and B2B features on a theme, or they may justify a headless front end with region-specific experiences. The decision here turns less on headless and more on platform fit, which is why comparisons such as Adobe Commerce vs Shopify Plus belong in the same evaluation.

A decision checklist for headless Shopify

Work through the list below with the people who will own the storefront afterward, not only the people approving the build. If most answers point toward the theme, the case for headless is weak.

What a move to headless, or back, involves

Moving to headless is a replatform of the front end, even though the commerce back end stays in place. It follows the same phases as any store build, with specific emphasis at each step. The phase durations below are typical ranges for store projects; they overlap in practice, and a headless build tends to sit toward the longer end of build and integrations because the whole front end is custom.

• Discovery and platform choice, 2–4 weeks: confirm the reason for headless, audit apps, choose the framework, hosting and CMS, and write the SEO requirements.
• Design, 3–6 weeks: design the components and page types, not just pages, so the CMS content model follows from them.
• Build and integrations, 6–16 weeks: the front end, the Storefront API integration, the CMS, rebuilt app features, and the cart handoff to checkout.
• Migration and data, 2–6 weeks, usually underestimated: content into the CMS, redirects, and any product or customer data changes.
• Testing and launch, 2–4 weeks: performance, SEO, accessibility, checkout handoff with every discount and currency case, and load testing for peak traffic.

For more on scheduling, see how long it takes to build an e-commerce store.

Reducing risk on the way in

You do not have to switch everything at once. Some teams start with a headless content section, such as a journal or lookbook, linked to a theme-based store, or they build one high-value experience, such as a product configurator, before committing the whole storefront. Keeping the theme store live and ready until the headless front end has proven itself through a full sales cycle is a sensible safeguard.

Moving back to a theme

Some businesses go headless and later decide the ongoing cost is not paying off. Moving back is possible, because products, customers, orders and checkout never left Shopify. The work is on the front end: build or customize a theme, move editorial content from the CMS into Shopify pages, metaobjects or a blog, reinstall theme-based apps, and map every headless URL to its theme equivalent with 301 redirects. The URL work is the part that most affects search traffic, so treat it with the same care as the original launch. If the headless build used custom URL patterns that Shopify's routes cannot reproduce, plan redirects for every one.