assetlinks.json (Digital Asset Links)
assetlinks.json is a file at /.well-known/assetlinks.json that proves a website and an Android app belong to the same owner. It lets links to your site open straight in your app, and enables shared sign-in and Trusted Web Activities.
  • The file must live at https://yourdomain/.well-known/assetlinks.json on every host your app handles.
  • Serve it over HTTPS, as application/json, with a 200 and no redirects.
  • If you use Play App Signing, take the SHA-256 fingerprint from Play Console, not your local keystore.
  • Android 15 and later support dynamic rules in the file, so you can change which paths open the app without shipping an update.
  • Firewalls and bot protection must not block Google's verifier from fetching the file.

assetlinks.json is the website half of Google's Digital Asset Links protocol. It is a small JSON file that states which Android apps are allowed to act on behalf of your domain. When it matches the app's own declaration, Android treats links to your site as verified App Links and opens them directly in the app, with no "Open with" prompt.

What it is used for

  • Android App Links: taps on your URLs, from search results, email or messages, open the right screen in your app.
  • Shared sign-in: saved passwords and passkeys can be shared between your site and app (the get_login_creds relation).
  • Trusted Web Activities: a web app wrapped as an Android app needs this file to show full screen, without a browser bar.

It is not a ranking factor. Its SEO value is in the user journey: app users who search on Android land in the app, and broken verification quietly sends them to the mobile web or a disambiguation dialog.

Basic example

 [{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.app",
    "sha256_cert_fingerprints": ["14:6D:E9:83:...:44:E5"]
  }
}]
  • package_name is the app's application ID.
  • sha256_cert_fingerprints can hold several fingerprints, for example release and debug keys.
  • The app's manifest must declare matching intent filters with android:autoVerify="true" .

Hosting requirements

  • Location: https://example.com/.well-known/assetlinks.json , at the root of the host.
  • HTTPS only, even if the app's intent filters also list http.
  • Content-Type: application/json .
  • A direct 200 response. No 301 or 302 redirects, including www to non-www.
  • One file per host. If the app handles example.com and www.example.com, both need it.
  • Publicly reachable, not behind a login, VPN or geo-block.

Play App Signing

Most apps are now signed by Google Play. The fingerprint from your local keystore will not match what users have installed. Copy the correct fingerprint, or the ready-made snippet, from Play Console under Release, Setup, App signing.

Dynamic rules (Android 15 and later)

On Android 15 and later, devices with Google services re-fetch the file and can apply extra path rules, so you can change which URLs open the app without releasing a new version:

 "relation_extensions": {
  "delegate_permission/common.handle_all_urls": {
    "dynamic_app_link_components": [
      {"/": "/checkout/*", "exclude": true},
      {"/": "/products/*"}
    ]
  }
}

Rules can match paths ("/"), query parameters ("?") and fragments ("#"). The first match wins, and a URL matching no rule stays on the web. Dynamic rules can only narrow what the manifest allows, never widen it. Older Android versions ignore them.

The iOS equivalent

Apple's version is apple-app-site-association , also served from /.well-known/. Most teams with both apps maintain the two files together, so keep them in your deployment checklist side by side.

Common mistakes

  • Using the upload key fingerprint instead of the Play App Signing key.
  • Serving the file through a redirect, or only on one hostname.
  • Wrong Content-Type, or a CMS returning an HTML 404 page with a 200 status.
  • A CDN or firewall challenging Google's fetcher, so verification silently fails.
  • Trailing commas or comments. JSON allows neither, and one syntax error invalidates the whole file.
  • Dropping the file during a site migration or platform change.

How to test

  • Open the URL in a browser and check the status code and Content-Type with curl -I .
  • Use Google's Digital Asset Links statement tester, or query the API at digitalassetlinks.googleapis.com.
  • On a device, adb shell pm get-app-links com.example.app shows whether each domain is verified.
  • Check Play Console's deep links report for verification errors.

Hosting it on a site builder

Some website builders do not let you upload files to /.well-known/. If yours does not, options include serving it from your CDN at the edge (for example a Cloudflare Worker or a static rule) or asking the platform's support team. Whatever you use, it must return the file directly, not redirect to it.

Related guides