Static Site SEO: Jamstack, SSG en vindbaarheid realiseren

TL;DR: Static site SEO begint met een belangrijk voordeel: essentiële content kan als vooraf gerenderde HTML aankomen, in plaats van te wachten op JavaScript. Maar Astro, Hugo, 11ty, Gatsby, Jekyll en statische Next.js-exports lossen canonicals, metadata, structured data, redirects, interne links of client-rendered widgets die content verbergen voor crawlers niet automatisch op. Beoordeel de uitgerolde HTML, niet het frameworkslabel.

Wat static sites echt “gratis” opleveren

Een static-site generator zoals Astro, Hugo, 11ty, Jekyll, Gatsby of Next.js in static-exportmodus draait templates en content tijdens de build. Daarbij worden HTML-bestanden gegenereerd, plus de CSS, JavaScript en assets die elke pagina nodig heeft. De hostinglaag kan die bestanden serveren zonder een database te hoeven bevragen of de pagina voor elk verzoek opnieuw te renderen.

Dat doet ertoe, omdat Google pagina’s verwerkt via crawlen, renderen, indexeren en serveren. Onze gids over hoe Google indexing werkt beschrijft die fases uitgebreid. Het statische voordeel is eenvoudiger: als de copy en links al in de gedownloade HTML staan, hoeft Google geen JavaScript te gebruiken om ze te ontdekken.

“Onthoud dat server-side of pre-rendering nog steeds een heel goed idee is, omdat het je website sneller maakt voor gebruikers en crawlers, en niet alle bots JavaScript kunnen uitvoeren.”

Dit is de formulering van Google Search Central in Understand the JavaScript SEO basics. Het is ook het sterkste argument voor static site SEO: pre-rendering haalt een afhankelijkheid weg. Het creëert geen relevantie, autoriteit, nuttige teksten of een samenhangende architectuur (ik zou die vier overigens met plezier aan een build-command delegeren).

Statische bestanden kun je bovendien makkelijk cachen op CDN-randen. Als je rendering per request wegneemt, elimineer je één bron van latency en failure. Google’s Web Vitals-documentatie definieert “goed” als: LCP binnen 2,5 seconden, INP van 200 milliseconden of minder en CLS van 0,1 of minder. Die drempels worden beoordeeld op het 75e percentiel, apart voor mobiel- en desktopverkeer.

Vertaal dit niet naar “static sites halen Core Web Vitals automatisch”. Een hero-afbeelding van 3 MB, render-blocking fonts, third-party scripts en een grote hydration-bundle kunnen nog steeds LCP of INP slopen. Statische architectuur geeft je ruimte om goed te presteren. Het dwingt geen asset budget af.

Snelheid maakt ook geen relevante pagina beter in rang. Het is infrastructuur, geen vervanging voor vraag, content of links.

De view-source-test vangt de grootste Jamstack SEO-fout

Een static site kan nog steeds een JavaScript-app zijn in een statische shell.

Astro islands, React-widgets, client-gefetched productgrids, reviewcomponenten, comments en “load more”-lijsten kunnen pas worden gevuld na hydration. Als SEO-relevante content binnenkomt via een API-request aan de browserzijde, ontbreekt die in de eerste response. Dan zit je weer in JavaScript SEO-territorium, zelfs als je deployment HTML-bestanden bevat.

Google beschrijft het app-shell-probleem direct: “de initiële HTML bevat niet de daadwerkelijke content”, dus Google moet JavaScript uitvoeren voordat het de gegenereerde content kan zien. In de documentatie staat ook dat een pagina in de renderqueue kan blijven “enkele seconden, maar het kan langer duren dan dat”. Sommige bots kunnen JavaScript helemaal niet uitvoeren.

Open de uitgerolde URL en gebruik view-source. Vertrouw niet op het Elements-paneel in DevTools, want dat toont de DOM nadat scripts die hebben aangepast. Zoek in de bron naar de headline, een paar opvallend verschillende zinnen, belangrijke links, productdetails en afbeeldings-alt-attributen.

Ontbreken ze? Verplaats de data dan naar de build. Haal het op tijdens het genereren en render het in de uitgevoerde HTML: de artikeltekst, lijst, reviews of productinformatie. Houd browser-JavaScript voor interactie, niet voor de primaire content. Onze frameworkgids legt uit hoe je Next.js, React en Nuxt-content aan de juiste kant van deze grens houdt.

Ik heb deze test zien falen op pagina’s die in Chrome perfect af leken. De browser had de data snel genoeg opgehaald dat er tijdens het beoordelen niets “fout” leek, terwijl view-source nauwelijks meer bevatte dan een root-element en scriptverwijzingen. Een groen vinkje bij de deployment is geen indexing-test (en, jammer genoeg, is “works on my machine” dat ook niet).

