App-Landingpage: So rankt deine App in der Websuche

Wer eine App veröffentlicht, denkt zuerst an App Store und Google Play. Aber ein großer Teil der Menschen sucht nicht im Store, sondern in Google: nach dem Namen der App, nach einer Lösung für ein Problem, nach einem Vergleich. Damit diese Suchanfragen bei dir landen und nicht bei einem Verzeichnis oder einem Konkurrenten, brauchst du eine Landingpage im Web, die als eigenständige Seite ranken kann. Genau darum geht es hier: um die Websuche, nicht um App-Store-Optimierung.

Die Kernaussage vorweg. Eine App-Landingpage rankt nicht, weil sie hübsch ist und zwei Store-Buttons enthält. Sie rankt, wenn sie eine konkrete Suchabsicht beantwortet, technisch sauber erreichbar ist und die Verbindung zwischen Web und App so gebaut ist, dass Google sie versteht und Nutzer nicht genervt werden. Die folgenden Abschnitte gehen der Reihe nach durch, was das praktisch heißt.

Welche Suchanfragen eine App-Landingpage überhaupt bedient

Bevor du eine Zeile schreibst, klär, für welche Anfragen die Seite gedacht ist. Bei Apps lassen sich grob vier Gruppen unterscheiden. Markenanfragen sind der Name der App, oft mit Zusätzen wie „download“, „login“ oder „kostenlos“. Problemanfragen beschreiben, was der Nutzer erreichen will, etwa „Haushaltsbuch App mit Bankanbindung“. Vergleichsanfragen drehen sich um Alternativen oder um „beste App für …“. Und schließlich gibt es Anfragen nach einzelnen Funktionen, zum Beispiel „Belege scannen und automatisch kategorisieren“.

Jede Gruppe hat eine andere Erwartung an die Ergebnisseite. Wer den Markennamen tippt, will schnell zum Download oder zum Login. Wer ein Problem beschreibt, will erst verstehen, ob die App es löst. Diese Unterscheidung bestimmt, wie viel erklärender Text die Seite braucht. Eine reine Download-Seite mit einem Screenshot-Karussell und drei Sätzen bedient nur die erste Gruppe, und auch die nur dann, wenn der Name eindeutig ist.

Wichtig ist außerdem die Erkenntnis, dass die Ergebnisseiten für App-Anfragen gemischt sind. Häufig erscheinen Store-Einträge, Bewertungsportale, Magazinartikel und die offizielle Website nebeneinander. Du konkurrierst also nicht nur mit anderen Apps, sondern mit den Store-Seiten deiner eigenen App. Das ist kein Grund zur Sorge, aber ein Grund, der Landingpage eine Aufgabe zu geben, die der Store-Eintrag nicht erfüllen kann: ausführlich erklären, Fragen beantworten und Vertrauen aufbauen.

Der Inhalt: mehr als Screenshots und Store-Buttons

Die häufigste Schwäche von App-Landingpages ist dünner Inhalt. Ein Hero-Bild, ein Slogan, drei Icons mit je einem Halbsatz und zwei Badges: Für Google ist das eine Seite mit sehr wenig Text, der sich kaum von tausend anderen unterscheidet. Die Suchmaschine kann daraus nicht ableiten, bei welchen Anfragen die Seite hilfreich wäre.

Schreib deshalb echte Abschnitte. Erkläre in einem klaren Satz, was die App tut und für wen sie gedacht ist, und zwar im ersten sichtbaren Textblock, nicht erst nach drei Bildschirmhöhen. Beschreibe danach jede wichtige Funktion mit einem Anwendungsfall: Wer nutzt sie in welcher Situation, und was passiert konkret? Ein Beispiel wirkt stärker als eine Liste von Adjektiven. „Du fotografierst den Kassenbon, die App liest Datum und Betrag aus und ordnet die Ausgabe einer Kategorie zu“ sagt mehr als „intelligente Belegerfassung“.

Ergänze Inhalte, die Nutzer vor dem Download tatsächlich brauchen. Dazu gehören unterstützte Geräte und Betriebssystemversionen, Preismodell und was kostenlos bleibt, Datenschutz und Berechtigungen in verständlicher Sprache sowie Sprachen und Regionen. Diese Angaben beantworten Fragen, die Menschen sonst in die Suchleiste tippen, und sie verhindern Enttäuschungen nach dem Download.

