Why is an empty result the most useful feature in platform comparisons search?

Someone types two service names with “versus” between them—“Instagram vs TikTok,” for example. It looks like the clearest query anyone writes, but it is one of the vaguest.

At least four different people write it, and they want four different things. To answer well, work out which of the four is in front of you before you decide what to show.

This page is about that: the intents hiding inside a two-name query, what each one actually needs, and how a catalog should be structured so the right thing comes back. It is also about the queries that should return a redirection rather than a comparison.

What to take away

The four intents behind two names

A decision. The reader is choosing and has not chosen. This is the intent everyone assumes and it is the least common of the four. It needs the trade-offs, the axes that separate the two, and an honest statement that the answer depends on the job.

A fact. The reader has already chosen and wants one specific difference settled: does this one let me export, does that one charge for the thing I need. They do not want a comparison. They want a row.

Reassurance. The reader has chosen, is committed, and wants to see the choice reflected back. Nothing you publish will change the decision, and the useful service is to tell them what to watch for on the option they took.

An alternative. The reader has typed the incumbent and a candidate they half remember—say, Instagram and TikTok—and what they actually want is the set of candidates for their job. The pair is a symptom.

Query understanding studies the gap between what was typed and what was meant.

For a small catalog, design the results page so all four intents find something on the first screen.

What to show for each

Building one page that serves all four is possible and is mostly a matter of ordering: the differences that matter, then the field-level answers, then the wider set, then the maintenance notes. A reader with any of the four intents finds their part within a screen or two. Give each comparison a visible last-verified date, and review it regularly and whenever a platform announces a material change.

The pairs that should not have a page

Some two-name queries are asking about services that cannot substitute for each other. Building the comparison anyway produces a page that ranks well, teaches nothing, and quietly implies a relationship that does not exist.

The honest response is a short page that says why these two are not alternatives, in one paragraph, and then points at the substitution set each of them genuinely belongs to. That serves the intent, which was almost always the fourth one, and it does not manufacture a comparison to capture a search.

Refusing to build the table is easier to hold to if the rule is written down in advance. For this catalog, include services whose primary purpose is social networking or community interaction; exclude general-purpose cloud storage such as Google Drive. An Instagram–Google Drive query then has a principled answer: no comparison, because the services are outside the same substitution set. Editors under traffic pressure discover reasons why this particular pair is different.

Making the catalog searchable for these queries

Three structures do most of the work.

Index the names, including former names and common misspellings. People search for what a thing was called when they last used it. For example, map Twitter to the current X entry so a search for either name resolves to one service, rather than a comparison between two. Keep the mapping in a synonym list applied to queries rather than to entries, as the General Notes on Catalog Search explain, so the entries themselves stay stable.

Index the field values, not only the prose. A reader searching for a property ("export includes timestamps") is searching a cell. Cells are short, closed, and easy to match, and matching them exactly is worth more than any amount of full-text cleverness.

Index the omissions. The blanks and the sought-not-found notes are what a reader looks for when a claim has just failed them. They are also the part of a catalog nobody else has.

What not to index: the editorial narrative, which matches everything and separates nothing.

The empty result is the feature

A search that returns nothing is an opportunity, and most catalogs waste it.

Say what was searched. Say which filters were active. Say how many entries matched before the last one was applied. Then offer the nearest thing: the substitution set, the entry for whichever of the two names is recorded, or the note that neither is.

Example empty-result page: “No comparison is recorded for Instagram and Google Drive. No filters are active. These services are not in the same substitution set: Instagram belongs to the social-networking set, while Google Drive is general-purpose cloud storage and outside this catalog’s scope. Browse Instagram’s set instead.”

Log the empty queries. Track which two-name searches return no results and which empty queries repeat, using one stated reporting period; publish counts only when the catalog’s own logs support them. Repeated queries are the shortest route to what the catalog should hold next, and repeated name searches with no result are the fastest way to find a service the inclusion rule should have admitted.

What the reader sees before they reach you

Most of these queries are answered elsewhere first, on a results page full of pages written to capture that exact phrase. That page sets the reader's expectation: a numbered list, a winner, a confident tone.

A search results page full of that primes readers to expect a verdict from you too.

The catalog's answer is deliberately different, and saying so in a sentence at the top costs nothing and prevents the reader concluding that the page is incomplete. "This page shows where the two differ and does not pick one, because the answer depends on what you need it for" is enough.

The reason is explained in the companion note, “Why a Ranked List Is the Wrong Output.” Honest outputs are a set, a partition, or a band. None looks like what the reader expected.

Common questions

Should a comparison page exist for every pair in a substitution set?

Only for the pairs where the choice is genuinely open. A set of five services has ten pairs and usually three worth writing about. The rest are covered by the set page itself, which shows all five against the same axes.

A reader searched a name that is not in the catalog at all.

Say so, and say whether it was considered and rejected, with the test it failed and the date. Under the inclusion rule above, Google Drive fails the catalog’s social-platform scope test: it is general-purpose cloud storage, not an eligible social network. State when that decision was reviewed. A stated omission is a better answer than a blank, and it is the answer that stops the same question arriving again.

Is it worth optimizing for the two-name query at all?

For discovery, yes, since it is how readers arrive. For the page itself, no: write the page for the reader who lands on it, not for the phrase that brought them. The two goals conflict less than people assume, because a page that actually answers the question is what a reader stays on.

What if the two names belong to the same service after a rename?

Return the entry with a note that these are one thing, and the date of the change. That is a genuine finding and it is exactly the sort of thing the Overview of Comparing Platforms warns about when a comparison is assembled from sources of different ages.