Wie man PWAs bewirbt: SEO, Indexierung und Installation

Wenn Sie eine native App veröffentlichen, ist der Nutzerpfad einfach: Er öffnet den App Store oder Google Play, gibt den Namen oder eine Suchanfrage ein und klickt auf "Installieren". Der Store selbst fungiert als Suchmaschine, Schaufenster, Zahlungssystem und Update-Kanal.

Mit PWAs ist alles anders. Es gibt kein sich selbst erstellendes Verzeichnis. Der Nutzer muss zuerst erfahren, dass das Produkt existiert, es dann in der Suche finden, einem Link folgen oder einen QR-Code erhalten und erst danach über die Installation nachdenken. All dies liegt in der Verantwortung des Entwicklers, und genau darum geht es in diesem Artikel.

Ich habe PWAs im Projekt Kazki AI (ein Service zur Generierung von Kindergeschichten) gestartet, Push-Benachrichtigungen für den Blog eines Psychologen eingerichtet und integriere derzeit eine PWA in ein weiteres Projekt. Zu Beginn war es mir wichtig, nicht nur den Service über einen Link zugänglich zu machen, sondern potenziellen Nutzern auch zu erklären, was er bietet und welches Problem er löst. Deshalb betrachte ich PWAs nicht nur als Technologie, sondern auch als Produkt, das eine klare öffentliche Seite zur Gewinnung von Zielgruppen benötigt. Wenn Sie noch zwischen PWA und nativen Apps wählen, lesen Sie zuerst PWA vs. Native in 2026: Vergleich und realer Fall.

📚 Artikelinhalt

• 📌 Wie unterscheidet sich die Auffindbarkeit von PWAs von nativen Apps
• 📌 Wie man PWAs in Google sichtbar macht
• 📌 Rendering, Routing, Indexierung: Warum PWAs "nicht sichtbar" sind
• 📌 Core Web Vitals für PWAs
• 📌 Wie Nutzer PWAs anhand des Namens finden
• 💼 Web-App-Verzeichnisse
• 💼 Google Play, App Store, Microsoft Store
• 💼 Promotion außerhalb der Suche
• 💼 Vom Besucher zur Installation
• 💼 Push: Wie man Nutzer zurückbringt
• 💼 Wie man Ergebnisse misst
• 💼 Wird eine SoftwareApplication-Markierung benötigt?
• ✅ Checkliste für SEO und PWA-Distribution
• ❓ Häufig gestellte Fragen (FAQ)

🎯 Abschnitt 1. Wie unterscheidet sich die Auffindbarkeit von PWAs von nativen Apps

Kurze Antwort: Bei nativen Apps sind Suche, Vertrauen und Installation an einem Ort (dem Store) konzentriert, während PWAs im Web verteilt sind. Jeder Kanal, der im Store "out of the box" funktioniert, muss für PWAs separat aufgebaut werden.

Im Store gibt der Nutzer einen Namen oder eine Kategorie ein, sieht Ergebnisse, Bewertungen und Screenshots und installiert die App mit einem einzigen Button. Bei PWAs gibt es diesen Weg nicht. Sie können in Google nach einer Suchanfrage nach einer Aufgabe gefunden werden, einen Link von einem Bekannten erhalten, über einen Artikel oder ein Verzeichnis darauf zugreifen oder einen QR-Code scannen. Jede dieser Quellen muss separat vorbereitet werden.

Auffindbarkeitskanäle: Was für Native funktioniert und was für PWAs

Wann das Fehlen im Store ein Problem ist und wann nicht

Ich empfehle, den Produkttyp und das Verhalten der Zielgruppe zu berücksichtigen. Das Fehlen im Store ist kritisch für massenhafte Consumer-Apps, bei denen ein erheblicher Teil der Nutzer daran gewöhnt ist, nach "Name + App Store" zu suchen. Für SaaS, Tools, Content- und B2B-Produkte, bei denen Nutzer über Google nach einer Lösung suchen oder einem direkten Link folgen, ist dies in der Regel ausreichend. Gleichzeitig rate ich davon ab, dies als universelle Regel zu betrachten: Überprüfen Sie zuerst in Ihrer eigenen Analytik, woher die Nutzer kommen, und entscheiden Sie dann, ob eine Präsenz in den Stores erforderlich ist.

🎯 Abschnitt 2. Wie man PWAs in Google sichtbar macht

Ein Google-Nutzer sucht nicht nach "PWA", sondern nach einer Lösung für sein Problem: "App zur Generierung von Geschichten", "Online-Aufgabenplaner". Wenn der einzige Eingang zu Ihrem Produkt der Login-Bildschirm ist, gibt es für die Suche nichts, woran sie sich festhalten kann. Aus meiner Erfahrung gibt es Projekte, bei denen Kunden eine obligatorische Authentifizierung verlangen, wodurch die meisten Seiten für Suchmaschinen-Crawler geschlossen bleiben. In diesem Fall empfehle ich, separate öffentliche Seiten mit Beschreibungen des Produkts, seiner Funktionen und Anwendungsfälle zu erstellen, damit potenzielle Nutzer es noch vor der Registrierung über Google finden können.

Was auf der öffentlichen Seite sein sollte

