Guide
Web vs App
Appkitekt AI scores both mobile apps and websites against the same Discovery · Selection · Trust frame. The frame is shared. The surfaces, signal floors, data sources and deploy mechanics are not.
In plain English
The way AI decides whether to recommend you is the same whether you're a website, a mobile app, or a service other apps plug into. We use the same 12 pillars and the same 0–100 score for all three. What changes is what we look at: HTML and site files for websites, App Store / Play data for apps, and manifest files for services. And how you ship a fix changes too — websites deploy instantly; apps go through Apple or Google review; services need a code change.
TL;DR (technical)
- Same DST chain, same 12 pillars, same 0–100 Index.
- Different factor floor: 130+ factors for web, 200+ factors for an app audit, 210+ factors for MCP / API audits.
- Different data sources: App Store Connect / Play / AASA / assetlinks / App Intents manifest in app mode; HTML / schema / sitemaps / /.well-known/ in web mode; MCP registries,
/.well-known/mcp.json, OpenAPI andtools/listin MCP mode. - Different Push-to-Live mechanics: instant edge deploys on web; staged App Store Connect / Play Console drafts + repo PRs on app; MCP manifest PRs and registry submissions on MCP.
- Same agent panel (ChatGPT, Claude, Gemini, Perplexity, Copilot, Grok, Meta AI, Apple Intelligence). The prompt class flips between URL-naming, app-naming and tool-calling.
A note on the third surface — MCP / API
Most of this guide compares web and app side-by-side because that's where most teams live. A growing subset of vendors — search APIs, data providers, automation platforms, agent-callable SaaS — has a third primary surface: the MCP server itself. MCP audits use the same 12 pillars, the same 0–100 Index and the same agent panel, but weight the MCP, AAIO, AXO and PROTO pillars heaviest and use tool-calling prompts instead of URL-naming or app-naming ones. The third column in the scoring table covers the per-pillar weights for that mode.
Data sources, side by side
| Layer | Web mode | App mode |
|---|---|---|
| Agent panel | URL-naming prompts across all 6 frontier models | Same panel, app-naming prompts ("best $category app for $job") |
| First-party fetch | HTML, schema.org JSON-LD, sitemap, RSS, /.well-known/ | App Store Connect API, Google Play Developer API, AASA, assetlinks.json, App Intents manifest (when repo connected) |
| Public corpus | HackerNews, Stack Exchange, Wikipedia, Reddit + other free APIs | Public App Store / Play listings, Wikidata, curated app lists, bounded reviews sample |
| Freshness signal | Sitemap lastmod, RSS, change feeds, edge cache headers | Version cadence, what's-new updates, ratings velocity, store-listing edits |
| Handoff layer | Schema for actions, /.well-known/mcp.json, public API | Universal Links (iOS) / Digital Asset Links (Android), App Intents, public API + MCP |
Triangulation rule is identical: one source is a hint, several agreeing is a finding. The source matrix in your report cites the exact mix that produced each intent.
Math and weights — what's shared, what differs
Both surfaces use the same roll-up formula, the same band labels (Invisible → Default-of-record), and the same confidence modifier. What changes is the base-weight distribution per pillar: app-mode audits weight AAIO, AXO, PULSE and RIVAL heavier because App Intents coverage, Universal-Link handoff, version cadence and rival-app overrides hit installs directly. Web-mode audits weight AEO, GEO and SIGNAL heavier because answer-shape pages, summarization survival and co-citations are the dominant levers.
The numbers are calibrated per audit and tuned again by the category modifier (games, productivity, finance, news, SaaS, etc.). See Scoring & weighting for the indicative table.
Pillar meaning per surface
| Pillar | In Web mode | In App mode |
|---|---|---|
| AEO | Answer-shape pages, schema, snippet-grade copy | Listing title / subtitle / description tuned for category-prompt match |
| GEO | Factual density that survives summarization | What's-new + listing copy that survives agent summarization |
| AAIO | Recommendation job on the web: entity clarity, category-prompt mindshare, page copy matching intent, structured facts anchoring authority | Same recommendation job in app mode: category-prompt mindshare on "best $category app for $job", listing copy tuned to those prompts, ratings velocity, editorial coverage. App Intents / connectors do NOT live here — see MCP row. |
| AXO | Token-efficient consumption layer, predictable errors | AASA + assetlinks.json so handoff lands; permissions hygiene |
| DAO | Per-model recipe drift on the RAG layer | Token-efficient App Intents responses so agents keep calling |
| PULSE | Mindshare in category prompts | Version cadence, what's-new freshness, ratings velocity |
| RIVAL | Which competitor URL the agent prefers and why | Which competitor app the agent recommends and on which prompts |
| PROTO | Emerging MCP / /.well-known specs | Emerging App Intents, Android Intents, MCP-for-apps specs |
| BUG | Per-LLM hallucinations about your URL, price, claims | Per-LLM hallucinations about features, price, platform, regions |
| SIGNAL | Sitemaps, citations, change feeds | Curated app lists, editorial coverage, Wikidata grounding |
| MCP | Public MCP server discoverable at /.well-known/mcp.json + registry presence, OpenAPI / function-calling surface | All invocation surfaces for an app live here: App Intents (iOS), App Actions (Android), ChatGPT Apps SDK manifest, Copilot connector, Perplexity action, and MCP-for-apps so agents can invoke in-app actions (search, add-to-cart, book) without screen-scraping. Orthogonal to AAIO (recommendation). |
| SOCIAL | X / LinkedIn / Reddit handle consistency + authoritative bios that retrieval grabs | Social proof anchoring the app's brand identity when agents triangulate beyond the store listing |
What changes in the UI when you flip modes
- The ARO factor count in copy goes from 130+ for web to 200+ for app, or 210+ for MCP / API audits.
- Intel metrics swap: Mindshare → Agent recommendation share; Citation share → Install-intent share; Retrieval inclusion → Handoff CVR.
- Optimizer Push-to-Live targets swap: edge worker / CMS / /.well-known/ → App Store Connect drafts / Play Console drafts / repo PRs.
- Connections checklist swaps: CMS + edge + DNS → App Store Connect API key, Play Console service account, app repo.
Where to read next
- Methodology — full data-source breakdown per surface.
- Scoring & weighting — the indicative per-mode weight table.
- The 12 pillars — definitions with App-mode lines.
- Reading the numbers — App-mode metrics you'll only see when auditing an app.
- Glossary — App Intents, AASA, assetlinks, ATT and the rest.