Shopify SEO: what you can change and what you cannot

Every product URL on Shopify carries /products/ and every collection carries /collections/, permanently, on every plan and every theme, and that fixed skeleton is very often the actual ceiling on a store's SEO. A store can rank for its brand name for years, go nowhere on anything else, and have been through more than one SEO agency whose reports all say the same three things: fix your titles, add alt text, write more blog content. None of it moves the needle, because none of it touches the thing that's actually capping the site, which is buried in how Shopify builds URLs, not in what anyone wrote on the page.

Shopify permanently locks one thing: the /products/ and /collections/ segments baked into every URL, on every plan, in every theme. Everything else that gets pinned on "the platform" during an audit, canonical tags, robots.txt, structured data, script bloat, faceted URLs, is a setting or a theme default that can be fixed without leaving Shopify. Below, I separate the two, then cover the one case where the URL ceiling itself is the problem and headless is the only real lever.

If you manage a Shopify store and keep hitting SEO walls you can't get a straight answer on, whether it's the platform, the theme, or something an agency set up wrong, what follows works through each lock and each default in turn, so you know which one you're looking at before you pay anyone to fix it.

What Shopify actually locks, permanently

There is exactly one thing on a standard Shopify storefront you cannot change, whatever plan you're on: the URL skeleton. Every product lives at /products/{handle}, every collection at /collections/{handle}, and when a product is viewed through a collection the path becomes /collections/{collection-handle}/products/{product-handle}. You cannot shorten it or drop the /products/ and /collections/ segments. I get asked about this on almost every Shopify audit, and the answer is always the same: it isn't configurable.

Worth saying plainly because it saves people time: this is genuinely rare. Everything else that gets labelled a platform limitation turns out, on inspection, to be a theme default nobody had checked, or a setting nobody remembered choosing.

The same product, several URLs

Every Shopify catalogue I audit for the first time turns up the same weak point. Because a product can sit in more than one collection, it's reachable through more than one path, and Shopify's default is to canonicalise every one of those paths back to the clean /products/{handle} URL. That default works. Until something overrides it.

The override is usually a theme customisation, or a filtering app, that sets its own canonical tag per URL instead of inheriting Shopify's. When that happens, a product sitting in four collections quietly becomes four separately indexable pages instead of one. Google doesn't merge them back together on its own. It treats four thin variants of the same product as four separate, weaker pages, and whatever ranking signal, reviews or internal links should have consolidated on one URL ends up split across all four instead.

The check I run first on any Shopify audit is Search Console's Coverage report, filtered to "Duplicate, Google chose different canonical than user". Any count above zero on a Shopify store is a signal that a canonical override happened somewhere, and it's worth finding before touching anything else, because every other fix you make is diluted while this one is live.

Filtered and faceted collection URLs

Shopify's native filtering, the Search & Discovery app that ships as a theme app extension, canonicalises filtered results back to the clean, unfiltered collection URL by default. A visitor filtering by colour or size gets a URL with parameters attached; the canonical tag on that page still points at the base collection, which is correct and keeps Google from indexing thousands of parameter combinations.

That default holds for Shopify's own filtering. It does not automatically hold for third-party filter apps layered on top, some of which don't inherit the canonical behaviour and self-canonicalise every combination instead. If you've installed a filtering app in the last year and never checked, view source on a filtered collection URL and look for what the canonical tag actually points at. It's a two-minute check, and it's one I've started running by default whenever a client installs a new filtering app, because it catches a genuinely common problem.

Pagination, which mostly takes care of itself

Collection and blog pagination on Shopify appends ?page=2 and up to the base URL. Google stopped using rel=next/rel=prev as a pagination signal some years ago, and the current, correct behaviour is for each paginated page to self-canonicalise rather than point back at page one. Shopify's default does exactly that. There's very little to fix here, and the more common mistake I see is agencies "fixing" pagination that was never broken, forcing every paginated page to canonicalise to page one and quietly de-indexing the products that only appear on page three.

robots.txt: editable, but not somewhere to improvise

For a long time Shopify's robots.txt was completely locked. That changed with robots.txt.liquid, a template you can add to your theme code to add or remove rules for any crawler or path. The defaults are sensible: disallow on /admin, /cart, /checkout, /search, /policies/ and filtered collection parameters that would otherwise duplicate. You can add extra sitemap references, block specific bots, or set crawl-delay rules.

