Data Solutions
Start here, not with a crawler
Run a crawler at a Shopify store and it will return a few hundred issues sorted by the tool's idea of severity. Missing alt text. Meta descriptions over 160 characters. H1s that appear twice. It is a real list of real facts, and working through it top to bottom is close to the least productive thing you can do with the time.
The reason is that crawler severity is not revenue severity. A tool cannot tell that your /collections/all page is the one carrying every category term you want, or that the 4,000 URLs it just found are filter combinations rather than products. Those distinctions are the whole job.
Four checks decide whether a Shopify store can rank. Do them in this order.
1. Are your collection pages indexable and distinct?
Collection pages are where category demand lands. Somebody searching merino wool base layers wants a page of merino wool base layers, not one product and not your homepage. On a store with any breadth, collections are the highest-value pages you own.
They are also the ones most likely to be quietly broken. Check each money collection for:
| Check | What wrong looks like |
|---|---|
| Status code | Anything but 200 |
| Robots meta | noindex left by a theme edit or an app |
| Canonical | Pointing at /collections/all or at a paginated variant |
| Sitemap | Absent from sitemap_collections_1.xml |
| Body copy | Zero words above or below the product grid |
That last row is the one people skip. A collection page consisting only of a product grid gives a search engine almost nothing to evaluate beyond the title tag and the product names. A few hundred words of genuinely useful copy, the kind that answers what a buyer would ask before choosing, is often the difference between position 20 and position 6.
The failure mode to watch for is copy written for the crawler rather than the buyer. If it reads like it exists to contain the phrase, it will perform like it.
2. How many filter URLs is Google crawling?
Shopify generates a URL for every filter and sort combination. Colour, size, price band, availability, sort order, and every intersection of those. A store with five filters can produce thousands of addressable URLs, most of them near-identical to the collection they came from and to each other.
Left open, this does two things, and the second is worse:
- It splits the signals that should be consolidating on one collection page across dozens of variants.
- It spends your crawl budget. Google has a finite appetite for any given site, and a store where most crawled URLs are filter permutations is a store whose actual products get crawled less often.
Open Search Console, go to the Pages report, and look at the crawled, currently not indexed bucket. If it is large and full of URLs carrying filter parameters, that is your answer. On stores where this is the constraint, it is usually the single biggest one.
The fix is a decision rather than a setting: which filter combinations, if any, represent real search demand and deserve an indexable page, and which are navigation conveniences that should not be crawled at all. Most stores need far fewer indexable facets than they have.
3. Can a search engine read your product pages?
View source on a product page. Not the rendered inspector view, the actual HTML. Find the product description.
If it is not there, nothing else on this list matters for that page. Plenty of themes and most review or tab apps render description content client-side, and Google's rendering of that is neither guaranteed nor prompt. A product page whose description is invisible in the HTML has its title tag and its product name to rank on, which for anything competitive is not enough.
While you are in there, check whether the description is yours. Manufacturer-supplied copy, used verbatim, is the same text on every retailer selling that product. It is not a penalty, but it is a guarantee that nothing distinguishes your page from a hundred others, so the ranking goes to whoever has the stronger domain. That is not a contest a growing store wins.
4. Do your money collections have any internal links?
Internal linking is the least glamorous item here and routinely the most valuable.
Count the links pointing at each of your top collections. Not navigation links alone, which every collection has and which therefore distinguish nothing. Count editorial links: from other collections, from blog content, from product pages, from anywhere that represents a real recommendation rather than a template.
On most stores the count is zero, and the collection sits three clicks from the homepage behind a mega-menu. That store will rank for its brand name and very little else, because nothing on the site indicates which pages matter.
This is the pattern that showed up most clearly in a project I ran outside e-commerce: on a reference site I built to about 1,300 articles, the two highest-traffic URLs were both category hub pages rather than any individual article, and the reason was internal links. Every article in a category linked up to its hub, and no individual page had anything comparable. Collections are the same shape of problem. Give them links and they behave like hubs.
The check that is not technical
Everything above assumes people are searching for what you sell, in terms your catalog is organised around. Verify that before spending on any of it.
Pull Search Console by query for the last six months and put it next to your margin report. You are looking for one of three situations:
- Impressions on the right terms, low clicks. A positioning and titling problem. Cheapest to fix.
- Impressions on terms you cannot profit from. A targeting problem. Your catalog and your query set have diverged, and no technical fix touches it.
- Almost no impressions. Either the store is too new, or the terms are genuinely uncontested because nobody searches them.
I have found the second case surprisingly often, including on my own site. Auditing my library of 44 articles against six months of Search Console data, one article was producing 78 percent of all clicks and a 22-article section I had assumed was the site's foundation turned out to be 4.6 percent. Every plan I had been making for that section was built on an assumption the data did not support.
That is the argument for looking at the data before the crawl. A crawler tells you what is broken. Only the query data tells you whether fixing it is worth anything.
What to do with the results
Sort what you find by one question: if this were fixed, would it change what a buyer sees in a search result, or what a search engine does with a page that already ranks?
Most crawler output fails that test. Alt text on a decorative image, a meta description four characters too long, a second H1 in a footer widget: real, findable, and worth almost nothing. The four checks above fail it too, most of the time, on most stores. But when one of them is the constraint, it is usually the whole constraint.
If you want a second pair of eyes on what you find, tell me what you sell and I will look at the store rather than at a crawl of it.