Ecommerce SEO Checklist: Step-by-Step Technical & On-Page Guide (2026)
An ecommerce SEO checklist in 18 steps: crawling, index coverage, product URLs, faceted navigation, product markup, Core Web Vitals, rendering and AI search.
TL;DR. This ecommerce SEO checklist has 18 steps in six groups: crawling and indexing, URLs and architecture, on-page content, product structured data, speed, and AI search. Each step says what to check, how to check it, and what a passing store looks like. Run the technical steps on your product, category and filter templates first, because one template fix changes thousands of URLs at once. The condensed version at the end is free to copy into your own tracker.
Every store has the same three templates doing most of the work: the category page, the product page and the filter page. An ecommerce SEO checklist is a way to test those templates in a fixed order, so you find the problem that affects 5,000 URLs before you polish one product description. The steps below are that order. Each one names the report or tool that shows the answer and the condition that counts as a pass.
The checklist works for Shopify, WooCommerce, Magento, BigCommerce and headless storefronts. Where a platform has its own quirk, the step says so. The strategy behind the steps, from keyword research to links, is in the full guide to ecommerce SEO.
1. Confirm crawlers can reach the store
What to check. Your robots.txt, your CDN or firewall bot rules, and any password or geo block that applies to crawlers.
How to check it. Open yourstore.com/robots.txt and read every Disallow line. Then fetch a product page with a crawler user agent. The Googlebot simulator does this from outside your network and shows the status code and the HTML it got. Repeat with GPTBot and PerplexityBot if you want AI assistants to see the store.
What good looks like. Product, category and guide URLs return 200 to every crawler you want. robots.txt blocks cart, checkout, account, internal search and sort URLs, and nothing you want indexed. A CDN rule that challenges bots with JavaScript or a CAPTCHA blocks every crawler that doesn't run a browser, so check the firewall's bot settings when the simulator gets a 403 or a challenge page. The robots.txt analyzer reads the file the way each crawler does and lists what each one is allowed to fetch.
2. Read the Page indexing report
What to check. How many product and category URLs Google has indexed, and why it has excluded the rest.
How to check it. In Google Search Console, open Indexing, then Pages. Compare the indexed count with the number of canonical products and categories in your store. Then open each "Why pages aren't indexed" reason and look at the sample URLs.
What good looks like. The indexed count is close to your canonical URL count, and the excluded reasons are ones you chose: "Excluded by noindex tag" on filter pages, "Alternate page with proper canonical tag" on variant URLs, "Blocked by robots.txt" on internal search. Two reasons point to problems on a store. "Discovered - currently not indexed" on product pages means Google knows the URLs and hasn't crawled them, which usually comes from crawl capacity spent on parameter URLs. "Crawled - currently not indexed" means Google read the page and left it out, which usually comes from thin or duplicate product content. Each has its own guide: Discovered - currently not indexed and Crawled - currently not indexed.
3. Clean the XML sitemap
What to check. That every URL in the sitemap is one you want indexed, and that it returns 200.
How to check it. Fetch each sitemap file and sample URLs from it. Crawl the sitemap with a site crawler and sort by status code and by canonical. In Search Console, open Sitemaps and compare "Discovered pages" with the indexed count from step 2.
What good looks like. The sitemap lists canonical, indexable URLs only: no variant parameters, no filter pages you noindex, no redirects, no 404s, no out-of-stock products you've removed. Split it by type, with one file for products, one for categories, one for guides, so the Sitemaps report shows which type Google is skipping. On Shopify the sitemap is generated for you and lists collection and product URLs; on Magento and WooCommerce the generator settings decide what goes in, so check them after every plugin or extension update.
4. Give every product one URL
What to check. Whether a product answers on more than one URL, and whether every signal agrees on which one is canonical.
How to check it. Open a product from a category, from site search, from a variant selector and from a marketing email, and compare the address bar each time. Then view source on each and read the rel="canonical" tag. A site crawler lists every URL with a canonical that points somewhere else; the site audit groups these with duplicate titles and near-duplicate pages, which is where the same product on several URLs shows up first.
What good looks like. One URL per product. The canonical tag on that URL points to itself, and every other version carries a canonical to it: collection-path URLs on Shopify, category-path URLs on Magento, ?variant= and tracking-parameter URLs everywhere. Internal links, the sitemap, the url in your structured data and your product feed all use the canonical URL. A canonical tag is a hint, and Google follows it more reliably when links and sitemaps point the same way. On Shopify, change your theme to link products with {{ product.url }} and remove the within: collection filter, because collection-path URLs return 200 and can't be redirected.
Variants. Decide whether color and size variants live on the parent URL or on their own pages, and let search demand decide. If "trail runner 2 black" has its own searches, a variant page can rank for it; if people search the product name only, one parent page is enough. Shopify and WooCommerce select a variant with a query parameter on the parent URL, and Magento configurable products can expose each simple product on its own URL. Variants without their own demand sit on the parent URL, with the parent as canonical and Google's ProductGroup markup listing each variant. Variants with real demand get their own indexable URL, title, image and self-referencing canonical. Whatever you choose, the markup, the feed and the canonical describe the same thing.
5. Control faceted navigation
What to check. How many URLs your filters create, how many of them Google crawls, and which ones deserve to be indexed.
How to check it. On a category page, apply three filters and a sort, and read the URL. Each parameter multiplies the URL count. Then search Google for site:yourstore.com inurl:? and check the Page indexing report for parameter URLs under "Crawled - currently not indexed" and "Duplicate without user-selected canonical". Your server logs, or the Encited crawl log if the store runs through Encited, show the share of Googlebot's requests that go to filter and sort URLs.
What good looks like. The few filter pages with search demand ("women's trail running shoes", "size 42 trail shoes") have clean URLs, unique titles, an intro and internal links. Every other combination is either disallowed in robots.txt or canonicalized to the category. Google's faceted navigation guidance says a parameter-based setup "can generate infinite URL spaces", and its crawl budget guide lists differently sorted versions of the same page as wasted crawling. The full method, with Shopify, Magento, WooCommerce and BigCommerce examples, is in faceted navigation SEO. One rule from it worth repeating: never block a URL in robots.txt and mark it noindex at the same time, because Google can't read the tag on a page it can't fetch.
6. Fix category pagination
What to check. How a category with 300 products exposes products 25 to 300 to a crawler.
How to check it. Scroll a category page to the bottom and look at what loads the next products: a page link, a "load more" button or infinite scroll. Then view source on page 2 and read its canonical tag.
What good looks like. Each page of the sequence has its own URL, such as ?page=2, linked with real <a href> links. Each page has a self-referencing canonical; Google's pagination guide says not to point the rest of the sequence at page 1. Products that appear only after a click or a scroll never get found from the category, because Google's crawlers don't click buttons. Keep the paginated URLs under the button as a fallback, so a crawler that doesn't run JavaScript still finds every product.
7. Set the right status for out-of-stock and removed products
What to check. What a sold-out product, a discontinued product and a deleted product each return.
How to check it. Find one of each in your catalog and fetch it with the Googlebot simulator. Read the status code and whether the product content is still in the HTML.
What good looks like.
| Situation | Status |
|---|---|
| Out of stock for now | 200, page stays indexable, availability set to OutOfStock, alternatives shown |
| Discontinued, with a successor | 301 to the successor |
| Discontinued, no successor, still gets traffic or links | 200 with a discontinued notice and links to alternatives, or 301 to the closest category |
| Gone, nothing relevant to send people to | 404 or 410 |
Don't noindex a product that's coming back; it loses its rankings and has to earn them again when stock returns. An "unavailable" page with no product content and a 200 status gets treated as a soft 404. Seasonal products keep the same URL every year.
8. Audit redirects and internal search
What to check. Redirect chains left by past migrations and theme changes, and whether your store's search results pages are crawlable.
How to check it. Crawl the store and sort by redirect hops. Fetch an old product URL from a year-old email or a backlink and count the hops to the final page. Then open your site search, search for anything, and read the URL: /search?q= on Shopify, /catalogsearch/result/ on Magento, ?s= with post_type=product on WooCommerce.
What good looks like. Every old URL reaches its destination in one hop, and internal links point at final URLs, never at redirects. Internal search pages are disallowed in robots.txt, because they can produce a URL for anything anyone types. On Shopify, check robots.txt.liquid for a /search rule, because current default files don't include one. When a search term shows real demand in your search logs, build a category or landing page for it.
Index coverage is the step most stores fall behind on, because new products arrive every week. Index Rush keeps the index status of every URL in one list, points to the indexed pages that already link to a new product so you can get those recrawled, and requests indexing for new URLs in one click. That turns step 2 from a quarterly report into something you check when a collection launches.
9. Flatten the category tree
What to check. How many clicks separate the homepage from a product, and whether each category has a real link to it.
How to check it. Crawl the store and read the crawl depth column. Pick ten products at random and count the clicks from the homepage through the menu, with JavaScript off, since a crawler follows <a href> links only.
What good looks like. Most products sit three clicks from the homepage: home, category, product, with subcategories in between on large catalogs. Every category and subcategory is linked from the navigation or from a parent category page as a real link. Categories with high search demand are linked from the homepage. A category that exists only in a mega menu rendered by JavaScript after load is invisible on the first crawl, so check the menu in the server HTML.
10. Link categories to products, and products to each other
What to check. The links on a category page, a product page and the breadcrumb trail.
How to check it. View source on a category page and count the product links in the HTML. View source on a product page and look for links to its category, related products and the breadcrumb.
What good looks like. Category pages link to every product on the page with an <a href> and the product name as anchor text. Product pages carry a breadcrumb trail with BreadcrumbList markup, links to related and alternative products, and a link back to the category. Related-product carousels built by JavaScript after load don't count until a crawler renders the page, so put the first set of links in the HTML. Guides and buying advice link to the categories and products they talk about.
11. Map keywords to categories, products and guides
What to check. That each search you want has one page assigned to it, and that the page type matches the search.
How to check it. Export your Search Console queries for the last three months and group them: category searches ("trail running shoes"), product searches ("trail runner 2 review"), and questions ("how to choose trail running shoes"). Assign each group to one URL. Where two of your pages rank for the same search, you've found a cannibalization problem.
What good looks like. Broad category searches go to category pages, product and model searches go to product pages, questions go to guides, and each search has one owner. The keyword research method, with the intent rules behind it, is in the ecommerce SEO strategy section of the full guide.
12. Write category titles, H1s and intros
What to check. Every category page has a unique title tag, one H1, a short intro and a meta description.
How to check it. Crawl the store and sort by title. Duplicate and missing titles show up immediately. Then open your top ten categories by impressions and read the intro text with JavaScript off.
What good looks like. The title names the category and the kind of product ("Trail running shoes for men") and matches the H1. A short intro above or below the product grid says what the category covers and links to the main subcategories. Each category has its own meta description. Category text that's hidden behind a "read more" toggle is fine as long as it's in the HTML.
13. Write product titles, descriptions, specs and image text
What to check. Whether your product pages have content a crawler can read that other stores selling the same product don't have.
How to check it. Take your top 20 products by impressions. Search a sentence from each description in Google with quotes. If it returns the manufacturer's site and ten other retailers, the description is shared. Then view source and check that specs and sizing are HTML text.
What good looks like. Each product has a title that follows one template ("Product name, key attribute | Brand"), a description you wrote, specs and sizing as text in the HTML, and no duplicate titles or meta descriptions across the catalog. Reviews are in the HTML too. Products with the same description across sizes or colors point at one canonical parent, as in step 4.
Images. The main product image has descriptive alt text with the product name, a file name that says what it is, and explicit width and height attributes. Images are served as WebP or AVIF at the size the template displays. The main image is not lazy-loaded; images below the fold are. A crawl with image extraction on lists missing alt text and oversized files; PageSpeed Insights names the Largest Contentful Paint element, which on most product templates is the main image.
14. Validate Product and ProductGroup markup
What to check. That each product page carries one valid product block, in the initial HTML, with the fields Google's merchant listings need.
How to check it. Paste a product URL into Google's Rich Results Test and read the detected items. Then view source and search for "@type": "Product" or ProductGroup to confirm the block is in the HTML the server sends. Search Console's Merchant listings and Product snippets reports list errors across the store.
What good looks like. One Product block per page, or one ProductGroup with hasVariant entries for products with variants. Google's merchant listing markup needs name, image and an Offer with price and priceCurrency; add availability, gtin, brand, sku, aggregateRating and review where you have them. A theme and a review app can each print their own Product, which leaves Google two conflicting products, so remove one. Google recommends putting the markup in the initial HTML and warns that markup generated by JavaScript "can make Shopping crawls less frequent and less reliable". The field reference and a full ProductGroup example are in the product structured data section of the full guide.
15. Match price and availability everywhere
What to check. That the price and stock status in the page, the structured data and your Merchant Center feed are the same number at the same time.
How to check it. Open Merchant Center and read the item issues: "Mismatched value (price)" and "Mismatched value (availability)" are the two to look for. Then open one flagged product, view source, and compare the price in the HTML with the markup and the feed.
What good looks like. No mismatch issues in Merchant Center. The price in the server HTML, the Offer in the markup and the feed agree. When the price is set by JavaScript after the page loads, Googlebot can read a different value from the one shoppers see, so put the price in the server response or serve crawlers a rendered snapshot that refreshes when prices change. Google's documentation says providing both structured data and a Merchant Center feed maximizes eligibility for its shopping results, so keep both current.
16. Pass Core Web Vitals on product and category templates
What to check. Field data for your three templates on mobile.
How to check it. Open Search Console, Core Web Vitals, mobile, and read the URL groups. Then run one product page and one category page through PageSpeed Insights and read the field data at the top.
What good looks like. Google's thresholds, measured at the 75th percentile of real visits: Largest Contentful Paint 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, Cumulative Layout Shift 0.1 or less. The usual causes of a fail on a store are app and plugin scripts for reviews, upsells, chat and tracking, large hero images and sliders, and themes or PWA bundles that must download and run before anything shows. Remove apps you don't use and the code they leave behind in the theme. Speed also sets how much Google crawls: Google's crawl budget guide says the crawl limit goes up while response times stay stable or improve, and goes down when the server slows or returns errors.
17. Check what crawlers get from a JavaScript storefront
What to check. Whether product name, price, stock, reviews and related-product links are in the HTML your server sends, before any JavaScript runs.
How to check it. Fetch a product page with the Googlebot simulator and read the HTML. Then fetch the same page as GPTBot. In Search Console, run URL Inspection, test the live URL and open the rendered HTML to compare what Google got after rendering with what the server sent.
What good looks like. The product facts are in the first response. Headless and single-page storefronts built on React, Vue or Next.js often send an empty shell and fill it in the browser. Google can render that in a second pass; Vercel and MERJ measured the wait on nextjs.org in April 2024 and found a median of 10 seconds, with the slowest 1% waiting about 18 hours. Most AI crawlers never run the JavaScript, so for them the product doesn't exist. The fix is server-side rendering, static generation, or a pre-render layer that serves crawlers a rendered snapshot of each page. How each option works, and what to fix before choosing one, is in the SPA SEO guide and on the dynamic rendering page. If the storefront sets prices or stock after a fetch, tell the renderer when the page is ready with window.prerenderReady = true, so the snapshot waits for the data.
A cheap way to run steps 1, 7 and 17 together is the ChatGPT crawler simulator: paste a product URL and read the status code, the title and the body text that OpenAI's crawlers receive. If the price isn't there, it isn't in any AI shopping answer either.
18. Allow AI crawlers and track AI shopping answers
What to check. Whether AI search crawlers can fetch your pages, and what AI assistants say when someone asks what to buy in your category.
How to check it. Read robots.txt and your CDN bot rules for GPTBot, OAI-SearchBot, PerplexityBot and ClaudeBot. Then ask ChatGPT, Perplexity and Gemini the questions your shoppers ask ("best trail running shoes under $150") and note which stores and products they name and which pages they cite.
What good looks like. OAI-SearchBot and the other AI search crawlers are allowed in robots.txt and in the CDN's bot settings, and your product facts are in the HTML they receive, as in step 17. Your main shopping questions are tracked over time across ChatGPT, Perplexity, Gemini and Claude, so you can see when your products enter or leave the answers and which review sites and roundups those answers cite. That tracking is what the AI visibility tracker does across engines, with the cited sources listed per answer. The sources are your off-site work: a product that AI answers never name is usually missing from the roundups and review pages the answers draw on.
The free ecommerce SEO checklist, condensed
Copy this list into your own tracker. Each line is one pass condition from the steps above.
Crawling and indexing
- Product, category and guide URLs return 200 to Googlebot and to AI crawlers.
- robots.txt blocks cart, checkout, account, internal search and sort URLs, and nothing you want indexed.
- No URL is blocked in robots.txt and marked noindex at the same time.
- The indexed count in the Page indexing report is close to your canonical URL count, and the excluded reasons are ones you chose.
- XML sitemaps list canonical, indexable, 200 URLs only, split by page type.
URLs and architecture
- Each product has one URL, and links, canonicals, sitemap, markup and feeds all use it.
- Variants without their own demand sit on the parent URL; variants with demand have their own indexable page.
- Filter pages with demand have clean URLs and titles; every other combination is blocked or canonicalized.
- Category pagination uses
?page=nURLs with<a href>links and self-referencing canonicals. - Out-of-stock products stay live at 200; discontinued products 301 to a successor or category; removed products return 404 or 410.
- Old URLs redirect in one hop, and internal links never point at a redirect.
- Most products sit three clicks from the homepage, and every category is linked with a real link.
- Category pages link to every product in the HTML; product pages carry breadcrumbs and related-product links in the HTML.
On-page content
- Each target search has one owner page, and the page type matches the search.
- Every category has a unique title, one H1, an intro and a meta description.
- Your top products have descriptions you wrote, with specs and sizing as HTML text.
- No duplicate titles or meta descriptions across the catalog.
- Product images have descriptive alt text, width and height, a modern format, and the main image is not lazy-loaded.
Structured data and feeds
- Each product page has one valid Product or ProductGroup block, in the initial HTML.
- Price and availability match across the page, the markup and Merchant Center.
- Category and product pages carry BreadcrumbList markup.
Speed
- Product and category templates pass Core Web Vitals on mobile.
- Unused apps and their leftover scripts are gone.
Rendering and AI search
- Product name, price, stock, reviews and related links are in the server HTML.
- URL Inspection shows Googlebot rendered the same content shoppers see.
- OAI-SearchBot and the other AI search crawlers are allowed.
- Your main shopping questions are tracked across ChatGPT, Perplexity, Gemini and Claude.
FAQ
What is an ecommerce SEO checklist? A fixed list of checks you run on an online store to find what stops its pages from being crawled, indexed and ranked: crawl rules, index coverage, product URLs, faceted navigation, on-page content, product markup, speed and rendering. Running it in order finds template problems before page-level ones.
How often should I run this ecommerce SEO checklist? Run the technical steps (1 to 8 and 14 to 17) after every theme, app or platform change and at least once a quarter. Run the index coverage step whenever you launch a collection or a batch of products. Run the content steps as part of your normal publishing work.
Is there a free ecommerce SEO checklist I can download? The condensed list above is free to copy into a spreadsheet, Notion or any tracker. Each line is the pass condition for one step in this guide.
Which step should I do first? Step 1, then step 2. If crawlers can't reach the store, or Google is indexing a fraction of your catalog, no amount of on-page work shows up in search. After those two, fix the template-level problems in steps 4 to 7, because each one affects every URL on that template.
Does the checklist apply to Shopify stores?
Yes. Shopify handles the sitemap and canonical tags for you, which covers parts of steps 3 and 4. The steps that still need your attention on Shopify are collection-path product links (step 4), filter and sort URLs (step 5), internal search in robots.txt.liquid (step 8), app scripts (step 16) and product markup printed by more than one app (step 14).
How is an ecommerce SEO checklist different from an ecommerce SEO audit? The checklist is the list of conditions; the audit is the run through them on your store, with findings and fixes. This page gives you the conditions and how to test each one. A crawl-based audit tool does the testing across every URL and groups the failures by type.
Does this checklist cover AI search? Yes, in steps 17 and 18. AI assistants read the HTML your server sends and most of them don't run JavaScript, so the rendering step decides whether your product facts exist for them at all. The tracking step tells you whether your products appear in their answers.
