Product sample: real product pages, compared source by source

On detected shops the deep scan checks up to five real product pages: visible price, JSON-LD, dataLayer and view_item, compared directly.

What gets tested

When the scan detects a shop, the deep scan finds product pages via sitemap.xml and URL patterns and loads up to five of them in a browser. On each page it collects four sources: the visible price, the Product schema (JSON-LD), the dataLayer contents and the view_item event with its GA4 request. The four individual checks of this module compare those sources against each other.

Why it matters

Product data is where shop tracking actually breaks. Templates change, prices move into new components, and the tracking keeps reporting values, just the wrong ones. A test on real product pages exposes that drift before it skews reports and bidding.

Common causes

The sitemap.xml is missing or lists no product pages; the check then finds nothing to test.
Product URLs follow no recognisable pattern (plain ID paths, say); discovery comes up empty.
Bot protection blocks the scan browser before the product page loads.
The headless browser is unavailable on the scan infrastructure at that moment.

The fix

On "not possible", start with the sitemap.xml: it should be reachable and list the product pages. Then check whether robots.txt locks the product paths for all crawlers. Once the sample runs, findings live in the four individual checks; this row only confirms what was tested.

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

How does the check know my product pages?

From two sources: the links on the scanned start page and your sitemap.xml. Both are filtered for product URL patterns (such as /products/ or /produkt/), and robots.txt rules are respected. From the matches, the check samples up to five pages.

Why a sample instead of every product?

Five product pages are enough to expose systematic errors: a missing view_item or a wrong dataLayer price almost always sits in the template, not in one product. A full crawl would take minutes and load the shop for no gain.

Does the check cover checkout and purchase?

No. A purchase event cannot fire without a real test order, and the check deliberately places none. That limit is stated in the result; checkout and purchase belong in the audit, with access to the shop.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint