App Indexing (App Deep Linking for Search)

TL;DR — “App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” was an old Google feature that pulled content out of your phone app and showed it in search results. Google shut it down. What people use now is called app deep links — links that, if you already have an app installed, open a search result inside the app instead of in your phone’s browser. The important part: this doesn’t help you rank higher. Google still ranks your website; deep links just change where the tap lands.

What “App Indexing” was

Years ago, Google let you connect your website to your native mobile app so that Google could show your app’s content — and links straight into it — in search results. That system was called App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. (and later Firebase App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.). If you searched for something and had the matching app installed, Google could send you into the app instead of a web page.

If you’re reading this because you foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. “App Indexing” in an old SEO checklist, a developer doc, or a plugin setting, here’s the short answer: it’s deprecated. Google turned it off. You don’t need to set it up, and if a tutorial tells you to, that tutorial is out of date.

What replaced it

The modern version of “open my app from a search result” is called app deep links, and each platform has its own name for it:

• Android calls it App Links.
• iOS calls it Universal Links.

Both do the same job: when someone taps a link to your site — from a Google result, another website, or an app — and they already have your app installed, the phone opens that content inside your app. If they don’t have the app, the same link just opens in their browser like normal.

The thing most people get wrong

App deep links do not help you rank. This is the myth to unlearn. Older articles claim that “indexing your app” boosts your rankings. Google has said plainly that it doesn’t — Search still uses your web page’s content to decide how you rank. Deep links only change the experience after someone clicks, for people who have your app. They’re a convenience feature, not a ranking trick.

There’s one real rule if you set them up: the app screen you link to should show the same content as the web page. Google builds the search snippet from your web page, so if the app shows something different, you’ve misled the person who tapped.

Want the full history, the exact files and steps for Android and iOS, and how to measure this in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.? Switch to the Advanced tab.

TL;DR — Google App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (2013) → Firebase App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. (2016, plus a short-lived “app streaming” experiment) → deprecated by ~2021. The successor is app deep links: Android App Links (verified with a Digital Asset Links file at /.well-known/assetlinks.json plus android:autoVerify intent filters) and iOS Universal Links (verified with an apple-app-site-association file plus the Associated Domains entitlement). Per Google’s May 2025 guidance, deep links don’t change indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. or ranking — Search still ranks the web page — and the deep-link destination should correspond to the web URL’s content. Measure app-link behavior with platform and app analytics rather than assuming a dedicated Search Console report is available.

Three eras, one confusing name

The reason “App Indexing” causes so much confusion is that the same idea wore three different names over a decade, and the last transition was a deprecation that a lot of older content never caught up to.

2013–2016 — Google App Indexing. In October 2013 Google announced that “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. can now index content in your Android app,” surfacing deep links to the app “straight in our search results when we think they’re relevant… and if the user has the app installed.” You declared app content through your existing sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. and Webmaster ToolsThe free, first-party consoles search engines give site owners — Google Search Console and Bing Webmaster Tools — to see how their pages are crawled, indexed, and ranked, and to fix problems. The legacy name is 'webmaster tools.'. This was Google crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. inside apps, the way it crawls web pages.

2016–~2021 — Firebase App Indexing. After Google’s 2014 Firebase acquisition, App Indexing was rebranded Firebase App Indexing around Google I/O 2016. It added iOS support and, for a while, an experiment called app streaming — a “Try Now” button that let users run an uninstalled app in-browser for a few minutes, straight from a search result. App streaming was a limited 2015–2016-era experiment and is long gone; don’t plan around it.

~2021–present — deprecated. The AppIndexApi interface is marked deprecated in Google’s own Android reference docs. Firebase’s live documentation now states that Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App,” with an explicit caution that “the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.” Firebase now points you to App Links and Universal Links as the recommended path. (The cutover landed in 2021 — the deprecation notice is present in an October 2022 archive snapshot but absent from October 2020.)

What replaced App Indexing: app deep links

Deep links are, in Google’s words, “special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content.” The key mental shift from the old model: this is verification and routing, handled at the OS and browser level — not a Google-run indexing pipeline. Nothing here is “submitted to an index.”

Android App Links (Digital Asset Links / assetlinks.json)

Android App Links are, per Google, “an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website. After they are verified, deep links to your website can immediately open corresponding content in your app, without requiring the user to select your app from a disambiguation dialog.” App Links is supported on Android 6 and later, and Google calls it “a recommended approach” for deep links to your own site.

The verification handshake is a Digital Asset Links file. When you put android:autoVerify="true" on an intent filter and the app is installed, “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” That JSON file lists which app package (and signing-cert fingerprint) is allowed to handle your domain’s links. Android 15 adds Dynamic App Links, letting you refine URL-matching behavior without shipping a new app version.

Two version/signing boundaries matter here. First, Dynamic App Links extend the underlying manifest association rather than replace it — on Android versions before 15, verification still runs on the standard manifest/assetlinks.json match alone. Second, verification fails outright, not partially, if the signing-certificate fingerprint listed in assetlinks.json doesn’t exactly match the installed build’s actual signing identity — a debug build signed with a different key than the assetlinks.json entry will never verify, even if every other field is correct.

The distinction worth keeping straight: a basic Android deep link uses intent filters but can trigger the “which app do you want to open this with?” disambiguation dialog. App Links add the Digital Asset Links verification so a verified domain opens directly in your app, no dialog.

iOS Universal Links (apple-app-site-association)

Apple’s equivalent is Universal Links. Apple: “When users tap or click a universal link, the system redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. the link directly to your app without routing through the person’s default web browser or your website… because universal links are standard HTTP or HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' links, one URL works for both your website and your app. If the person hasn’t installed your app, the system opens the URL in their default web browser.”

The verification file here is apple-app-site-association, hosted on your web server: “When someone installs your app, the system checks a file stored on your web server to verify that your website allows your app to open URLs on its behalf.” On the app side you need the Associated Domains entitlement matching the domains in that file. Same principle as Android — a trust handshake between the site and the app, checked by the device, not a search-ranking signal.

A valid apple-app-site-association file and a correctly matching entitlement don’t guarantee every tap opens the app, though. Apple documents real cases where a Universal Link still opens in Safari despite a working association — for example when the link is tapped from within Safari itself while already browsing the same domain, or when the person has previously chosen to keep opening that domain’s links in the browser. And when the app genuinely isn’t installed, or the association doesn’t match, a standard HTTP(S) link is supposed to fall back to opening in the browser rather than dead-ending on a broken custom scheme — that fallback is the system working as designed, not a bug to chase.

Both platforms are supported by Google Search as deep-link targets.

Do app deep links affect rankings? (No — and here’s the exact quote)

This is the single most important correction in this whole topic, because ranking pages still get it wrong. You’ll find articles claiming things like “App Indexing will influence ranking… whether or not the user has your app installed” or “Google will use the content within your app as a signal in ranking.” Those claims are false, and Google’s own May 2025 post says so directly:

“Adding deep links to your website connects the website’s URLs with the relevant app pages. It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking. App deep links enable users to go from Search results directly to the corresponding app page (if installed), resulting in a better user experience.”

Read that carefully: the web page is what’s indexed and ranked. The deep link is a post-click routing layer that only kicks in for users who already have the app. It’s a UX improvement, not a visibility lever. If someone tells you configuring assetlinks.json will lift your rankings, they’re wrong.

The one real requirement: content parity

There is exactly one substantive rule, and it’s about honesty to the user. Google:

“Because Search uses your web page content for indexing and ranking, you should only add deep links in cases where the app page contains the same content as the corresponding web page. Otherwise, the title and snippet shown for the page in Google Search could mislead users about the content they will see after they click. Layout or other UX differences between app pages and the corresponding web pages are OK, as long as the content matches.”

So: a native, prettier, differently-laid-out app screen is fine. A screen showing different content than the web page is not — because the snippet the user tapped was built from the web page, and now they’ve landed somewhere that doesn’t match. Parity is about content, not appearance.

How to implement it today

Android: Use App Links. Associate your app with your website in the app manifest (intent filters with android:autoVerify="true"), then publish /.well-known/assetlinks.json on your site listing your app’s package name and signing-certificate fingerprint. Android verifies the association on install. The Android Studio App Links Assistant and the Play Console’s Deep Links page help you generate and validate the setup.

