SEO voor progressive web apps: wat er misgaat en hoe je het oplost

SEO voor progressive web apps: wat er misgaat en hoe je het oplost

De meeste teams bouwen een PWA, een progressive web app (een website die zich gedraagt als een native app, installeerbaar en geschikt voor gebruik zonder internetverbinding), en gaan ervan uit dat de SEO zichzelf wel regelt. Dat doet het niet. Dezelfde JavaScript-zware architectuur die een PWA snel en app-achtig maakt, is precies wat de app onzichtbaar kan maken voor zoekmachines als je de rendering niet bewust aanpakt. Dit artikel behandelt de specifieke keuzes die bepalen of je PWA rankt of verdwijnt.

Een PWA is niet inherent slecht voor SEO. De renderingstrategie erachter meestal wel.

Waarom pwas SEO-problemen veroorzaken die de meeste teams niet verwachten

PWAs veroorzaken SEO-problemen niet vanwege de technologie zelf, maar omdat het standaard bouwpad de gebruikerservaring in de browser vooropstelt boven wat een crawler bij eerste contact ziet. Googlebot kan JavaScript uitvoeren, maar doet dat in een tweede golf, vaak met een vertraging van seconden of langer. Inhoud die alleen na die uitvoering bestaat, kan laat, gedeeltelijk of helemaal niet worden geïndexeerd.

De web.dev PWA-documentatie maakt duidelijk dat PWAs compatibel zijn met zoekindexering, maar compatibiliteit is niet hetzelfde als geoptimaliseerd zijn voor indexering. Het verschil tussen die twee is precies waar rankings stil worden.

Service workers, de achtergrondscripts die offline-functionaliteit en pushmeldingen in een PWA mogelijk maken, kunnen netwerkaanvragen onderscheppen op manieren die crawlers in verwarring brengen. Als een service worker een gecachte shell naar Googlebot stuurt in plaats van de volledige pagina-inhoud, indexeert de crawler een leeg kader. Dat is geen hypothetisch scenario. Het gebeurt in echte projecten, en het valt pas op als een rankingdaling weken later zichtbaar wordt.

De andere veelvoorkomende verrassing is het app-shell-model. Bij dit patroon laadt eerst een minimale HTML-shell en vult JavaScript de inhoud daarna dynamisch in. Voor gebruikers voelt dit direct aan. Voor Googlebot bij een eerste crawl kan het eruitzien als een pagina zonder inhoud.

Renderingstrategie: de keuze die alles bepaalt

De belangrijkste SEO-beslissing voor een PWA is hoe pagina’s worden gerenderd: op de server vóór levering, in de browser na het laden, of als vooraf gebouwd statisch bestand. Maak je hier de verkeerde keuze, dan helpt geen enkele metatag je er nog uit.

SSR, server-side rendering, betekent dat de server een volledig opgebouwde HTML-pagina naar de browser en naar Googlebot stuurt. De crawler ziet direct echte inhoud, zonder dat JavaScript hoeft te worden uitgevoerd. Dit is de veiligste optie voor SEO, en het is wat de meeste contentrijke of e-commerce PWAs standaard zouden moeten gebruiken.

CSR, client-side rendering, betekent dat de browser een vrijwel leeg HTML-bestand ontvangt en JavaScript de pagina in de browser opbouwt. Googlebot kan dit uiteindelijk renderen, maar de vertraging is reëel en het risico op onvolledige indexering is reëel. In een e-commerce PWA-project leidde de overstap van CSR naar SSR voor productpagina’s tot herstel van ongeveer 40 procent van de eerder niet-geïndexeerde URL’s binnen zes weken na heruitrol. Dat patroon is gangbaar genoeg om als basisverwachting te hanteren.

