PWA und SEO: Wenn eine Progressive Web App zur Sichtbarkeitsfalle wird – Eine Case Study.
Progressive Web Apps (PWA) gelten als moderne Webtechnologie mit großem Potenzial. Doch was passiert, wenn eine PWA für den falschen Anwendungsfall eingesetzt wird? Diese Case Study zeigt, wie ein E-Commerce-Unternehmen durch eine PWA-Implementierung massiv an SEO-Sichtbarkeit verlor – und wie gezielte Maßnahmen die Trendwende einleiteten.
Abbildung 1: Java Script-Code, wie man ihn bei PWAs schreibt.
Inhalt
- Welche Frontend-Technologie ist die Richtige für einen Onlineshop?
- Was sind Progressive Web Apps (PWA)?
- Wie unterscheiden sich native Apps, PWA und klassische Webseiten?
- Der Ausgangspunkt: Organische Sichtbarkeit im freien Fall
- PWA und SEO: Warum Progressive Web Apps für Suchmaschinen problematisch sind
- Die Analyse: Fünf PWA-bedingte SEO-Probleme im Detail
- Die strategische Entscheidung: PWA sofort umbauen oder Relaunch abwarten?
- Die umgesetzten SEO-Maßnahmen an der PWA
- Die Ergebnisse: Wie die SEO-Sichtbarkeit trotz PWA zurückkehrte
- Ist eine PWA für Dein Projekt sinnvoll?
- Learnings: Was diese PWA-SEO-Case-Study lehrt
- Fazit: PWA mit Bedacht einsetzen, und: SEO von Anfang an mitdenken!
Welche Frontend-Technologie ist die Richtige für einen Onlineshop?
Technologische Entscheidungen gehören zu den folgenreichsten im E-Commerce. Wenn ein Onlineshop auf eine Architektur wie eine Progressive Web App (kurz: PWA) setzt, die nicht zum eigenen Anwendungsfall passt, kann das über Monate hinweg organische Sichtbarkeit und damit Umsatz kosten – schleichend, fast unbemerkt. Genau das ist einem unserer Kunden passiert: einem etablierten E-Commerce-Unternehmen mit zwei großen Onlineshops, das seine gesamte Frontend-Architektur auf eine PWA umgestellt hatte.
In dieser Case Study zeige ich Dir, was genau passiert ist, wie wir die PWA-bedingten SEO-Probleme identifiziert haben und welche Maßnahmen letztlich zur Trendwende geführt haben. Und vor allem: Was Du daraus für Deine eigenen Projekte mitnehmen kannst – unabhängig davon, ob Du gerade eine PWA evaluierst oder bereits einsetzt.
Was sind Progressive Web Apps (PWA)?
Bevor wir in die eigentliche Case Study einsteigen, klären wir zunächst die Grundlagen. Denn die Frage „Was ist eine PWA?“ wird erstaunlich oft falsch beantwortet.
Eine Progressive Web App (PWA) ist streng genommen keine einfache Website-Technologie, sondern eine vollwertige Anwendungstechnologie. Sie wird komplett mittels Java Script realisiert und läuft vollständig im Browser. Vergleichbar mit einer nativen App aus dem App Store, jedoch plattformunabhängig und ohne Installation über einen Store.
Der Kern einer PWA ist der sogenannte Service Worker: ein Skript, das im Hintergrund des Browsers läuft und als „intelligenter Helfer“ fungiert. Beim ersten Besuch einer PWA wird dieser Service Worker installiert und speichert das Grundgerüst der Anwendung (die sogenannte App Shell) lokal auf dem Gerät des Users. Bei jedem weiteren Besuch liefert der Service Worker dieses Grundgerüst sofort aus: die PWA erscheint augenblicklich, selbst ohne aktive Internetverbindung. Erst danach werden im Hintergrund neue Inhalte vom Server nachgeladen.
Abbildung 2: Ladeverhalten einer PWA
PWAs bringen enorme Vorteile bei hochdynamischen, interaktiven Anwendungen: Social-Media-Plattformen wie Facebook, Echtzeit-Dashboards, kollaborative Tools oder Messaging-Dienste. Überall dort, wo sich Inhalte asynchron und ständig verändern, spielen Progressive Web Apps ihre Stärken voll aus.
Wie unterscheiden sich native Apps, PWA und klassische Webseiten?
Um die Bedeutung einer PWA für SEO richtig einzuordnen, hilft der direkte Vergleich der drei Ansätze:
Klassische Website (HTML/CSS, serverseitig)
Bei einer klassischen Website wird bei jedem Seitenaufruf eine vollständige HTML-Datei vom Server an den Browser gesendet. Der Browser interpretiert das HTML, lädt CSS und gegebenenfalls etwas Java Script nach und stellt die Seite dar. Bei jedem Klick auf einen Link wird ein neues, vollständiges HTML-Dokument geladen.
Dieses Modell ist für Suchmaschinen optimal: Jede URL liefert ein fertiges Dokument mit allen rankingkritischen Inhalten.
Progressive Web App (PWA)
Eine PWA funktioniert grundlegend anders. Beim ersten Besuch wird ein nahezu leeres Grundgerüst (die App Shell) geladen und der Service Worker installiert. Die eigentlichen Inhalte – Produktdaten, Texte, Bilder – werden nachträglich über Java Script-Requests (häufig als JSON über APIs) in dieses Gerüst hineingerendert.
Bei Folgebesuchen kommt die PWA-Magic zum Tragen: Der Service Worker liefert die App Shell sofort aus dem Cache, Inhalte werden asynchron nachgeladen. Das fühlt sich für den*die Nutzer*in schnell und App-ähnlich an, doch: Für Suchmaschinen-Crawler, die auf vollständige HTML-Dokumente angewiesen sind, entsteht ein fundamentales Problem.
Abbildung 3: Ladeverhalten der unterschiedlichen Technologien
Native App (iOS/Android)
Native Apps werden über App Stores installiert, laufen auf dem Betriebssystem des Geräts und haben vollen Zugriff auf Geräte-Features wie Kamera, GPS oder Push-Notifications.
Für SEO sind sie irrelevant, ihre Inhalte sind für Suchmaschinen nicht direkt indexierbar (es sei denn, App Indexing ist implementiert). Native Apps bedienen einen völlig anderen Kanal.
Die entscheidende Erkenntnis: Eine PWA sitzt architektonisch zwischen nativer App und klassischer Website. Sie bietet App-ähnliches Verhalten im Browser, aber genau dieses Verhalten macht sie für Suchmaschinen schwieriger zu verarbeiten als eine klassische HTML-Website. Und genau hier liegt das PWA-SEO-Risiko, das viele unterschätzen.
Der Ausgangspunkt: Organische Sichtbarkeit im freien Fall
Als wir das Projekt übernahmen, zeigte sich bei beiden Shops des Kunden das gleiche alarmierende Bild:
Die organische Sichtbarkeit sank seit Monaten kontinuierlich. Kein plötzlicher Absturz nach einem Google-Update, kein offensichtlicher Content-Verlust, sondern ein schleichendes Abschmelzen der Rankings über einen längeren Zeitraum.
Abbildung 4: Fallende Sichtbarkeit im ersten Shop
Der zweite Shop zeigte mit leichtem Zeitversatz exakt dasselbe Muster. Ein starkes Indiz dafür, dass hier kein Content-Problem vorlag, sondern ein technisches, strukturelles Problem, und zwar eines, das beide Shops gleichermaßen betraf.
Abbildung 5: Fallende Sichtbarkeit im zweiten Shop
Besonders aufschlussreich: Auch die österreichischen Ableger der beiden Shops, die denselben TechStack nutzten, zeigten identische Verluste. Das grenzte die Ursache endgültig ein. Es musste an der gemeinsamen technologischen Basis liegen: der Progressive Web App.
PWA und SEO: Warum Progressive Web Apps für Suchmaschinen problematisch sind
Wir SEOs kämpfen seit mindestens zehn Jahren mit Java Script-Framework-Technologien beim Einsatz für Websites. Und eine PWA potenziert diese Probleme noch. Die Gründe sind vielschichtig:
Suchmaschinen und Java Script-Rendering: Google interpretiert Websites in zwei Phasen. Zunächst das reine HTML (Text-Crawling), dann eine zweite Runde mit Java Script-Rendering über einen Headless Browser. Dabei werden nicht immer alle Elemente zuverlässig erkannt. Frameworks wie ReactJS, AngularJS, VueJS oder NextJS hatten alle dasselbe Grundproblem: Sie liefern mit und ohne Java Script unterschiedliche Inhalte aus.
Die SEO-Antwort: Server Side Rendering (SSR). Die Idee klingt einfach. Das Java Script wird auf dem Server gerendert, und der Client bekommt fertiges HTML. Das war auch bei unserem Kunden teilweise umgesetzt. Aber hier drängt sich eine unbequeme Frage auf:
Wenn ich eine PWA baue, um dann per SSR doch wieder statisches HTML auszuliefern, warum habe ich dann eine Progressive Web App gebaut?
Dazu kommt der Prozess der Hydration: Das vorgerenderte HTML wird im Browser nachträglich mit Java Script-Funktionalität „zum Leben erweckt“. Erst ist die Seite „trocken“ (kein JS aktiv), dann wird parallel zur Anzeige das virtuelle DOM aufgebaut, und erst danach werden Klicks und Eingaben tatsächlich aktiv. Auch dieser Prozess ist für Crawler nicht trivial zu handhaben.
Abbildung 6: Prinzip der Hydration einer PWA
Google hat zu den verschiedenen Rendering-Methoden und deren SEO-Implikationen klare Empfehlungen publiziert, die allerdings längst nicht jedes Entwicklungsteam auf dem Schirm hat.
Abbildung 7: Infosheet über verschiedene Methoden und ihre Implikationen
💡 Tipp: Lies Dir Googles Dokumentation zu Rendering-Strategien auf web.dev durch. Die Tabelle mit den Trade-offs zwischen Static SSR, Server Rendering, CSR und Universal Rendering ist Gold wert für jede Architekturentscheidung rund um PWA und SEO.
Die Analyse: Fünf PWA-bedingte SEO-Probleme im Detail
Die technische Analyse mit den Chrome DevTools und der Google Search Console brachte fünf zentrale Probleme ans Licht, die alle direkt mit der PWA-Architektur zusammenhingen.
1. Frontend ohne Java Script = keine nutzbares Shop-Frontend
Die gesamte Seite war ohne aktiviertes Java Script schlicht nicht nutzbar. Der Content wurde zwar sichtbar, allerdings war die Seite schlicht nicht nutzbar. Für einen menschlichen Nutzer mit modernem Browser kein offensichtliches Problem, sofern Java Script aktiviert ist – für Suchmaschinen-Crawler hingegen eine erhebliche Hürde.
💡 Tipp: Teste Deine PWA regelmäßig mit deaktiviertem Java Script im Browser. Was Du dann siehst, ist eine Annäherung an das, was ein Crawler im ersten Durchlauf wahrnimmt. Nutze dafür die Chrome DevTools (Settings → Debugger → Disable Java Script) oder den Live-Test im URL-Prüftool der
2. Google crawlte die PWA-API statt HTML-Seiten
Ein Blick in die GSC-Crawling-Statistiken offenbarte: Google verbrachte den Großteil seiner Crawling-Ressourcen damit, JSON-Daten über die API abzurufen, Produktdaten, Preisinformationen, Konfigurationen. Über 52 % aller gecrawlten Ressourcen waren JSON, nur 36 % waren tatsächliches HTML.
Abbildung 8: Crawling-Verteilung, aufgeteilt nach Dateityp
Das bedeutet: Google investierte den Großteil seines Crawling-Budgets in Daten, die keinerlei rankingkritische Onpage-Signale enthalten.
Titles, Descriptions, Überschriften, strukturierte Daten – all das steckt im HTML, nicht in der JSON-API einer PWA.
Abbildung 9: Menge der Crawling-Anfragen, Spike durch JSON-Crawls
3. Unterschiedliche Inhalte mit und ohne Java Script-Rendering
Die PWA lieferte je nach Java Script-Status unterschiedliche Inhalte aus, bzw. zeigte Inhalte erst gar nicht an. Das serverseitig vorgerenderte Template enthielt nur ein Grundgerüst. Die eigentlichen Inhalte (Produkte, Preise, Bilder, Beschreibungen) wurden erst nachträglich via Java Script hineingerendert. Google konnte zwar das Template indexieren, aber die tatsächlich rankingkritischen Inhalte wurden nur sporadisch oder unvollständig erfasst.
💡 Tipp: Vergleiche immer die Browser-Ansicht Deiner PWA mit dem gerenderten Screenshot im GSC-URL-Prüftool. Weichen diese deutlich voneinander ab, hast Du ein Rendering-Problem. Nutze den Live-Test, nicht nur den Index-Test – der Live-Test zeigt Dir den aktuellen Zustand.
4. Über 740 Java Script-Requests pro Seitenaufruf
Die PWA-Architektur lud bei jedem Seitenaufruf über 740 Java Script-Ressourcen nach. Insgesamt wurden mehr als 1.400 einzelne Requests an den Server gestellt. Zum Vergleich: Ein klassisches Magento-Frontend kommt mit einem Bruchteil davon aus.
Abbildung 10: Netzwerktraffic (Requests an den Server und Datenmenge) PWA
Abbildung 11: Netzwerk-Traffic (Requests an den Server und Datenmenge) „normales“ Frontend Magentoshop
💡 Tipp: Nutze den „Network“-Tab der Chrome DevTools, um die Anzahl der Requests Deiner Seite zu analysieren. Filtere nach Dokumenttyp (JS, CSS, XHR) und sortiere nach Größe. Jeder unnötige Request kostet Ladezeit und Crawling-Ressourcen, bei einer PWA mit hunderten JS-Dateien summiert sich das massiv.
5. PWA-Seitengröße weit über Googles Empfehlungen
Der Gesamtumfang aller geladenen Dateien lag bei der PWA zwischen 35 und 45 MB pro Seitenaufruf. Googles eigene Empfehlungen für die maximale Seitengröße liegen deutlich darunter. Ein klares Signal, dass die PWA-Architektur für einen E-Commerce-Shop überdimensioniert war.
Abbildung 12: Google-Statement zur Dateigrößen beim Crawling (Quelle).
Abbildung 13: Google-Statement zur Dateigrößenbegrenzung (Quelle)
Die strategische Entscheidung: PWA sofort umbauen oder Relaunch abwarten?
Die Entscheidung, das PWA-Frontend komplett zu wechseln, war beim Kunden bereits gefallen, aber der Relaunch-Termin lag noch in einiger Ferne. Zwei Optionen standen im Raum:
Option A: Die bestehende PWA sofort und vollständig umbauen, um sie für Suchmaschinen tauglich zu machen.
Option B: Gezielt die Low Hanging Fruits ernten, Maßnahmen umsetzen, die sich im Relaunch migrieren lassen, und den vollen Fokus auf den Relaunch legen.
Wir haben uns für Option B entschieden – den betriebswirtschaftlich sinnvollsten Weg. Keine redundante Arbeit, kein Verzögern des Relaunches. Nur Maßnahmen, die sofort wirken und gleichzeitig ins neue Frontend übertragbar sind.
Abbildung 13: Abwägung, ob direkt optimieren oder auf den Relaunch fokussieren
💡 Tipp: Stehst Du vor einer ähnlichen Entscheidung mit Deiner PWA? Rechne es durch und handle nicht nach Bauchgefühl. Was kosten Dich die Umsatzeinbußen durch den Status quo, bis der Relaunch live geht? Was würde es kosten, jetzt die PWA zu optimieren, wenn der Relaunch sich dadurch um X Wochen verschiebt (inklusive potenziell doppelter Entwicklungskosten)? Der betriebswirtschaftlich sinnvollste Weg gewinnt immer.
Die umgesetzten SEO-Maßnahmen an der PWA
Die folgenden Maßnahmen haben wir für die ersten Optimierungen umgesetzt.
Priorität 1: Crawling-Budget der PWA richtig steuern
Das erste Ziel: Googles Crawling-Ressourcen weg von den JSON-API-Endpunkten der PWA und hin zu den tatsächlich rankingkritischen HTML-Dokumenten lenken.
Die Umsetzung war simpel – ein gezielter Eintrag in der robots.txt:
User-Agent: Googlebot
Disallow: /api
Die These dahinter: Wenn Google bei einer PWA überwiegend JSON-Produktdaten crawlt und bewertet, gehen die eigentlichen Onpage-Signale aus den HTML-Dokumenten unter. Durch das Blockieren der API-Endpunkte zwingen wir den Crawler, sich auf die HTML-Seiten zu konzentrieren.
💡 Tipp: Prüfe in der Google Search Console unter „Einstellungen → Crawling-Statistiken“, welche Dateitypen Google bei Deiner PWA am häufigsten crawlt. Ist der HTML-Anteil auffällig niedrig, verschwendet der Bot seine Ressourcen möglicherweise für irrelevante API-Endpunkte. Eine gezielte robots.txt-Steuerung kann hier Wunder wirken.
Priorität 2: PWA ohne Java Script nutzbar machen
Spezielle CSS-Attribute blockierten die gesamte PWA, wenn Java Script deaktiviert war. Diese Blockaden wurden entfernt, sodass die Seite zumindest navigierbar und die Inhalte zugänglich waren – auch ohne vollständiges Java Script-Rendering.
Google bewertet CSS als Ressource und nutzt es, um die tatsächliche Nutzbarkeit einer Seite einzuschätzen. CSS-Regeln, die eine PWA komplett blockieren, senden ein fatales Signal, nicht nur hinsichtlich Usability, sondern potenziell auch in Richtung Cloaking-Verdacht.
💡 Tipp: Achte darauf, dass CSS-Regeln wie display: none oder visibility: hidden in Deiner PWA nicht dafür verwendet werden, die gesamte Seite bei fehlendem Java Script auszublenden. Eine <noscript>-Fallback-Lösung ist der sauberere Weg. Sie signalisiert Suchmaschinen, dass Du an Zugänglichkeit gedacht hast.
Priorität 3: „Migrierbare“ Onpage-Optimierungen
Parallel dazu haben wir alle Onpage-Maßnahmen umgesetzt, die sich 1:1 auf das neue Frontend übertragen ließen, also unabhängig von der PWA-Architektur Bestand haben:
- Strukturierte Daten angereichert und korrigiert
- Interne Verlinkung optimiert, Linkattribute bereinigt
- Meta-Titles und -Descriptions überarbeitet
- Indexierungsschema bei Paginierungen korrigiert
- Canonical Tags harmonisiert
- Headline-Struktur (H1–H6) überprüft und angepasst
- Vereinzelt Content ergänzt und optimiert
💡 Tipp: In Relaunch-Szenarien – besonders beim Wechsel weg von einer PWA – lohnt es sich immer zu prüfen: Welche SEO-Optimierungen kann ich jetzt umsetzen, die mit dem Relaunch nicht verloren gehen? Strukturierte Daten, Canonical-Strategien, interne Verlinkungskonzepte: All das lässt sich in der Regel problemlos portieren.
Was wir an der PWA bewusst nicht angefasst haben
Alles, was einen strukturellen Eingriff in die PWA-Architektur erfordert hätte, haben wir konsequent ausgeklammert:
- Begrenzung der Dokumentengröße und Ressourcen-Routing
- Optimierung der Java Script-Nutzung (Script-Splitting/Merging)
- CSS-Optimierung und Konsolidierung
- Bildformat-Umstellungen
- Bereinigung der HTML-Sources
- Grundlegende Änderungen am Rendering oder dem Hydrationsprinzip der PWA
Diese Punkte wurden direkt in die Relaunch-Planung aufgenommen, als Anforderungen an das neue, nicht-PWA-basierte Frontend.
Die Ergebnisse: Wie die SEO-Sichtbarkeit trotz PWA zurückkehrte
Die Wirkung der Maßnahmen zeigte sich zunächst in den Crawling-Statistiken: Der Linkgraph verschob sich in die richtige Richtung. Google crawlte wieder verstärkt HTML-Dokumente statt API-Endpunkte der PWA.
Abbildung 14: Googles Betrachtung des Linkgraphs korrigiert sich
Und dann das, worauf es wirklich ankommt, begann sich zu erholen: Die organische Sichtbarkeit. Bei beiden Shops kehrten Rankings zurück, der Abwärtstrend war gestoppt.
Abbildung 15: Sichtbarkeit vom ersten Shop erholt sich
Abbildung 16: Sichtbarkeit vom zweiten Shop erholt sich
Wohlgemerkt: Das waren die Ergebnisse noch vor dem Relaunch auf ein neues Frontend. Allein durch gezielte, chirurgische Eingriffe in die bestehende PWA-Architektur, ohne deren Grundstruktur anzutasten.
Ist eine PWA für Dein Projekt sinnvoll?
Das ist die Frage, die sich nach dieser Case Study aufdrängt. Und die Antwort ist – wie so oft im SEO – differenzierter, als wir es uns wünschen.
Wann eine Progressive Web App Sinn ergibt:
Eine PWA ist die richtige Wahl, wenn Dein Projekt tatsächlich die Stärken dieser Technologie benötigt:
- Offline-Fähigkeit,
- Push-Notifications im Browser,
- hochdynamische Inhalte, die sich ständig und in Echtzeit verändern,
- App-ähnliche Interaktionsmuster ohne App-Store-Abhängigkeit.
Denke an Szenarien wie Social-Media-Plattformen, Collaboration Tools, Echtzeit-Dashboards oder Progressive Web Apps für interne Business-Anwendungen, bei denen SEO keine Rolle spielt.
Wann Du von einer PWA absehen solltest:
Für
- überwiegend statische Websites,
- klassische Onlineshops mit Kategorie- und Produktseiten,
- Blogs,
- Unternehmenswebsites oder
- statische Content-Plattformen
ist eine PWA in aller Regel Overkill – und im schlimmsten Fall ein SEO-Risiko.
Die Vorteile einer Progressive Web App kommen hier kaum zum Tragen, die Nachteile für die Suchmaschinenoptimierung dafür umso mehr.
PWA: Ja oder nein? 4 Fragen, die Dir bei der Entscheidung helfen können
Bevor Du Dich für oder gegen eine PWA entscheidest, stelle Dir folgende Fragen:
- Benötige ich die spezifischen PWA-Features (Offline-Fähigkeit, Service Worker, App Shell)? Oder möchte ich „nur“ eine schnelle, moderne Website?
- Wie wichtig ist organische Sichtbarkeit für mein Geschäftsmodell? Je höher die SEO-Abhängigkeit, desto kritischer die Technologiewahl.
- Hat mein Entwicklungsteam Erfahrung mit den SEO-Implikationen von Java Script-Frameworks und PWA-Architekturen? Wenn nein, wer im Team stellt sicher, dass SEO-Anforderungen in der Architektur berücksichtigt werden?
- Ergibt sich durch die Anpassung an Marketing- und SEO-Anforderungen (SSR, Hydratation, Pre-Rendering) weiterhin ein technischer Vorteil der PWA? Oder neutralisiere ich damit genau die Features, die eine Progressive Web App auszeichnen?
💡 Tipp: Challenged eure Entwickler*innen! Die Frage „Welche Technologie wollen wir verwenden?“ ist die falsche Fragestellung. Die richtige lautet: „Welche Technologie passt zu unserem konkreten Anwendungsfall?“ Wollen wir eine größtenteils statische Website, einen Onlineshop, einen dynamischen Marktplatz oder ein Social Network? Die Antwort bestimmt die Technologie und nicht der Coding Comfort des Teams.
Abbildung 17: Key Takeaways aus dieser Case Study
Learnings: Was diese PWA-SEO-Case-Study lehrt
Wie bei allen kniffligen Fällen, haben wir auch hier einiges gelernt. Hier sind die Key Learnings von diesem Fall.
1. Technologiewahl ist eine Businessentscheidung
Die Architektur muss die Geschäftsanforderungen widerspiegeln, nicht umgekehrt. Ich habe selbst Fälle erlebt, in denen, durch technologische Hürden einer PWA, Businessanforderungen schlicht nicht mehr umsetzbar waren. Wenn die Technologie Dein Geschäftsziel einschränkt, stimmt etwas Grundlegendes nicht.
2. PWA und SEO bleiben ein Spannungsfeld
Auch nach Jahren des Fortschritts gibt es nach wie vor Implikationen beim Crawling und Indexing von Java Script-Framework-basierten Websites – ob PWA, ReactJS, AngularJS, VueJS oder NextJS.
Google selbst sagt, dass es Einschränkungen gibt. Wer das bei der Wahl einer Progressive Web App ignoriert, geht ein messbares SEO-Risiko ein.
3. Betriebswirtschaftlich denken, nicht technologisch träumen
Achte immer auf den Business Impact. Rechne aus, was der wirtschaftlich bessere Weg aus einer solchen Situation ist. Die Frage „Was kostet mich der Status quo vs. was kostet mich die sofortige Optimierung?“ liefert fast immer eine klarere Antwort als jede technische Diskussion.
4. Strategische Aspekte vs. Coding Comfort
Eine unbequeme Wahrheit: Manchmal wird eine PWA nicht deshalb gewählt, weil sie die beste Lösung für das Problem ist, sondern weil das Entwicklungsteam damit am liebsten arbeitet. Das ist menschlich nachvollziehbar, aber betriebswirtschaftlich fatal. Wäge immer ab: strategische Notwendigkeit vs. technologische Präferenz.
Fazit: PWA mit Bedacht einsetzen, und: SEO von Anfang an mitdenken!
Diese Case Study zeigt ein Muster, das mir in der SEO-Praxis immer wieder begegnet: Trendtechnologien wie Progressive Web Apps werden eingesetzt, ohne, dass der tatsächliche Anwendungsfall das rechtfertigt. Die Konsequenzen sind oft schleichend und wenn sie sichtbar werden, hat man sich bereits in eine PWA-Architektur manövriert, aus der ein schneller Rollback nicht möglich ist.
Die gute Nachricht: Selbst in einer solchen Situation lässt sich mit gezielten, durchdachten SEO-Maßnahmen eine Trendwende einleiten.
Die noch bessere Nachricht: Mit der richtigen Fragestellung zu Beginn eines Projekts lässt sich die Situation komplett vermeiden.
Mein Rat: Investiere die Zeit in die Technologieevaluierung am Anfang. Challenge die Empfehlungen. Rechne den Business Case durch. Und frage Dich bei jeder Architekturentscheidung: Dient diese Progressive Web App unserem Geschäftsziel – oder nur dem technologischen Ehrgeiz?
Du stehst vor einer ähnlichen Herausforderung oder planst einen Technologiewechsel weg oder von einer PWA oder gar hin zu einer solchen Technologie? Kontaktiere uns gern, wir helfen Dir, die richtige Entscheidung zu treffen.
Bildnachweis: Titelbild: tippapatt/stock.adobe.com; Bild 2: Grafik Seokratie GmbH, Ladeverhalten schematisch dargestellt; Bild 3: Grafik Seokratie GmbH, Ladeverhalten grafisch dargestellt; Bild 4 & Bild 5: Screenshot Seokratie GmbH, Sichtbarkeitschart sistrix.de, Bild 6: Grafik Seokratie GmbH, schematische Darstellung Funktionsweise Hydration einer PWA; Bild 7: Screenshot Seokratie GmbH, Search Console Crawlingstatistiken; Bild 8: Screenshot Seokratie GmbH, Search Console Crawlingrequests; Bild: 9 & Bild 10: Screenshot Seokratie GmbH, Chrome Web Developer Toolbar; Bild 11 & Bild 12: Screenshot Seokratie GmbH, Google Webedeveloper https://web.dev/; Bild 13: Screenshot Seokratie GmbH, Darstellung einer Waage mit Argumenten, Bild 14: Screenshot Seokratie GmbH, Google Search Console interne Verlinkung; Bild 15 & Bild 16: Screenshot Seokratie GmbH, Sichtbarkeitsentwicklung sistrix.de; Bild 17: dzmitry/stock.adobe.com