• Separate URL für jeden wichtigen "Bildschirm": Startseite, Funktionen, Preise, Artikel. Nicht eine URL für die gesamte Anwendung.
• Realer Inhalt in HTML: Produktbeschreibung, Funktionen, Bilder mit alt-Attributen, klarer Call-to-Action.
• Einzigartige title und meta description für jede Seite. Google kann sie in den Suchergebnissen überschreiben, und die description ist kein Rankingfaktor, aber sie beeinflusst, ob auf den Snippet geklickt wird.
• Normale Links <a href>. Googlebot folgt Links mit dem href-Attribut, nicht JavaScript-Klick-Handlern.
• sitemap.xml: Hilft beim Finden von Seiten, garantiert aber keine Indexierung.
• Blockieren Sie keine Skripte und Stile in robots.txt, die für das Rendering der Seite benötigt werden.

<head>
  <title>Kazki AI — Generator für Kindergeschichten nach Prompt</title>
  <meta name="description" content="Erstellen Sie personalisierte Geschichten für Kinder in Sekundenschnelle.">
  <link rel="canonical" href="https://example.com/">
  <link rel="manifest" href="/manifest.json">
</head>

Search Console: Überprüfung statt Annahmen

Wenn Sie neu sind, empfehle ich, mit der Google Search Console zu beginnen. Registrieren Sie Ihre Website und verwenden Sie das Tool "URL-Prüfung". Es zeigt an, ob die Seite indexiert ist, welches HTML Google nach dem Rendering gesehen hat und wie der Screenshot der Seite aussieht. Für PWAs ist dies der schnellste Weg, um herauszufinden, was der Suchroboter tatsächlich sieht, und nicht nur das, was Sie in Ihrem Browser sehen. Der Bericht "Seitenindexierung" hilft zu verstehen, warum einzelne URLs nicht in den Index aufgenommen wurden. Wenn Sie Schwierigkeiten bei der Einrichtung oder Überprüfung der Indexierung haben, schreiben Sie mir – ich helfe Ihnen, es zu verstehen.

Bing und IndexNow

Ich empfehle, Bing nicht nur wegen seines geringeren Marktanteils im Vergleich zu Google zu ignorieren. In einigen Ländern und bei bestimmten Zielgruppen wird es häufiger genutzt, daher sollten Sie die Geografie Ihres Traffics berücksichtigen. Fügen Sie Ihre Website zu Bing Webmaster Tools hinzu und richten Sie IndexNow ein, um unterstützte Suchmaschinen über neue und aktualisierte URLs zu informieren. Dies ist ein zusätzlicher Kanal zur Entdeckung von Seiten, der einfach einzurichten ist. Selbst wenn derzeit die meisten Besucher von Google kommen, halte ich eine solche Integration für sinnvoll: Sie erweitert die Möglichkeiten der Suchsichtbarkeit, ohne die Haupt-SEO-Strategie ändern zu müssen. Gleichzeitig garantiert IndexNow keine Indexierung von Seiten. Google nutzt dieses Protokoll nicht, daher sollten Sie für Google weiterhin mit sitemap und Google Search Console arbeiten.

Anfragen nach Aufgaben, nicht nach Technologie

Nutzer suchen selten nach "PWA". Formulieren Sie Ihre Seiten so, dass sie sich auf das konzentrieren, was die Person tun möchte, und bewahren Sie das Wort "PWA" für Artikel für Entwickler auf. Beispiele und Vorgehensweisen für eine neue Marke werden in Abschnitt 5 behandelt.

Als Nächstes kommt der für PWAs wichtigste technische Abschnitt: Warum eine App, die im Browser perfekt funktioniert, für Google leer erscheinen kann.

🔗 Lesen Sie auch

• PWA vs. Native in 2026: Vergleich und realer Fall
• 8 kritische Fehler bei der PWA-Integration

🎯 Abschnitt 3. Rendering, Routing, Indexierung: Warum PWAs "nicht sichtbar" sind

Aus meiner Erfahrung sind die meisten Probleme mit der Suchsichtbarkeit von PWAs auf die technische Implementierung zurückzuführen. Inhalte können erst nach Ausführung von JavaScript erscheinen, alle internen Seiten können eine einzige URL verwenden, und nicht existierende Adressen können einen Status 200 anstelle von 404 zurückgeben. Das Manifest oder der Service Worker allein lösen diese Probleme nicht: Es ist wichtig, Routing, HTTP-Statuscodes und die Verfügbarkeit von Inhalten für Suchroboter korrekt zu konfigurieren.

Google verarbeitet JavaScript-Seiten in drei Schritten: Crawling, Rendering und Indexierung. Für das Rendering wird die aktuelle Version von Chromium verwendet, aber sie arbeitet in einer Warteschlange, sodass Inhalte, die erst nach Ausführung von Skripten erscheinen, später als normaler HTML in den Index aufgenommen werden können. Außerdem klickt, scrollt oder loggt sich der Roboter nicht ein. Alles, was nur nach einer Benutzeraktion erscheint, wird nicht in die Suche aufgenommen. [Google: JavaScript SEO]

Problem 1. Client-seitiges Rendering (CSR)

In einem klassischen SPA gibt der Server eine leere Hülle aus, und der Inhalt erscheint nach dem Laden der Skripte. Es gibt drei Ansätze, und die Wahl sollte vom Seitentyp abhängen:

Aus meiner Erfahrung empfehle ich, den öffentlichen und den geschlossenen Teil einer PWA zu trennen. Landingpages, Funktionsseiten, Preise und Artikel sollten als fertiges HTML geliefert werden, während die Benutzeroberfläche der autorisierten Anwendung clientseitig bleiben kann. In meinen Projekten erwäge ich auch ein separates DTO zur zentralisierten Generierung von SEO-Daten und sitemaps: öffentliche URLs, Aktualisierungsdaten und andere notwendige Metadaten. Dies vereinfacht die Indexierungsverwaltung, ersetzt aber nicht die korrekte HTML-Generierung, die Konfiguration von HTTP-Statuscodes und die Verfügbarkeit von Seiten für Suchroboter. Google beschrieb Dynamic Rendering – die Bereitstellung einer separaten Seitenversion für Bots – früher als Workaround, rät aber nicht dazu als langfristige Lösung.

Problem 2. Eine URL für die gesamte Anwendung

Wenn sich Abschnitte ohne Adressänderung umschalten oder die Adresse wie /#/pricing aussieht, ist dies für Google eine einzige Seite. Der Teil nach dem # wird nicht als separate URL betrachtet. Verwenden Sie die History API, damit jeder öffentliche Abschnitt eine saubere Adresse hat:

// Saubere URLs anstelle von Hash-Routen
history.pushState({}, '', '/pricing');

// In React Router: BrowserRouter, nicht HashRouter
// In Vue Router: createWebHistory(), nicht createWebHashHistory()

Der Server muss dabei in der Lage sein, die gewünschte Seite bei einer direkten Anfrage an /pricing zu liefern und nicht nur nach dem Laden der SPA.

Problem 3. "Soft" 404s

Eine typische SPA-Falle: Der Server liefert für jeden unbekannten Pfad index.html mit dem Status 200, und die Meldung "Seite nicht gefunden" wird von JavaScript angezeigt. Für die Suchmaschine kann eine solche Adresse wie eine erfolgreich geladene Seite aussehen und nicht wie ein 404-Fehler, was das Risiko birgt, dass nicht existierende URLs in den Index aufgenommen werden. Lösung: Auf Serverebene geben Sie für nicht existierende Routen den echten 404-Status zurück, und für gelöschte Seiten verwenden Sie 410 oder 301 auf eine relevante aktuelle Adresse. Aus meiner Erfahrung empfehle ich, dies nicht nur aus SEO-Sicht zu prüfen, sondern auch im Kontext von GEO: Korrektes Routing hilft Systemen, die richtigen Serverantworten zu erhalten, garantiert aber allein keine Erwähnungen oder Zitate in KI-Antworten.

Problem 4. Metadaten und Links aus JavaScript

• title, description und canonical sollten besser bereits im HTML vom Server geliefert und nicht nach dem Laden per Skript eingefügt werden.
• Die Navigation sollte über normale <a href="/path"> erfolgen und nicht über onclick ohne href.
• Inhalte, die erst nach einem Klick oder Scrollen geladen werden, werden vom Roboter nicht gesehen.

Was das Manifest und der Service Worker für SEO bringen und was nicht

Separat zum Service Worker: Aggressives Caching von HTML kann Nutzern veraltete Seiten liefern, und Fehler bei der fetch-Verarbeitung brechen das Routing. Typische Fehler und Korrekturen habe ich im Artikel 8 kritische Fehler bei der PWA-Integration behandelt. Für SEO gilt die Hauptregel: Was indexiert werden soll, muss der Server unverändert liefern, unabhängig davon, was der Service Worker tut.

Wie man überprüft, was Google sieht

