Competitor Product Schema Analysis: Missing and Excess

To read a competitor's product structured data, open the public product page, pull out the JSON-LD (or Microdata or RDFa) blocks, and set each field against the required and recommended lists in Google's Product and Offer documentation. Mark each field as present, missing, excess or doubtful. The result is a gap list for your own product template, not a recipe for copying someone else's markup. It suits ecommerce SEO leads, marketplace template owners and developers who maintain product page markup.

Example scenario: a mechanical watch retailer. The retailers, pages and values are invented.

What a rival's markup can and cannot tell you

Markup on a competitor's page is a public record of what that team's template emits. You can see whether it states a price, an availability value, shipping and return terms, identifiers, brand and several image URLs. That is useful comparison data because your own template is built from the same field vocabulary.

Questions the page can answer

• Is this a page where a shopper can buy the product, or a review or referral page?
• Does it carry all required fields for the experience it appears to target?
• Which recommended fields are filled: brand, color, size, identifiers, condition, shipping, returns?
• Do the price and stock state in the markup match what a visitor sees on the page?

Questions it cannot answer

Whether the rival earned a rich result, for which queries, and what the markup did for its traffic cannot be read from a page. Your own Search Console reports cover only your own property. The documentation has no statement on how a rival's field choices affect its results, so any claim of that kind would be a guess.

Getting the markup out of the page

Google supports three formats: JSON-LD, Microdata and RDFa, and recommends JSON-LD. A rival page can use any of them, so identify the format first.

Page source

Open the product page in a normal browser session and view its source. Search for script elements whose type is application/ld+json. One page can hold several blocks, such as Product, BreadcrumbList and Organization. Copy the Product block into a text file and indent it so that the nested Offer and Brand objects are easy to read. One page opened by hand is enough. Bulk crawling, logging in to reach pages, or any automation that breaks the site's terms of use is outside this method.

Rendered HTML

Some stores add the markup with scripts after the page loads. If page source shows no block, open the elements panel in the browser's developer tools and search the rendered document. The difference is itself a finding, because Google recommends Product markup in the initial HTML for merchants who want the best results in shopping experiences.

Whether to name a validation tool

Google's merchant listing documentation (Opens in a new tab) tells you to validate your code with the Rich Results Test. The documentation has no statement on using that tool against a competitor's page. Practical suggestion: make browser inspection the method for rival pages and keep the named tool for your own templates, where its output is about your code and cannot be mixed up with a guess about someone else's site.

Required fields first, then the recommended ones

The merchant listing documentation gives the backbone for the comparison. On Product, name, image and offers are required, and offers must be a nested Offer. Inside the Offer, price (or priceSpecification.price) and priceCurrency (or priceSpecification.priceCurrency) are required. Everything else is recommended.

Give each rival its own column and fill the cells with one of four words: present, missing, excess or doubtful. Excess means the page does not show the thing the field describes. Doubtful means the value contradicts the visible page.

Reading the Offer block

The price line is the easiest to misread. Merchant listing experiences require a price greater than zero, while product snippets do not. The active price can sit directly on the Offer or inside priceSpecification. When both are present, Google uses offers.price and ignores priceSpecification. If a rival carries both with different numbers, record it as an inconsistency.

The documentation lists ten availability values, among them InStock, OutOfStock, PreOrder and SoldOut, and asks for no more than one. itemCondition has three values: NewCondition, RefurbishedCondition and UsedCondition, again with one allowed. For priceValidUntil, the page warns that a listing may not display when the date is in the past. A past date on a rival page is worth a note, but what it does to that rival is not something the page tells you.

One currency, one URL

Where a product is sold in several currencies, the documentation asks for a distinct URL per currency. If a rival's page marks up euro and dollar prices at one address, write "currency per URL: no" in your table. It is a checkpoint for your own template, not a verdict on the rival.

Identifiers, images and brand

Watch pages are identifier-heavy, so the identifier rules matter. For sku, give at most one value, with no whitespace characters, and ASCII is recommended. For gtin, use the numeric form; the URL form is not supported. Use the narrowest GTIN property that applies. For brand.name, include at most one brand name. A rival page that puts two brand names in one field, or a sku with a space in it, shows markup that departs from the documentation and should not be imitated.

For image, Google prefers pictures that show the product clearly. For best results it recommends several high-resolution images, with width times height of at least 50 thousand pixels, in 16x9, 4x3 and 1x1 ratios. Image URLs must be crawlable and indexable, and the images must represent the marked-up content. Note the number of ratios a rival offers and record it next to your own.

Example scenario: three mechanical watch pages

Example scenario: you compare your own watch page with two independent retailers, Retailer A and Retailer B. All values are invented.

