Technical SEO On A Store: What To Fix (And In What Order)

You have a list. It came out of a crawl tool or an agency report, it runs to a couple of hundred items, and every line is marked as a problem.

What ecommerce technical SEO work never tells you is which three to do this month. Items at the top are usually whichever ones a tool finds easiest to count, and your most expensive problem may sit near the bottom.

I am John Butterworth and I run the retainers at Mint SEO myself. Stores that land on my desk rarely have two hundred problems.

They have four. The work was done in the wrong order, so expensive fixes landed on pages Google had already decided not to store.

Here is the order. Below I take the four jobs in the sequence they pay, with the place in your own data to check each one.

What The Technical Work On A Store Actually Is

Selling online is not a brochure site with a checkout bolted on. A shop differs from an ordinary website in one specific way, which is that the catalogue writes URLs by itself.

Filters, sort orders, variants and internal search all mint new addresses without anybody publishing a page. A 200-product catalogue routinely becomes six figures of fetchable URLs, and that one fact sets the running order into four jobs:

1. Crawl control. Decide which of those self-generated URLs Google may fetch at all. Your URL structure and site architecture get settled at this stage.
2. Indexing. Of the pages you do want fetched, get the ones that earn money stored. Duplicate content is what usually stops them.
3. Serving speed. Make the stored pages usable on a phone. Page speed on a store is an apps problem before it is an images problem.
4. Markup. Describe the product so it qualifies for result features. Product schema and the rest of your structured data go on last.

Each job is wasted while the one above it is wrong.

Google splits the crawl budget in two. Its crawl budget documentation sets a capacity limit from how well your server responds, then a demand side from site size and content quality.

So a catalogue burning its allowance on sort-order URLs is starving the pages you need read. Marking up a product page beautifully achieves nothing if that page is not stored.

Shaving a second off a template does nothing for a page Google never reaches. Where the money sits matters just as much, and one merchant put it flatly on r/shopify:

Most Shopify stores get 80% of their organic traffic from product and collection pages.

Those two templates are what all four jobs are about. That is why they come before anything else in which job to do first across the whole programme.

How We Run A Store Audit At Mint SEO

When a store comes to us, the first thing we hand back is a running order.

I am John Butterworth, I run the Mint SEO retainers myself, and the diagnosis is nearly always about which fault came first. That diagnosis is deliberately narrow.

We pull your server logs and crawl stats to see where Google is spending its time. Then we compare that against the URLs carrying revenue.

From there we work out which of the four jobs is blocking the other three, and you get an ordered plan with the reason each item sits where it does. What you do not get is a two-hundred-line spreadsheet that leaves the sequencing to you.

Mint SEO works to one job, more revenue from organic search, delivered through eight disciplines. The one covering ecommerce technical SEO is where most stores are held back.

If you want the ordered version for your own catalogue, ask us for an SEO audit and strategy. If you would rather talk it through first, book a free 30-minute consultation and I will tell you which of the four is your problem.

The URLs Your Catalogue Invents

Here is the job that separates a shop from every other kind of website. It is a crawling decision rather than an indexing one, and that distinction is where most stores go wrong.

Sitebulb draws the line where it counts, recommending "making a distinction based on what generates a new landing page (facets), while filters are for users but not search engines". That test puts the decision where the cost sits. Anything generating a page worth ranking can be crawled; anything that only helps someone browse should never reach a crawler.

Your decision is taken at facet level, and it is a single question. May this attribute generate crawlable URLs at all?

Taken one facet at a time, that is a handful of decisions across your whole catalogue. Taken one URL at a time it never ends.

Reaching for noindex feels right and does not work. Google's crawling documentation is explicit about what happens:

Don't use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.

That page still gets fetched. You have spent the crawl budget and gained nothing.

Google names infinite scrolling pages that duplicate information, and differently sorted versions of the same page, as URLs to block with robots.txt.

