Comparison and Alternative Pages: The Highest-Intent Pages

Nobody types a competitor name followed by "alternative" unless they are already unhappy with the competitor. That is the entire commercial argument for these pages, and it is worth being precise about what kind of argument it is: it is reasoning about human behaviour, not a figure Google publishes.

We are not going to print a conversion rate for comparison traffic. We do not have a defensible cross-portfolio number for it, no platform publishes one, and an invented benchmark would be worth less than the reasoning it replaced. What we can say is structural. A person searching for your category — "budget tracking app" — is browsing. A person searching for a named competitor plus "alternative", "vs", or "review" has narrowed the field to one product and is looking for a reason to leave it or stay with it. The second person is further down the same journey. That is the whole claim.

Google's own SEO Starter Guide frames the job in a way that fits this exactly. It tells you to "think about the words that a user might search for to find a piece of your content" and notes that "users who know a lot about the topic might use different keywords in their search queries than someone who is new to the topic." A competitor-plus-alternative query is the knowledgeable version of a category query. The person knows the market. They are using vocabulary a beginner would not.

Across the 300+ apps we have managed since 2013, the pattern that keeps repeating is not that these pages produce enormous volume. They rarely do. It is that the volume they produce behaves differently from everything else in the acquisition mix, and teams underweight them because they judge every page by sessions.

Because store metadata policy limits what you may say about other brands, and because the store listing is not where that search happens. Two separate constraints, both of which push the answer onto a page you control on the open web.

Google Play's Metadata policy is explicit that you should not "use a celebrity's name or a brand's logo without permission". It also targets padding directly, telling developers to avoid "repetitive or unrelated keywords or references" and prohibiting metadata that is "misleading" or "non-descriptive, irrelevant, excessive". Stuffing a rival's brand name into your short description to catch their branded search is precisely the practice that language covers, and the enforcement risk sits on your distribution, not on a blog post.

The second constraint is more basic and gets ignored more often. Store search is a walled index. A user comparing two products reads reviews, forums, and articles on the open web before they open a store at all; by the time they reach the store they have usually already chosen. Your listing is the closing surface, not the consideration surface, which is why listing work and comparison content are not substitutes for each other. Our guide to store listing conversion covers the closing half of that.

This is also why the work does not belong to the ASO team alone. A comparison page is a web asset that feeds a store conversion, which makes it a joint piece of work between whoever owns the site and whoever owns the listing. In our portfolio, the single most common reason these pages never get built is that neither team believes they own them.

Google documents how it crawls, indexes, and what it treats as spam — it does not publish a taxonomy of search intent, so any claim that "Google recognises commercial-investigation intent" is inference dressed as documentation. This section exists because the rest of the article depends on you knowing which sentences are load-bearing.

Read Google's in-depth guide to how Search works and you will find crawling, indexing, and serving described in detail. What you will not find is a section on intent classification, a list of query categories, or any statement about how commercial queries are treated differently from informational ones. The guide states that when a user enters a query, Google's machines "search the index for matching pages and return the results we believe are the highest quality and most relevant to the user's query", and that "relevancy is determined by hundreds of factors". That is as far as the primary source goes.

So the honest split looks like this:

• Documented: what Google considers helpful content, what it classifies as doorway and scaled-content abuse, how it handles duplicate URLs, and which structured-data features you are eligible for. All of that is quotable, and all of it constrains the page you build.
• Documented: that different users search for the same thing with different vocabulary, and that Google finds most new pages through links.
• Reasoning: that a searcher using a competitor's brand name plus "alternative" is closer to a decision than a searcher using a category term. This follows from what the words mean, not from anything Google has said.
• Unpublishable: any conversion rate, traffic estimate, or ranking-probability figure for these pages. If someone hands you one, ask where it was measured.

We flag this because the genre is full of confident numbers with no lineage. The same discipline applies to the internal case: we can tell you what these pages did structurally for clients, and we will not convert that into a percentage we cannot reconstruct. Our piece on measuring app acquisition properly covers why a number you cannot rebuild is worse than no number.

Whether the page is a destination or a turnstile — and Google defines the failure mode precisely enough to test yourself against it. This is the risk that actually kills these programmes, and it is entirely avoidable.

The Spam policies for Google web search define doorway abuse as when "sites or pages are created to rank for specific, similar search queries" and "lead users to intermediate pages that aren't as useful as the final destination". Read that against the typical templated comparison page: forty near-identical URLs, one per competitor, each a thin table above a download button. The user lands, learns nothing they could not have learned on your homepage, and is funnelled onward. That is the definition, almost word for word.

The same page also defines scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", and calls out generating numerous pages with AI tools or stitching content together without user value. A generated set of "X vs Y" pages built from a spreadsheet of competitors is the exact shape that policy describes, and the fact that a language model wrote them quickly is the aggravating factor rather than the excuse.

The distinction is not cosmetic and cannot be solved by adding words. A thin page with more words is a longer thin page. What makes a comparison page a destination is that it contains judgement someone could not have produced without using both products — which is why the ones that work are usually written by the people who built the thing, not by a content pipeline.

Yes, and Google's helpful-content guidance actively rewards the first-hand experience you have — but the moment you try to turn that judgement into a star rating in search results, a separate rule shuts it down. Both halves matter, and teams usually learn the second one after building the page.