1. Ich öffne in der Google Search Console den Abschnitt "URL-Prüfung" und starte eine Live-Prüfung der öffentlichen Seite.
2. Ich überprüfe das gerenderte HTML und den Screenshot. Wenn die Seite leer ist oder im HTML kein wichtiger Text vorhanden ist, prüfe ich, ob das Rendering korrekt funktioniert.
3. Ich vergleiche die anfängliche Serverantwort (curl -s https://example.com/) mit dem, was der Browser anzeigt. Wenn das Ergebnis von curl keinen Hauptinhalt enthält, bedeutet dies, dass er von der Ausführung von JavaScript abhängen kann.
4. Im Bericht "Seitenindexierung" überprüfe ich die Status "Entdeckt, derzeit nicht indexiert" und "Soft 404-Fehler", um zu verstehen, warum Seiten nicht in den Index aufgenommen werden.

🎯 Abschnitt 4. Core Web Vitals für PWA

Kurze Antwort: Geschwindigkeit ist für PWAs doppelt wichtig – als Qualitätsindikator für Google und als Teil des Produkts selbst. Sie ist jedoch ein unterstützender Faktor und kein Ersatz für relevante Inhalte. In meiner Praxis empfehle ich, nicht nur die Ladezeit zu berücksichtigen, sondern auch, wie sie die Benutzerinteraktion mit der Website beeinflusst. Mehr dazu erzähle ich im Artikel Core Web Vitals: drei Metriken, die die Website-Konversion beeinflussen.

Google nutzt Core Web Vitals zur Bewertung des Nutzererlebnisses. Die wichtigsten Metriken und die Schwellenwerte für „Gut“:

• LCP (Largest Contentful Paint – Ladezeit des größten Inhalts): bis zu 2,5 s;
• INP (Interaction to Next Paint – Reaktionsfähigkeit auf Interaktionen): bis zu 200 ms;
• CLS (Cumulative Layout Shift – kumulative Layoutverschiebungen): bis zu 0,1.

Für PWAs gibt es spezifische Risiken. Ein schweres JavaScript-Bundle verzögert LCP, insbesondere wenn der Inhalt clientseitig generiert wird. Ein Service Worker kann wiederholte Besuche beschleunigen, hilft aber nicht unbedingt beim ersten Öffnen. Daher empfehle ich, das anfängliche Laden zu optimieren: JavaScript-Bundles aufzuteilen, das Laden von sekundären Skripten zu verzögern, Bildgrößen festzulegen, um CLS zu reduzieren, und die Seitenanzeige nicht durch ressourcenintensive Elemente zu blockieren.

Ich überprüfe die tatsächlichen Werte im Core Web Vitals-Bericht in der Google Search Console und in PageSpeed Insights. Wenn die Website über genügend Felddaten verfügt, zeigt PageSpeed Insights die Ergebnisse der tatsächlichen Nutzung der letzten 28 Tage an. Die Laborwerte von Lighthouse sind für die Diagnose nützlich, ersetzen aber keine Felddaten. Schritt für Schritt zur Geschwindigkeitsprüfung und Optimierung erkläre ich im Artikel Google PageSpeed Insights: Wie man 90 Punkte erreicht.

🎯 Abschnitt 5. Wie Benutzer PWAs anhand des Namens finden

Kurze Antwort: Im Store funktioniert die Suche nach dem Namen von selbst. Im Web findet man ein Produkt anhand des Namens nur, wenn Google es bereits „kennt“, und für eine neue Marke ohne Erwähnungen ist dies nicht garantiert.

Jemand hört den Namen von einem Bekannten und gibt ihn bei Google ein, nicht im Store. Wenn der Name neu ist oder mit einem gebräuchlichen Wort übereinstimmt, werden andere Websites in den Suchergebnissen angezeigt. Hier helfen Meta-Tags nicht, da sie den ersten Platz nach dem Namen nicht garantieren.

Was hilft, warum es wichtig ist und was passiert, wenn man es ignoriert

• Einzigartiger Name. Überprüfen Sie die Suchergebnisse dazu vor dem Start. Wenn andere Produkte die Top-Positionen belegen, überlegen Sie, den Namen zu ändern oder eine Präzisierung hinzuzufügen („Name + Kategorie“).

  Warum es wichtig ist: Die Suchmaschine zeigt Ergebnisse nach Relevanz an, und wenn der Name mit einem gebräuchlichen Wort oder einem anderen Produkt übereinstimmt, wird die Suchanfrage mehrdeutig. Ihre Website konkurriert nicht nur mit Ihrer Nische, sondern mit allen, die einen ähnlichen Namen haben.

  Wenn Sie es ignorieren: Eine Person, die den Namen von einem Bekannten gehört hat, landet auf einer fremden Website, und Sie verlieren die qualifiziertesten Besucher. Den Namen nach dem Start zu ändern ist teuer: Sie müssen die Domain, Links, Erwähnungen und Profile verschieben, und die angesammelten Erwähnungen unter dem alten Namen gehen teilweise verloren.

• Einheitliche Schreibweise überall: Domain, title, name im Manifest, Profile in sozialen Netzwerken und Katalogen.

  Warum es wichtig ist: Eine einheitliche Schreibweise hilft sowohl Suchmaschinen als auch Menschen zu verstehen, dass es sich um dasselbe Produkt handelt. Der Name im Manifest wird außerdem unter dem Symbol auf dem Startbildschirm und in der Installationsaufforderung angezeigt, sodass er Teil der Wiedererkennung ist.

  Wenn Sie es ignorieren: Erwähnungen verteilen sich auf verschiedene Varianten („Kazki AI“, „KazkiAI“, „Казки AI“), und Google hat Schwierigkeiten, sie mit einer einzigen Website zu verknüpfen. Benutzer geben unterschiedliche Schreibweisen ein und finden das Produkt nicht immer, und die Diskrepanz zwischen dem Namen auf der Website und dem Symbol untergräbt das Vertrauen in die Anwendung.

• Eine öffentliche Produktseite mit dem genauen Namen in der Überschrift und im Text.

  Warum es wichtig ist: Genau diese Seite kann bei einer Markensuche angezeigt werden. Der geschlossene Teil der Anwendung, der erst nach dem Login geöffnet wird, wird nicht indiziert, sodass Google ohne eine öffentliche Seite nichts anzeigen kann.

  Wenn Sie es ignorieren: Unter dem Produktnamen werden in den Suchergebnissen nur externe Seiten (Kataloge, soziale Netzwerke, Rezensionen) oder gar nichts Relevantes angezeigt. Der Benutzer kann nicht schnell überprüfen, ob das Produkt existiert und ob es die tatsächliche Website ist, und ein Teil der Besucher wird abspringen.

• Erwähnungen auf anderen Websites: Artikel, Kataloge, Diskussionen. Externe Links und Erwähnungen helfen Google zu verstehen, dass die Marke existiert.

  Warum es wichtig ist: Für eine neue Marke ist dies eines der wenigen externen Signale dafür, dass das Produkt echt ist und nicht nur von den Eigentümern gesprochen wird. Qualitativ hochwertige Erwähnungen bringen auch echte Besucher.

  Wenn Sie es ignorieren: Sie bleiben die einzige Informationsquelle über sich selbst, und es ist schwieriger, eine neue Marke in den Suchergebnissen zu „verankern“. Es gibt auch ein umgekehrtes Risiko: Profile in externen Katalogen können Ihre Website bei einer Markensuche übertreffen, wenn Ihre eigenen Seiten schwach sind.

• Die Auszeichnung des Websitenamens (WebSite mit name) hilft Google, den Namen in den Suchergebnissen korrekt anzuzeigen, beeinflusst aber nicht die Position bei einer Markensuche.

  Warum es wichtig ist: Dies ist ein Hinweis für Google, welcher Name über dem Snippet angezeigt werden soll. Die Implementierung ist kostengünstig und besonders nützlich, wenn der Name komplex ist oder die Domain nicht mit der Marke übereinstimmt.

  Wenn Sie es ignorieren: Google wählt den Namen selbst anhand anderer Signale (Überschriften, title, Erwähnungen), und die Domain oder eine ungünstige Schreibweise kann in den Suchergebnissen angezeigt werden. Dies schadet den Positionen nicht, beeinträchtigt aber den ersten Eindruck des Snippets. Die Auszeichnung gibt keine Garantien, und Google kann einen anderen Namen anzeigen.

Fazit: Keiner dieser Punkte allein „bringt“ die Marke an die Spitze. Zusammen verringern sie die Wahrscheinlichkeit, dass eine Person, die genau Ihr Produkt sucht, stattdessen ein fremdes findet. Für eine neue Marke ohne Nachfrage bringen diese Schritte keinen schnellen Traffic, legen aber die Grundlage, auf der die Markensuche später wachsen kann.

Neue Marke vs. Marke mit Nachfrage

Wenn ich an der Promotion eines neuen Produkts arbeite, empfehle ich, sich anfangs auf die Aufgaben der Benutzer zu konzentrieren und nicht nur auf den Markennamen. Anstatt beispielsweise auf Suchanfragen mit dem Namen eines neuen Dienstes zu hoffen, lohnt es sich, Anfragen wie „App für Gute-Nacht-Geschichten“ zu bearbeiten. Am Anfang kennt man das Produkt vielleicht noch nicht, daher ist es wichtig, potenziellen Benutzern die Möglichkeit zu geben, es über ein spezifisches Bedürfnis zu finden. Die Markennachfrage kann mit der Verbreitung des Produkts entstehen, dies ist jedoch nicht für jedes Projekt eine garantierte Phase.

Beim Projekt Kazki AI habe ich mich ebenfalls auf die praktische Anwendung des Dienstes – die Generierung von Kindergeschichten – konzentriert und nicht nur auf seinen Namen. Dies ist einer der Ansätze, die ich für eine neue Marke in Betracht ziehen würde, aber keine universelle Regel: Die Strategie hängt von der Nische, der Zielgruppe und der vorhandenen Nachfrage ab. Um die Ergebnisse zu bewerten, empfehle ich, die Markensuchen in der Google Search Console zu verfolgen. Wenn Benutzer beginnen, das Produkt nach seinem Namen zu suchen, kann dies auf eine wachsende Bekanntheit hindeuten.

💼 Abschnitt 6. Web-App-Kataloge

Kurze Antwort: Kataloge können erste Benutzer und Erwähnungen bringen, aber massenhaftes Platzieren „um der Links willen“ funktioniert nicht. Wählen Sie Plattformen nach relevanter Zielgruppe, nicht nach Quantität.

Kataloge gibt es in zwei Arten, und sie haben unterschiedliche Ziele:

• Benutzerquellen: Launch-Plattformen (wie Product Hunt), thematische SaaS- und Tool-Kataloge, wo Menschen tatsächlich nach neuen Produkten suchen.
• Link- und Erwähnungsquellen: Kataloge, die Google helfen, den Namen mit Ihrer Website zu verknüpfen. Viele Kataloge setzen nofollow-Links, erwarten Sie also keinen SEO-Effekt davon.

Wie man einen Katalog bewertet

Fügen Sie Ihr Produkt zu einigen wirklich relevanten Katalogen hinzu, nicht zu hundert zufälligen. Verwenden Sie für jeden ein separates UTM-Tag, um später in der Analytik zu sehen, welcher Kanal Besuche gebracht hat, und nicht nur „referral“.

💼 Abschnitt 7. Google Play, App Store, Microsoft Store

Kurze Antwort: PWAs können in Stores veröffentlicht werden, aber das geschieht nicht automatisch und ohne Anpassungen. Jeder Store hat seinen eigenen Wrapper und seine eigenen Anforderungen, und Apple ist am strengsten zu „einfachen Websites in Wrappern“.

Lohnt sich das?

Die Veröffentlichung im Store fügt einen weiteren Kanal für Entdeckung und Vertrauen hinzu, aber damit kommen auch Provisionen, Moderation und die Wartung eines separaten Pakets. Wenn Ihre Zielgruppe über Google nach einer Lösung sucht, ist der Store möglicherweise überflüssig. Wenn Benutzer es gewohnt sind, Apps im Store zu suchen, ist dies eine Option, die eine Überlegung wert ist. Berücksichtigen Sie sofort, dass für den App Store wahrscheinlich ein nativer Mehrwert über die Website hinaus erforderlich ist, z. B. Push-Benachrichtigungen, Systemintegration oder Offline-Funktionen, und planen Sie dafür Zeit ein.

Wann ein nativer Ansatz gerechtfertigt ist, lesen Sie im Artikel PWA vs. Native im Jahr 2026.

💼 Abschnitt 8. Promotion außerhalb der Suche

Kurze Antwort: Die Suche bringt Leute, die bereits nach Lösungen suchen. Die restlichen müssen Sie selbst über Communities, Inhalte, Partnerschaften und direkte Links finden.

Für PWAs ist ein Link ein vollwertiger Einstieg in das Produkt, ohne den Zwischenschritt „in den Store gehen“. Das ist für die meisten Kanäle praktisch. Gruppieren Sie sie nach Zweck:

Ein QR-Code, der zu einer PWA führt, ist besonders praktisch, wenn das Produkt an einem bestimmten Ort verwendet wird: Die Person scannt und öffnet die App sofort ohne Store. Verwenden Sie für alle Kanäle UTM-Tags, sonst vermischt sich in der Analytik alles zu „direct“.

💼 Abschnitt 9. Vom Besucher zur Installation

Kurze Antwort: Erster Besuch, Installation und regelmäßige Nutzung sind drei verschiedene Ereignisse. Die Installation ist kein Selbstzweck, ihr Ziel ist die Rückkehr des Benutzers.

Android und Desktop (Chromium)

Chrome und andere Chromium-Browser unterstützen das Ereignis beforeinstallprompt. Sie können es abfangen und Ihren eigenen „Installieren“-Button zum richtigen Zeitpunkt anzeigen, nicht sofort beim Betreten:

let deferredPrompt;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();          // Standardbanner nicht sofort anzeigen
  deferredPrompt = e;
  showInstallButton();         // eigenen Button anzeigen
});

