An app store is a discovery surface. A website is a building.

A product exists in two places: an app store listing that people find, and a website for the same product that nobody arrives at. The marketing copy is the same. The product is the same.

The store is not a better shop window. It is a different kind of object.

The case this post is about#

One product, found in an app store and not found on the web, with the same name and the same words.

The store ships four things with every listing:

query       a search box containing only things of this kind
ranking     an ordering function over that set, run for you
taxonomy    categories somebody already browses
action      the thing the visitor came to do, on the same page

The website had none of them. It described the product accurately, loaded fast, and was indexed — and a visitor arriving on it could read about the thing rather than do it.

This post follows those four rows, because the gap is not worse marketing or worse technique. It is that the fourth line is a property of the page, and no amount of optimisation adds it.

The symptom#

The visible version is a traffic graph with nothing on it. The site is live, it is indexed, the technical checks pass, and the number of people arriving from a search engine is approximately none — while the same product, listed in a store, is found by people typing roughly what it does.

The second thing is that the obvious diagnosis is wrong. It reads as an SEO problem, so the response is SEO work: metadata, structured data, a sitemap, faster pages. All of that is worth doing and none of it addresses the actual asymmetry, which is that the two surfaces are not competing on the same axis at all.

The third is where the comparison breaks. A store listing sits inside a system that already has the query, the ranking, the category taxonomy and the install button in one place. Somebody who wants the thing types what it does into a box that only contains things of that kind, and the store's job is to order them. A website has none of that around it: the query happens somewhere else, the ranking is against the entire web, and the action the visitor came to take may not be on the page at all.

The fourth is the one I had to be honest with myself about. On the web, the thing that ranks is the thing that does the work. If the site describes a product and the product itself lives elsewhere, then there is nothing on that page for somebody with the intent — and the page will not rank, because it should not. The marketing site was not under-optimised; it was not the thing people were looking for.

Why the obvious fix failed#

More SEO. Metadata, schema, internal linking, performance. Genuinely necessary and it is tuning for a race you have not entered. These make a page that should rank rank better; they do not turn a description of a product into the product.

Write content around the keywords. The standard play, and for a product with a functional intent it mostly produces articles that rank for people who want to read about the thing rather than use it. A visitor who wanted to do something and found an essay leaves, and the engagement signal that follows is accurate.

Submit to the index faster. Sitemaps, indexing APIs, pinging. Worth having — and getting indexed quickly is not the same as being worth returning. Fast indexation of a page that satisfies nobody is a faster route to the same outcome.

Port the store listing to the web. The intuitive move: same copy, same screenshots, same positioning. It fails because the store listing's job is to convert somebody the store has already delivered. It is a conversion asset that works because discovery happened upstream, and on the web there is no upstream.

Those four failures share a shape worth naming: each one improves the page and none of them changes what the page is. That is the signature of working on the wrong layer — effort that is real, results that are real, and a ceiling that does not move, because the constraint was never the thing being improved.

The actual mechanism#

A store bundles four things into one surface, and on the web each of them is a separate thing you build.

query       a search box containing only things of this kind
ranking     an ordering function over that set, run for you
taxonomy    categories somebody already browses
action      the thing the visitor came to do, on the same page

The last line is the one that decides everything else. Search engines rank pages by whether they satisfy the intent behind a query, and a functional query — somebody wanting to do something — is satisfied by a page that does it. That is why utility pages outrank descriptions of utilities: not because of better technique, but because the page is the answer rather than a pointer to it.

So the honest version of "closing the gap" is not an SEO project. It is a product question: does the thing people are searching for exist on the web at all? If it does not, the SEO work is preparation, and it should be understood as preparation rather than as an attempt that is underperforming.

The sub-case worth separating, because it is where the real SEO work belongs, is what happens once the page is the answer. At that point the technique matters a great deal — the structure of the page, how fast it responds, whether the action works without an account, whether it is reachable without a redirect. All of that is downstream of having something to offer, and all of it is wasted in front of it.

There is an ordering consequence that is easy to get backwards. Because the technique work is well-documented, cheap to start and produces visible artifacts, it is the natural thing to do while the product half is still being built — and it feels like progress. It is not wasted, exactly; it is prepaid. The risk is that months of it accumulate into a belief that the SEO has been tried and does not work, when what has been tried is the half that was never going to be sufficient alone.

The fix#

decide      whether the web surface does the thing, or only describes it
build       the doing part first — the page has to be the answer
then        the SEO technique, which now has something to work on
measure     from the point the product exists, not from the site going live

