This Shopify SEO checklist is deliberately platform-specific. General ecommerce advice applies to Shopify like it applies to everything else; what follows is the set of things that are true because of how Shopify itself is built, and that therefore never appear in a generic guide.
The duplicate product paths, which are by design
Every product on a Shopify store is reachable at two addresses: its own product path, and a longer path nested under whichever collection the visitor came through. A product in six collections therefore has seven working URLs.
Shopify sets the canonical tag correctly for this, so the situation is handled rather than broken — but only if nothing in your theme or apps overrides it, which is worth checking rather than assuming. What is still worth fixing is your own internal linking: if your collection grids link to the nested version, every internal link on the store points at the non-canonical address. Linking directly to the product path costs nothing and removes the ambiguity entirely.
Variant URLs
Selecting a variant appends a parameter to the address, which creates a distinct URL for every colour and size. These are canonicalised to the parent product, which is right for most stores.
It is worth pausing on when it is not. If your variants are things people search for by name — a specific colourway, a particular size in a category where size is the query — then collapsing them all into one page means you never rank for the thing being searched. The answer in that case is usually separate products rather than variants, which is a merchandising decision with SEO consequences and is far cheaper to make before the catalogue is built than after.
What robots.txt.liquid can and cannot do
Shopify lets you edit the robots file through a theme template, which is more control than it used to give and less than people assume.
Use it to keep crawlers out of things that are navigation rather than content: filtered and sorted collection views, internal search results, cart and checkout paths. That is genuine crawl budget being spent on pages that will never rank and should never be indexed.
What it cannot do is remove something already indexed — blocking a URL prevents recrawling, which can freeze a bad result in place rather than removing it. If something is indexed that should not be, let it be crawled and serve the instruction not to index it, then block it later once it has dropped out.
Collections: the part worth the most
Shopify collection pages ship as a heading and a grid. That is the correct default and it is not a page that can outrank a competitor who has written something.
Two Shopify-specific notes. Automated collections built on tags can generate a large number of thin pages very quickly — one per tag combination, each with a handful of products and nothing written. Be deliberate about which of those deserve to exist and be indexed at all. And the collection description field renders above the grid in most themes, which means a long description pushes the products down; the usual answer is a short lead above and the substantial writing below the grid, which most themes support and most stores never use.
Theme and app settings that decide how you are crawled
Check what your theme does with pagination — infinite scroll that loads products with no crawlable links means the products past the first page may as well not exist. There should be real links, even if they are visually hidden behind the scroll behaviour.
Check your structured data. Most themes emit product markup; many emit it with fields missing or with a rating from an app that is no longer installed. Markup describing reviews you do not have is the most common route to a manual penalty on a Shopify store.
Check what your apps inject. Apps frequently add their own markup, their own canonical tags and their own scripts to every page. An app installed for a campaign two years ago that still loads on every product page is both a speed problem and, sometimes, a correctness problem.
The blog, which is usually wasted
Shopify stores get a blog and most of them use it for announcements nobody searches for. It is the only part of the store where you can answer the questions that come before the purchase, which is where the volume is.
Two mechanical points: the default blog URL structure nests posts under the blog handle, so choose that handle deliberately rather than accepting the default; and tag pages on the blog generate the same thin-page problem as automated collections, and rarely deserve to be indexed.
The order to work through it
Fix internal linking to canonical product paths, and block the navigation URLs. Both are quick, neither is visible to customers, and together they stop the store competing with itself.
Then audit the structured data and remove any markup describing things that are not true. This is risk reduction rather than growth, and it is worth doing before you attract more attention.
Then write your five highest-intent collection pages properly. Then the blog, aimed at pre-purchase questions. Then speed, measured on the field data in Search Console rather than a synthetic score.
The broader argument behind steps three and four is in the general catalogue guide, which covers why collection pages carry the demand. If you would rather have the list for your specific store than the generic one, the teardown does exactly that.