Dit is het onderscheid dat ik het meest belangrijk vind bij de static sites die we bij SEOJuice inspecteren. Er gaat veel aandacht uit naar de frameworkkeuze, maar de crawler ontvangt een HTTP-response, niet jullie architectuur-intenties.

Het SEO-werk dat je generator bij je laat

Genereer en inspecteer de XML-sitemap

Sitemapgedrag verschilt per generator. Hugo genereert sitemap.xml standaard; de documentatie bevat zelfs een sectie over sitemapgeneratie uitschakelen, wat laat zien dat het aan staat tenzij je het uitzet.

Een minimale, valide sitemap heeft één url-blok per pagina:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-19</lastmod>
  </url>
</urlset>

Astro kiest een andere aanpak. In de sitemapdocumentatie staat dat @astrojs/sitemap de URL van de uitgerolde site nodig heeft voordat het een sitemap kan genereren. Zodra het is geconfigureerd, voegt de integratie sitemapindex- en sitemapbestanden toe aan de outputdirectory.

Voor andere generatoren: check de huidige documentatie en plugin-ecosystemen, in plaats van aan te nemen dat er een sitemap bestaat. De test is niet of een dependency in je packagebestand staat. De test is of de uitgerolde sitemap laadt, het juiste content-type teruggeeft en de production-URL’s bevat die je echt geïndexeerd wilt hebben.

Inspecteer daarna een voorbeeld. Let op staging-hosts, niet-canonieke slashvarianten, parameter-URL’s, ontbrekende secties en pagina’s die uitgesloten moeten worden. Een sitemap kan syntactisch correct zijn, maar dan het verkeerde “siteplaatje” beschrijven.

Astro verdient extra aandacht, omdat de geconfigureerde site-URL ook handig is om absolute URL’s te construeren. Onze Astro SEO-checklist gaat dieper in op sitemaps, canonicals en problemen per island.

Genereer canonicals op basis van de production-URL

Static-site generators bepalen doorgaans niet automatisch canonical-URL’s voor je. Je layout moet een canonical maken voor elke pagina die geïndexeerd kan worden, met de production base URL en het genormaliseerde pad van de pagina. Een staging-domein of localhost-waarde die in productie “gebakken” zit, stuurt zoekmachines naar de verkeerde versie.

Relatieve canonicals zijn nog een vermijdbare ambiguïteit. Bouw absolute URL’s en definieer vervolgens één policy voor trailing slashes, indexbestanden en URL-hoofdletters. Je canonical, interne links, sitemapentries en redirectregels moeten met elkaar overeenkomen.

We hebben SEOJuice in januari 2026 verplaatst van seojuice.io naar seojuice.com. De zichtbare navigatie was het makkelijke deel. Het echte migratieoppervlak bestond uit canonical tags, sitemapentries, interne links, structured-data URL’s, asset-referenties en redirects op hostniveau. Eén oude hostname die in een gedeelde template stond, kon vóórdat iemand het doorhad in elke gegenereerde pagina terechtkomen (een heerlijk efficiënte manier om een fout te schalen).

Ik vertrouw geen universele canonical-component die tussen frameworks wordt gekopieerd. Base paths, slashgedrag, URL-helpers en omgevingsvariabelen verschillen. Inspecteer de uiteindelijke HTML op de uiteindelijke URL. Templates zijn implementatiedetails; wat de crawler krijgt is de uitgerolde output.

Stop met het uitrollen van één titel voor de hele site

Paginatitles, meta descriptions, Open Graph-fields en social tags komen meestal uit front matter die wordt doorgegeven aan een gedeelde layout. Als die front matter ontbreekt of de fallback te breed is, kunnen honderden pagina’s één generieke titel erven.

Maak essentiële metadata expliciet in het contentmodel. Geef elke pagina die geïndexeerd kan worden een unieke, beschrijvende titel en een relevante description. Definieer fallback-logica voor voorspelbare gevallen, maar laat een site-wide merkstring niet stilletjes de titel van elke pagina worden.

Crawl daarna de gegenereerde site op duplicaten, lege waarden, fout gespelde tags en onverwacht lange waardes. Static generation maakt consistentie, inclusief consistente fouten.

Voeg structured data toe aan de echte pagina

Google Search Central definieert structured data als “een gestandaardiseerd formaat om informatie over een pagina te geven en de inhoud van de pagina te classificeren.” Google adviseert JSON-LD en zegt dat de markup op de pagina moet staan die het beschrijft.