installBtn.addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  const { outcome } = await deferredPrompt.userChoice; // 'accepted' | 'dismissed'
  deferredPrompt = null;
  hideInstallButton();
});

window.addEventListener('appinstalled', () => {
  // Installationsereignis, nur in unterstützten Browsern
});

Dieses Ereignis ist nicht in allen Browsern verfügbar: z. B. im iOS Safari fehlt es. Daher ist es als alleiniger Weg zur Anzeige einer Aufforderung nicht geeignet.

iOS

Auf dem iPhone gibt es keine automatische Installationsaufforderung. Der Benutzer muss manuell „Teilen → Zum Startbildschirm“ durchlaufen. Daher müssen Sie die Aufforderung selbst anzeigen: eine kurze Anleitung mit einem Screenshot in dem Moment, in dem die Person bereits den Wert des Produkts erkannt hat. Ab iOS 16.4 können „Zum Startbildschirm“ auch von Drittanbieter-Browsern angeboten werden, aber die Verfügbarkeit des Punktes hängt vom Browser ab, daher ist es in der Anleitung zuverlässiger, den universellen Weg zu schreiben. Warum dies für Push-Benachrichtigungen wichtig ist, habe ich im Artikel PWA Push-Benachrichtigungen auf iOS im Jahr 2026 erläutert: Ohne Installation auf dem Startbildschirm auf iOS können keine Push-Benachrichtigungen abonniert werden.