Vermeide dabei zwei Fallen. Erstens: Kopiere nicht die Store-Beschreibung. Sie existiert bereits unter anderer URL, und identischer Text bringt der Webseite keinen eigenen Wert. Zweitens: Verstecke keine Inhalte in Tabs oder Slidern, die nur per Skript nachgeladen werden. Was im ausgelieferten HTML oder nach dem Rendern nicht sauber im Dokument steht, kann nicht zuverlässig berücksichtigt werden.

• Ein klarer Einleitungssatz: Was tut die App, für wen, auf welchen Plattformen?
• Funktionsabschnitte mit je einem konkreten Anwendungsfall statt Schlagworten
• Preis, Gerätevoraussetzungen, Sprachen und Datenschutz als sichtbarer Text
• Screenshots mit aussagekräftigem Alternativtext und Bildunterschrift
• Ein FAQ-Block, der echte Fragen vor dem Download beantwortet

Seitenstruktur: Eine Startseite oder mehrere Seiten?

Bei einer einzigen App reicht oft eine starke Hauptseite. Sobald die App mehrere klar getrennte Anwendungsfälle hat, lohnt es sich, pro Anwendungsfall eine eigene Seite anzulegen. Eine Fitness-App, die Läufer, Radfahrer und Kraftsportler bedient, erreicht mit drei Seiten, die jeweils ein Thema erschöpfend behandeln, mehr Suchabsichten als mit einer einzigen Seite, die alles streift.

Dabei gilt die übliche Regel gegen Überschneidung: Jede Seite braucht eine eigene Hauptabsicht. Wenn zwei Seiten praktisch dasselbe versprechen, konkurrieren sie gegeneinander. Setze außerdem auf eine flache, nachvollziehbare URL-Struktur, etwa die Hauptseite der App, darunter Unterseiten für Funktionen, Preise und Hilfe. Verlinke von der Hauptseite auf diese Unterseiten und zurück, damit Nutzer und Crawler die Zusammenhänge sehen.

Denk auch an die Pflichtseiten, die oft vergessen werden: Datenschutzerklärung, Nutzungsbedingungen und eine Support-Seite. Die Stores verlangen meist eine URL dafür, und diese Seiten sollten nicht versehentlich auf noindex stehen. Sie sind zudem ein Vertrauenssignal für Menschen, die eine unbekannte App prüfen.

Web und App verbinden: Deep Links, die Google versteht

Der technisch interessanteste Teil ist die Brücke zwischen Webseite und App. Ziel ist, dass ein Link auf deine Webseite entweder in der App landet, wenn sie installiert ist, oder im Browser, wenn nicht. Dafür gibt es auf beiden Plattformen etablierte Mechanismen, die auf normalen HTTPS-Adressen basieren.

Unter iOS heißt der Mechanismus Universal Links. Du hinterlegst auf deiner Domain eine Datei namens apple-app-site-association, die festlegt, welche Pfade die App öffnen darf, und trägst die Domain in der App als Associated Domain ein. Unter Android funktioniert das Gegenstück über Android App Links: Eine Datei assetlinks.json unter dem Pfad .well-known verknüpft die Domain mit dem Paketnamen und dem Signaturzertifikat deiner App. Beide Dateien müssen direkt und ohne Weiterleitung per HTTPS erreichbar sein.

Für die Suche ist der Kernpunkt: Die Webseiten-URL bleibt die kanonische Adresse. Eine Seite, die im Browser Inhalte zeigt, sollte dieselbe URL haben, die auch die App öffnet. So entsteht keine zweite Adresswelt mit eigenem Schema, die Google nicht erreichen kann. Benutzerdefinierte Schemata wie meineapp:// funktionieren nur auf Geräten mit installierter App und sind für die Websuche wertlos.

Ein Wort zu Altlasten. Früher bot Google eine eigene App-Indexierung an, und Firebase Dynamic Links war ein verbreiteter Weg, geteilte Links zu verwalten. Der Dienst Firebase Dynamic Links ist eingestellt. Wenn deine Kampagnen oder Seiten noch auf solche Kurzlinks verweisen, prüfe sie und stelle auf eigene Domain-Links oder einen anderen Anbieter um. Verlasse dich nicht darauf, dass Google App-Inhalte separat aus dem Gerät indexiert; plane so, dass die Inhalte im Web stehen, wo sie gefunden werden können.

