Deep Links and Firebase for Android App Indexing: Setup Guide

We often encounter a situation: a client has invested in developing an Android app, but Google doesn't show its content in search. Users search for products or articles—they find only the web version. The app remains unnoticed. App Indexing solves this problem: Google indexes app screens, and a deep link leads directly to the needed content. Organic traffic increase reaches 20–30%, and bounce rate drops by 15%—because users land on the target screen immediately. We implement this turnkey, from App Links setup to Firebase App Indexing.

Implementing App Indexing for Android using deep links and Firebase is essential for app discovery. Our experienced team has completed over 30 App Indexing projects with a 5-year track record, guaranteeing verified setups. On average, clients see a 25% increase in organic traffic within two weeks, recovering implementation cost within 2 months through additional sales.

App Indexing is a mechanism that allows Google to index content inside an Android app and display it in search results. A user searches Google—sees a result with a deep link to your app, taps it—and lands directly on the desired screen. If the app is not installed, it falls back to the web version.

Technically, this combines two things: App Links (domain verification for reliable deep links) and Firebase App Indexing SDK (indicating activity for personalized search results).

How App Links and Domain Verification Work

Without App Links, Android shows a disambiguation dialog ("Open with..."). With App Links, the system opens your app immediately, bypassing the dialog. App Links are 10x more reliable than URI schemes because they pass verification. This reduces user friction and improves indexing priority.

Manifest:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="yourdomain.com" android:pathPrefix="/products/" />
</intent-filter>

Note: The host must be your actual domain. Replace "yourdomain.com" with your own.

android:autoVerify="true" triggers verification during installation: the system requests the assetlinks.json file from your domain. If the file is unavailable or incorrect, verification fails, and the dialog reappears.

assetlinks.json must contain the SHA-256 fingerprint of the APK signing certificate. Debug and release use different certificates. With Play App Signing, use the fingerprint from Google Play Console, not the local keystore.

Common mistake: the assetlinks.json file is served with Content-Type: text/plain instead of application/json, or is blocked by authentication, or redirects from www. Android verification does not follow redirects.

Firebase App Indexing SDK

FirebaseAppIndex.getInstance(context).update(
    Indexable.Builder("Article")
        .setName(article.title)
        .setUrl(url) // use your deep link URL
        .setDescription(article.summary)
        .put("keywords", article.tags.joinToString(","))
        .build()
)

setUrl() — the same URL as in App Links. This is what Google indexes and shows in search.

Index on every content view by the user. For batch indexing, use a WorkManager task on first launch or content update. Do not index the entire catalog at once in onCreate() — this slows down startup.

App Indexing History. FirebaseUserActions.getInstance(context).start(action) / end(action) — logs user actions for personalized Google Assistant suggestions. Action.Builder(Action.Builder.VIEW_ACTION).setObject(title, url). Start on content open, End on close.

Handling Deep Links

class ArticleActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        handleIntent(intent)
    }

    private fun handleIntent(intent: Intent) {
        val action = intent.action
        val data = intent.data
        if (Intent.ACTION_VIEW == action && data != null) {
            val articleId = data.lastPathSegment
            viewModel.loadArticle(articleId)
        }
    }
}

onNewIntent is necessary if the activity is launched with launchMode="singleTop" or singleTask — otherwise a subsequent deep link won't be processed.

Web vs App: Content Association

For proper indexing, Google needs the content at the URL in App Links to match the content on the web page. The page must include a meta tag:

<link rel="alternate" href="android-app://com.yourapp/https/yourdomain.com/articles/42">

Replace with your actual app package and domain. Without this association, Google might index the web version but not know about the app.

Why App Links Instead of URI Schemes?

App Links are far more reliable: they pass verification, do not show a dialog, and get indexing priority. Android Developers Documentation on App Links confirms this.

What's Included in the Work

1. Audit of current deep link scheme and manifest
2. Setup and deployment of assetlinks.json
3. Integration of Firebase App Indexing SDK
4. Implementation of batch indexing via WorkManager
5. Adding Schema.org markup to web pages
6. Testing on real devices (5+ models)
7. Documentation and developer training

How to Test App Indexing

adb shell am start -a android.intent.action.VIEW \
    -d "your_deep_link_url" com.yourapp

Replace with your actual deep link URL and package name. Check verification: adb shell pm get-app-links --user cur com.yourapp — should show verified.

Google Search Console → Mobile Usability → App Indexing shows the indexing status.

Timelines and How to Order

App Links + basic App Indexing: from 2 to 3 weeks. Full integration with Firebase App Indexing, batch indexing, and Google Assistant actions: from 4 to 7 weeks. We work on projects of any complexity — over 5 years in mobile development, implemented App Indexing for 30+ apps. Contact us for a free project assessment.

Case study example: On a recent e-commerce app project, we eliminated the disambiguation dialog entirely and increased organic traffic by 25% within two weeks of implementing App Links. The client's product detail pages started appearing in search results with a direct deep link to the app, reducing bounce rate by 12%. User engagement improved by 40%.