Wann man die Installation anbieten sollte

• Nach der ersten nützlichen Aktion (Geschichte erstellt, Einstellungen gespeichert), nicht beim ersten Laden der Seite.
• Mit Erklärung des Nutzens: schnellerer Start, Benachrichtigungen, Symbol auf dem Bildschirm. Nicht „Installieren Sie unsere App“, sondern was genau der Benutzer erhält.
• Zeigen Sie die Aufforderung nicht an, wenn die App bereits im standalone-Modus geöffnet ist, und quälen Sie diejenigen nicht, die sie abgelehnt haben: Speichern Sie die Wahl für einige Tage.

💼 Abschnitt 10. Push: Wie man den Benutzer zurückholt

Kurze Antwort: Die Suche bringt den Menschen einmal, und Push hilft, ihn zurückzuholen. Daher ist es für PWAs Teil der Engagement-Strategie und keine Zusatzfunktion.

Der Benutzer kommt von Google, schaut sich das Produkt an und schließt den Tab. Ohne einen Rückkanal verlieren Sie ihn. Push löst dies: „Neue Geschichte fertig“ bringt den Menschen ohne Store und ohne Newsletter zurück in die App.

Was ich in der Praxis eingerichtet habe

Bei Kazki AI informierten Push-Benachrichtigungen die Benutzer über neue Geschichten und erinnerten an Abonnements. Im Blog eines praktizierenden Psychologen informierten Benachrichtigungen Abonnenten über neue Kurse und Veröffentlichungen. Beide Projekte zeigten, dass die Technologie für Informationsbenachrichtigungen zuverlässig genug funktioniert und kritische Benachrichtigungen besser per E-Mail dupliziert werden sollten. Details mit Code (Abonnement, Manifest, Service Worker, Push-Handler, 7 Gründe, warum Push-Benachrichtigungen nicht ankommen) finden Sie im Artikel PWA Push-Benachrichtigungen auf iOS im Jahr 2026: Was wirklich funktioniert.

