Comparison pages help people choose between options. In schema terms, that creates a simple problem: a comparison page is often about more than one item at once, while Google rich result features are mostly built around page types with one clear primary focus, such as a product page, article page, review page, or breadcrumb trail.
Google’s supported feature list includes things like Product, Review snippet, Article, and Breadcrumb, but it does not list a dedicated rich result feature for generic comparison pages.
If you want the broader cluster first, start with Schema for SEO. If you need the syntax first, read JSON LD Basics. If your comparison page is evaluating software or SaaS offers, keep Product Schema for SaaS, SoftwareApplication Schema, and Review Snippet Rules close while you build the page.
The short answer
For most comparison pages, start with BreadcrumbList and a page type that matches the page’s role. Use product or software markup only when the page gives one item a clear primary role, or when child URLs carry that markup on their own dedicated pages. If the page is an editorial review page for a product, Google supports product review related enhancements such as review information and pros and cons, but that is tied to product review pages, not to every side by side comparison URL.
What a comparison page is
A comparison page is often one of three things:
- an editorial article comparing two or more tools
- a commercial comparison page routing users to product pages
- a category style page that lists alternatives by use case
Google’s structured data rules say the markup on a page should describe the content of that page and should not label hidden or irrelevant content. That means the first job is not picking a schema type. The first job is deciding what the page is trying to be.
Start with page role, not feature wish lists
A lot of comparison pages go wrong because teams start with the rich result they want, then force the markup to fit. Google’s policies point the other way: structured data should match the visible page content and the page’s main focus. So if the page reads like an editorial comparison, treat it like an editorial page first. If it routes people into product choices, keep the hierarchy and entity roles clear.
That is why Markup Prioritization belongs next to this page. The order is simple: define the page role, choose the markup that fits that role, then validate the result.
What to add first on most comparison pages
BreadcrumbList
Breadcrumb markup is one of the safest first layers for comparison pages because it helps Google understand the page’s position in the site hierarchy. Google documents Breadcrumb as a supported search feature for generic pages.
If you have not built that part of the cluster yet, read Breadcrumb Schema.
WebPage or Article style page logic
Google supports Article rich results for news, sports, and blog article pages. Comparison pages that read like long form editorial content are often closer to an article than to a product page. Google also says structured data should classify page content in a way that matches the visible page. That makes article style markup a better fit than forced product markup when the page is a written comparison of multiple options.
Item organization, not fake single item markup
If the comparison page lists multiple tools, the page can still describe the items in a structured way for your own graph, but that does not mean Google has a dedicated comparison rich result waiting for it. The safer move is to keep the page level markup tied to the comparison page itself and place full product or software markup on the child URLs that focus on one item.
What belongs on child pages instead
Google’s Product documentation is built around product pages. It says product structured data can make product pages eligible for richer appearances that include price, availability, ratings, and more. Google also separates product snippets from merchant listings and notes that editorial product review pages can include pros and cons.
That creates a clean split for comparison clusters:
- comparison page: page hierarchy, editorial framing, route to child choices
- child product page:
Productand offer details where supported - child software page: software specific markup where the software is the main entity
- editorial product review page: review related markup, including pros and cons where the page qualifies
On Semantec SEO, that means Product Schema for SaaS and SoftwareApplication Schema belong closer to the reviewed or sold item page than to the broad comparison URL.
Comparison page markup patterns that work
For most comparison pages, a clean default looks like this:
BreadcrumbList- a page type that reflects the content, often
WebPageor article style logic - structured references to the compared items only if the page clearly presents them and the markup matches what readers can see
- child URLs carrying the heavy product or software markup on their own pages
This keeps the page honest. It also keeps the product rich result work on pages that are built for it.
A simple JSON LD pattern
Below is a safe starter pattern for an editorial comparison page.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://semantecseo.com/compare/mirena-vs-chatgpt/",
"url": "https://semantecseo.com/compare/mirena-vs-chatgpt/",
"name": "MIRENA vs ChatGPT",
"description": "Editorial comparison of MIRENA and ChatGPT for SEO workflow use."
},
{
"@type": "BreadcrumbList",
"@id": "https://semantecseo.com/compare/mirena-vs-chatgpt/#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://semantecseo.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Compare",
"item": "https://semantecseo.com/compare/"
},
{
"@type": "ListItem",
"position": 3,
"name": "MIRENA vs ChatGPT",
"item": "https://semantecseo.com/compare/mirena-vs-chatgpt/"
}
]
}
]
}
This pattern gives the page a clear identity and a clear path in the site. It does not pretend the page is a single product page. Google’s rules say the markup should describe the content of the page it sits on, and that is exactly what this pattern does.
When review related markup can fit
Google supports review snippets for supported item types, and its product documentation says editorial product review pages can carry review information and pros and cons. That means review related markup can fit a comparison page only when the page is functioning as a real editorial review of a specific product or a tightly framed review page with visible review content.
That is a narrower use case than many teams expect. A broad “tool A vs tool B” page with a table and a short verdict is not always the same thing as a dedicated review page for one product. If you are building that layer, read Review Snippet Rules next.
What not to do
Do not mark up the whole page as one product when it compares several
Google’s product feature docs are for product pages. A side by side comparison page is a different page role unless one product clearly owns the page.
Do not add review stars with no visible review content
Google says structured data should describe visible page content and should not describe hidden content. Review related markup also has its own feature rules. ([Google for Developers][3])
Do not expect a comparison rich result feature that Google has not documented
Google’s supported feature list is published, and generic comparison pages are not a listed standalone rich result type.
Do not blur article, product, and category logic on one URL
The page should have one clear primary role. When the role is mixed, the schema tends to get mixed too. Google’s structured data intro and policy pages both push toward matching the markup to the content on the page.
A better way to think about comparison page schema
Comparison page markup is less about squeezing rich results out of one URL and more about keeping the site graph clean.
A good comparison page should:
- sit in the right part of the hierarchy
- identify the compared items clearly in the copy
- route people to the right child pages
- keep product or software markup on pages built around one item
- validate cleanly before release
That is why Schema Debugging and Rich Results Test Guide are natural next reads after this page.
A short review checklist
Before you publish markup on a comparison page, check this:
- the page has one clear role
- breadcrumb markup reflects the real site path
- the page level schema matches the visible content
- product or software markup sits on child URLs unless one item clearly owns the page
- review related markup appears only when the page qualifies as a real review page with visible review content
- the page passes validation in the Rich Results Test page and is checked again after release
Final take
Markup for comparison pages should fit the page role, not force the page into a product pattern it does not own.
Start with breadcrumb markup and a page type that matches the content. Keep product, software, offer, and review heavy markup on the child URLs that focus on one item. Use comparison pages to strengthen hierarchy, entity clarity, and routing across the site. That path is cleaner for both SEO and maintenance.
FAQ
Is there a Google rich result type for generic comparison pages?
Google publishes a supported feature list for rich results, and generic comparison pages are not listed as their own standalone feature.
Should a comparison page use Product schema?
Only if the page is truly centered on one product. Google’s product docs are built around product pages, not broad side by side pages by default.
Can pros and cons markup fit a comparison page?
It can fit when the page qualifies as an editorial product review page and the pros and cons are visible on page. Google documents pros and cons for editorial product review pages.
What is the safest schema to add first?
Breadcrumb markup is one of the safest first layers because Google supports it for generic pages and it reflects hierarchy clearly.
What should I read next?
Go to Review Snippet Rules, Markup Prioritization, or Schema Debugging.