Is Headless Better for SEO? We Tested It on Real Stores

Every few months a client asks us the same question. Should we go headless? They have read that it is faster, that Google likes it better, and now that the AI shopping tools care about it too.

We stopped answering from theory and ran a test. We took three real Shopify stores and put a headless store next to a normal Liquid store in the same industry. Then we measured the things the architecture is supposed to change: speed, what a crawler can read, the technical basics, and whether an AI agent can reach the products.

TL;DR

• The Liquid store loaded faster in every pair we tested, though every store on both sides still failed Core Web Vitals overall. That is the opposite of the reason people usually go headless.

• Both architectures kept their product facts in the raw HTML. The fear that headless hides content from crawlers did not hold here.

• The technical basics were inconsistent on both platforms. Two of three headless stores were missing a sitemap, canonical, or robots rule, and the single worst result was a Liquid store missing all three.

• AI crawler access was a settings choice, not an architecture one. Two stores blocked AI crawlers in robots.txt, unrelated to headless or Liquid.

• Every real difference but one traced back to the build, not the platform. The exception: headless stores stayed usable with JavaScript off in all three pairs, against one of three Liquid stores

What we found, in one table

Here is the whole test in four lines. The sections below show the numbers behind each one.

In three of the four checks, the build decided the result, not whether the store was headless or Liquid. The fourth, whether the page still worked with JavaScript off, split cleanly along architecture lines instead

What this test can and cannot tell you

This is a head-to-head on three pairs, not a study of a thousand stores. Three pairs cannot prove that one architecture ranks better. Rankings depend on backlinks, domain age, catalog size, and content, and three pairs cannot hold all of those steady.

What three careful pairs can do is show you what headless controls, and how real stores handle it. Treat it as a close look at six real stores, not a rule for every store. Where all three pairs point the same way, take it seriously. Where they split, we say so.

This also fills a gap in our own data.
Our 1,000-store speed benchmark left headless stores out on purpose, because they behave differently and would have muddied the Liquid numbers. This test is the headless side of that question, run on a smaller scale.

A before/after study of one store migrating would control for cross-store differences like backlinks and domain age that this test can't. It would introduce its own confound, time, since algorithm changes and content updates tend to happen alongside a migration.

What headless actually changes

Going headless changes how your storefront is built.
Your Shopify backend still runs the catalog, the cart, and the checkout. The front end becomes a separate custom app that pulls data through the Storefront API.

It changes what ends up in your page's raw HTML before any JavaScript runs. The raw HTML is what a crawler reads first. It affects how fast the page loads, and it decides whether an AI agent can see your product. A Liquid theme does all of that for you. On headless, each piece is a decision your build team has to get right.

So the real question is simple

Does the build put the product facts where machines can read them, or hide them behind JavaScript? A headless build can do either. That is why we tested real stores.

How we ran the test

Three pairs, six stores, across three branches in outdoor gear and sports industry. We chose outdoor and sports brands because the category spans athleisure, footwear and cycling with comparable store sizes and traffic, letting us hold industry roughly constant across all three pairs.

1 . First we confirmed each store's architecture by hand.
A custom domain hides the easy signals. Headless stores were verified as Hydrogen builds. Liquid stores were verified as standard theme builds.

That verification mattered
We started with more candidates and dropped the ones that turned out not to be headless once we checked them properly. Inside each pair the two stores sit at a similar size, so the main structural difference is the architecture, not one brand being ten times bigger than the other.

2. Then we ran the same four checks on all six stores
How the product page renders in raw HTML, Core Web Vitals on mobile, the technical basics, and whether AI crawlers are allowed in. We used the same kind of product page on both sides of a pair.

One honest limit. A win in any single check often says more about the team that built the store than about headless or Liquid. Keep that in mind as you read.

Result 1: What a crawler actually reads

The common fear is that headless hides your content behind JavaScript, leaving crawlers with a blank page. We checked it directly. For each store we opened the raw server HTML and looked for the product name, price, description, and schema before any JavaScript ran.

Every headless store put the product name, price, and description right in the raw HTML, same as the Liquid stores. On the exact thing headless is supposed to break, both did the job.

Two things stood out, and only one of them is about headless versus Liquid

1. The Liquid stores were the ones that broke with JavaScript off. 

We reloaded each product page with JavaScript disabled. All three headless stores still showed the product. Two of the three Liquid stores did not. State Bicycle dropped to a near-black, broken page. The facts were in its HTML, but the page fell apart without scripts.

This is the one result in the whole test that split cleanly along architecture lines: three for three on one side, one for three on the other. We would not lean on it too hard given the sample size, but it is the closest thing to an architecture-level pattern we found