Shopify's own documentation is unusually blunt about the risk here: this is an unsupported customisation, and getting it wrong can lose you all your organic traffic. I've never had a reason to touch the default disallows on checkout, cart or admin, and I wouldn't recommend anyone else does either. The genuinely useful edits are additive: extra sitemaps, specific bot rules, nothing that removes what Shopify already blocks for good reason.

The sitemap you can't hand-edit

Shopify's sitemap.xml is generated automatically and there is no interface, Liquid template or setting that lets you hand-edit which URLs appear in it. You cannot open the file and remove a single product. What you can do is pull a specific product out of the sitemap by setting its status to Unlisted, or by using the SEO "hidden" metafield: both add noindex/nofollow to the page and drop it from the sitemap, while leaving the URL itself live for anyone who already links to it. That's the actual lever, and it's the thing I point people to whenever they come in looking for a sitemap settings page that doesn't exist.

Theme speed and the app-script problem

Shopify's Online Store 2.0 architecture lets apps inject scripts through "app embed blocks" that load on every page of the storefront by default, whether or not that particular page uses the app's functionality. Install six apps for six different jobs, and it's common for all six to be loading their JavaScript on every product, collection and cart page regardless of relevance. Nobody set out to build it that way; it's simply the path of least resistance for app developers, and in the audits I run, almost nobody has checked it.

This sits in the grey area between platform and theme: the app-embed mechanism is Shopify's architecture, but which embeds are switched on, and on which templates, is entirely within your control through the theme editor's App Embeds panel. Turning off the embeds that aren't earning their keep on a specific template reliably does more for Core Web Vitals than any amount of image compression.

Structured data: the baseline is free, completeness is theme work

Dawn and most modern Online Store 2.0 themes ship Product, Organization and BreadcrumbList schema out of the box, generated automatically via Shopify's structured_data Liquid filter. That covers the basics on a product page: name, price, currency, availability. It does not automatically cover reviews, GTIN, brand-level detail or a full return policy, all of which need to be added manually in theme code or through an app, and all of which are worth having if the product data exists to support them.

The quickest way to check what your theme actually emits: open a product page, view source, and search for application/ld+json. Whatever's missing from that block, reviews, GTIN, brand detail, is the honest to-do list, not a mystery.

Where headless changes the answer

Everything above is a theme-level or operational fix. There is one category of problem it doesn't touch: when the URL structure or the templating ceiling itself is the constraint, not something living inside it. That's why I built Periodico's storefront headless on Next.js against Shopify's Storefront API instead of inside a Liquid theme. The URL skeleton was part of it, but the honest trigger was accumulated drag: the client are fashion and design people with exact ideas about how the store should look, the theme made those ideas slow or impossible to build, and the site had grown into a puzzle of apps, some of them paid, that made every CRO change slower than the one before. At that point the theme layer itself was the constraint, and no amount of tidying inside it was going to change that. Going headless takes Shopify's own routing out of the request path entirely. URL structure, canonical logic, faceted navigation and pagination patterns become decisions you make in your own front end, not defaults you inherit or fight.

The trade is real, and worth being honest about before recommending it to anyone. Everything Shopify used to do automatically, sitemap generation, canonical handling, the baseline structured data, becomes something you now own and maintain yourself. Checkout, in most setups, still redirects to a Shopify-hosted checkout domain unless the store is on Plus with Checkout Extensibility, so headless doesn't remove every Shopify dependency, just the front-end ones.

When headless is the wrong answer for an SEO problem

Most of the time, it is. Headless is a genuine engineering investment: a front-end rebuild and a deployment pipeline you now own, on top of everything that used to be Shopify's problem. Canonical mismanagement, thin collections, an unaudited app-embed list, faceted URL bloat, all the things covered above, are fixable inside a standard Shopify theme, and every time I've fixed one, it's taken days, not months. Reaching for a headless rebuild to solve it is a disproportionate answer that trades a solvable content problem for a much bigger engineering one.

The honest version of the test I use: if a theme developer could ship the fix inside a week, it's a theme problem. If the fix needs a URL or template structure Shopify's own routing genuinely cannot produce, that's the point headless earns its cost, and not before.

If your Shopify store has hit a wall an agency couldn't explain, our SEO team runs exactly this kind of audit, platform limit versus theme default versus unmade decision, before recommending anything as large as a rebuild. It's also the starting point for most of the work inside our ecommerce marketing service.