This is a support-style, task-oriented audit checklist for ecommerce sites: diagnose, test, and triage technical and content SEO issues, then prioritize what to fix first. It is a one-time diagnostic workflow (not an ongoing program) focused on ecommerce-specific problems — catalog scale, faceted navigation, product variants, and feed health. It describes observable problems and how to act on them; it doesn’t promise rankings or revenue.

Prerequisites (have these ready): a verified Google Search Console (GSC) property, access to PageSpeed Insights or Lighthouse, the ability to run a site crawl (Screaming Frog or Sitebulb), access to your CMS and product feed, and a staging environment. Safety rule for the whole checklist: test changes in staging and back up templates, feeds, and redirect maps before deploying anything.

Quick Takeaways: How to Use This Checklist

What this will do: surface indexation, architecture, product/category, schema, performance, and measurement issues with exact test steps and pass/fail signals. What it will not do: guarantee outcomes, replace a full engineering review, or auto-fix anything.

Run top-line checks first, then go pillar by pillar:

  1. Indexation — GSC > Pages (Indexing) report; note “Not indexed” reasons.
  2. Server errors — crawl for 5xx and soft 404s.
  3. Core Web Vitals — PageSpeed Insights on representative product and category templates.
  4. Sitemap — confirm the XML sitemap matches crawlable, indexable URLs.

Expected result after remediation: cleaner indexing signals, fewer crawl errors, and valid structured data — measured in GSC and your crawler, not assumed. Safety rule throughout: any change to templates, canonicalization, redirects, or feeds needs a backup and a staging test first.

Quick Definitions

  • Product page: a single product detail page with price, SKU, and attributes.
  • Category page: a collection/index page listing multiple products.
  • Faceted navigation: URL filters and sorts that generate many URL permutations.
  • Crawl budget: the number of pages search engines crawl on your site over time.
  • Indexability: whether a page is allowed and discoverable for indexing.
  • Canonical tag: rel=canonical, signaling the preferred URL among duplicates.
  • Structured data / schema: JSON-LD describing entities like Product, Offer, Review.
  • Core Web Vitals: LCP, INP (formerly FID), and CLS.
  • Sitemap: an XML file listing URLs for discovery.
  • Robots directives: robots.txt and meta robots rules controlling crawl/index.
  • Duplicate content / keyword cannibalization: multiple URLs competing for the same content or query.
  • Crawl anomalies: server errors, soft 404s, and redirect loops.

Priority at a Glance: Impact vs Effort Matrix

Use this to schedule grouped sprints. Each row maps to a checklist item below and is export-ready (one row per item: Item, Impact, Effort, Test method, Owner). Owners: Dev (developer/SRE), SEO, Merch/Content.

Checklist itemImpactEffortExact test method (tool + path)Owner
Fix incorrect canonicalsHighLowView source / crawler: inspect rel=canonicalDev/SEO
Add missing URLs to XML sitemapHighLowGSC > Sitemaps; compare to crawl exportSEO
Correct meta robots/robots.txt blocksHighLowGSC > URL Inspection; fetch robots.txtDev/SEO
Required Product JSON-LD fieldsHighLow–MedRich Results Test > enter URLDev/SEO
Contain faceted-filter index bloatHighMed–HighScreaming Frog: crawl + filter URL paramsDev/SEO
Resolve 5xx / soft 404sHighMedCrawl + GSC > Pages reportDev
LCP/INP/CLS on key templatesHighMed–HighPageSpeed Insights on template URLsDev
Unique category intro + intent matchMedMedManual review vs SERP intentMerch/Content
Fix orphan / deep (>3–4 clicks) pagesMedMedCrawl > crawl-depth / orphan reportSEO/Dev
Merchant Center feed errorsMedMedMerchant Center > DiagnosticsMerch/Dev

Quick wins are the High-impact / Low-effort rows at the top. If technical blockers persist after these, see the escalation paths in Support resources.

Full Checklist — Grouped by Pillar

Each item follows the same micro-structure so it stays answerable and exportable: Purpose · Exact test steps · Expected pass/fail · Good vs bad · Quick remediation · Impact/Effort · Owner · Revert/safety.

Technical SEO: Indexation, Crawl Health, and Sitemaps

Purpose: Confirm important URLs can be crawled and indexed, and that errors aren’t wasting crawl budget.

Exact test steps: GSC > Pages (Indexing) report → review “Why pages aren’t indexed.” Run URL Inspection on a sample product and category URL. Crawl the site (Screaming Frog: Configuration > Spider) and export Response Codes; filter for 5xx and soft 404s. Compare sitemap URLs to indexable, crawlable URLs.

Expected pass/fail: Pass = key templates indexed; sitemap ≈ indexable URLs; no widespread 5xx/soft 404s. Fail = large “Discovered – not indexed/Crawled – not indexed” buckets or server errors.

