Was ist ein Deep Link?

Der Begriff Deep Link stammt aus dem Web und bezeichnet einen Link, der direkt zu einer bestimmten Unterseite einer Website führt, etwa zur Produktseite selbst statt zur Startseite oder zur übergeordneten Kategorieseite. Das ist die ursprüngliche Bedeutung des Begriffs, und sie gilt weiterhin, wenn von Verlinkungsstruktur innerhalb einer Domain die Rede ist.

Mit den mobilen Apps kam eine zweite, heute gebräuchlichere Bedeutung dazu: Ein App-Deep-Link ist ein spezieller Link, der eine bestimmte Ansicht oder einen bestimmten Inhalt direkt innerhalb einer App öffnet, statt sie nur auf ihrem Startbildschirm zu starten. Ein Link zu einem Produkt in der App eines Onlineshops, der genau diese Produktseite öffnet statt des allgemeinen Katalogs, ist ein typisches Beispiel.

In beiden Fällen steckt dieselbe Idee dahinter: den generischen Einstiegspunkt überspringen und direkt zum gesuchten Inhalt führen. Auf einer Website zeigt sich diese Navigationstiefe meist in der Breadcrumb der Seite; in der organischen Suche verlinkt Google häufig direkt auf diese Unterseite statt auf die Startseite.

Im Kern löst ein Deferred Deep Link ein Koordinationsproblem zwischen Installation und Zielinhalt: Ohne installierte App kann kein Link sie öffnen, also führt das System zunächst in den Store und holt das eigentliche Ziel erst danach nach. Viele Kampagnen wickeln diesen Vorgang über einen eigenen URL-Shortener ab, der zugleich misst, woher jede Installation kommt.

Ein App-Deep-Link braucht eine Methode, mit der das Betriebssystem weiß, welche App er öffnen soll. Die älteste sind Custom-URI-Schemes, Adressen mit einem eigenen Präfix wie meineapp://produkt/123, die das System bei der Installation der App zuordnet. Sie funktionieren, haben aber ein Problem: Registrieren zwei unterschiedliche Apps dasselbe Schema, gibt es keine verlässliche Methode zu entscheiden, welche geöffnet werden soll, und ist die App nicht installiert, schlägt der Link einfach fehl, ohne Rückmeldung.

Die heutigen Standards lösen das mit normalen HTTPS-Links statt eigenen Schemes. Unter iOS heißen sie Universal Links, unter Android App Links, und beide funktionieren nach demselben Prinzip: Die App veröffentlicht eine Verifizierungsdatei auf ihrer Domain, apple-app-site-association oder assetlinks.json, die dem Betriebssystem beweist, dass Domain-Inhaber und App-Anbieter dieselbe Instanz sind. Mit dieser Verifizierung öffnet derselbe Link die App, wenn sie installiert ist, und landet sonst ganz natürlich im Browser.

Der Deferred Deep Link fügt noch ein Element hinzu: Da die App auf dem Gerät noch gar nicht existiert, kann weder Scheme noch Verifizierung greifen. Die übliche Lösung läuft über ein Attribution-SDK eines Drittanbieters, das während der gesamten Customer Journey speichert, welchen Inhalt der Nutzer eigentlich erreichen wollte, vom Klick auf die Anzeige bis zum ersten Start der installierten App, und diesen Bildschirm dann öffnet statt des generischen Willkommensbildschirms.

Auf der Website erleichtert eine klare interne Verlinkungsstruktur zu tiefer liegenden Seiten, dass ein Crawler sie findet und indexiert, statt nur Startseite und Hauptkategorien zu erfassen. Das ist einer der Gründe, warum technisches SEO einem so alten Konzept wie einem gut gesetzten Link weiterhin Aufmerksamkeit widmet.

Bei Apps geht es vor allem um Conversion und Messbarkeit. Eine Kampagne, die direkt zur Produktseite in der App führt statt nur zum Startbildschirm, verkürzt den Weg zwischen Klick und Kauf, und das zeigt sich in der Conversion-Rate der Kampagne. Der Deferred Deep Link macht zudem messbar, welche Anzeige welche Installation ausgelöst hat, etwas, das sich sonst nicht feststellen ließe, wenn der Link nur die App allgemein öffnen würde.

Google kann App-Inhalte über korrekt eingerichtete Deep Links crawlen und indexieren und sie so in mobilen Suchergebnissen anzeigen, wenn der Nutzer die passende App bereits installiert hat, ein zusätzlicher Sichtbarkeits-Kanal neben der klassischen organischen Suche.

• Nutze für neue Links immer Universal Links oder App Links statt Custom-URI-Schemes: Sie sind sicherer und hängen nicht davon ab, dass keine andere App dasselbe Präfix registriert.
• Prüfe die Datei apple-app-site-association bzw. assetlinks.json nach jedem Domain- oder Zertifikatswechsel; ein Fehler dort bricht die Verifizierung ohne sichtbare Warnung.
• Definiere ein klares Fallback-Verhalten für den Fall, dass jemand den Link ohne installierte App öffnet, statt es stillschweigend fehlschlagen zu lassen.
• Teste jeden Deep Link in beiden realen Szenarien: mit installierter App und ohne, nicht nur im Desktop-Browser.
• Prüfe bei einem Attribution-SDK für Deferred Deep Links vorab, welche Daten es an Dritte sendet, nicht nur, ob es funktioniert.
• Verlinke auf der Website intern zu tiefer liegenden Seiten mit beschreibendem Ankertext, nicht nur über das Hauptmenü.

• Keine klare Fehlerseite einrichten, wenn ein Deep Link auf nicht mehr existierenden Inhalt zeigt: Der Nutzer landet bei einem Error 400 oder einem leeren Bildschirm ohne Erklärung.
• 2026 noch ausschließlich Custom-URI-Schemes einsetzen, obwohl Universal Links und App Links längst der von Apple und Google empfohlene Standard sind.
• Vergessen, die Verifizierungsdatei nach einem Domain- oder Hosting-Wechsel neu hochzuladen, wodurch alle Deep Links auf einen Schlag ausfallen.
• Einen defekten Deep Link fälschlich als App-Problem behandeln: Der Fehler liegt fast immer in der Domain-Verifizierung oder im Link selbst, nicht im Code des Zielbildschirms.
• Installationen aus einem Deferred Deep Link nicht getrennt messen und dadurch nicht erkennen, welche Kampagne sie wirklich ausgelöst hat.