iOS: Implement Universal Links. Publish an apple-app-site-association file on your web server describing which paths map to your app, and add the Associated Domains entitlement in your app for the matching domains. Apple’s Universal Links debugging guidance walks through common failures (wrong content-type on the file, missing entitlement, cached association).

Neither file is crawled into a “search index” the way App Indexing implied — they’re trust handshakes the device checks. Get them wrong and links simply fall back to the browser; get them right and installed users route into the app.

How to measure it: Search Console’s Android app filter

Google exposes app-deep-link performance natively: “Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. includes performance of your site’s app deep links for Android. In the Performance reportThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data., you can use the Android App Search appearance filter to see when your Android app deep links are found and shown to users.” That gives you clicks, impressions, CTR, and position for results where the Android app deep link appeared — the concrete, current way to see whether any of this is doing anything. (This filter was added back in 2019; it’s still the current tool per Google’s 2025 post.)

Keep the two jobs separate, though. The Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. filter is a traffic/appearance report — Android-only, dependent on Google actually surfacing the app-deep-link treatment for a given query, and not itself proof that anything is indexed or ranking. Confirming a deep link technically works is a different exercise: fetch the association files and test tap-through on real devices (see the Scripts and Validation Tests tabs). Don’t treat a quiet Search Console report as evidence your setup is broken, and don’t treat clicks in the report as an SEO signal — it’s telling you about routing volume, not ranking.

Bing and app deep links

Don’t assume Google/Bing parity here. Bing ran a Windows-centric “app linking” program starting in April 2014, aimed at Windows 8.1 and Windows Phone — but those pages are now dead (the dev URL returns a 404, the blog posts redirect to the generic blog homepage), and Windows Phone itself was discontinued. There is no current, Bing-published equivalent of Google’s 2025 app-deep-links guidance. The practical upshot: App Links and Universal Links still function in Bing/Edge on mobile because they’re OS- and browser-level standards, not something a search engine has to opt into — so you implement them the same way regardless. There’s just no Bing doc to point at.

Legacy things you’ll still see in the wild

A couple of adjacent techniques cause confusion, so name them and move on:

• potentialAction / ViewAction schema.org markup with an android-app:// deep-link target. This is a legacy technique tied to the old App Indexing era. You may still find it in codebases and schema.org’s action vocabulary, but Google’s current recommendation is App Links / Universal Links configuration, not this markup. Treat it as “you may still see this,” not as a recommendation.
• Firebase Dynamic Links is a different, separately-deprecated Firebase product — a URL-shortening / deferred-deep-linking service for marketing attribution, not the App Indexing content system. It’s being sunset too, and its own migration guidance also points to App Links and Universal Links. Don’t conflate the two deprecations.

The clean model to walk away with: (1) old Google App Indexing / Firebase App Indexing crawl-and-stream system = dead; (2) App Links / Universal Links deep linking = current, routing/UX only, no ranking effect; (3) Bing’s old Windows-era app-linking = also dead, no documented replacement.

AI summary

A condensed take on the Advanced version:

• App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. is deprecated. Google App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. (2013) → Firebase App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (2016) → deprecated ~2021. The AppIndexApi is marked deprecated in Google’s docs; the Google Search app no longer uses Firebase App Indexing content.
• What replaced it: app deep links — Android App Links (verified via a Digital Asset Links file at /.well-known/assetlinks.json + android:autoVerify intent filters) and iOS Universal Links (verified via apple-app-site-association
  • the Associated Domains entitlement). These are OS/browser-level verification and routing, not a Google-run index.
• Deep links do NOT affect ranking. Per Google’s May 2025 post: they “don’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” They only route installed users into the app after a click.
• The one real rule is content parity: only deep-link an app screen that shows the same content as the web page (layout/UX differences are fine).
• Measure it with Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Android app Search-appearance filter — but that’s a traffic report, not proof the technical association works or that anything ranks differently; verify the association itself with device/file tests.
• Neither platform guarantees every verified tap opens the app. Android verification fails outright on a signing-certificate mismatch (Dynamic App Links on Android 15 extend, not replace, the manifest match); iOS documents legitimate cases — same-domain Safari browsing, prior user choice — where a Universal Link still opens in the browser despite a working association.
• Bing has no current equivalent guidance; its Windows-era program is dead, but App Links/Universal Links still work in Edge because they’re OS-level standards.
• Don’t confuse App Indexing with Firebase Dynamic Links (a separate, separately-deprecated product), or treat potentialAction/ViewAction markup as current best practice.

