App indexing

Definition

App indexing is the practice of making app content discoverable through search, either by indexing the equivalent web page so its result opens in the app via a verified link, or by submitting that content to the device's own search index.

Almost everything written about app indexing describes a system that no longer exists. Google's App Indexing programme shipped in 2015, moved under Firebase, and was deprecated along with the android-app:// sitemap annotation that fed it — there is no separate app index to submit to any more. What survives are two unrelated mechanisms that both get called app indexing, and conflating them is why teams add markup that does nothing.

The two things called app indexing

The distinction that matters commercially is the last two rows. Only the web side can bring you a user who does not have the app, because only the web side has something for a crawler to fetch. On-device indexing is a retention surface: it makes content the user has already seen findable again without opening your app first.

The web side: index the page, let the link do the routing

The working model is unglamorous. Publish the content at a real URL, mark it up so it can earn a rich result, and verify your domain for App Links and Universal Links. Google Search on Android hands a verified App Link to the app when the user has it installed and to the browser when they do not — with no app-specific submission, sitemap annotation or SDK involved.

<!-- RETIRED. The android-app:// sitemap annotation fed Google's
     App Indexing programme. It is no longer supported and adds
     nothing to a sitemap today. Delete it if you still ship it. -->
<url>
  <loc>https://example.com/product/42</loc>
  <xhtml:link rel="alternate"
              href="android-app://com.example.app/https/example.com/product/42" />
</url>

<!-- CURRENT. An ordinary sitemap entry. The app association is
     declared out-of-band in assetlinks.json and the AASA file,
     not per-URL in the sitemap. -->
<url>
  <loc>https://example.com/product/42</loc>
  <lastmod>2026-09-11</lastmod>
</url>

<!-- iOS: the banner is also the signal Applebot reads to connect
     this page to your App Store listing. -->
<meta name="apple-itunes-app"
      content="app-id=123456789, app-argument=https://example.com/product/42">

The apple-itunes-app meta tag does double duty: it renders a Smart App Banner and it associates the page with your App Store listing for Apple's crawler. The app-argument is the URL your app receives when the banner is tapped, so it should be the same canonical URL as loc rather than a bare homepage — a mismatch here is a common cause of a banner that opens the app on the wrong screen.

The device side: submitting content to Spotlight

On-device indexing is a live, supported API on both platforms and is worth doing for a content-heavy app. On iOS it is NSUserActivity for things the user visited and CoreSpotlight for a bulk catalogue; the important detail is that the activity must carry the same URL your Universal Link uses, so that a Spotlight result and a search result route through one code path.

import CoreSpotlight
import MobileCoreServices

func indexProduct(id: String, name: String, summary: String) {
    let attributes = CSSearchableItemAttributeSet(itemContentType: "public.url")
    attributes.title = name
    attributes.contentDescription = summary

    let activity = NSUserActivity(activityType: "com.example.app.viewProduct")
    activity.title = name

    // The same canonical URL the Universal Link uses. This is what
    // lets one router handle a Spotlight tap and a web link tap.
    activity.webpageURL = URL(string: "https://example.com/product/\(id)")
    activity.contentAttributeSet = attributes

    activity.isEligibleForSearch = true        // this device's index
    activity.isEligibleForHandoff = false
    // Only set this if the content is genuinely public — it makes
    // the item a candidate for Apple's server-side index.
    activity.isEligibleForPublicIndexing = true

    activity.becomeCurrent()
}

The practical failure mode on the device side is routing, not indexing. A Spotlight result hands your app an NSUserActivity rather than a URL open, so an app whose deep link handling lives only in the URL callback receives the activity and does nothing. Both entry points need to converge on the same router — the same requirement that makes how to test a deep link worth running for every surface rather than once for the browser.

For measurement, neither side gives you campaign attribution. An indexed result is organic by definition: there is no click identifier in a search result that opens your app, so the install shows up with no source unless the landing page attaches one. If organic app-opens matter to your reporting, tag the canonical URL's own query parameters server-side and treat the result as a channel rather than a campaign — see why installs go unattributed for the wider version of this problem.