Product Page Evidence Checklist Template

Product Page Evidence Checklist (fill-in)

When to use: One row per claim: value shown, source of truth, feed value, structured data property, owner and status, with a completion check.

Product page evidence checklist

One row per claim the page makes. Every row needs a source of truth, and the page, the feed and the structured data must all say the same thing.

Per-row detail (fill for every row)

• Specification source: [document or system, version, date checked]
• Where the claim appears: [title, bullets, spec table, image, FAQ, JSON-LD]
• How it updates: [live from system / nightly sync / manual edit]
• Mismatch found: [page says X, feed says Y, markup says Z]
• Fix: [change the page / change the feed / change the markup / change the source]
• Date checked: [YYYY-MM-DD]

Next action

• Owner: [name] - action: [fix the first row marked Fix or Missing] by [date]
• Data owner: [merchandising or ops lead] - action: confirm each source of truth is the system that really changes first
• Developer: [name] - action: [update the JSON-LD template so it reads from the same fields as the page]

Completion check

• Every claim on the page has a named source of truth and a checked date.
• Price, currency and availability are the same on the page, in the feed and in the markup.
• Every variant has its own ID, and its URL shows the right image, price and stock.
• Shipping and returns on the page match the settings Google reads first.
• Nothing in the structured data is missing from the visible page.
• No row is still marked Fix or Missing without an owner and a date.

Source-of-Truth Register

When to use: Name the one system that owns each product fact, who can change it and how the page gets it.

Name one source of truth per fact

Most product page errors start when two systems hold the same fact. Pick the one that changes first. Everything else, including the page, should copy from it.

Specification claims: what counts as a source

• Good: the manufacturer's spec sheet with a version or date, your own measured value with who measured it, a certificate you hold.
• Weak: a competitor's listing, an old catalogue, a marketplace copy of your own page.
• Not a source: "we think", a supplier email with no attachment, an AI-written description.

Rules

• If the page and the source disagree, fix the source first, then let the page update.
• Copy written by hand (bullets, FAQs, image text) needs its own check. It does not update when the data changes.
• Record the date you checked. A spec that was true last season may not be true now.

Rewrite thin or copied spec copy with the Content Optimizer, then come back and log the source for every number it keeps.

Structured Data Consistency Check

When to use: Pick product snippet or merchant listing markup, then check each property against what the page shows.

Product snippet or merchant listing?

Google has two kinds of Product structured data. Pick the right one before you check properties. Checked on Google Search Central on 7 November 2026.

Check each property against the page

What Google's guidelines say

• Don't mark up content that is not visible to readers of the page.
• Structured data must be a true representation of the page content.
• Google may try to verify merchant listing product data before showing it in search results.
• If you sell in several currencies, use a distinct URL per currency.

Build the JSON-LD with the Schema Markup Generator. For a full pre-launch markup review, use the Structured Data Validation Brief Template.

Variants, Availability and Shipping Facts

When to use: Check variant IDs and URLs, stock values and where Google reads your shipping and return policies.

Variants

Variants are where pages drift. The size picker says one thing, the markup says another. Check every variant, not just the default one.

• Group ID: [productGroupID or inProductGroupWithID] - Google requires one of them. If both are set, they must match.
• Variant IDs: [one sku or gtin per variant] - each variant needs a unique ID in its markup.
• Variant URLs: [?size=26] - each variant must be preselectable with a distinct URL, showing its own image, price and availability.
• Varies by: [size, color, material] - variesBy and hasVariant are recommended on the ProductGroup.
• Single page or one page per variant: [single / multi-page] - on multi-page setups, each page needs full, self-contained markup.

Availability

• Stock message shown: [In stock / Only 3 left / Pre-order / Out of stock]
• schema.org value used: [InStock / LimitedAvailability / PreOrder / BackOrder / OutOfStock]
• Feed value: [in_stock / out_of_stock / preorder / backorder]
• Sync interval between inventory, page and feed: [live / hourly / daily]

Shipping and returns facts