Official documentation

Primary-source documentation from Google, Android, and Apple.

Google — current guidance

• App deep links: connecting your website and app (May 2, 2025) — the current, authoritative explainer: what deep links do, the no-ranking-effect statement, content parity, and the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. filter.
• Firebase App Indexing — the live page carrying the deprecation notice and the pointer to App Links / Universal Links.

Google — historical (for context on what’s deprecated)

• Indexing apps just like websites (Oct 31, 2013) — the original App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. announcement.

Android

• About deep links — deep links, App Links, and the verification model (updated 2026-06-18).
• Verify Android App Links — android:autoVerify and the Digital Asset Links / assetlinks.json requirement.

Apple

• Allowing apps and websites to link to your content — Universal Links overview and the server-file verification model.
• Supporting associated domains — the apple-app-site-association file and the Associated Domains entitlement.

Industry standard (not Google-specific)

• ViewAction / Actions (schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor.) — the legacy potentialAction/ViewAction vocabulary; useful context, not a current Google recommendation.

Quotes from the source

On-the-record statements from Google, Android, and Apple. Each Google/Android link is a deep link that jumps to the quoted passage on the source page.

Google — the original App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. announcement (2013)

• “Just like it crawls and indexes websites, GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. can now index content in your Android app… If both the webpage and the app contents are successfully indexed, Google will then try to show deep links to your app straight in our search results when we think they’re relevant for the user’s query and if the user has the app installed.” — Lawrence Chang, Product Manager, Google. Jump to quote

Google — Firebase App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. is deprecated (live docs)

• “Firebase App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. is no longer the recommended way of indexing content for display as suggested results in Google Search App.” Jump to quote

Google — deep links don’t change ranking (May 2025)

• “It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” — John Mueller (Google Search Relations) and Sabs (Android Developer Relations). Jump to quote
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” Jump to quote

Android — App Links and the verification file

• “Android App Links is an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website.” — Android Developers. Jump to quote
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” Jump to quote

Apple — Universal Links

• “When users tap or click a universal link, the system redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. the link directly to your app without routing through the person’s default web browser or your website… If the person hasn’t installed your app, the system opens the URL in their default web browser.” — Apple Developer Documentation, “Allowing apps and websites to link to your content.”

Should you set up app deep links?

A quick path through the “do I even need this?” question — because for a lot of sites the honest answer is “no.”

1. Do you have a native mobile app that mirrors your website’s content?

• No app → Stop. There’s nothing to deep-link. App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. / deep links are irrelevant to you. (And if you foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. “App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page.” in a checklist, delete that line — it’s deprecated.)
• Yes → continue.

2. Are you doing this for rankings?

• Yes → Stop and re-read. Deep links don’t affect indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. or ranking. If SEO visibility is the goal, invest in your mobile web page, not deep-link plumbing.
• No — I want installed users routed into the app → continue.

3. Does the app screen show the same content as the matching web page?

• No (different content) → Don’t deep-link that URL. A mismatch misleads users, because the snippet was built from the web page. Fix parity first (layout/UX differences are fine — content differences are not).
• Yes → continue.

4. Which platform(s)?

• Android → App Links: android:autoVerify intent filters + a Digital Asset Links file at /.well-known/assetlinks.json.
• iOS → Universal Links: apple-app-site-association on your server + the Associated Domains entitlement.
• Both → do both; they’re independent.

5. How will you know it’s working?

• Check Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Android app Search-appearance filter for Android.
• Test the actual tap-through on real devices, and validate the association files (App Links Assistant on Android; Apple’s Universal Links debugging on iOS).

Rule of thumb: deep links are a UX/routing upgrade for sites with a real, content-matching app — not an SEO ranking project, and not something to bolt on just because an old guide mentioned “App Indexing.”

App deep link setup checklist

Only relevant if you have a native app that mirrors your web content:

• Confirmed you’re not expecting a ranking lift — deep links change routing, not ranking.
• Content parity verified: each deep-linked app screen shows the same content as its corresponding web page (layout/UX differences are OK).
• Android: intent filters use android:autoVerify="true" for your domain.
• Android: /.well-known/assetlinks.json published, served over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' with the correct content type, listing your app’s package name and signing-cert fingerprint.
• iOS: apple-app-site-association published on your server (correct content type, no redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.) with the right path patterns.
• iOS: Associated Domains entitlement added in the app, matching the domains in the association file.
• Tested real tap-throughs on physical Android and iOS devices (installed and not-installed cases).
• Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Android app Search-appearance filter reviewed for impressions/clicks once live.
• Removed any deprecated references — old App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. tags, Firebase App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. SDK calls, or potentialAction/android-app:// markup you were relying on as “the” mechanism.

Anti-patterns to avoid

• Treating App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. as current. The AppIndexApi is deprecated and the Google Search app no longer uses Firebase App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. content. If a guide, plugin, or checklist tells you to “enable App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.,” it’s out of date.
• Expecting a ranking boost. The most-repeated myth on old ranking pages: “indexing your app influences ranking.” Google says the opposite — Search ranks the web page; deep links don’t change that.
• Deep-linking to mismatched content. Sending a user who tapped a web-page snippet into an app screen with different content. Google explicitly warns this misleads users. Parity is about content, not looks.
• Chasing “app streaming.” The “Try Now” preview-an-uninstalled-app feature was a 2015–2016 experiment and is gone. Don’t design around it.
• Confusing Firebase App Indexing with Firebase Dynamic Links. Different products, both deprecated, solving different problems (content indexing vs. URL-shortening/attribution). Both point to App Links / Universal Links now.
• Assuming Bing parity. Bing’s old Windows-era app-linking program is dead with no documented replacement. App Links/Universal Links still work in Edge because they’re OS-level standards — but there’s no Bing doc to follow.
• Skipping verification and wondering why it “doesn’t work.” A wrong content type, a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. on the association file, or a missing entitlement silently drops you back to the browser. The files are a strict handshake, not a suggestion.

Common app deep-link failures

A web link still opens in the browser on Android

Symptom: An installed app does not claim a matching HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' URL. Likely cause: Domain verification failed because the manifest host, package name, signing certificate fingerprint, or assetlinks.json response does not match. Fix: Check the installed build’s signing identity, fetch the association file directly, and rerun Android’s link verification before testing the tap again.

A Universal Link opens Safari instead of the iOS app

Symptom: The same HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' URL works on the web but bypasses the installed app. Likely cause: The Associated Domains entitlement or the apple-app-site-association paths do not authorize the URL — but check the documented non-broken cases first: Apple’s own guidance describes links tapped inside Safari on the same domain, or a domain the person previously chose to keep opening in the browser, as expected browser-opens, not verification failures. Fix: Confirm the domain entitlement, file availability, and path rules, then retest after reinstalling or refreshing the device’s association state — and rule out same-domain or prior user-choice behavior before assuming the association is broken.

The app opens to the wrong screen

Symptom: Verification succeeds but the app lands on a homepage or mismatched content. Likely cause: The OS association is correct while the app’s route mapping is incomplete. Fix: Map the incoming path and parameters to the corresponding screen, preserve a safe web fallback, and compare the app content with the web page that supplied the search snippet.

App deep links — cheat sheet

Then vs. now

Verification files

Fast facts

• Deep links change routing after a click, not indexing or ranking.
• Only deep-link app screens with content matching the web page.
• Android needs android:autoVerify="true" intent filters.
• iOS needs the Associated Domains entitlement.
• Measure with GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Android app Search-appearance filter.
• Bing: no current equivalent guidance; standards still work in Edge.

Check your association files

Deep links fail silently, so the fastest debugging step is confirming the two verification files exist, return 200, and serve the right content type.

macOS / Linux — fetch and inspect the files

# Android — Digital Asset Links. Expect HTTP 200 and application/json.
curl -sI https://example.com/.well-known/assetlinks.json | grep -iE "HTTP/|content-type"
curl -s https://example.com/.well-known/assetlinks.json | head

# iOS — apple-app-site-association. Must be 200, JSON, and NOT redirected.
# -L follows redirects; if the final URL differs, that's a problem for iOS.
curl -sIL -o /dev/null -w "final: %{url_effective}  code: %{http_code}\n" \
  https://example.com/.well-known/apple-app-site-association