The reading: itemCondition is documented as recommended and your catalog knows which watches are pre-owned, so it goes on the list. mpn is recommended and your data holds reference numbers, so it goes on the list too. Nobody fills gtin, and if your catalog has no GTIN data, the documentation gives no reason to invent one. Retailer A's sku with a space breaks the stated rule, so you do not copy it. Retailer A's three image ratios match the documentation's advice, which is a reason to prepare more ratios. The return policy is a bigger design question.

Excess and invisible fields

Google's general structured data guidelines (Opens in a new tab) say not to mark up content that is not visible to readers of the page. Their example is a performer: if the JSON-LD describes one, the HTML body must describe the same one. Irrelevant or misleading content, such as fake reviews, is also off limits. A violation of the quality guidelines can prevent correct markup from showing as a rich result, and a manual action can make the page lose eligibility for rich results.

Flag a field as doubtful when you see any of these on a rival page:

• The marked-up price differs from the price on screen.
• An aggregateRating is present but the page shows no reviews.
• The product name in the markup is a different model from the page heading.
• The image URL points to a picture that does not show the product.

Absence from Google's list does not make a field excess. The guidelines ask for the narrowest applicable schema.org type and property names, so a valid property outside the documented list can be legitimate. Reserve the excess label for fields the visible page does not support.

Page type fit, variants and script-built markup

Only pages where a shopper can buy the product are eligible for merchant listing experiences, not pages that link out to other sites selling it. Product rich results support pages focused on a single product or on variants of one product, and the documentation's counter-example is that "shoes in our shop" is not a specific product. Variants count when each has a distinct URL. The documentation recommends adding markup to product pages rather than to pages that list products or a category.

When a rival's category page carries Product markup, write "page type mismatch" in the table. The rule applies to you as well: mark up product pages, not the listing pages that lead to them.

Script-generated markup

For merchants optimizing for all types of shopping results, Google recommends putting Product structured data in the initial HTML. Dynamically generated markup can make shopping crawls less frequent and less reliable, which is a concern for fast-changing price and availability. If you generate markup with JavaScript, the server needs enough capacity for the increased traffic from Google. If a rival's block shows up only in rendered HTML, add a row for it, but do not assume what it costs them.

Feeds and policies in the same picture

Google's Product structured data overview (Opens in a new tab) says product data can come from structured data on pages, from Merchant Center feeds, or from both, and that providing both maximizes eligibility and helps Google verify the data. Some experiences combine the two: product snippets, for instance, can use price data from the merchant feed when the on-page markup lacks it. A field missing from a rival's page may therefore be supplied through a feed you cannot see. Mark such cells "missing (may come from feed)". For return terms, Google recommends a global policy under Organization markup rather than repeating it on each offer, so a missing offer-level policy on a rival page is not proof of a missing policy. Your own feed errors are covered in the Merchant Center product data errors guide.

A rule for adopting a field

Run each field through these questions in order:

1. Is it required for the experience you target? If it is missing from your template, add it.
2. If it is only recommended, does your catalog really hold the information, and is it visible on the page? If both are true, add it.
3. If the information is not in your catalog or not shown to visitors, leave the field out. Do not invent data to fill a field.
4. If the field appears on a rival page but not in the documentation, check the schema.org definition and adopt it only when it represents something visible on your page.

A rival's choice does not count as a reason by itself. The reasons are the documentation, the visible page and your own data.

From findings to a backlog

A comparison can produce dozens of rows. Sort them with the documentation's own split between required and recommended. Practical suggestion: use the priority table as a first-pass ordering.

Give each backlog item an owner: template developers for missing required fields, catalog owners for missing identifiers, image producers for aspect ratios. Ship in small steps, test your own page with the Rich Results Test after each change, and watch the relevant Search Console report after release. Google does not guarantee that structured data produces a particular search feature, and some enhancements, such as price drops, are computed by Google and not guaranteed to appear. Write "made eligible", not "will appear", in your status reports. Google's field lists can change, so check the current page before you build.

Category, review and variant fields

Three groups of recommended fields separate one rival template from another: category data, reviews and variants. Each has its own rules in the documentation.

The category field

The category property takes an array that can mix plain text and CategoryCode objects. Plain text stands for your own custom product category, similar to the product_type attribute in product feeds, and the documentation recommends keeping custom product types under 750 characters. To state a Google product category, use the CategoryCode type, point inCodeSet at the Google Product Taxonomy URL, and give either the numeric ID or the full path in codeValue. In the path form the levels are separated by a greater-than sign and each segment must contain at least one letter. When you read a rival page, record which form it uses: plain text, CategoryCode or both. In the watch example, a plain text value such as "Automatic watches" is a custom type.

Ratings and reviews