Google recommends one store-wide shipping policy and one return policy under Organization markup. Use offer-level shippingDetails or hasMerchantReturnPolicy only to override them for some products.

Google uses this order, strongest first: Content API for Shopping settings, then Merchant Center or Search Console settings, then product-level markup, then Organization markup.

• Shipping rate and destination shown: [rate, countries]
• Handling time and transit time shown: [days]
• Return window, method and fees shown: [days, mail / in store, free or paid]
• Where Google reads them: [Search Console / Merchant Center / Organization markup / Offer markup]
• Do all of them say the same thing? [Yes / No, list the gap]

If you set shipping in Search Console and in markup, Google uses only Search Console. Fix the settings first, not just the JSON-LD.

Merchant Center and Feed Match Audit

When to use: Compare price, currency, stock and IDs across the page HTML, the feed and the JSON-LD.

Page vs feed vs markup audit

Merchant Center compares your product data with the landing page. A mismatch can get a product disapproved, so audit the three sources side by side.

What Merchant Center Help says

• Prices in the HTML need to match the prices uploaded in Merchant Center exactly.
• Googlebot reads the HTML your server returns. A price added with JavaScript after the page loads can trigger an error.
• Google uses structured data to understand prices on landing pages, so wrong markup can cause a mismatch.
• Availability in your product data must match the landing page. Too many products with wrong availability can lead to account suspension.

Common causes to check

• The feed updates once a day, but stock changes every hour.
• A sale price shows on the page, but the feed still has the old price.
• The JSON-LD shows the default variant while the page shows another one.
• Prices are set by JavaScript, so the HTML has no price or an old one.

Crawl your product URLs with the Website Audit to find pages with missing or broken markup, then check titles and descriptions with On-Page SEO.

Spreadsheet Header (CSV)

When to use: A paste-ready header row and allowed values to run the checklist in Google Sheets or Excel.

Paste-ready spreadsheet header

Paste this row into cell A1 of Google Sheets or Excel, then split text to columns by comma. One row per claim per product URL.

product_url,variant_sku,claim_type,value_on_page,source_of_truth,source_ref,feed_value,markup_property,markup_value,where_google_reads_it,result,fix,owner,status,date_checked

Allowed values

• claim_type: spec, price, sale_price, currency, availability, variant, shipping, returns, rating, review, image
• where_google_reads_it: content_api, merchant_center, search_console, offer_markup, organization_markup, page_only
• result: match, mismatch, missing_on_page, missing_in_feed, missing_in_markup
• status: ok, fix, missing, blocked

Sheet tips

• Add data validation dropdowns on claim_type, result and status.
• Use a formula that flags a row when value_on_page, feed_value and markup_value are not all equal.
• Filter by status = fix and sort by owner for the weekly review.
• Keep source_ref as a link to the spec sheet, settings screen or policy page.

Worked Example (fictional cookware store)

When to use: A filled-in checklist for an invented skillet with three sizes, four mismatches and the fixes.

Worked example: Cobblemarsh Kitchen, Thornquay skillet

Example only. Cobblemarsh Kitchen, the Thornquay skillet, Brindlefen Foundry and every URL, price and finding below are invented to show a filled-in checklist.

Page: /skillets/thornquay-cast-iron/ with three sizes (20, 26 and 30 cm). The store sells directly, so it uses merchant listing markup.

What the checklist found

• The weight came from an old catalogue. The page now shows 2.4 kg and cites spec sheet v3.
• The sale price was added by JavaScript after load, so the HTML and JSON-LD kept the old price, and the feed was never updated. The price is now rendered on the server from the ERP.
• The JSON-LD always used the stock status of the 20 cm size. Each variant now reads its own stock.
• The page copy promised faster dispatch than the shipping settings. The copy now says 2 to 3 days.

Why this works

• Each fact now has one owner and one system, so the next change updates everywhere.
• The fixes went to the source and the template, not just one page.
• Shoppers see the same promise on the page, in Google and at checkout.

Need product pages and data feeds built this way from the start? See ecommerce development or book a free consultation with Anatolii Ulitovskyi.