Canonicals do not settle it either, and practitioners keep finding this the hard way. One technical SEO on r/TechSEO described the symptom precisely, reading server logs on a large store:

Filtered URLs with parameters are being crawled far more frequently than their canonical category pages. Canonicals are set correctly, internal links favour clean URLs, and parameter handling hasn't changed recently.

A canonical is only a consolidation hint about which URL to store, and it is not an instruction to stop fetching anything.

Use robots.txt at facet level instead. It stops the fetch outright, where noindex stops only the storing and does so after the fetch has already happened.

On a store that already has a mess, sequencing matters. Per Google's robots.txt documentation, blocking a URL prevents crawling but does not by itself remove one already indexed.

Let the unwanted URLs be crawled and dropped first, then block the facet. Blocking first freezes the index bloat in place.

On Shopify a good deal of this is done for you. The default robots.txt published by the Shopify Help Centre blocks the admin, cart and checkout paths, plus a wildcard rule stopping multi-filter collection URLs being fetched.

We wanted to know how many merchants ever touch that file. On 5th August 2026 we fetched robots.txt across a frame built from two public lists of Shopify stores, kept the 59 stores whose file still carried the platform's generated signature, and counted every directive absent from at least half the sample as a merchant edit.

Of those 59 stores, 35 run the template untouched, which is most of the sample.

The merchants who had changed something were strikingly consistent about why. Almost every one of those edits aimed at a query parameter, filter, sort or paging URL. Almost none aimed at anything else.

Pagination is the neighbouring decision and follows the same logic, which I have set out in how pagination decides what Google can reach.

Which Filters Deserve To Be Indexed

A facet earns indexing when people search its combination by name, and the rest get blocked.

Sitebulb's guide makes the commercial case for keeping some: faceted navigation is the only way to generate enough landing pages to capture long-tail search demand across your products.

"Womens waterproof walking boots" has real demand behind it. That combination earns a crawlable page with its own copy and its own internal linking.

Nobody types "womens waterproof walking boots size 6 sorted by price ascending", so that gets blocked at facet level. Every facet then belongs in exactly one of three buckets.

Promote the ones with real demand to proper landing pages with their own copy. Leave the borderline ones crawlable but not internally linked.

Block the rest so they never generate a fetchable URL at all. Write that list facet by facet and the job becomes finite.

What The AI Crawlers Are Taking

Crawl allowance now has a second claimant. In July 2026 Cloudflare set out how site owners can refuse AI crawling while still admitting multi-purpose crawlers such as Googlebot, Applebot and BingBot.

Our robots.txt sample shows how far this has reached ordinary merchants. Only 6 of the 59 stores named an AI crawler at all, and the files that did named GPTBot and ClaudeBot most often.

Five of those six are large, well-resourced brands. Google-Extended and Applebot-Extended turned up alongside PerplexityBot, CCBot and Bytespider.

Blocking them is a commercial decision, and the technical part of it is trivial. It turns on whether you want your product data in AI answers.

What is not in doubt is that this fetching competes with Googlebot for the same server capacity.

Crawled, Currently Not Indexed

Job two looks like job one and is not. Here your pages have already been fetched.

Google looked at them and decided they were not worth a place in the index. Nothing in your robots.txt or your canonicals changes that verdict, because it is a verdict about the pages.

This is the report store owners bring us most often, and the scale it reaches is genuinely large. One practitioner on r/SEO described a catalogue in exactly that state:

I have over 5 million unindexed addresses, divided into 3 million with the noindex tag and 2 million with the status of waiting for indexing.

Causes on a store are boringly consistent. Product pages carry the manufacturer's description and nothing else, or variants sit on separate URLs saying the same thing.

Discontinued lines still return 200. Thin category pages get built for a taxonomy nobody shops by.

Your fix is the pages, and usually it is subtraction. Consolidate variants onto one URL and retire discontinued products properly.