Both fields are recommended and tied to review guidelines. The documentation says that if you add a review, the reviewer's name must be a valid name for a Person or Team. A promotional line such as "50% off on Black Friday" is the documentation's example of what not to use, while "James Smith" or "CNET Reviewers" is what it recommends. The general guidelines also rule out fake reviews. When a rival page carries an aggregateRating, check whether the page itself shows customer reviews. If not, mark the cell doubtful.

Variants and separate URLs

Google offers product variant structured data to help it understand which products are variations of the same parent product, and both product snippets and merchant listings support it. Merchant listings also mention variants that have their own distinct URL. If a rival gives each dial color its own URL with its own color value, record "one URL per variant, variant-specific color". If all colors are listed in one field on one page, the structure differs. Choose the model deliberately in your own template.

Choosing which rivals to read

The columns you choose matter as much as the rows. Retailers who share a results page with you, marketplaces carrying the same model and brand sites can all use different templates. Reading three groups gives a fuller picture:

• Retailers selling the same watch model, for a like-for-like Offer comparison.
• Retailers in the same category with different models, for template-level patterns such as identifiers and image sets.
• Marketplace listing pages, for seller and price structure.

Practical suggestion: take one rival from each group and read two product pages from different parts of the catalog on each. Record the address, the date, the markup format and the page type for each reading, since rival pages change and a table without a date is hard to trust two months on.

States worth separate notes

Example scenario: a luxury watch page shows InStock in the morning while the sold-out page of a discontinued model from the same retailer shows OutOfStock or SoldOut. Both pages come from one template, so reading only one would give an incomplete picture of how the template handles availability. Read at least one page in each state, then test your own template in the same states: in stock, out of stock, pre-order and discontinued. A template that handles only the in-stock state will emit stale or empty offers when the catalog changes.

A sample record

Keep the record to field names and states. Copying a rival's text, photographs or full JSON into your files adds risk and no value, and it keeps the table short.

Each record should say who read the page, on which date, with which browser view (source or rendered), and which table cells it changed. That small discipline lets a colleague repeat the reading and compare it with yours when the two tables disagree.

Checklist before you start the comparison

• The rival page is public and needs no login.
• The markup format is identified.
• Page source and rendered HTML were both looked at.
• Required fields are entered in the table.
• Offer values (price, currency, availability, condition) are read.
• Identifier, brand and image rules are checked against the documentation.
• Fields that contradict the visible page are marked doubtful.
• Page type and variant URLs are noted.
• The reading date is recorded.

Pitfalls

Pasting a rival's values

Copying a rival's JSON turns their product facts into yours and risks marking up content your page does not show. The table should yield a list of fields, not a list of values.

Reading a missing field as an advantage

A missing field proves nothing about advantage. The rival may supply it by feed.

Judging a template from one page

One page shows one state. A sold-out watch page may carry OutOfStock where the in-stock page of the same retailer carries InStock, and both come from the same template.

Mixing page types

A review page and a store page do not share the same required fields. Separate them before comparing.

Ignoring terms of use

Opening pages one at a time is a public reading. Automated bulk collection can break a site's terms, so keep the exercise manual.

Frequently Asked Questions

How do I view a competitor's product markup?

Open the public product page, view the source and look for script blocks of type application/ld+json. If nothing shows, check the rendered HTML in your browser's developer tools, because some sites add the markup with scripts.

Which fields do merchant listings require?

According to Google's merchant listing page, Product needs name, image and offers, where offers is a nested Offer. Inside the Offer, price and priceCurrency are required.

Should I add a field just because a rival has it?

No. Add it when the documentation requires it, or when it is recommended and your catalog holds the information and the page shows it. A rival's field does not justify the change on its own.

What does it mean when a rival puts Product markup on a category page?

Google's documentation says product rich results support pages focused on one product or its variants, and it recommends marking up product pages instead of listing pages. Record it as a page type mismatch.

Is a field that is missing on a rival's page really missing?

Not necessarily. Google says data can come from page markup, from Merchant Center feeds or from both, so the rival may supply it through a feed that you cannot see.

Does adding the markup guarantee a rich result?

No. Google does not guarantee that structured data leads to a search feature, and some enhancements, such as price drops, are computed by Google and not guaranteed to appear.

Conclusion

Reading a rival's product structured data is a four-step job: view the markup on a public page, set its fields against the documented required and recommended lists, flag whatever contradicts the visible page or the documentation, and turn the gaps into a backlog with the adoption rule. The rival's fields serve as a yardstick, not as a template. The decision stays with the documentation, your visible page and your own catalog data.

Once your product pages are in order, you can also build up the link profile around them. See the backlink packages for the options. To build your own Product schema, read product schema markup for ecommerce.