What a shopper sees on State Bicycle's product page.

The same page with JavaScript switched off. The content is in the HTML, but the page does not hold together without scripts.

2. Product schema split by industry, not architecture.

Both cycling stores were missing Product schema, the JSON-LD that spells out name, price, and availability for search engines and AI. The headless bike store and the Liquid bike store both skipped it. 

In this pair, that looks like a shared blind spot between these two teams, not an architecture flaw. With only one cycling pair, we would not generalize this to cycling stores as a category.

Searching State Bicycle's raw HTML for product schema returns nothing.

Result 2: Core Web Vitals, where the "faster" claim gets tested

Speed is the benefit headless is sold on. Nearly every article you will read says headless is quicker and therefore better for SEO. We measured it on real stores, on mobile, using real-user field data from Chrome.

Look at the LCP column.
In every pair, the Liquid store painted its main content faster than the headless store. Alphalete beat Gymshark, 1.8 seconds to 2.5. Xero Shoes beat Atoms, 1.6 seconds to 2.5. State Bicycle beat Factor Bikes, 1.9 seconds to 4.7.

One result we did not expect.
Gymshark and Atoms share identical numbers because both fall below the traffic volume CrUX needs to report page-level field data, so CrUX returns the origin-level fallback for both instead of independent measurements.

 Gymshark's LCP sits around 2.5 to 2.9 seconds over the period

 Alphalete, on Liquid, holds a faster LCP across the same window

We will not overstate three pairs.
Shopify's hosting makes a well-built Liquid store quick, and a heavy custom front end can lose that speed if it is not built with care. But the direction here is clear and consistent. Headless did not make these stores faster. On some it made them slower. If you are going headless to get faster, that depends on the build, and you should not assume it.

For context, our own Shopify speed benchmarks study measured 1,000 Liquid stores and found a median mobile LCP of 2.26 seconds, with 48% passing Core Web Vitals. That study left headless out on purpose. 

All three headless stores landed at or above that median, with the cycling store well beyond it. So against the Liquid baseline, these headless builds were not faster.

Every store failed for different reasons

Every store in the test failed Core Web Vitals, headless and Liquid alike. They failed for different reasons, and the reason matters more than the badge:

• Gymshark failed on interaction delay (INP 466 ms). It loads, then feels slow to respond to taps.

• State Bicycle failed on layout shift (CLS 0.33). It loads fast, then jumps around as elements settle.
  

State Bicycle passes on speed but fails Core Web Vitals on layout shift.

A pass/fail badge hides that. The fix depends on which metric is failing, which is what a proper site speed audit pins down.

Result 3: The technical basics

Speed and rendering get the headlines. The plain technical work is where builds tend to slip either way, and headless gives you more surface area to forget something, because everything a Liquid theme gives you for free has to be rebuilt by hand.

This is the most mixed result in the test, and again it does not sort by architecture. Gymshark, headless, kept every basic in place. Factor Bikes, also headless, was missing its sitemap, canonical tags, and robots rules on the pages we checked. Alphalete, on Liquid, was missing the same three.

This is about odds, not certainty. These basics are a choice on every platform.

 A Liquid theme ships a sitemap by default. On headless, someone has to build it, so it is easier to miss. Two of our three headless stores had at least one basic missing or incomplete. 

The worst single result, though, was a Liquid store, Alphalete, missing all three. So the platform is not what breaks these basics, Liquid can fail here just as badly, as Alphalete shows. Headless just adds more surface area to forget them.

Result 4: Can AI agents reach the store?

When someone asks ChatGPT, Perplexity, or Google's AI to find a product, a crawler goes and reads the store. Many of these crawlers do not run JavaScript, so what sits in the raw HTML matters.

 But there is an earlier gate: the store has to let the crawler in at all. We ran every store through our Agentic Commerce Readiness Check, which tests whether 36 known AI crawlers are allowed or blocked in the store's robots rules.

Among these six stores, this did not track with headless or Liquid.
Whether an AI crawler gets in is a line in your robots file, a decision someone made on purpose or inherited from a default.

Alphalete blocks 20 of the 36 AI crawlers we test. Gymshark blocks 5, including Anthropic's. The other four stores let everyone in. A store can look flawless to a shopper and still turn away the crawler that feeds an AI answer. We ran this exact scan across a thousand Shopify stores for our AI Search Readiness Report, and blocked or half-blocked crawlers were common even on stores that were otherwise well built.

The AI-readability gap we found was a settings choice. Headless did not cause it and Liquid did not prevent it.

Letting the crawler in is only the first step. In a separate study of 1,000 stores, our duplicate content and AI citations report found that even stores AI can read get cited as the source just 2.8% of the time, because the product copy is thin or copied from the same text a dozen other sites use. 

