Begin with infrastructure checks because a useful product or category page cannot compete as intended if search engines cannot reliably discover, render, consolidate, or index it.
Core Web Vitals and page weight
Evidence required: field data where available, repeatable lab tests for representative category and product templates, and a breakdown of the images, scripts, fonts, and layout behavior affecting LCP, INP, and CLS.
Pass condition: representative templates have documented performance evidence, no unexplained regression, and a known component or resource owner for material bottlenecks. Fail condition: important templates are slowed or destabilized by media, JavaScript, third-party code, or layout movement and the cause cannot be traced to an accountable component.
Severity: high when the affected template is reused across a substantial part of the catalog or blocks normal shopping behavior. Owner: frontend engineering or the performance owner. Corrective action: resize and compress media, defer or remove avoidable script work, reserve layout space, and correct the specific resource or component identified by the evidence.
Validation: rerun the same template tests and compare Google Search Console and PageSpeed Insights evidence after deployment so the before-and-after result is attributable to the change.
Product structured data with AggregateRating
Evidence required: rendered JSON-LD, the visible product details it describes, the source of any rating information, and current eligibility checks for the properties used.
Pass condition: markup reflects content users can see, identifies the same product represented on the page, uses supported properties appropriately, and has no critical validation error. Fail condition: markup contains hidden or inaccurate facts, describes a different variant than the visible page, includes rating data that cannot be substantiated, or fails required validation.
Severity: high on product templates because one implementation defect can repeat across many catalog URLs. Owner: SEO and ecommerce development. Corrective action: align markup with the visible product record, remove unsupported properties, and correct the template logic producing the mismatch.
If ratings come from customer reviews, keep review collection separate from markup eligibility and do not filter requests based on positive sentiment. Validation: retest affected examples against Schema.org references and Google Rich Results Test, then review Google Search Console reporting where it applies. Passing validation confirms implementation quality, not a guaranteed rich result or ranking change.
Faceted navigation for material and size
Evidence required: a crawl export of filter URLs, indexability directives, canonical targets, sitemap presence, internal links, parameter patterns, and examples of filter combinations that shoppers can reach.
Pass condition: indexable filter destinations are deliberately selected because they provide distinct search and shopping value, while low-value combinations do not expand into uncontrolled duplicate or near-duplicate crawl paths.
Fail condition: ordinary filtering generates large families of crawlable or indexable URLs with little distinct content, conflicting canonicals, or no clear search purpose. Severity: critical when the pattern consumes crawl attention across major mattress categories or creates competing indexable pages.
Owner: technical SEO and ecommerce platform development. Corrective action: document which facets deserve standalone destinations, consolidate or restrict low-value combinations, align canonical and internal-link behavior, and preserve usable shopping filters for customers.
Validation: recrawl the same category set with Screaming Frog or Sitebulb and compare indexable URL counts, canonical targets, internal links, and parameter behavior to the baseline export.
Canonical handling for product variants
Evidence required: a variant URL inventory, each canonical target, sitemap inclusion, internal-link destinations, selectable size or firmness behavior, and indexation samples.
Pass condition: canonical tags represent the intended consolidation strategy and agree with navigation, internal links, and sitemap signals without hiding a variant page that contains meaningfully distinct information shoppers need.
Fail condition: variants alternate between conflicting targets, self-canonicalize unintentionally, point at unavailable products, or consolidate pages whose content and purchase options materially differ.
Severity: high where common size, firmness, or configuration choices create competing URLs for the same product family. Owner: technical SEO and platform development. Corrective action: define the intended primary URL for each variant pattern, update canonical logic, and make internal links and sitemap entries support that decision.
Validation: inspect deployed source on representative variants, sample indexation behavior, and compare findings in Ahrefs or Semrush with direct page checks after release.
Breadcrumb structured data
Evidence required: visible breadcrumbs, internal navigation paths, and corresponding markup on category, sub-category, and product templates. Pass condition: breadcrumb labels, destinations, and hierarchy describe the path a shopper can actually navigate, and the markup validates without critical errors.
Fail condition: structured data invents a hierarchy, omits material levels shown to users, links to inconsistent destinations, or disagrees with the visible breadcrumb trail. Severity: medium unless the defect is template-wide and creates widespread hierarchy conflicts.
Owner: SEO and development. Corrective action: choose the intended navigable hierarchy, synchronize visible breadcrumbs and internal links, then make the markup describe that same structure. Validation: test affected templates after deployment and review Google Search Console observations for consistency rather than treating breadcrumb markup as a guaranteed visibility gain.