Prerendering is een tussenoptie: pagina’s worden tijdens het bouwproces gerenderd en als statische HTML geserveerd. Dit werkt goed voor inhoud die niet vaak verandert, zoals marketingpagina’s of blogberichten. Het schiet tekort wanneer inhoud gepersonaliseerd is of regelmatig wordt bijgewerkt, omdat de statische momentopname veroudert.

Dynamische rendering, waarbij een server detecteert of de bezoeker een bot is en een vooraf gerenderde versie specifiek aan crawlers serveert, is een omweg die Google historisch gezien heeft getolereerd maar niet officieel aanbeveelt. Gebruik het alleen als SSR of prerendering echt niet haalbaar is.

Beslisbox

• Geschikt als: je PWA inhoud serveert die moet ranken, je controle hebt over de renderingslaag, en je team SSR of statische generatie kan implementeren
• Minder geschikt als: je volledige app achter een inlogscherm zit en organisch zoekverkeer geen doel is
• Waarschijnlijk overbodig als: je een intern hulpmiddel of een volledig beveiligd SaaS-product bouwt waarbij geen pagina’s openbaar geïndexeerd hoeven te worden

Crawlbaarheid, sitemaps en wat googlebot werkelijk ziet

Googlebot kan een PWA crawlen, maar heeft daarvoor een duidelijk pad nodig. Zonder een goede sitemap en een robots.txt-bestand dat JavaScript- of CSS-bestanden niet per ongeluk blokkeert, gokt de crawler. Gokken is geen strategie.

Je sitemap moet elke URL bevatten die moet ranken. In een PWA met client-side routing worden routes vaak in JavaScript gedefinieerd en bestaan ze nooit als echte serverpaden. Als die routes niet worden omgezet naar echte serverreacties, worden ze niet gecrawld. Dit is een van de meest voorkomende hiaten in PWA SEO-audits: de sitemap vermeldt URL’s die aan de oppervlakte een 200-statuscode retourneren, maar die dezelfde lege shell serveren ongeacht welke route wordt opgevraagd.

Test dit door je PWA-URL’s rechtstreeks op te halen met een hulpmiddel zoals de URL-inspectietool van Google Search Console. Vergelijk wat de gerenderde pagina toont met wat de onbewerkte HTML-broncode bevat. Als die twee er heel anders uitzien, heb je een renderingsprobleem, geen sitemapprobleem.

Een praktische controle die tijd bespaart: schakel JavaScript uit in je browser en laad elke belangrijke pagina. Wat je ziet, is ongeveer wat een crawler bij eerste contact ziet. Als de pagina leeg is of alleen een laadanimatie toont, wordt die inhoud niet betrouwbaar geïndexeerd.

Voor teams die werken aan complexere SEO-vraagstukken bieden onze SEO-diensten technische audits die PWA-specifieke renderingscontroles standaard omvatten.

Metatags, structured data en het app-shell-probleem

Metatags in een PWA moeten aanwezig zijn in de server-gerenderde HTML, niet door JavaScript worden ingevoegd nadat de pagina is geladen. Dat klinkt vanzelfsprekend. Het is ook onjuist in een verrassend groot aantal live PWAs.

Het app-shell-model, waarbij een statisch HTML-kader wordt geserveerd en JavaScript de inhoud invult, betekent vaak dat de shell generieke of lege metatags bevat. De titeltag zegt op elke pagina “Mijn App”. De metabeschrijving is leeg. De canonical-tag verwijst naar het hoofddomein, ongeacht welk product of artikel wordt bekeken. Googlebot indexeert de shell, niet de inhoud.

De oplossing is ervoor te zorgen dat de unieke metatags van elke pagina, titel, beschrijving, canonical-URL en Open Graph-tags, ofwel server-gerenderd zijn, ofwel worden afgehandeld door een bibliotheek zoals React Helmet of Vue Meta die ze in de documentkop schrijft voordat de crawler klaar is met renderen. In de praktijk maakt SSR dit eenvoudig. Met CSR vereist het bewuste inspanning en testen.