Access gets you in the room. Original, product-specific copy in the HTML is what gets you cited. Nothing in this test suggests headless or Liquid has an edge at either.

Check your own store in two minutes

You do not need our test to see where your store stands. Two checks, both quick:

1. The view-source check (60 seconds). Open one of your product pages. Right-click, choose View Page Source. Press Ctrl+F and search for your product name, then your price. If both show up in that raw text, a crawler reads them directly. If they are missing from the source but show on the live page, JavaScript is adding them, and anything that does not run JavaScript sees less than your shoppers do.

2. The AI crawler check (automated). Run your domain through the Agentic Commerce Readiness Check. It tells you which of the 36 AI crawlers your robots file allows, and whether your product schema, Shop Pay, and policies are readable to an agent.

If the first check comes back thin or the second shows crawlers blocked, that is a fixable build or settings problem, not a reason to change platforms.

So, is headless better for SEO?

On the evidence from these three pairs, no, not on its own. In the one place it is most often promised to help, speed, it did the opposite here. The Liquid store was faster in every pair.

The main takeaway is that the build decided three of the four checks. Architecture had a hand in the fourth: whether the page still worked with JavaScript off.

• Both architectures kept product facts in the raw HTML.

• The Liquid stores loaded faster in every pair, and our headless stores sat at or above the 2.26s median we measured across 1,000 Liquid stores, meaning slower, not faster

• Headless held up without JavaScript in all three pairs. Two of three Liquid stores broke. That is the one place architecture, not just the build, plausibly explains the gap.

• The missing technical basics were inconsistent on both platforms, though headless gives you more surface area to forget, since a theme ships these by default and headless doesn't.

• The AI-crawler blocking was a robots setting, unrelated to either architecture.

This does not reduce the value of going for a headless build.
Plenty of strong stores run on it. It means headless gives you no free SEO gain. Treat it as a shortcut and you can end up slower and less complete than the Liquid store you started with.

Who should go headless, and who should not

Stay on Liquid if you are ranking well.
Nothing in our test showed headless pulling ahead on speed, technical basics, or AI crawler access. Its only edge was staying usable with JavaScript off, which matters most if your current Liquid build already leans on client-side rendering for core content. 

Go headless if you need what Liquid cannot give you.
a level of design control, a custom experience, or complex omnichannel. Just go in knowing that rendering, the technical basics, and AI-crawler access are now yours to build and maintain. Budget for that work up front instead of finding it after launch.

Our best example from the test is Gymshark. product facts in the HTML, page still standing with JavaScript off, every technical basic in place. It is still loaded slower than its Liquid rival and still blocks one major AI crawler, which shows even a strong headless build has trade-offs to manage. Achievable, just not automatic.

Five things to verify before you go headless

If you are moving to headless or even planning a migration from another platform to Shopify, confirm these on staging before you launch. Each one is a place our test or the wider record shows builds slipping.

1. Server-side rendering is on for product pages. Your name, price, and description must be in the raw HTML, not added by JavaScript. Use the view-source check above.

2. Product schema carries over. The JSON-LD that describes each product has to be rebuilt on the new front end. It does not come along on its own.

3. Sitemap, canonicals, and robots rules exist and are correct. These are the basics headless most often drops. Confirm each one is present, not assumed.

4. A 1:1 redirect map is built and tested. If any URLs change, every old URL needs a 301 to its replacement, tested before you flip traffic. This is the single most common cause of migration traffic loss.

5. AI crawler access is deliberate. Check your robots file allows the AI crawlers you want. Do not inherit a default that blocks the tools now sending shopping traffic.

Can you recover errors on Headless?

A headless build that is fast, readable to crawlers, and readable to AI agents costs real money and real time. It needs server-side rendering set up right, the technical basics rebuilt by hand, and someone to maintain all of it as the store grows.

Weigh that against a Liquid build that reaches a similar place on SEO with far less to manage.

Mistakes here are recoverable. If a headless store launches with content hidden behindJavaScript or a sitemap missing, the cost is real while it is live. The day you move the facts back into the HTML and restore the basics, crawlers see the store properly again.

This is a build problem with a build fix, not a permanent penalty.

Headless is a design and control decision, not an SEO upgrade.

In our tests the Liquid stores were faster, though not always as resilient without JavaScript.

If you go headless, hold the build to a high bar on speed, rendering, the technical basics, and AI crawler access. If you stay on Liquid, you are not missing an SEO advantage.

If you are weighing the move, or you are already headless and want to know whether the build is costing you speed or AI visibility, that is the kind of thing we audit every week. 

FAQs on Shopify Headless vs. Liquid