• Jede Inhaltsseite hat genau eine HTTPS-URL, die im Web und in der App gilt
• apple-app-site-association und assetlinks.json sind ohne Weiterleitung abrufbar
• Pfade in diesen Dateien decken nur die Bereiche ab, die die App wirklich öffnen kann
• Links auf eigene Kurzdomains statt auf eingestellte Drittdienste
• Test auf echten Geräten: mit installierter App und ohne

Smart Banner und Install-Hinweise ohne Interstitial-Problem

Viele Seiten wollen Besucher auf dem Smartphone so schnell wie möglich zur App führen, und genau hier entstehen Probleme. Google hat schon vor Jahren klargestellt, dass Seiten mit aufdringlichen Interstitials auf Mobilgeräten schlechter bewertet werden können: Elemente, die nach dem Aufruf den Hauptinhalt verdecken und erst weggeklickt werden müssen. Ein ganzseitiger Bildschirm „Lade unsere App“, der den Inhalt blockiert, fällt in diese Kategorie. Das gilt auch für große Overlays, die den Inhalt nach dem Laden überdecken.

Ausgenommen sind Banner, die einen vertretbaren Teil des Bildschirms belegen und den Inhalt nicht verdecken. Google nennt dafür ausdrücklich Beispiele wie die Smart App Banner von Safari und die Install-Banner von Chrome. Der Apple-Banner wird über ein meta-Tag mit dem Namen apple-itunes-app und der App-ID im head der Seite eingebunden. Er wird vom System dargestellt, nimmt wenig Platz ein und lässt sich schließen. Bei Chrome hängt der Installationshinweis an den Kriterien für eine Progressive Web App.

Wenn du einen eigenen Banner baust, halte dich an wenige Regeln. Er sollte schmal sein, am oberen oder unteren Rand sitzen, sich mit einem gut erreichbaren Schließen-Symbol entfernen lassen und den Text nicht verdecken. Er darf nicht erscheinen, bevor der Nutzer überhaupt etwas lesen konnte, und er sollte nach dem Schließen nicht bei jedem Seitenaufruf wiederkommen. Merke dir die Entscheidung im Browser für einige Wochen.

Eine Sonderfrage ist der Zwang zur App. Wer Mobilnutzer von einer Seite automatisch in den Store umleitet oder den Inhalt erst nach App-Installation zeigt, riskiert zweierlei: schlechte Nutzersignale und Abwertung, weil der Crawler mit anderem Verhalten konfrontiert wird als ein Mensch. Eine Seite, die dem Googlebot Inhalt zeigt und Menschen einen Store-Zwang, widerspricht außerdem dem Grundsatz, beiden dasselbe zu liefern. Zeige den Inhalt immer, und biete die App als Option an.

Technische Basis: Crawlbarkeit, Geschwindigkeit, strukturierte Daten

App-Landingpages sind häufig mit JavaScript-Frameworks gebaut und voller Animationen. Prüfe deshalb mit der URL-Prüfung in der Search Console, was Google nach dem Rendern tatsächlich sieht. Steht der Haupttext im gerenderten HTML? Sind Bilder, die Funktionen zeigen, als echte Bildelemente eingebunden? Liefert die Seite den Statuscode 200, und blockiert die robots.txt weder Skripte noch Stylesheets, die zum Rendern nötig sind?

Die Ladegeschwindigkeit verdient bei App-Seiten besondere Aufmerksamkeit, denn sie sind oft bildlastig. Große Screenshots und Videos gehören komprimiert, in modernen Formaten ausgeliefert und mit festen Abmessungen eingebunden, damit sich das Layout beim Laden nicht verschiebt. Videos sollten nicht automatisch mit Ton und voller Datenmenge starten. Die Core Web Vitals sind ein Rankingsignal, und auf Mobilgeräten mit schwächerer Verbindung wirken sich schwere Seiten besonders aus.

