A Storefront Decoupled From Shopify’s Theme Limits

When your design needs to break out of the Liquid and theme model, when you need cross-channel commerce across web, app and kiosk, or when you have hit a performance ceiling on a heavy theme that optimization cannot fix. Those are the cases where an extra codebase pays for itself. Being direct about the opposite case: most stores that feel slow are slow because of apps, images and third-party scripts, and headless removes none of those. We audit first and will recommend a theme rebuild plus a speed pass when that is the cheaper route to the same outcome.

Most apps work through the Storefront API and App Bridge, but some ship Liquid-only front-end components that simply will not render on a custom storefront. We audit your installed stack before committing to an architecture and recommend swaps where needed, since discovering that a critical review, loyalty or subscription app is Liquid-only halfway through a build is an expensive surprise. Admin-side apps that never touch the storefront are unaffected. Where an app has no headless-capable equivalent, the options are building that piece ourselves or keeping the affected surface on Liquid, and we cost both for you.

Hydrogen on Oxygen for tighter Shopify integration and Oxygen-edge performance; Next.js when your team already runs a Next platform and wants commerce as one module. The deciding factor is usually who maintains it after launch rather than benchmark numbers, because the framework your developers already know will get updated and the other one will not. Hydrogen keeps hosting, caching and Shopify data access on one supported path. Next gives you more freedom and more responsibility. We will recommend against both if the requirement can be met by a well-built Liquid theme.

Edge server rendering, dynamic sitemaps, structured data on every product and collection page, incremental regeneration for stable URLs, and one-to-one redirects from the legacy theme. The real risk on headless is not that Google cannot render JavaScript, it is that a custom frontend silently drops the metadata a theme handled for free: canonicals, hreflang, pagination and product schema. We treat those as build requirements with tests, not as a launch checklist. Core Web Vitals are held to Google's field thresholds, largest contentful paint under 2.5 seconds, interaction to next paint under 200 milliseconds and layout shift under 0.1.

The storefront customers see is built separately from Shopify's backend for checkout, inventory and orders, connected through the GraphQL Storefront API instead of Liquid templates. Shopify still runs commerce; the frontend is fully custom. What changes commercially is ownership: you gain complete control of the interface and take on a codebase, a hosting pipeline and dependency maintenance that a theme never required. Checkout normally stays on Shopify, which is what keeps PCI scope and conversion risk contained. That combination, a custom frontend with Shopify checkout, is the configuration we recommend in almost every headless project.

A standard migration from a theme to a Hydrogen or Remix storefront typically takes 6 to 10 weeks. Multi-channel builds across web, app and kiosk usually run 10 to 16 weeks depending on scope. The schedule is driven mostly by how much bespoke functionality the current theme has accumulated, since every custom section and Liquid-only app has to be rebuilt rather than carried across. We front-load an architecture review so that inventory is known before development starts, and we stage the launch with the old theme still available, so cutover is a decision rather than a leap.

Not if the migration is done correctly. We map every URL to its new equivalent, preserve structured data, and validate rankings against the old theme before and after cutover. Where rankings do drop on headless launches, the cause is almost always mundane: missing canonicals, changed URL patterns without redirects, crawling blocked on a preview domain, or pages that only render after JavaScript executes. Those are checked as part of the build rather than after go-live. Expect some short-term volatility while search engines re-crawl at scale, and judge the outcome over weeks, not the first few days.

For content-heavy pages such as editorial or landing pages, yes. A headless CMS layered alongside Shopify's commerce data usually works better than forcing blog-style content into commerce data structures. Shopify metaobjects have improved a great deal and can cover moderate content needs without another vendor, so we check that first rather than defaulting to a CMS you then pay for indefinitely. The question we ask is who publishes content and how often: a marketing team publishing weekly needs proper editorial tooling and previews, while a handful of static pages does not justify a second system.

Yes. The same Storefront API that powers your web frontend can back a native app, so you maintain one product catalog and one set of business rules across both. That is the genuine strategic argument for headless, and it is stronger than the performance argument usually given. What it does not do is make the app free: you still need native development, app store releases and a separate release cadence to maintain. We usually recommend proving the web storefront first, then reusing its data layer and business logic for the app, rather than building both at once.

They do not carry over automatically. Custom Liquid sections, apps and checkout customizations are rebuilt in the new frontend during the migration, which is part of what the architecture review scopes out upfront. That review is also where features get retired, because most themes accumulate sections nobody uses and rebuilding them is pure cost. Checkout customizations are the exception in a good way: Checkout UI Extensions and Functions run on Shopify checkout and keep working regardless of how the storefront is built. You get the inventory and a per-item estimate before anyone commits to a launch date.

Yes. Headless pairs well with Plus for merchants who need both enterprise-scale Shopify features and a fully custom frontend, particularly for multi-region or multi-brand storefronts. Plus contributes higher API limits, organization-level structure, native B2B and checkout extensibility, which are precisely the constraints a custom storefront at scale tends to hit first. You do not need Plus to go headless, and we will not tell you that you do. Where both are on the table we sequence them: get the platform structure right first, then rebuild the frontend, rather than changing two foundations at once.

More than a theme, since you are maintaining a separate codebase and deployment pipeline. Most clients move to an ongoing support plan after launch for framework updates, dependency maintenance and continued feature work. Budget for it deliberately: frameworks ship breaking versions, Shopify retires API versions on a schedule, and a headless storefront left untouched for a year becomes expensive to restart. That ongoing cost is the main reason we talk some clients out of headless when a theme would do the job. When the strategic case is real it is money well spent, and you should know the number upfront.