If someone asks an assistant about your app, what can it actually read?

Look at how people search now and the shape has changed. Pulled from Google Trends on 20 August 2026, the top related query for "app store optimization" over the past twelve months is "what is app store optimization" — a question, not a keyword, at a relative value of 100 and still rising at +50%.

Questions are what people type into assistants, and an assistant answering one does something a person does not: it fetches a handful of pages, reads whatever the server sent, and composes an answer from that. It usually does not run your JavaScript, and it does not scroll.

So the practical question for anyone with a site — or an app they hope gets recommended — is narrow and checkable: when something fetches your URL and does not execute a script, what does it get?

Measure it, do not assume it

Strip the <script> and <style> blocks out of a served page, strip the tags, and count the words. That is close to what a non-executing reader has to work with.

Run on this site's own build:

That last row is the finding, and it is worth being precise about why it is bad rather than merely low.

This site is a single-page app. Routes that are prerendered at build time ship real HTML. Routes that are not — the per-app analytics view, per-app keyword pages, per-storefront reviews — are served by a fallback that returns the homepage's HTML and lets the browser swap in the right view. A human never notices. A non-executing reader asks about one specific app and receives the site's front page: right word count, wrong page, no mention of the app it asked about.

The fix is not clever. It is to render the page on the server for the URLs that are supposed to be answers. On this site that is 2,286 prerendered pages, and the routes that stay dynamic are marked noindex precisely because a homepage duplicate is worse than an absence.

Say what you allow, in a file that is read

robots.txt has quietly become the place you declare more than crawling. This site serves a Content Signals line:

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no, use=reference
Allow: /

Four separate permissions, and they are genuinely separate: index and link to it; read it to answer someone's question and cite it; do not train a model on it; consume it as a reference rather than wholesale.

One trap worth knowing about, because it cost this site something before it was found. A CDN feature that adds AI-crawler controls may merge its block into your robots.txt rather than replace it. Ours did, and the two disagreed — the injected block sent Disallow: / to GPTBot, ClaudeBot, CCBot, Google-Extended, Applebot-Extended and others, while the file below it allowed several of the same agents. Googlebot was unaffected, so nothing in Search Console ever flagged it. Two contradictory groups for one user-agent are resolved differently by different crawlers, and the strict ones were being told to stay away from a site whose entire premise is being read and cited.

If you have ever ticked an "AI crawler" toggle in a dashboard, fetch your own robots.txt and read what is actually served. It may not be the file in your repository.

Write the answer, not the pitch

The rest is editorial, and it is the same discipline that makes a page useful to a person.

Answer the question in the first paragraph. A reader that composes an answer from a handful of pages rewards the page that states the fact early, and skips the one that warms up for four paragraphs.

Attribute your numbers inline. "Apple's screenshot specifications list 6.9" as required" is quotable. "Studies show most users decide in seconds" is not, and a careful reader drops it.

Say what you do not know. A page that marks its own limits is safer to quote than one that sounds certain about everything, because the quoting party inherits your confidence along with your claim.

Keep the structure honest. One <h1>, headings that describe the section beneath them, tables for things that are actually tabular. This is not a trick for machines; it is what makes a page skimmable, and skimmable is the property both readers share.

There is also a plain-text option worth having: an llms.txt at your root, listing your pages with a sentence each. It costs nothing and it removes the guesswork about what your site contains.

Being recommended is a separate problem

Everything above is about whether your site can be read. Whether an assistant recommends your app is a different question, and a harder one — the answer is composed from whatever the model has absorbed about your category, which is not a surface you control or can audit.

What you can do is check. Appstro's AI visibility check asks discovery-shaped questions of a model and reports whether your app comes back. That is a spot check with a sample size of one conversation, and the page says so. It is not a rank, it is not stable between runs, and nobody should sell you a number for it.

The MCP server is the other half: it exposes this site's App Store data to an assistant directly, so a model answering a question about an app can fetch the real figures instead of recalling them.

What this cannot tell you

• Not what people ask assistants. No public dataset of assistant prompts exists. The Trends figure above is web search behaviour, which is a related signal and not the same thing. Anyone quoting you a share of "AI search traffic" is quoting a model, not a measurement.
• Not whether you were cited. Assistants mostly do not send a referrer, so your analytics cannot see a citation the way it sees a link.
• Not whether being readable causes recommendations. Being readable is necessary. Nothing public establishes it is sufficient.
• Not a stable answer from any model. Ask twice, get two answers. Treat single runs as anecdotes.

The work

Fetch one of your own pages with scripts disabled and read what comes back. If it is your homepage when you asked for something specific, that is the whole project. Then fetch your robots.txt and check it says what you think it says.