In diesem Ratgeber
Ziel: Wer auf deiner Website ist oder einen geteilten Link antippt, landet dort, wo er hin soll: in deiner App, wenn sie installiert ist, sonst auf der Store-Seite.
Drei Bausteine
- Smart App Banner (iOS). Ein Banner, das Safari auf deiner Webseite anzeigen kann und das deine App öffnet oder anbietet. Gesetzt wird es per Meta-Tag im Seitenkopf. Tag-Name, Felder und unterstützte Browser behandelt diese Seite nicht; lies vor der Umsetzung Apples aktuelle Dokumentation („Promoting Apps with Smart App Banners“).
- Deep Link. Ein Link, der einen bestimmten Bildschirm der App öffnet, nicht nur den Startbildschirm.
- Android App Links. Web-Links (http/https), die direkt in deiner App öffnen, sobald das System geprüft hat, dass dir die Domain gehört.
Android App Links: Was die offizielle Seite sagt
Laut Android Developers (abgerufen am 24.10.2026):
- Ist
android:autoVerify="true"in mindestens einem Intent-Filter gesetzt, prüft das System bei der Installation auf Android 6.0 (API 23) oder höher automatisch die Hosts deiner Intent-Filter. - Für jeden Hostnamen fragt Android eine Digital-Asset-Links-Datei unter
https://hostname/.well-known/assetlinks.jsonab. - Das System berücksichtigt nur Intent-Filter mit Action
android.intent.action.VIEW, den KategorienBROWSABLEundDEFAULTund dem Schemahttpoderhttps.
Schritte
- Lege die Ziele fest. Start, ein Produkt, eine Einladung, ein Inhalt. Schreibe je Ziel das URL-Muster auf, etwa
/item/123. - Baue eine Web-Alternative. Dieselbe URL muss für Leute ohne App eine nützliche Seite mit Store-Button öffnen. Siehe Aufbau einer App-Landingpage.
- Richte Android ein. Intent-Filter mit autoVerify ergänzen und assetlinks.json wie oben auf deiner Domain bereitstellen.
- Richte iOS ein. Meta-Tag für das Banner setzen und, für Links, die direkt die App öffnen, die Domain mit der App verknüpfen. Genaue Dateien und Berechtigungen stehen in Apples aktueller Dokumentation.
- Verarbeite den Link in der App. Pfad lesen und den richtigen Bildschirm öffnen. Zeige einen sinnvollen Bildschirm, wenn der Inhalt nicht mehr existiert.
Teststeps
Warte unter Android nach der Installation auf die asynchrone Prüfung (die offizielle Seite nennt mindestens 20 Sekunden) und prüfe dann den Zustand:
adb shell am start -a android.intent.action.VIEW \
-c android.intent.category.BROWSABLE \
-d "https://deine.domain/item/123"
Ab Android 12 kannst du die Prüfung manuell anstoßen und auslesen mit adb shell pm verify-app-links --re-verify PACKAGE_NAME und adb shell pm get-app-links PACKAGE_NAME. Eine bestandene Domain zeigt verified; none kann bedeuten, dass die Prüfung noch nicht fertig ist.
Testmatrix, jeweils auf einem echten Gerät:
| Fall | Erwartet |
|---|---|
| App installiert, Link im Browser antippen | Öffnet den richtigen Bildschirm |
| App nicht installiert | Webseite mit Store-Button |
| Link aus Messenger oder Social-App | Öffnet, oder Rückfall auf die Webseite |
| Link auf gelöschten Inhalt | Freundliche Meldung, kein Absturz |
| Neuinstallation, dann Antippen | Zuerst Store-Seite; nach der Installation nur dann der richtige Inhalt, wenn du verzögertes Routing gebaut hast |
Teste auf jeder unterstützten Betriebssystemversion. In-App-Browser und manche Messenger behandeln Links anders, teste auch diese.
Stolperfallen
- Falsche oder nicht erreichbare assetlinks.json, oder eine hinter einer Weiterleitung.
- Links, die nur auf deinem Testgerät funktionieren.
- Die Web-Alternative vergessen.
- Unterschiedliches Verhalten bei Debug- und Release-Signatur; prüfe den Zertifikats-Fingerabdruck in deiner Datei.
Hol dir privates, strukturiertes Feedback von Testern, die deine Links auf echten Geräten ausprobieren.
Verwandt: Pressekit, Warteliste, Hub App-Store-Optimierung und Launch.