Good vs bad: Good — sitemap lists only canonical, 200-status, indexable URLs. Bad — sitemap includes redirects, 404s, or noindex URLs.

Quick remediation: Remove non-canonical/error URLs from the sitemap, fix server errors, and resubmit. For unresolved crawl/indexation blockers, see Technical SEO Audit.

Impact/Effort: High / Med ·

Owner: Dev/SEO ·

Revert/safety: Back up the current sitemap and any config before changes; deploy via staging.

Expected results / success criteria: Indexing reports stabilize, sitemap and index counts converge, and server-error counts trend toward zero in GSC and your crawler.

Robots Directives & Canonicalization

Purpose: Ensure you aren’t accidentally blocking or de-duplicating important pages incorrectly.

Exact test steps: Fetch https://yoursite.com/robots.txt and review Disallow lines. In a crawler, check meta robots and X-Robots-Tag headers. Inspect rel=canonical on product variants and filtered URLs. In Screaming Frog: Configuration > Spider > Respect Noindex off, so you can see noindexed pages during the audit.

Expected pass/fail: Pass = canonicals point to preferred URLs; no critical pages disallowed/noindexed. Fail = canonical loops/chains, self-referencing errors, or blocked key templates.

Good vs bad: Good — variant URLs canonicalize to the main product; filters canonicalize to the clean category. Bad — every variant self-canonicalizes and competes, or canonicals point to redirected URLs.

Quick remediation: Correct canonical targets and remove erroneous Disallow/noindex.

Revert/safety: Save the existing robots.txt and template snippets; change one rule at a time and re-test in staging.

Impact/Effort: High / Low ·

Owner: Dev/SEO.

Faceted Navigation, Filters, and Pagination

Purpose: Prevent filter/sort permutations from creating index bloat and duplicate content.

Exact test steps: Crawl and sample filter URLs (e.g., ?color=, ?sort=) to measure permutations; in GSC > Pages, watch for inflated “Crawled – currently not indexed.”

Expected pass/fail: Pass = low-value filter URLs aren’t indexable. Fail = thousands of near-duplicate filter URLs indexable.

Good vs bad: Good — a curated set of valuable facets is indexable; the rest are noindex or canonicalized. Bad — every filter combination is a live, indexable URL.

Quick remediation: Short-term — noindex low-value filter pages and handle obvious parameters. Long-term — server-side canonicalization or an AJAX filter UI that doesn’t expose indexable URLs.

Platform note: behavior differs across Shopify, Magento, and WooCommerce (and filter apps) — confirm before rollout. For catalog-scale architecture, see Enterprise SEO Services.

Impact/Effort: High / Med–High ·

Owner: Dev/SEO ·

Revert/safety: Stage and monitor indexation for several weeks.

Product Page Optimization (Content, Variants, and Schema)

Purpose: Ensure product pages are unique, correctly canonicalized across variants, and carry valid Product schema. Exact test steps: Spot-check for unique descriptions (not duplicated manufacturer copy). Review variant URL handling and canonicals. Validate Product JSON-LD in the Rich Results Test for required fields: name, image, price, priceCurrency, availability, sku. Expected pass/fail: Pass = required fields present, no critical errors. Fail = missing price/availability or invalid types. Good vs bad: Good — one canonical product URL with complete, valid Offer data. Bad — many indexable variant URLs with thin, duplicated content. Quick remediation: Add missing schema fields and de-duplicate content. A minimal valid pattern:

