Resolution Layer Case Study · Read & Diagnose
Guitar product pages.
A preliminary read of product pages from a large online musical-instrument retailer — where the page says one thing about paying over time and its source says another, and where a price sits in the data a search engine reads.
This is a real EKOM catalog analysis, with the client's identity removed. The client is a large online musical-instrument retailer that sells through its own product pages. EKOM opened two of its guitar product pages and one listing page in an ordinary browser, and read what each page shows a shopper, what its source carries, and the structured data embedded in it. This is two pages: it supports examples, and every share below is a share of those two pages.
The same wrong values appeared on both pages, which is why two pages are informative. Whether they repeat across the catalog is an inference from two, not a count, and it is the first question for the retailer's web team.
A shopper reads a page. A search engine and an assistant read what the page says about itself, and where the words and the fields disagree, or a field is missing, the machine has nothing to go on.
Brand names, product names, prices and part numbers are not attached to the findings here, because on a retailer's catalog a brand, a product and a price together can identify the retailer. Nothing was supplied by the retailer and nothing has been confirmed with it; each finding is a lead until someone with the product system agrees.
What's inside
- At a glance — the findings, the severity split and how the read was done.
- A hidden payment no product could carry — what the page source says about paying over time.
- A price a search engine cannot read — and one point of context from the listing page.
- Where it traces back, and what's next — the two upstream sources the findings may collapse into.
Nothing was supplied and no internal system was touched. Everything below was read from the retailer's own public pages.
The two findings
Theme
What it is
Severity
Financing that says different things
The source of both pages carries a hidden monthly payment that no guitar could carry; the shopper is shown a different, low payment
critical
A price that is not machine-readable
On both pages the price is in the product data under a key search engines do not read; no SKU and no barcode
high
How EKOM read these pages
1
Open
Two guitar product pages and one listing page, each opened as a shopper would open it.
Each page was read once.
→
2
Read
The visible page, the page source, and the structured data inside each product page.
Each value is traced to the page it came from.
→
3
Check
The words on the page against the source and the data behind them, and each listed payment against its price.
2 findings, 2 sources.
Signals from two pages, not a verified defect list. Some may prove intentional, which is why each is tied to the values behind it.
A hidden payment no product could carry.
The lead finding is about what the page source says about paying over time, as against what the shopper is shown.
Critical · Financing
On both pages, the source carries a four-figure monthly payment over 48 months, hidden from view.
Each product page's source contains a financing block marked hidden, which the page's own script later replaces with the real offer. The hidden text is identical on two products at different prices, and multiplied out it comes to roughly sixty thousand dollars, not the price of a guitar. A shopper never sees it. A reader that takes the page's source without running its scripts, such as a crawler or a shopping assistant, is told that a guitar costing a few hundred dollars costs four figures a month.
Where
What it says
Verdict
The visible page
A low monthly payment over 36 months
shown
The page source
A four-figure monthly payment over 48 months, hidden
disagrees on 2
A third message
A separate instalment widget says something different again, and none of the three is in the data.
Beside the financing line, each page shows a lender widget with its own monthly figure. The hidden text, the visible line and the widget each describe the same product differently, and none appears in the page's structured data, so a machine reader cannot tell which one is real.
One question stays open: the retailer's web team can say whether the hidden text is a fixed placeholder value, in which case it would be on every product page that carries it.
A price a search engine cannot read.
The second finding is about how the price is published in the product data. Below it, one observation from the listing page that is not a finding.
High · Product data
Both pages publish the price under a key that search engines do not read.
Each page carries schema.org product data with price, availability and condition, but under the key Offers rather than offers. Schema.org property names are case-sensitive, so a reader that follows the standard finds a product with no price and no availability. The same data carries no SKU and no barcode; only the manufacturer part number is present.
Field
What the 2 pages hold
Verdict
Offer key
Capitalized on both pages, holding price, availability and condition
wrong case on 2
SKU and barcode
None on either page
absent on 2
Part number
Present on both
present
Context · not a finding
On the listing page, financing terms follow the brand, not the price.
The listing page showed two financing styles side by side: a 6-month term on the two dearer products from one brand and a 36-month term on the two cheaper products from another. Every payment on the page is the price divided by the months, rounded up to the next dollar, so the arithmetic is sound. The pattern points to brand-specific promotions, and that rule is the retailer's to confirm.
What is strong. The price in the page markup matched the price in the product data on both pages, and the data otherwise carries name, brand, category, description, image, part number, an aggregate rating and reviews. The key is the problem, not the data.
Two findings may be one story. They look like two upstream sources of wrong data, and a source shows where else to look. Each tell below is a pattern in the data; the source is EKOM's reading of it.
A placeholder value in the financing data that ships in the source
The tell: the same hidden text on two products at different prices, replaced by the real offer once the page's script runs.
Product data written to a pattern and not checked against the standard
The tell: the same capitalized key on both pages with the price intact under it, and no SKU or barcode on either.
Correcting two pages corrects two pages. A wrong value is quick to fix once found; at catalog scale, finding it is the problem.
What this means, and what's next.
A shopper starts with the offer on the page. A search engine starts with the product data. An assistant starts with the fields. On these pages the first has what it needs, and the other two are reading a page that says something else.
The cost follows the field. A price under the wrong key leaves a search result and a shopping feed with a product and no price. A hidden payment of four figures a month beside a visible low one puts two different answers in front of any reader that does not run the page. A second clock runs underneath: more comparisons now start with an assistant, and an assistant reads the fields.
This pass read and diagnosed. The same structural understanding powers what follows — turning a diagnosed catalog into one a shopper, a search engine and an assistant can all read the same way.
1 · Apply the corrections the page already answers for itself
Carry the offer the page already shows the shopper in the slot where the placeholder sits, and use the key name the standard expects for the price. Approved as patterns, not page by page.
2 · Settle the questions only the business can answer
Which financing offer is the offer of record, which identifiers exist and should be published, and what rule sits behind the terms by brand come from inside the business.
3 · Hold the line at intake
Keep ongoing intelligence where product data meets the page, so the next page published with a placeholder in its source, or a price under the wrong key, is caught the day it goes live.
This is how EKOM moves a catalog from insight to impact —
and helps keep pages saying what the data says as the business grows.