Windows (PowerShell)

# Android
(Invoke-WebRequest -Uri "https://example.com/.well-known/assetlinks.json").Headers["Content-Type"]

# iOS — confirm status and that it isn't redirecting away
Invoke-WebRequest -Uri "https://example.com/.well-known/apple-app-site-association" -MaximumRedirection 0

Browser DevTools console — quick reachability check

// Paste in the console on your own domain. Both should log ok:true.
["/.well-known/assetlinks.json", "/.well-known/apple-app-site-association"]
  .forEach(async p => {
    const r = await fetch(p, { redirect: "manual" });
    console.log(p, "ok:", r.ok, "type:", r.headers.get("content-type"));
  });

Bookmarklet — one-click check on the current site

javascript:(async()=>{for(const p of["/.well-known/assetlinks.json","/.well-known/apple-app-site-association"]){try{const r=await fetch(p,{redirect:"manual"});alert(p+"\nstatus: "+r.status+"\ntype: "+(r.headers.get("content-type")||"—"));}catch(e){alert(p+" — fetch failed: "+e.message);}}})();

If a file 404s, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., or serves the wrong content type, the OS won’t verify the association — and links quietly fall back to the browser instead of opening the app.

Tools for setting up and debugging deep links

• Android Studio — App Links Assistant — generates intent filters, creates and validates your Digital Asset Links (assetlinks.json), and tests link handling.
• Google Play Console — Deep Links page — surfaces the status of your app’s deep links and verification.
• Digital Asset Links validation — verify that your published assetlinks.json correctly associates your domain and app package/fingerprint.
• Apple Universal Links debugging — Apple’s guidance for diagnosing why a Universal Link opens the browser instead of the app (association-file content type, entitlement, cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency.).
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Performance reportThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. — the Android app Search appearance filter shows impressions, clicks, CTR, and position for results where your Android app deep link appeared.
• curl / DevTools / a bookmarklet — the fastest first check that both association files return 200 with the right content type and no redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. (see the Scripts tab).

Resources worth your time

My writing

