Headless gives you complete control over the front end, and it takes away everything the theme was quietly doing for you. Sitemaps, metadata, structured data, rendering and redirects all become things somebody has to specify. This service makes sure that somebody exists before launch rather than after.
Headless gives you complete control and takes away every default. Sitemaps, metadata and rendering all become somebody’s job.
What headless Shopify means
A headless build separates the shop from the storefront. Shopify keeps the products, orders, inventory and checkout, and the front end is a custom application that fetches that data and renders it. Nothing about the customer-facing site comes from a Shopify theme.
That’s the appeal and the risk in the same sentence. Full design and performance control, and no default behaviour to fall back on.
Who it’s for
This suits businesses where the standard storefront genuinely isn’t enough:
- brands whose design requirements outgrow a theme
- shops with a serious performance problem a theme can’t fix
- businesses combining a shop with substantial content or tools
- anyone already headless and losing search visibility without knowing why
If a well-built theme would do the job, it usually should. Headless is a larger commitment in build and in maintenance, and it should be chosen for a reason rather than for its reputation.
What a headless build stops doing for you
| Thing | What happens by default |
|---|---|
| XML sitemap | Not generated. It has to be built to spec |
| Meta titles and descriptions | Nothing populates them. Every template needs rules |
| Structured data | None. Product, Offer, Breadcrumb and Organization all need building |
| Canonical tags | Not automatic, and easy to get wrong across variants and collections |
| Redirects | Shopify’s redirect handling doesn’t apply to the custom front end |
| Rendering | Content may only exist after JavaScript runs unless you decide otherwise |
| Pagination | Collection paging behaviour has to be specified |
| Robots and indexing rules | Yours to define, including what happens to filtered and sorted URLs |
The sitemap is the one that catches people out most. On a project where the redirects had been planned carefully and tested, the sitemap was the thing nobody had thought about, precisely because a normal build just produces one.
The problems it usually solves
A headless launch that lost visibility. Usually rendering, missing metadata or a sitemap that doesn’t exist, rather than anything about the content.
Content that isn’t in the HTML. If the product description and headings only appear after JavaScript runs, what a crawler receives is far thinner than what a visitor sees.
Variant and filter URLs multiplying. Without canonical and indexing rules, every filter combination becomes a page.
A migration to headless being planned by developers alone. The SEO requirements are specification items, and specifying them after launch means rebuilding rather than building.
What’s included
- A pre-build specification covering every item in the table above
- Rendering decisions, so the content search engines need is in the HTML
- Sitemap generation, built and validated against live indexable URLs
- Metadata rules per template, with sensible defaults and overrides
- Structured data for products, offers, breadcrumbs and the business
- Canonical and indexing rules for variants, filters and pagination
- Redirect mapping where this replaces an existing site
- Pre-launch and post-launch checks, with the post-launch one scheduled rather than optional
What you get
- A written SEO specification your developers can build from
- The sitemap and schema built and validated
- A launch checklist with the things that must be verified before going live
- A post-launch review, because headless problems tend to appear a fortnight later
Limitations
Headless is more expensive to build and to maintain, and it moves responsibility for things that used to be automatic onto your team. That’s a permanent cost rather than a launch one.
Performance also isn’t automatic. A badly built headless storefront can be slower than a good theme, and the architecture on its own guarantees nothing.
What this won’t solve
Going headless won’t improve rankings by itself. It’s a build decision that removes constraints and adds responsibility. If the current site’s problem is content or authority, a replatform changes the front end and leaves the problem exactly where it was.
Talk to the person doing the work
There is no account manager here and no team to be handed to. If you get in touch, it is me who reads it, me who looks at your site, and me who does the work if we go ahead.
Get in touch, or start with a free assessment.
Engagement and price
There are no list prices here, and that is deliberate. What a piece of work costs depends on the state of the site, how much of it there is and what you actually need, none of which I know before looking at it.
So it starts with a free analysis. I look at your site, your Search Console and who you are really competing with, then come back with what I would do first and what it would cost to do. No obligation attached, and if the honest answer is that you do not need me yet, I will say so.
How the work gets done
Specifications are checked against the technical SEO checks, sitemaps built through the sitemap toolkit and structured data through the schema toolkit. This service sits under web development. Where it replaces an existing shop, see site migrations, and the Kwiat migration case study covers a headless move.
FAQ
Does headless Shopify hurt SEO?
Not inherently, but it removes the defaults a theme provides. Sitemaps, metadata, structured data and rendering all become things somebody has to specify. Sites that lose visibility after going headless almost always lost it to one of those being missed rather than to the architecture.
Do I need a sitemap if Shopify generates one?
Your headless front end needs its own. Shopify’s sitemap describes the Shopify storefront, which isn’t the site your customers see. On a headless build the sitemap has to be generated from your own indexable URLs and specified as a deliverable before launch.
Should I go headless?
Only for a specific reason a theme can’t meet, such as design requirements it can’t support or a performance problem it can’t fix. It’s a larger commitment to build and to maintain, so it should be chosen deliberately rather than because it sounds more advanced.
What usually breaks after a headless launch?
Rendering and metadata first, then the sitemap. The pattern is consistent: things a theme did automatically that nobody specified. That’s why the SEO requirements belong in the build specification rather than in a review after the site is already live.
Planning a headless build?
Get in touch before the specification is finalised. That’s when this work is worth the most.