json

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example Product",
  "image": ["https://yoursite.com/img/example.jpg"],
  "sku": "SKU-123",
  "offers": {
    "@type": "Offer",
    "price": "29.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Example only — populate from real product data and validate before deploying; do not hardcode placeholder values in production. For product/category content patterns, see SEO content strategy. Impact/Effort: High / Low–Med · Owner: Dev/SEO/Merch · Revert/safety: Edit schema in a template copy; validate in staging first.

Category Pages (Intent, Intro Content, and Pagination)

Purpose: Make category pages match search intent and link to the right products and facets. Exact test steps: Compare H1/title to the dominant SERP intent for the head term. Check for unique intro copy (placed so it doesn’t push products far down). Inspect pagination (rel handling / “view all” logic) and internal links to top SKUs. Expected pass/fail: Pass = clear intent match, concise unique intro, crawlable pagination. Fail = duplicated/boilerplate intros or paginated pages competing with page 1. Good vs bad: Good — a short curated intro plus prominent products and links to key facets. Bad — a wall of keyword-stuffed text above the fold and no internal links. Quick remediation: Add curated intro text, fix pagination handling, and link to top SKUs/facets. Impact/Effort: Med / Med · Owner: Merch/Content · Revert/safety: Keep prior copy versioned in the CMS.

Structured Data, Feeds, and Merchant Center Checks

Purpose: Keep Product/Offer/Review markup and the product feed valid so listings stay eligible for rich results. Exact test steps: Run key URLs through the Rich Results Test and Schema Validator. In GSC > Enhancements, review Product/Merchant listings for errors. In Google Merchant Center > Diagnostics, review feed disapprovals (price mismatch, availability, GTIN/SKU mapping). Expected pass/fail: Pass = schema valid; feed diagnostics clear or non-critical. Fail = mismatched price/availability between page and feed, or invalid GTIN/SKU. Good vs bad: Good — page price/availability matches the feed and schema. Bad — schema says InStock while the feed/page disagree. Quick remediation: Align price formats and availability across page, schema, and feed; fix GTIN/SKU mapping; monitor GSC after deploy. Impact/Effort: Med / Med · Owner: Merch/Dev · Revert/safety: Back up the feed template; change mappings incrementally.

Internal Linking & Site Architecture (Crawl Depth, Orphan Pages)

Purpose: Keep important products within a shallow crawl depth and eliminate orphan pages. Exact test steps: Crawl and review crawl-depth and orphan reports (Screaming Frog/Sitebulb; cross-reference with GSC and analytics URL lists to find orphans). Flag key pages deeper than 3–4 clicks. Expected pass/fail: Pass = priority products reachable in ≤3–4 clicks; no important orphans. Fail = key SKUs orphaned or buried. Good vs bad: Good — categories link to top products; breadcrumbs and curated links shorten paths. Bad — products only reachable via search or deep pagination. Quick remediation: Add curated internal links and breadcrumb schema; surface deep SKUs from relevant categories. For catalog-scale architecture and faceted navigation, see Enterprise SEO Services. Impact/Effort: Med / Med · Owner: SEO/Dev/Merch.

Performance & Core Web Vitals

Purpose: Verify representative templates meet Core Web Vitals thresholds. Exact test steps: Run PageSpeed Insights/Lighthouse on representative template URLs (home, a category, a product). Record LCP, INP (or FID where INP isn’t available), and CLS for mobile and desktop. Cross-check field data in GSC > Core Web Vitals. Expected pass/fail: Pass = LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 (field data) on key templates. Fail = templates in “Needs improvement”/”Poor.” Good vs bad: Good — optimized hero image, fast server response, reserved image space. Bad — large unoptimized hero, heavy main-thread JS, layout shifts on load. Quick remediation: Optimize/serve hero images responsively (LCP), reduce/defer unused JS (INP), reserve dimensions for media (CLS). QA across templates and devices. Impact/Effort: High / Med–High · Owner: Dev · Revert/safety: Roll out template by template; keep a performance baseline to compare against.

Measurement, Monitoring, and Alerting

Purpose: Detect regressions early instead of discovering them in a traffic drop. Exact test steps: Enable GSC email alerts for Coverage/Indexing changes. Schedule recurring crawls (weekly). Configure a PageSpeed Insights API check on key templates. Set analytics alerts for organic-traffic or conversion drops on key segments. Expected pass/fail: Pass = alerts active and routed to an owner. Fail = no automated monitoring. Minimal monitoring examples: GSC — enable alerts in the property’s notification settings and review the Indexing report weekly. PageSpeed Insights API — run weekly against 3–5 representative template URLs and log scores over time. Analytics — alert when organic sessions or conversion rate on key templates drop beyond a set threshold week-over-week. Impact/Effort: Med / Low–Med · Owner: SEO/Dev.

Platform-Specific Notes: Shopify, Magento, WooCommerce

Keep platform guidance conservative and confirm in staging — defaults and apps change.

  • Shopify-specific: Check theme templates for correct canonical handling of product variants; confirm filter apps don’t expose indexable filter URLs; verify the Shopify sitemap includes expected product/collection URLs; ensure Product JSON-LD is present in the Liquid template. Theme/app updates can reintroduce issues — re-test after updates. For theme pitfalls, see Shopify SEO Services.
  • Magento: Watch for layered-navigation parameters creating indexable permutations; confirm canonical settings for products in multiple categories; validate sitemap configuration.
  • WooCommerce: Review default product/category permalinks and pagination; confirm an SEO plugin isn’t emitting conflicting canonicals or duplicate schema.

Treat these as parity checks, not Shopify-only — each platform exposes faceted/canonical issues differently.

How to Run a Focused Ecommerce SEO Audit — Step by Step

One-day quick audit (top-line triage):

  1. GSC > Pages (Indexing): record top “not indexed” reasons.
  2. Crawl the site; export response codes and flag 5xx/soft 404s.
  3. PageSpeed Insights on three template URLs (home, category, product).
  4. Validate Product schema on two product URLs (Rich Results Test).
  5. Sample 10–20 filter URLs for index-bloat risk.
  6. Fill the Impact vs Effort table; schedule High-impact/Low-effort items first.

Deeper multi-day audit: add full crawl-depth/orphan analysis, category-intent review, Merchant Center diagnostics, internal-link remediation, and template-level Core Web Vitals work. Recommended artifacts: the priority table and an annotated crawl export. For help sequencing and scoping the work, see SEO consulting.

Troubleshooting Matrix: Symptoms → Immediate Checks

Pattern for each row: symptom → 3–5 immediate tests → remediation.

  • Product pages not indexed → GSC URL Inspection; check robots/meta robots; check rel=canonical; confirm in sitemap; check 200 status & internal links → unblock, fix canonical, add to sitemap, fix errors, request indexing.
  • Index bloat from filters → crawl for parameter URLs; check GSC “Crawled – not indexed”; count indexable facets → noindex/canonicalize low-value facets; plan server-side or AJAX handling; monitor.
  • Rich results missing after schema fix → Rich Results Test; GSC > Enhancements; confirm page indexable/crawled; compare rendered HTML; allow reprocessing time → fix remaining markup errors; re-validate; gather examples before escalating.
  • Sudden organic drop → check GSC Indexing & manual actions; diff recent deploys; re-crawl for new noindex/canonical/redirect changes; check Core Web Vitals field data → roll back the offending change in staging, then redeploy.
  • Duplicate/cannibalized URLs → crawl for duplicate titles; map query→URL; check canonicals → consolidate with canonicals/redirects; differentiate or merge content.

Support Resources and Next Steps

These are escalation paths for unresolved technical issues, not sales prompts — use them only when a blocker can’t be resolved internally.

FAQ

1. How do I quickly check why product pages aren’t indexed?

  1. GSC > Pages (Indexing): filter affected URLs and note the reason.
  2. Run URL Inspection on a sample product (view indexing status + rendered HTML).
  3. Confirm not blocked by robots.txt or meta robots.
  4. Check rel=canonical for wrong canonicalization.
  5. Confirm the URL is in the XML sitemap and linked from category pages. Fix: unblock, correct canonical, add to sitemap, fix server errors, request indexing.

2. What if faceted filters create thousands of indexable URLs?

  1. Crawl and sample filter URLs to measure permutations.
  2. Short-term: noindex low-value filter pages; handle obvious parameters.
  3. Long-term: server-side canonicalization or an AJAX filter UI that doesn’t expose indexable URLs.
  4. Always stage changes and monitor indexation after deploy.

3. How do I test whether my Product structured data is valid?

  1. Paste the URL into the Rich Results Test and the Schema Validator. 2) Confirm required JSON-LD fields: name, image, price, priceCurrency, availability, sku. 3) Resolve errors. 4) Re-validate in Rich Results Test and GSC > Enhancements. Pass = no critical errors.