The ordering is enforceable, which is the part that stops "build the thing first" being advice. The check asks whether the page does the thing or only describes it:

type Surface = { route: string; kind: "tool" | "article"; interactive?: string };

export async function assertDoesTheThing(s: Surface, dist: string) {
  if (s.kind !== "tool") return;                 // articles describe, by definition

  const html = await Deno.readTextFile(`${dist}${s.route}/index.html`);

  // A tool page has to carry the thing itself. A description of a tool, with a
  // waitlist form, is an article wearing a tool's metadata — and every SEO
  // technique applied to it is optimising the wrong page.
  const hasInteractive = s.interactive ? html.includes(s.interactive) : false;
  const hasWaitlist = /coming soon|join the waitlist|notify me/i.test(html);

  if (!hasInteractive) {
    throw new Error(`${s.route}: declared a tool, ships no interactive surface` +
      (hasWaitlist ? " — it is a waitlist page" : ""));
  }
}

Run over the routes declared as tools:

$ deno task verify-surfaces
✗ /tools/apk-size: declared a tool, ships no interactive surface — it is a waitlist page
  /blog/three-phases: article — skipped
2 surfaces · 1 failing

That failure is the whole post. The page had correct titles, a canonical, structured data and a sitemap entry — every technique applied properly to a page that did not yet do anything.

The fourth line is a discipline about honesty with yourself more than a technique. A traffic baseline taken while the site is a brochure tells you nothing about whether the SEO works, and it is extremely tempting to treat the first number after a product lands as evidence for whichever change you made most recently.

What this reframes is where the difficulty actually sits. The store gave you discovery for free and the price was that the store owns it: the ranking function is theirs, the rules change without notice, and the relationship with the person who installed the thing is mediated. The web charges you the full cost of building discovery yourself, and what you get in return is that it is yours.

How we proved it#

The asymmetry is structural and can be reasoned about without data, which is the part I am confident in. A store search box contains only applications; a web search box contains everything. Those are different problems, and no amount of metadata changes which one you are solving.

The store's box is also doing work that is invisible until you lose it. Everything in it has been through a review process, carries a rating, states a size and a price, and can be acquired by one action — so the comparison a person makes there is narrow and well-supported. On the open web the same person has to establish what the thing is, whether it is safe, and what happens if they proceed, usually from the page itself.

The failure mode is visible in what ranks for functional queries. For almost any "do X" search, the results are pages that do X. That is a thing anybody can check in a minute, and it is the whole argument for why a description page does not compete.

What I cannot tell you is the number. The honest state is that the web surface for the product I am describing does not yet do the thing — the functional part is unshipped — so there is no post-fix traffic figure, and any before-and-after I offered would be measuring a change that has not happened. This post's topic entry has been waiting on exactly that data since it was written, and I have chosen to publish the structural argument rather than hold it until there are numbers, because the structural argument is the part that was actually load-bearing.

What I have not solved: whether the web surface can win at all in a category with established leaders. The structural argument says what you need to compete; it does not say that competing is sensible when the incumbents have years of accumulated authority. That is a judgement about a specific market and I do not have a general answer to it.

And a caution about the framing, because it can be taken too far: none of this means store presence is the easy option. Store discovery has its own ranking function, its own optimisation discipline and its own rule changes that can remove you overnight. The asymmetry is about what comes bundled, not about which is harder overall.

The thing I would tell somebody is to notice when an SEO problem is wearing a product problem's clothes. The symptom — no organic traffic — is identical in both cases, and the two have completely different responses, with the expensive mistake being a year of content work in front of a page that was never going to be the answer to the question people were asking.

What this generalizes to#

A distribution channel you did not build has a shape, and products that grew inside one are often missing the parts the channel was providing.

The pattern shows up on exit from any bundled surface. A business whose customers all came from one marketplace discovering it has no direct relationship with them. A library whose users all arrived through one framework's ecosystem. A service that grew entirely inside somebody else's platform. In each case the thing looks complete and is missing the apparatus that was supplied by the context — usually discovery, sometimes trust, sometimes the transaction itself.

So the useful question before leaving or widening beyond a channel is which parts of this were the channel's, listed explicitly, rather than assumed to be properties of the product. Everything on that list is something you are about to have to build, and the common error is to budget for the move and not for the apparatus.

The second error is to assume the apparatus transfers. A reputation built inside a marketplace is often held by the marketplace: the reviews, the ranking history, the install base's relationship with the brand. Some of it moves with you and some of it was always an attribute of your position in somebody else's system, and the difference is worth establishing before it is load-bearing in a plan.