Bei strukturierten Daten kommt für Apps der Typ SoftwareApplication oder genauer MobileApplication infrage. Du kannst Name, Betriebssystem, Kategorie und Angebot beschreiben. Erwarte davon aber keine garantierte Sonderdarstellung: Google zeigt Rich Results für Software-Apps nur unter bestimmten Bedingungen, etwa mit Bewertungen oder Preisangaben, und die Auszeichnung muss mit dem sichtbaren Seiteninhalt übereinstimmen. Füge keine Bewertungen ein, die du nicht tatsächlich auf der Seite zeigst oder belegen kannst. Der Wert der Auszeichnung liegt vor allem darin, die Entität eindeutig zu beschreiben.

Hilfreich ist außerdem die saubere Verknüpfung der Entität im Web. Verlinke von der Landingpage auf die Store-Einträge und umgekehrt im Store auf die Website. Nutze auf der Seite denselben Namen, dasselbe Icon und dieselbe Kurzbeschreibung wie im Store, damit Google die Verbindung zwischen den Adressen erkennen kann.

Häufige Fehler und wie du sie erkennst

Der erste typische Fehler ist die Markenkollision. Heißt die App wie ein Alltagswort, findet Google eine Vielzahl anderer Bedeutungen, und die Landingpage geht unter. Hier hilft ein beschreibender Zusatz im Titel und in der Überschrift, etwa „Name – Haushaltsbuch App für iPhone und Android“, und konsequent derselbe Name mit Zusatz in allen Profilen und Erwähnungen.

Der zweite Fehler ist die Weiterleitung an den Store. Manche Seiten leiten mobile Nutzer per Skript direkt zur Store-Adresse um. Damit kann die Landingpage kaum ranken, weil ein Besuch sie nie wirklich zeigt. Lass die Seite stehen und biete Buttons an.

Der dritte Fehler ist eine getrennte mobile Domain oder eine versteckte Variante. Verwende dieselbe URL und dasselbe responsive Layout für alle Geräte. Mobile-first-Indexierung bedeutet, dass die mobile Fassung maßgeblich ist; fehlt dort Text, den die Desktopseite zeigt, fehlt er für Google.

Der vierte Fehler ist ein Seitenbestand, der nur Versionsnotizen führt. Eine Seite mit „Was ist neu“ kann nützlich sein, wenn sie dauerhaft unter einer stabilen URL liegt und verständlich erklärt. Wird aber jede Version als neue dünne Seite angelegt, entsteht Masse ohne Wert. Bündele sie in einem Changelog.

• Seite auf dem Smartphone mit deaktiviertem JavaScript und normal vergleichen
• Banner und Overlays beim ersten Aufruf prüfen: Verdecken sie Text?
• Jeden Store-Link und jeden Deep Link auf beiden Betriebssystemen testen
• Titel und H1 darauf prüfen, ob sie die App auch für Fremde einordnen

Erfolg messen: Was du in der Search Console siehst

Richte die Domain in der Search Console ein und beobachte in der Leistungsübersicht zuerst die Anfragen, bei denen die Landingpage Impressionen bekommt. Trenne Markenanfragen von allem anderen. Ein Anstieg bei Markenanfragen zeigt Bekanntheit, nicht SEO-Erfolg der Seite. Die eigentlich spannende Zahl sind die Anfragen ohne Markennamen: Sie zeigen, ob die Seite für Problem- und Funktionsbegriffe sichtbar wird.

Schau dir außerdem an, was nach dem Klick passiert. Ereignisse für Klicks auf die Store-Buttons lassen sich mit deinem Analysewerkzeug erfassen, und Kampagnenparameter an den Store-Links verraten, welche Seiten Installationen anstoßen. Nutze dafür die von den Stores vorgesehenen Parameter und sei vorsichtig mit Datenschutz und Einwilligung. Rechne nicht damit, dass jede Installation sauber einer Websuche zugeordnet werden kann; die Verbindung zwischen Web und Store ist lückenhaft.

Gib einer neuen Landingpage Zeit. Ein realistischer Rhythmus ist, nach dem Start die Indexierung zu prüfen, dann die Anfragen zu beobachten und die Inhalte anhand echter Suchbegriffe nachzuschärfen. Wenn bestimmte Fragen immer wieder in den Anfragen auftauchen, ergänze sie als Abschnitt oder als Eintrag im FAQ.