4. Which Core Web Vitals should I prioritize for product pages?

Prioritize LCP, INP (or FID where INP isn’t available), and CLS. Run PageSpeed Insights on representative product/category templates, compare to thresholds, then fix: hero image + server response (LCP), main-thread JS (INP), reserved media dimensions (CLS). Test across templates and devices.

5. How should I prioritize fixes with limited engineering resources?

  1. Fix High-impact/Low-effort first (canonicals, sitemap, meta robots, critical schema).
  2. Then High-impact/High-effort (template rewrites, architecture).
  3. Then Medium/Low items.
  4. Use the Impact vs Effort table to group sprints and assign owners.

6. Are there Shopify-specific checks I should run?

  1. Inspect theme templates for correct canonical handling of variants.
  2. Verify filter apps/pagination don’t expose indexable filter URLs.
  3. Confirm the Shopify sitemap includes expected product/collection URLs.
  4. Ensure JSON-LD is present in Liquid templates. Re-test after theme/app updates.

7. What if rich results don’t appear after fixing schema?

  1. Confirm markup passes the Rich Results Test.
  2. Check GSC > Enhancements processes without errors.
  3. Confirm pages are indexable and re-crawled after changes.
  4. Allow reprocessing time.
  5. If it persists, compare rendered HTML on staging and gather examples before opening a ticket.

8. Which monitoring should I set up to detect future regressions?

  1. Enable GSC Coverage/Indexing alerts.
  2. Schedule weekly crawls.
  3. Configure a PageSpeed Insights API check (e.g., weekly) on 3–5 representative templates.
  4. Set analytics alerts for organic-traffic/conversion drops on key segments.

9. How do I use the downloadable checklist template?

The checklist mirrors the pillar items as one row each. Export/import: open the Google Sheet, duplicate it to your workspace (File > Make a copy), then fill the per-item fields — Status, Test result (pass/fail), Owner, Impact, Effort, Notes. For a print run, use the single-page PDF, which lists top-level items only. Keep the editable sheet as your working audit log and re-run it each quarter.