Then give the pages that remain something the manufacturer's feed does not have.

Which pages deserve that investment is a keyword question as much as a technical one. It runs on the reasoning behind the searches your catalogue can realistically win.

Finding The Waste In Your Own Search Console

No tool is needed to start. Open Google Search Console and find Crawl Stats under Settings, which is where most people never look.

That report breaks Googlebot's requests down by file type, purpose and response. Two readings then tell you which problem is yours.

If most requests hit URLs with question marks in them, that is job one and your crawl control is leaking. If they land cleanly on product and collection URLs but the Page Indexing report still shows those unstored, that is job two.

Check your XML sitemap against the same report. A sitemap full of URLs Google declines to store is its own signal.

For a catalogue large enough to justify it, server logs beat sampling. The Log File Analyser from Screaming Frog reads Apache, IIS and Nginx formats if you can get the files out of your host.

Where A Shopping Page Loses Its Speed

Speed on a store is not really about images, and platform data shows it. Per the HTTP Archive Web Almanac, Shopify desktop reaches a 76% Core Web Vitals pass rate against WooCommerce on 33%.

No difference in JPEG compression explains a spread that wide. In that same chapter, on Shopify desktop 92% of origins record good LCP against 45% on WooCommerce.

Loading is therefore where the platforms diverge. A hosted platform controls the theme, the CDN and the image pipeline, while a self-hosted stack lets the merchant control all three badly.

What that leaves on a well-hosted store is responsiveness, and responsiveness is an apps problem.

Every review widget, chat bubble and recommendation block ships JavaScript. It runs on the main thread while your shopper is trying to tap a variant.

Those scripts delay the tap. A store can therefore pass on loading and still feel slow to the person using it.

Your ecommerce technical SEO work here is really an app audit. Count what the theme loads on a product page or a collection page, find any that nobody has used since installation, and delete them. Deferring keeps the payload.

One warning about scores. A lab score is only a simulation on synthetic hardware. One optimisation specialist summarised the platform's own advice on r/shopify:

Shopify's advice is to compare a PageSpeed Insights run against Lighthouse in Chrome DevTools.

Field data in Search Console is what Google acts on. Chase the field numbers and read the return in the same terms as what a good conversion rate looks like.

Product Markup And The Fields That Moved This Year

Markup goes last because it only pays on a page already crawled, stored and quick. Once those are true it is the cheapest win on the list.

Even so, your base is smaller than most merchants expect. Per Google's merchant listing reference, required fields remain name, image and offers carrying price and priceCurrency.

Brand, gtin, sku and aggregateRating are only recommended. Marking those up is still worth doing, because richer results draw on them.

Worth knowing this year is that the specification moved, as PPC Land reported at the time:

The July 7, 2026 update to the Merchant listing documentation adds detail on how the Product.category property can accept two distinct data types: plain text and a new CategoryCode object.

Google's reference now defines the property like this:

Specifies the product's categories. This property can accept an array of values, mixing plain text strings and CategoryCode objects.

To put a Google Product Category in the page itself, the same reference tells you to use the CategoryCode type.

That settles a mismatch which used to cause real trouble. Your feed said one category and your page said another, so the two systems disagreed about what you were selling.

Now the page can carry the same taxonomy code your feed does. Sale timing was formalised in the same pass, and Google documents `priceValidUntil` like this:

The date and time after which the price will no longer be available, in ISO 8601 format.

A lapsed date on a promotion is a common reason a price stops showing. Treat markup as something you maintain on a schedule.

That specification changed twice during 2026, so schema which validated cleanly last year can be incomplete now, and nothing on your store will tell you because it does not break.

Put a re-validation in the calendar and check it against the current reference. The same discipline keeps the other three ecommerce technical SEO jobs from drifting.

If you do one thing after reading this, open Crawl Stats and look at where Googlebot is spending its requests. That single screen tells you which of the four jobs is yours.