Het object moet overeenkomen met de zichtbare content en alle vereiste properties bevatten om in aanmerking te komen voor enhanced presentation in Search. In aanmerking komen is geen garantie op een rich result. Schema verduidelijkt betekenis voor machines; het dwingt Google niet om een resultaat te decoreren.

Genereer structured data uit dezelfde bron als de zichtbare pagina, waar mogelijk. Productnamen, prijzen, datums en auteurinformatie dubbel opslaan in aparte handmatige velden zorgt voor drift. Valideer representatieve paginatypes na de deployment, niet alleen de JSON-LD-template los.

Schrijf de saaie basisfeatures goed uit

Je hebt nog steeds een correct robots.txt-bestand nodig, bruikbare alt-tekst voor afbeeldingen, consistente heading levels, beschrijvende anchors en interne links. Static generation voorkomt geen weespagina’s. Een URL kan in de outputdirectory staan en in de sitemap, terwijl hij toch losstaat van de paden die gebruikers en crawlers volgen.

Wat we zien bij sites die SEOJuice gebruiken: dit is vaak precies waar “schone” architectuur stopt met helpen. De site bouwt snel en serveert snel, maar gerelateerde pagina’s zijn niet gekoppeld, metadata-dekking is ongelijk en oude content ligt meerdere lagen van elke huidige pagina vandaan. Geen van die defecten vereist een migratie naar een ander framework. Het vraagt om onderhoud.

Saaie klusjes, vooral. Maar wel met impact.

Redirects horen bij host of CDN

Een puur statische deployment heeft geen server-side applicatierouter die voor elk request draait. Redirects horen daarom bij de hosting- of CDN-laag, niet in een client-side component.

Netlify’s documentatie zegt dat de redirect-engine de eerste matchende regel van boven naar beneden verwerkt en standaard 301 gebruikt. Volgorde doet ertoe. Een brede wildcard boven een specifieke migratieregel kan het verzoek als eerste “pakken”.

Vercel exposeert redirects, clean URLs en trailing-slashgedrag als projectconfiguratie. Cloudflare Pages ondersteunt ook een _redirects-bestand, maar de default is 302 in plaats van Netlify’s 301. Zet de status expliciet als je een permanente move bedoelt (ik moest dat verschil twee keer checken; identieke bestandsnamen nodigen uit tot de verkeerde aanname).

Houd de redirect map naast de source en test oude URL’s na de deployment. Cover pagina’s die zijn hernoemd, samengevoegde artikelen, domeinvarianten, protocolwijzigingen en je gekozen trailing-slashbeleid. Test de geretourneerde status en bestemming, inclusief redirectketens.

Een client-side router die een oude route ziet en de URL in de browser aanpast is niet hetzelfde. De originele response blijft een 200 of 404, en clients zonder JavaScript krijgen nooit de bedoelde redirect.

Dynamic features zijn prima buiten het primaire contentpad

Formulieren kunnen gebruikmaken van een host-feature, een third-party endpoint of een serverless function. De interactie bij het versturen is niet indexeerbare content, maar de pagina moet wel vooraf gerenderde copy bevatten die uitlegt wat het formulier doet.

Client-side search kan gebruikmaken van een lokale index of een gehoste API. Zoekresultaten zouden doorgaans niet het enige ontdekkingspad voor je content moeten worden. Elk belangrijk resultaat moet zijn eigen statische URL hebben én ten minste één crawlbare interne link buiten de zoekinterface om.

Comments en review-widgets vereisen extra aandacht. Als ze hydrateren nadat de pagina is geladen, kan hun content ontbreken in de oorspronkelijke HTML. Wanneer reviews inhoudelijk echt bijdragen aan een productpagina, render dan de relevante reviewcontent tijdens de build en genereer accurate structured data op basis van dezelfde bron.

Personalisatie, aanbevelingen en experimenten kunnen client-side blijven als de primaire pagina er niet afhankelijk van is. Mijn regel is bot: bepaal indexeerbare content tijdens de build; voeg optionele interactie in de browser toe.

Een releaseproces dat static SEO-defecten opvangt

1. Build met productionconfiguratie. Controleer dat de echte hostname en base path beschikbaar zijn voor templates.
2. Inspecteer raw HTML. Controleer titles, descriptions, canonicals, headings, links, alt-tekst, JSON-LD en de primaire content.
3. Open sitemap en robots.txt. Verifieer dat beide zijn uitgerold en intern consistent zijn.
4. Schakel JavaScript uit. Bevestig dat de hoofdinfo en navigatie beschikbaar blijven.
5. Test oude URL’s. Verifieer dat de host de bedoelde status en eindbestemming teruggeeft.
6. Meet representatieve pagina’s. Vergelijk ze met de LCP-, INP- en CLS-drempels in plaats van aan te nemen dat “static” automatisch snel is.
7. Crawl na de deployment. Zoek naar duplicaatmetadata, ontbrekende canonicals, weespagina’s, kapotte links en onverwachte statuscodes.