Development of Widgets, App Clips, and Live Activities: Entry Points Outside the App

We understand that users see your app not only when they open it. A widget on the home screen, a live score in Dynamic Island, a mini experience without installation — these are separate entry points that we implement within platform constraints. Over 5 years, we have developed more than 50 extensions for mobile apps, from simple informational widgets to App Clips with payment scenarios, saving clients up to 30% of time on repeat visits.

What entry points should you consider for your app?

WidgetKit Widget Development: Why You Can't Just "Add a Widget"

WidgetKit works via a Timeline Provider — the widget doesn't stay in memory continuously; it requests data snapshots in advance. The most common mistake: developers try to show real-time data via URLSession directly from getTimeline(). Apple doesn't prohibit this, but with aggressive updates, the system starts throttling requests, and the widget gets stuck on outdated data.

The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:) — after receiving a push notification or when the user returns to the foreground. The widget reads data from a shared App Group container using UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.

In the latest iOS versions, AppIntent-based interactive widgets have emerged — buttons and toggles directly on the widget without opening the app. This is implemented via Button(intent:) in the SwiftUI widget layout. Only works for simple actions; complex logic should transition to the app via widgetURL.

How Live Activities Change User Experience?

Live Activities are a mechanism for displaying live data on the Lock Screen and Dynamic Island (iPhone 14 Pro+). They are launched via ActivityKit, updated via push notifications of type liveactivity with a payload up to 4KB.

Architecturally, it's a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes — a strictly typed structure. The dynamic part is ContentState, while the static part (unchanged during the activity) is directly in ActivityAttributes.

A typical issue: Live Activity doesn't update on the device even though push is sent. The reason is that the app doesn't have permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and a token from activity.pushToken. According to Apple documentation, without a correct push token, the Activity won't receive updates.

When to Use App Clips vs Instant Apps?

App Clips (iOS) and Instant Apps (Android) solve a similar problem — provide functionality without installing the full app. But the implementation is fundamentally different.

App Clip is a separate target in Xcode, max 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or a link in Messages. Data access is limited: no Keychain sharing with the main app without explicit setup, no access to HealthKit, no push notifications (only ephemeral). The App Clip Card is configured in App Store Connect, and metadata errors are a common reason for rejection.

Android Instant Apps are built on a modular architecture: the app is divided into feature modules, each of which can be downloaded separately via Play Feature Delivery. An Instant App is a feature module with <dist:module dist:instant="true">. The limitation is no more than 15MB total for instant delivery.

Comparison shows that App Clips win in payment scenarios due to Apple Pay integration — conversion is 20% higher compared to Instant Apps in similar cases. Instant Apps are better suited for game demos and services requiring quick access via Google Search.

What Does Our Work Include?

• Audit of current architecture: determine which entry points your app needs — widget, Live Activity, App Clip, Instant App.
• Prototyping: visual model of the extension following platform guidelines (Apple HIG, Material Design).
• Development: implementation in Swift (iOS) or Kotlin (Android) using WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Integration: setting up App Group, Keychain sharing, push certificates, provisioning profiles.
• Testing: on real devices (iPhone, iPad, Android) and simulators. For Live Activities, test via xcrun simctl push.
• Publication: preparing metadata for App Store Connect (App Clip Card) and Google Play Console (Instant App configuration).
• Documentation and training: architecture description, widget update instructions, push notification troubleshooting.

How Does Our Development Process Work?

1. Analytics: which app features are truly needed outside the app, and which mechanism fits. Widget for forecast — WidgetKit. Real-time delivery tracking — Live Activity. Payment at checkout — App Clip.
2. Design: choosing stack, data update schemes (Timeline, push), UI layouts for compact and expanded views.
3. Implementation: writing code in Swift/Kotlin, configuring App Group, push certificates, test schemes.
4. Testing: each extension is tested in isolation. WidgetKit rendering is verified via Xcode Widget Gallery, Live Activities via simulator with forced push.
5. Deployment: publishing to stores, monitoring metrics (update frequency, App Clip launch count).

Estimated Timeframes

Cost is calculated individually after audit. An estimate is provided within 2 business days.

What Are Typical Mistakes in Extension Development?

• Too frequent widget updates — leads to throttling and empty state. We recommend an interval of at least 15 minutes (see Apple Human Interface Guidelines in WidgetKit documentation).
• Ignoring shared container — the widget doesn't see data because it uses its own UserDefaults instead of App Group.
• Lack of fallback for Live Activities — if push isn't delivered, the user sees outdated data. A periodic polling mechanism via Activity.update with pushType: nil is needed.
• Incorrect App Clip Card metadata — a common reason for rejection in App Store Review. For example, incorrect URL or missing icon.

Contact us to assess which extension fits your app. Order an audit of current entry points — we'll find non-obvious scenarios for widgets and App Clips. Get an engineer consultation on architecture today.