Structured data, de JSON-LD-opmaak die Google vertelt wat voor type inhoud een pagina bevat, volgt dezelfde regel. Plaats het in de server-gerenderde HTML. Als het alleen verschijnt nadat JavaScript is uitgevoerd, kan het inconsistent worden opgepikt. Voor productpagina’s, artikelen of lokale bedrijfspagina’s in een PWA kan die inconsistentie betekenen dat je rich results misloopt die concurrenten met eenvoudigere websites standaard wel krijgen.

Core web vitals en prestaties: waar pwas echt een voordeel hebben

Core Web Vitals zijn Googles set prestatiestatistieken die rechtstreeks van invloed zijn op zoekrankings: Largest Contentful Paint (hoe snel de hoofdinhoud laadt), Interaction to Next Paint (hoe snel de pagina reageert op gebruikersinvoer) en Cumulative Layout Shift (hoeveel de lay-out verschuift tijdens het laden). PWAs kunnen, goed gebouwd, traditionele websites op deze statistieken echt overtreffen.

De service worker-caching die crawlbaarheidsproblemen veroorzaakt voor SEO, maakt terugkerende bezoeken ook extreem snel voor echte gebruikers. Een PWA die bestanden agressief cachet, kan terugkerende bezoekers bijna direct laden, wat de Core Web Vitals-gegevens van echte gebruikers verbetert en op termijn de rankings.

Het addertje onder het gras is dat de prestaties bij het eerste bezoek nog steeds afhangen van hoeveel JavaScript de browser moet downloaden en uitvoeren voordat er iets nuttigs verschijnt. Een op React gebaseerde PWA met een grote bundel en geen SSR kan een slechte Largest Contentful Paint-score hebben bij het eerste laden, ook al voelen volgende bezoeken direct aan. Dit is de afweging die de meeste PWA-prestatiegesprekken overslaan.

Het vooraf laden van kritieke bronnen, code splitting om de initiële bundelgrootte te verkleinen, en het gebruik van SSR om bij het eerste laden zinvolle HTML te leveren, zijn de drie hefbomen die Core Web Vitals-scores in een PWA-context werkelijk bewegen. Lighthouse, Googles open-source auditprogramma, brengt de specifieke knelpunten voor jouw build in kaart.

SEO in een pwa op de lange termijn onderhouden

PWA SEO is geen eenmalige instelling. De architectuur introduceert doorlopende risico’s die traditionele CMS-gebaseerde websites op dezelfde manier niet kennen. Elke raamwerkupdate, elke nieuwe route die via client-side routing wordt toegevoegd, en elke wijziging in de cachingstrategie van de service worker is een potentieel SEO-moment.

Het meest voorkomende patroon van langetermijnfalen ziet er zo uit: het team krijgt de initiële renderingsinstelling goed, lanceert de PWA, en zes maanden later werkt een ontwikkelaar de service worker bij om agressiever te cachen. De nieuwe cachingregel serveert per ongeluk verouderde of shell-only reacties aan Googlebot. Niemand merkt het totdat rankings dalen. Tegen die tijd is de oorzaak moeilijk te achterhalen.

Geautomatiseerde monitoring van gerenderde pagina-inhoud, niet alleen van HTTP-statuscodes, is het praktische antwoord. Hulpmiddelen zoals Screaming Frog met ingeschakelde JavaScript-rendering, of een aangepast script dat onbewerkte HTML vergelijkt met gerenderde uitvoer, vangen dit soort problemen op voordat Google dat doet.

Wat je maandelijks checkt