Was für die Auffindbarkeit und Rückkehr wichtig ist

• Bitten Sie um Erlaubnis nach dem Wert, nicht beim ersten Laden. Auf iOS ist die Anfrage nur per Klick auf einen Button möglich.
• Verlassen Sie sich nicht nur auf Push. Auf iOS können Abonnements ungültig werden, und ein Teil der Benutzer wird die PWA einfach nicht installieren. Fügen Sie E-Mail, einen In-App-Feed und einen Zähler auf dem Symbol hinzu.
• Service oder eigener Backend. Wenn das Szenario einfach ist, reicht eine eigene Zustellung aus. Wenn Segmentierung und Kampagnen erforderlich sind, ziehen Sie fertige Dienste in Betracht. Vergleich: Push-Dienste für PWAs: OneSignal, FCM, Pushwoosh, WonderPush und Braze.

💼 Abschnitt 11. Wie man Ergebnisse misst

Bauen Sie einen Trichter von der Anzeige in der Suche bis zum wiederholten Besuch auf, aber erwarten Sie keine einheitliche Messung von Installationen in allen Browsern. Nehmen Sie Suchmetriken und Produktmetriken aus verschiedenen Tools.

Der Trichter sieht so aus:

1. Anzeige in der Suche (Search Console: Impressionen, durchschnittliche Position);
2. Klick (Search Console: Klicks; Analytik: Sitzungen nach Quelle);
3. Erster Start (Analytik: Ereignis der ersten Zielaktion);
4. Installation, wenn messbar;
5. Wiederholte Besuche (Analytik: Rückkehr in 7/30 Tagen);
6. Zielaktion (Registrierung, Kauf, Abonnement).

Was gemessen werden kann und was nicht

Praktische Methode, um Sitzungen einer installierten App von normalen Tabs zu unterscheiden:

const isStandalone =
  window.matchMedia('(display-mode: standalone)').matches ||
  window.navigator.standalone === true;

// Beispiel für GA4: Übergabe des Modus als Ereignisparameter
gtag('event', 'app_open', {
  display_mode: isStandalone ? 'standalone' : 'browser'
});

window.addEventListener('appinstalled', () => {
  gtag('event', 'pwa_installed');
});

Um den Parameter display_mode in den GA4-Berichten anzuzeigen, registrieren Sie ihn als benutzerdefiniertes Maß. Ein weiterer Trick: Fügen Sie dem start_url im Manifest ein Tag hinzu (z. B. /?source=pwa), damit Starts vom Startbildschirm in den Traffic-Quellen sichtbar sind.

Analysieren Sie nicht nur die Anzahl der Installationen. Wichtiger ist, ob diejenigen, die installiert haben, zurückkehren und ob Benutzer für die Anfragen kommen, die Sie wirklich festigen wollten.

💼 Abschnitt 12. Benötigt die SoftwareApplication-Auszeichnung?

Kurze Antwort: Die Auszeichnung hilft der Suchmaschine, die Seite zu verstehen, ist aber keine Bedingung für die Indexierung und erhöht die Positionen nicht. Google zeigt spezielle Ergebnisse für Anwendungen nur an, wenn seine Anforderungen erfüllt sind, und es gibt keine Garantie.

Ich empfehle, die Verwendung von SoftwareApplication oder WebApplication von Schema.org für die öffentliche Produktseite in Betracht zu ziehen. Eine solche Auszeichnung hilft Suchmaschinen besser zu verstehen, was der Dienst anbietet. Gleichzeitig ist ihre Implementierung keine obligatorische Bedingung für die Indexierung oder Sichtbarkeit der Seite in der Suche. Wenn Sie ein erweitertes Ergebnis für Anwendungen in Google erhalten möchten, überprüfen Sie die aktuellen Anforderungen in der offiziellen Dokumentation: Sie können sich ändern. Wichtig ist, dass die Auszeichnung dem tatsächlichen Inhalt der Seite entspricht. Fügen Sie keine erfundenen Preise, Bewertungen oder Rezensionen hinzu – dies verstößt gegen die Google-Richtlinien und kann zum Verlust erweiterter Ergebnisse führen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Anwendungsname",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}
</script>

Dies ist ein minimales Beispiel. Fügen Sie Bewertungen (aggregateRating) nur hinzu, wenn Sie echte Rezensionen haben, die auf der Seite sichtbar sind. Die Auszeichnung dient der Klarheit, nicht als Werbemittel, daher sollten Sie sich hauptsächlich auf die Abschnitte 2-5 konzentrieren.

✅ Abschnitt 13. SEO-Checkliste und PWA-Distribution

Die Reihenfolge der Aktionen hängt davon ab, ob das Produkt eine erkennbare Marke hat. Unten sind zwei Szenarien und ein Plan für die ersten sieben Tage.

Szenario A. Neues Produkt ohne Marke