Draai dit proces voor paginatypen, niet alleen voor de homepage. Blogposts, productpagina’s, paginering, tag-archieven, documentatiepagina’s en landing pages gebruiken vaak andere layouts. Eén “gezonde” homepage zegt je bijna niets over duizend gegenereerde URL’s.

Bij migraties: bewaar de lijst met oude URL’s en test die automatisch na de release. We hebben tijdens de SEOJuice-domeinverplaatsing geleerd dat migratiechecks zowel moeten dekken wat gebruikers niet kunnen zien als wat ze wél kunnen. Canonicals en structured-data-identifiers zijn bij een visuele review relatief makkelijk te missen.

Waar SEOJuice past, en waar het niet past

SEOJuice voegt continu interne links, meta titles en descriptions, schema markup en afbeeldings-alt-tekst toe aan een live site. Je kunt het installeren via een JavaScript-snippet of via een WordPress/CMS-plugin, en er is een gratis plan beschikbaar zonder creditcard.

Er is een belangrijke grens voor static sites. Metadata, schema en links die via de snippet worden geïnjecteerd, hangen af van client-side rendering. Daardoor staan ze niet in de originele crawl-step HTML en zijn ze mogelijk niet beschikbaar voor niet-JavaScript bots. Houd primaire content, canonicals, essentiële titles en descriptions en kritieke JSON-LD in de gegenereerde HTML wanneer je controle hebt over de build. Gebruik de snippet voor incrementeel on-page werk dat soepel moet degraderen, niet als excuus om een lege shell uit te rollen.

SEOJuice vervangt ook niet je sitemap, CDN-redirects, build-architectuur of contentstrategie. Als je wilt zien welke onderdelen van de on-page laag ontbreken, begin dan met de gratis SEO-audit. Fix eerst de structurele issues in de build en automatiseer daarna de repetitieve laag waar die trade-off logisch is.

Veelgestelde vragen

Zijn static sites goed voor SEO?

Ja, als startpunt voor een architectuur. Pre-rendered HTML haalt de afhankelijkheid van JavaScript rendering weg voor content die in de bron aanwezig is, terwijl CDN-delivery het makkelijker maakt om sterke prestaties te halen. Je hebt nog steeds relevante content, metadata, canonicals, een sitemap, structured data, interne links en redirects nodig.

Hebben static sites een XML-sitemap nodig?

Ja. Hugo genereert sitemap.xml standaard, terwijl Astro zijn sitemap-integratie en een geconfigureerde site-URL vereist. Andere generatoren hebben mogelijk project-specifieke configuratie of een plugin nodig. Inspecteer de uitgerolde sitemap in plaats van ervan uit te gaan dat de build er correct één heeft gemaakt.

Is Jamstack goed voor SEO?

Jamstack kan dezelfde voordelen bieden als andere static architecturen: pre-rendered markup en CDN-delivery. Het risico ontstaat wanneer belangrijke content via browser-side APIs wordt opgehaald. Als het ontbreekt in de gegenereerde HTML, moet Google JavaScript renderen om het te zien, en andere bots kunnen het zelfs volledig missen.

Hoe zet ik redirects op een static site goed?

Configureer ze op host of CDN. Netlify ondersteunt _redirects en netlify.toml, Vercel gebruikt projectconfiguratie en Cloudflare Pages ondersteunt een _redirects-bestand. Geef permanente statuscodes bewust aan, houd regels in version control en test de HTTP-response na de deployment.

Indexeert Google JavaScript op static sites?

Google kan JavaScript renderen, maar dat gebeurt na het crawlen en kan worden uitgesteld. Google merkt ook op dat niet alle bots JavaScript kunnen draaien. Als primaire content pas verschijnt na hydration, render die dan in de gegenereerde HTML in plaats van afhankelijk te zijn van uitvoering in de browser.

Hebben static sites nog steeds meta tags en canonical tags nodig?

Ja. Static-site generators verzinnen niet betrouwbaar unieke titles, descriptions, Open Graph tags of canonical-URL’s voor elk project. Genereer ze vanuit paginadata, gebruik de production base URL voor absolute canonicals en inspecteer de uiteindelijke HTML op duplicaten of staging-waarden.