• Google Search Console dekkingsrapport: let op nieuwe vermeldingen van “Ontdekt, momenteel niet geïndexeerd” of “Gecrawld, momenteel niet geïndexeerd” na elke uitrol
• URL-inspectie steekproeven: test 5 tot 10 belangrijke URL’s na elke grote release om te bevestigen dat gerenderde inhoud overeenkomt met de verwachte uitvoer
• Core Web Vitals veldgegevens: controleer de CrUX-gegevens (Chrome User Experience Report) in Search Console op prestatieverslechteringen bij echte gebruikers
• Service worker-wijzigingenlogboek: beoordeel elke service worker-update op cachingregels die van invloed kunnen zijn op wat crawlers ontvangen
• Structured data-validatie: voer belangrijke paginatypen na sjabloonwijzigingen door de Rich Results Test van Google

SEO voor progressive web apps is een oplosbaar probleem, maar het vereist bewuste keuzes op architectuurniveau, niet alleen op inhoudsniveau. De renderingstrategie, de service worker-configuratie en de methode voor het leveren van metatags hebben elk echte rankingconsequenties. Studio Ubique werkt samen met teams die PWAs bouwen om deze technische SEO-hiaten te auditen en op te lossen voordat ze rankingproblemen worden. Volgens Google Search Central (2024) verwerkt Googlebot JavaScript in een uitgestelde tweede golf, wat betekent dat inhoud die afhankelijk is van client-side rendering standaard een indexeringsrisico met zich meebrengt.

Veelgestelde vragen

Kan Google een progressive web app indexeren?

Ja, Google kan een PWA indexeren, maar de kwaliteit van die indexering hangt sterk af van hoe de app zijn inhoud rendert. Als pagina’s server-gerenderd of vooraf gerenderd zijn, ziet Googlebot direct volledige HTML. Als inhoud alleen verschijnt nadat client-side JavaScript is uitgevoerd, kan indexering vertraagd, gedeeltelijk of inconsistent zijn, afhankelijk van hoe complex de rendering is.

Schaden service workers de SEO?

Service workers schaden SEO niet standaard, maar ze kunnen dat wel doen als ze onzorgvuldig zijn geconfigureerd. Een service worker die aanvragen onderschept en een gecachte app-shell naar alle bezoekers serveert, inclusief Googlebot, zorgt ervoor dat de crawler een lege of vrijwel lege pagina indexeert. De oplossing is ervoor te zorgen dat service workers volledige inhoud aan crawlers serveren, of SSR te gebruiken zodat de serverreactie al volledig is voordat de service worker erbij betrokken is.

Wat is de beste renderingstrategie voor pwa SEO?

Server-side rendering is de meest betrouwbare optie voor SEO in een PWA. Het levert bij eerste contact volledige HTML aan Googlebot, zonder dat JavaScript hoeft te worden uitgevoerd. Statische generatie, prerendering tijdens het bouwproces, is een goed alternatief voor inhoud die niet vaak verandert. Client-side rendering alleen brengt het meeste indexeringsrisico met zich mee en moet worden vermeden voor pagina’s die in zoekresultaten moeten ranken.

Hoe controleer ik wat googlebot ziet op mijn pwa?

Gebruik de URL-inspectietool in Google Search Console en klik op “Live URL testen” om de gerenderde versie van een pagina te bekijken. Vergelijk de gerenderde uitvoer met de onbewerkte HTML-broncode. Als de gerenderde versie aanzienlijk meer inhoud bevat dan de onbewerkte HTML, zijn je pagina’s afhankelijk van client-side JavaScript voor hun inhoud, wat een risicofactor is voor indexering. Je kunt ook JavaScript uitschakelen in je browser als snelle eerste controle.

Heeft een pwa-manifestbestand invloed op SEO?

Het manifest.json-bestand, dat bepaalt hoe een PWA eruitziet wanneer het op een apparaat wordt geïnstalleerd, heeft geen directe invloed op zoekrankings. Google gebruikt het niet als rankingsignaal. Een goed geconfigureerd manifest draagt echter bij aan een betere gebruikerservaring voor bezoekers die de app installeren, en gebruikerservaringssignalen werken op termijn door in Core Web Vitals-gegevens. Houd het manifest nauwkeurig bij, maar behandel het niet als een SEO-hefboom.