• Mobile-First Indexing Goes Mobile-Only — the related-but-distinct concept of which version of your page Google indexes (don’t conflate it with app deep linking).
• The Beginner’s Guide to Technical SEO — where mobile and app-adjacent topics fit the bigger crawl/indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed./rank picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, including how GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls as a smartphone. (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• App deep links: connecting your website and app (Google) — the current, authoritative guidance and the source of the no-ranking-effect and content-parity statements.
• Firebase App Indexing (Google/Firebase) — the live deprecation notice pointing to App Links / Universal Links.
• About deep links (Android) — App Links and the verification model.
• Verify Android App Links (Android) — the assetlinks.json requirement.
• Allowing apps and websites to link to your content (Apple) — Universal Links and apple-app-site-association.
• Google App Indexing Becomes Firebase App Indexing (Search Engine Land) — Barry Schwartz’s coverage of the 2016 rebrand at Google I/O.

Stats worth citing

• App deep links don’t change indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. or ranking — Google’s own May 2025 statement: Search “continues to use the content of your web pages for indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. and ranking.” The most important, most-misreported fact on this topic. Source
• Firebase App IndexingApp Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page. is deprecated — the Google Search app for Android “no longer uses local content indexed via Firebase App Indexing,” per Firebase’s live docs. The transition landed in 2021 (present in an Oct 2022 archive, absent from Oct 2020). Source
• App Links supported on Android 6+ — Google calls App Links “a recommended approach” for deep links to your own website, verified via the Digital Asset Links file at /.well-known/assetlinks.json. Source

Prompts for app deep-link QA

Review Android association data

Review this Android intent-filter and assetlinks.json together. Check host/path
coverage, android:autoVerify, package name, relation value, and certificate
fingerprints for internal consistency. Return: definite mismatches, items that require
device verification, affected URL patterns, and exact tests to run. Do not assume an
unshown signing certificate or redirect behavior.

MANIFEST:
[paste]

ASSETLINKS_JSON:
[paste]

Build a content-parity test matrix

Turn this list of web URLs and intended app destinations into a QA matrix. For each
row include web content identity, Android destination, iOS destination, installed-app
behavior, no-app fallback, and a pass/fail content-parity check. Flag rows where the
app screen's content appears different from the web page; do not treat layout changes
as content mismatches.

[paste URL-to-screen mapping]

Validate an app deep-link release

Test the public association files

Test to run: Fetch both well-known association endpoints without cookies or authentication and validate their JSON. Expected result: Successful responses contain the production app identifiers, fingerprints, and intended path rules. Failure interpretation: Devices cannot verify the site-app relationship. Monitoring window: Immediate after deployment and after certificate changes. Rollback trigger: Either file errors, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. unexpectedly, or authorizes the wrong production identity.

Test installed and uninstalled behavior

Test to run: Tap representative HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' links on real Android and iOS devices with the app installed, then without it. Expected result: Installed users reach the matching app screen; other users reach the same web URL. Failure interpretation: Verification, routing, or fallback behavior is incomplete. Monitoring window: Immediate for every app release. Rollback trigger: Links dead-end, open the wrong screen, or cannot fall back to the web.

Test content parity

Test to run: Compare the searchable content of each web result with its app destination. Expected result: The subject and substantive content match, even if layout differs. Failure interpretation: The deep link can mislead users because Search indexes the web page. Monitoring window: Before mapping a route and after major content-template changes. Rollback trigger: The app destination no longer fulfills the web result’s title and snippet.

Measure app deep-link health

Android app search appearance

Metric: Impressions and clicks for the Android App search appearance. What it tells you: How often Google surfaced results with an Android deep-link treatment and how much traffic used them. How to pull it: Search Console PerformanceThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data., filtered to Android App search appearance. Benchmark / realistic range: Establish a baseline by query and page; eligibility depends on app adoption and relevant results, so there is no universal target. Cadence: Monthly, with release annotations.

Successful route-open rate

Metric: Valid deep-link opens divided by app-link attempts. What it tells you: Whether verified links reach the intended screen rather than a fallback or error. How to pull it: App analytics events at link receipt and destination render, excluding sensitive URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO.. Benchmark / realistic range: Use your own platform and version baseline; investigate sustained regression after a release. Cadence: Weekly and per app release.

Parity exception count

Metric: Mapped web URLs whose app destination no longer contains equivalent content. What it tells you: Whether routing still meets the central content-parity requirement. How to pull it: A maintained URL-to-screen inventory plus release QA. Benchmark / realistic range: Zero known exceptions is the appropriate target. Cadence: Each release and after major web or app information-architecture changes.

Test yourself: App Indexing

Five quick questions on what App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. was, what replaced it, and what it actually does for SEO. Pick an answer for each, then check.

App Indexing

App Indexing was Google's now-deprecated system (2013–~2021) for indexing native app content and streaming uninstalled apps into search results. It's been replaced by app deep links — Android App Links and iOS Universal Links — which route users who have the app installed from a search result into the matching in-app screen. Deep links don't change indexing or ranking; Google still ranks the web page.

Related: Mobile-First Indexing, Mobile SEO

App Indexing

App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. originally referred to a Google Search feature (launched in 2013, later folded into “Firebase App IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” in 2016) that crawled and indexed content inside native Android and iOS apps and surfaced deep links — and, briefly, streamed uninstalled apps — directly in search results, so users could jump from a Google result straight into an app.

Google deprecated this system. The AppIndexApi interface is marked deprecated in Google’s own Android reference docs, and Firebase’s live docs state Firebase App Indexing “is no longer the recommended way of indexing content for display as suggested results in Google Search App.”

The successor mechanisms today are Android App Links (verified via a Digital Asset Links file at /.well-known/assetlinks.json) and iOS Universal Links (verified via an apple-app-site-association file) — collectively “app deep links.”

The most important current fact: configuring app deep links does not change indexing or ranking. Google Search continues to rank based on the web page’s content; deep links only affect whether a user who already has the app installed is routed into the app instead of the mobile browser after clicking a search result. The one real requirement is content parity — only deep-link to an app screen that shows the same content as the corresponding web page, since the search snippet is built from that web page.

Related: Mobile-First Indexing, Mobile SEO

Changelog