The half of the SEO audit nobody implements
The common version of this: you paid for an SEO audit, it came back as a document, and about a third of it was addressed to a developer. That third is still sitting in the document.
It stalls for a structural reason rather than a lazy one. The SEO consultant can’t implement it — it’s theme work, and touching a live theme isn’t their job. The developer can’t prioritise it — it arrives as a list of assertions without the reasoning, so it looks like preference. And nobody owns the gap, so it becomes the thing that gets done next quarter, permanently.
Meanwhile the technical layer is doing whatever the theme’s author decided in 2021 — which might be fine, and might be quietly telling search engines to ignore half your collection pages.
Check it yourself
Open Google’s Rich Results Test and run one product page. If the structured data doesn’t validate, the rich result you’re hoping for isn’t going to appear — that’s binary, not a matter of opinion.
View source on a collection page and search for canonical. It should point at the page you’re on, or deliberately elsewhere. If it points somewhere surprising, that’s a real problem and it’s invisible from the front end.
Check Search Console’s coverage report for pages excluded by a noindex or a canonical. Shopify generates a lot of URLs; some of them should be excluded, and occasionally the wrong ones are.
Then open your slowest product page in PageSpeed. Speed is a ranking input, and it’s the one place where this overlaps entirely with the performance work.
What the work involves
Auditing what the theme is actually emitting — structured data, canonicals, meta handling, the crawl paths Shopify generates by default and the ones your apps added.
Implementing the technical half of someone else’s audit, if you have one — with the reasoning written down, so the next person knows why it’s like that.
Fixing what’s mechanically wrong: invalid schema, canonicals pointing at the wrong place, pagination that hides half a collection, redirects that chain three deep after a migration.
The speed work, because it’s a ranking input and it’s the same job as the performance engagement.
A re-run of the same tests afterwards, so you can see what changed.
What this isn’t — and this list is longer than the one above
It isn’t keyword strategy. I don’t do keyword research, I don’t decide what your pages should target, and I won’t pretend the technical layer substitutes for that.
It isn’t content. Most of what makes a store rank is having pages worth ranking, and that’s not a theme problem.
It isn’t link building. Not a service, not a referral, not a thing I have opinions about.
And it isn’t a ranking promise. I won’t tell you what this will do to your positions, because nobody honest can. What I can tell you is whether the technical layer is doing something wrong, and fix it if it is. If someone has quoted you a position, that’s the tell.
What the standard says about this
- A performance target that holds as content grows — Whether the store is fast on the pages that carry real content, measured in numbers rather than impressions.
- Structure that survives the next change — Whether the theme can absorb a new section without a developer rewriting a template.
Two ways to find out
The checks above are published and free. Run them yourself, or send me the store and I'll run them for you.