• Öffentliche Produktseite mit HTML-Inhalt (SSG/SSR/Prerendering).
• Saubere URLs, korrekte 404/410-Status, keine Hash-Routen.
• Einzigartige title und description, sitemap.xml, robots.txt ohne Blockierung von Skripten und Stilen.
• Search Console und Bing Webmaster Tools, Überprüfung der Live-URL.
• Seiten für Anfragen zur Benutzeraufgabe, nicht für den Namen.
• 2-3 relevante Verzeichnisse und thematische Communities mit UTM-Tags.
• Installationsschaltfläche (Chromium), Hinweis für iOS, Push nach dem ersten Wert.
• Analysen mit dem Parameter display_mode und dem Ereignis appinstalled.

Szenario B. Bestehendes Produkt mit etablierter Nachfrage

• Überprüfung von Markenanfragen in der Search Console und deren Snippets (title, Website-Name).
• Audit des Renderings und der „weichen“ 404 für Seiten, die bereits Impressionen haben.
• Core Web Vitals für Seiten mit dem höchsten Traffic.
• Prüfung der Veröffentlichung in Stores, wenn die Zielgruppe die Anwendung genau dort sucht.
• Push und E-Mail zur Rückgewinnung bestehender Benutzer.

Plan für die ersten 7 Tage nach der Veröffentlichung

Dies ist ein Aktionsplan, keine Wachstumsprognose. Indexierung und Positionen hängen von vielen Faktoren ab, und ein Ergebnis innerhalb von sieben Tagen ist nicht garantiert.

❓ Häufig gestellte Fragen (FAQ)

Kann man PWA im App Store finden?

Nur, wenn es über eine native Hülle im Store veröffentlicht wurde. Eine normale PWA erscheint nicht im App Store: Benutzer finden sie über die Suche, Links oder Verzeichnisse und fügen sie auf dem iPhone manuell zum Startbildschirm hinzu.

Wie indexiert Google PWA?

Google crawlt öffentliche URLs, rendert sie in Chromium und fügt sie dem Index hinzu. Inhalte, die erst nach Ausführung von JavaScript erscheinen, können verzögert indexiert werden, und durch Authentifizierung geschützte Inhalte werden gar nicht indexiert. Es ist zuverlässiger, öffentliche Seiten als fertiges HTML (SSG, SSR oder Prerendering) bereitzustellen.

Benötigt PWA eine separate Website?

PWA ist die Website selbst, aber der öffentliche Teil (Landingpage, Funktionen, Preise, Artikel) sollte als separate indexierbare Seiten gestaltet werden. Der geschlossene Teil der Anwendung nach dem Login wird nicht in der Suche erscheinen.

Kann PWA in Google ranken?

Ja, wenn seine öffentlichen Seiten für die Indexierung zugänglich sind, einzigartigen Inhalt haben und die Anfrage des Benutzers erfüllen. Die Tatsache, dass es sich um eine PWA handelt, hat keinen Einfluss auf die Positionen: Das Manifest und der Service Worker sind keine Rankingfaktoren.

Kann man PWA in Google Play veröffentlichen?

Ja, über Trusted Web Activity: PWA wird in ein Android-Paket verpackt und die Verbindung zur Domain bestätigt. Überprüfen Sie die aktuellen Anforderungen an Entwicklerkonten und Anwendungen im Play Console, da diese sich ändern.

Wie installiert man PWA auf dem iPhone?

Öffnen Sie die Website in Safari (oder einem anderen Browser, der diese Option hat), tippen Sie auf „Teilen“ und wählen Sie „Zum Startbildschirm“. Es gibt keine automatische Installationsaufforderung unter iOS, daher muss der Hinweis in der Benutzeroberfläche angezeigt werden. Push-Benachrichtigungen auf dem iPhone sind nur für Anwendungen verfügbar, die zum Startbildschirm hinzugefügt wurden.

✅ Schlussfolgerungen

Eine native Anwendung findet man im Store, eine PWA muss man selbst „verbreiten“. Suche, korrektes Rendering, Verzeichnisse, Rückgewinnung über Push und Messung bilden ein einheitliches System, und jede Komponente ist notwendig.

• Technische Grundlage: öffentliche Seiten als fertiges HTML, saubere URLs, korrekte Status.
• Auffindbarkeit: Anfragen zur Aufgabe am Anfang, Markenbedarf später.
• Distribution: 2-3 relevante Verzeichnisse, Communities, bei Bedarf Stores.
• Rückgewinnung: Push + E-Mail + In-App, unter Berücksichtigung von iOS-Beschränkungen.
• Messung: Trichter von der Impression bis zum wiederholten Besuch.

🔗 Lesen Sie auch

• PWA vs. Native in 2026: Vergleich und realer Fall
• PWA Push-Benachrichtigungen auf iOS in 2026: Was wirklich funktioniert
• 8 kritische Fehler bei der PWA-Integration: Szenarien, Ursachen und Lösungen mit Code
• Push-Dienste für PWA: OneSignal, FCM, Pushwoosh, WonderPush und Braze

📖 Quellen

• Google Search Central: JavaScript SEO basics
• Google Search Central: Make your links crawlable
• Google Search Central: Build and submit a sitemap
• Google Search Central: Software app structured data
• web.dev: Web Vitals
• web.dev: Customize the install experience
• Chrome for Developers: Trusted Web Activity
• Apple: App Store Review Guidelines (Abschnitt 4.2)
• PWABuilder
• IndexNow