Google's guidance on creating helpful, reliable, people-first content defines people-first content as "content that's created primarily for people, and not to manipulate search engine rankings", and its self-assessment questions are a usable specification for a comparison page. It asks whether "the content provide[s] original information, reporting, research, or analysis", whether the content is "written or reviewed by an expert or enthusiast who demonstrably knows the topic well", and whether after reading it "someone [will] leave feeling they've learned enough about a topic to help achieve their goal."

The same document sets out a "Who, How, Why" framework. On "Who", it asks whether it is "self-evident to your visitors who authored your content" and whether pages "carry a byline, where one might be expected". On reviews specifically it points at "the number of products that were tested, what the test results were, and how the tests were conducted". On "Why", it states that the reason for creating content "should be that you're creating content primarily to help people".

None of that prohibits an interested party from writing the comparison. It requires the interest to be visible and the work to be real. A comparison page that says who wrote it, when they tested, on which plan and which platform, and where the competitor is genuinely better, satisfies far more of that self-assessment than an anonymous neutral-sounding table does.

The answer to the query in the first screen, then the evidence that you earned that answer, then the segment-by-segment verdict. Ordering it any other way turns a decision page into a brochure.

On headings and structure, the SEO Starter Guide is plain: "break up long content into paragraphs and sections, and provide headings to help users navigate your pages". For a comparison page that means headings phrased the way the decision is phrased, so a reader scanning for their own situation can find it without reading the whole thing.

One practical note on naming. If your product name is a generic word, comparison queries collide with unrelated searches and the page fights ambiguity it did not create — which is one of several reasons naming deserves its own decision process, covered in how to name your app.

As many as you can write from genuine first-hand use, which for most teams is a single-digit number — and the failure mode of exceeding that is documented, not hypothetical. The instinct to cover every competitor in the market is the instinct that produces the doorway pattern.

There is a second, quieter problem with a large set: they resemble each other. Google's documentation on specifying a canonical URL notes that "if you don't specify a canonical URL, Google will identify which version of the URL is objectively the best version to show to users in Search", and ranks the available signals: redirects and rel="canonical" annotations are each described as "a strong signal", while inclusion in a sitemap is "a weak signal".

That has a direct consequence for a templated comparison set. If twenty of your pages differ only in a product name and two table rows, you have created a set of near-duplicates and handed the choice of which one represents them to Google. Canonical tags are the right tool when you deliberately have two URLs for one thing — a "vs" page and an "alternatives" page covering identical ground, say. They are not a fix for a set that is duplicative because it was generated rather than written.

The other cap is maintenance. Every page you publish is a promise you will keep it accurate, and comparison content decays faster than almost anything else on a site because it depends on someone else's roadmap. Five pages you revisit every quarter beat thirty you wrote once.

It can describe your app; it cannot put a star rating for your own product into search results, because Google explicitly excludes reviews an entity controls about itself. This is the rule that most often surprises teams after they have already built the markup.

The review snippet structured data documentation states that "if the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature." It gives the example directly: "a review about entity A is placed on the website of entity A, either directly in their structured data or through an embedded third-party widget (for example, Google Business reviews or Facebook reviews widget)."

So a comparison page on your own domain, carrying your own aggregate rating for your own product, is describing the case that rule exists to exclude. Building it wastes engineering time at best.

What is available is the SoftwareApplication type. Google's software app documentation lists name, offers.price — set to 0 if the app is free — and either aggregateRating or review as required properties, with applicationCategory and operatingSystem recommended. Note the required rating property carefully alongside the self-serving rule above: the type requires a rating, and the review-snippet guidance restricts when self-controlled ratings earn the star feature. The markup can still help Google understand the entity even where the visual feature does not appear, and Google is clear in the same documentation that it "does not guarantee that features that consume structured data will show up in search results".

On the title element, Google's guidance on influencing title links asks for "descriptive and concise text", warns against keyword stuffing — "there's no reason to have the same words or phrases appear multiple times" — and stresses that it is "important to have distinct text that describes the content of the page in the title element for each page on your site". That last clause is the one a templated comparison set breaks first, because the template writes the title too.

Through a hand-off you design deliberately, because the reader is on the web and the product is in a store — and that transition is where most of the intent you captured gets lost. A comparison page that ranks and does not convert is usually a hand-off problem, not a content problem.

The mechanics belong to the wider web-to-app problem, which we cover in web-to-app funnels. The comparison-page-specific points are narrower:

• Carry the context across the gap. Someone who arrived on a "switching from X" page and lands in a generic first-run experience has to re-explain their situation to your onboarding. Where the store supports a tailored destination, use one — custom product pages exist for exactly this kind of segmented entry.
• Make the migration path the call to action. For a switching audience the blocking question is rarely "is this better", it is "what happens to my data". An import path answers the real objection; a download button answers a question they had already resolved.
• Use link text that describes the destination. The SEO Starter Guide notes that link text "tells users and Google something about the page you're linking to", and that most new pages Google finds are discovered through links. Both halves apply to how you wire these pages into the rest of the site.
• Instrument the specific page, not the channel. Comparison pages are low-volume and high-intent, so they disappear inside an aggregate organic number. If you cannot see the page separately, you will conclude it did nothing.

The last point is where most of these programmes quietly die. The page produces a small number of unusually good users, the reporting shows a rounding error, and the page gets cut in the next content review. Whoever commissions this work should agree in advance how it will be judged, because judging it on sessions guarantees the wrong answer.

If you are weighing whether comparison content is worth the maintenance for your category — or you have a set of templated pages you now suspect fits the doorway description above — that is a specific enough question to answer quickly. Tell us which competitor you lose to, or see how we treat store and web surfaces as one system in our ASO work.