Astro SEO: Zo zorg je dat een Astro-site hoger scoort

TL;DR: Astro geeft je een sterke SEO-basis omdat het statische HTML vooraf rendert (prerenderen) en standaard client-side JavaScript verwijdert. Zet site in astro.config.mjs, houd indexeerbare content buiten client:only-componenten, en configureer unieke metadata, absolute canonicals, een sitemap en één consistent URL-formaat. Inspecteer daarna de gegenereerde HTML. Een nette componentstructuur bewijst niet dat de gepubliceerde pagina crawlbaar is.

Astro is goed voor SEO, maar het doet SEO niet voor je

Het sterkste onderdeel van Astro SEO is geen SEO-pakket. Het is het render-model van Astro.

“Standaard rendert Astro automatisch elk UI-component alleen als HTML & CSS, waarbij alle client-side JavaScript automatisch wordt weggelaten.”

Dat is Astro’s eigen beschrijving in de Islands architecture documentatie. Astro hydrateert alleen de componenten die expliciet zijn gemarkeerd om in de browser te draaien, en laat de rest van de pagina als statische HTML staan.

Het onderscheid is belangrijk omdat Google het downloaden van JavaScript en het uitvoeren ervan niet als dezelfde handeling beschouwt.

“Google verwerkt JavaScript-webapps in drie hoofd-fasen: 1. Crawling 2. Rendering 3. Indexing”

Google Search Central legt verder uit dat een headless Chromium de pagina rendert zodra Google’s resources dat toelaten. Google kan JavaScript renderen, maar content die pas na uitvoering ontstaat, hangt af van die extra fase. De standaardkeuze “statische HTML” van Astro verwijdert die afhankelijkheid, omdat de relevante content al in de response kan staan. Onze JavaScript SEO guide behandelt het mechanisme nog dieper.

Dat is een echt technisch voordeel. Het is geen automatisch rankingvoordeel. Statische HTML kan geen dunne pagina’s redden, geen dubbele titles, geen zwakke interne linkstructuur, geen onbedoelde canonicalisatie, of content waar niemand op zit te wachten.

Astro levert uitzonderlijk goede ‘plumbing’. Je moet het nog wel aansluiten.

Zet eerst de productiesite-URL

Voordat je een SEO-component toevoegt, configureer je site in astro.config.mjs:

Zet het één keer in je Astro-config zodat canonicals en de sitemap naar echte URL’s verwijzen:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://example.com',   // maakt canonical-URL’s en de sitemap mogelijk
  integrations: [sitemap()],
});

Astro’s Configuration Reference definieert site als de uiteindelijke, ingezette URL en zegt dat Astro die waarde gebruikt om sitemap- en canonical-URL’s te genereren. De default is undefined, en Astro raadt sterk aan om het in te stellen.

Met één regel stuur je meerdere systemen aan:

• Astro.site is undefined zonder die instelling.
• @astrojs/sitemap heeft het nodig om sitemap-URL’s te genereren.
• @astrojs/rss gebruikt het om artikel-links te maken.
• Canonical- en social-image-URL’s hebben het nodig voor een betrouwbare production origin.

We zagen de spiegelvariant van deze afhankelijkheid tijdens onze seojuice.io naar seojuice.com-migratie in januari 2026. Canonicals, sitemap-vermeldingen, Open Graph-URL’s en interne referenties moesten allemaal samenkomen op één production origin. Een migratie maakt het probleem meteen zichtbaar; een vergeten site-waarde verbergt dezelfde categorie fout in een build die verder wél succesvol lijkt.

Stel eerst de production-URL in, bouw, en inspecteer de output voordat je downstream-integraties gaat debuggen (één origin, meerdere symptomen).

Bouw één head-component, niet tientallen variaties

Astro levert geen speciale metadata-abstraction. Titles en descriptions zijn gewone HTML-tags. Voor de meeste sites is de onderhoudbare aanpak een gedeelde layout die via Astro.props paginawaarden-specifiek kan ontvangen.

De eerste en derde regel zijn Astro’s frontmatter-fences. Elke pagina of content-entry moet zijn eigen title en description aanleveren. Een fallback is handig om onvolledige data te vangen, maar laat een site-wide default niet stilletjes de metadata worden voor elke URL.

Ik geef er de voorkeur aan om vereiste metadata tijdens de build te valideren in plaats van weken later omissies in Search Console te ontdekken. Als een publieke contentpagina geen title of description heeft, is de build laten falen vaak het vriendelijkere gedrag.

Moet je het astro-seo-pakket gebruiken?

Het community astro-seo-pakket kan de gebruikelijke tags bundelen. Installeer het met npm install astro-seo, importeer SEO vanuit het pakket en render de component binnen de document head. In de repository staat ondersteuning voor titles, descriptions, canonicals, robots-directives, Open Graph, Twitter-cards, title templates, taal-alternates en custom tags.

Wees precies over wat het is: astro-seo is een third-party component die wordt onderhouden door jonasmerlin, geen officiële @astrojs-integratie. Ik zou het gebruiken wanneer de API relevante herhaling wegneemt. Voor een kleine marketingsite is een lokale head-component vaak makkelijker te auditen en minder makkelijk ‘over je heen te laten groeien’ (minder dependencies kunnen een feature zijn, geen esthetische voorkeur).

Houd social-metadata naast search-metadata

Open Graph en Twitter-cards zijn standaard meta tags. Genereer ze in dezelfde gedeelde head-component zodat de paginatitel, description, canonical URL en afbeelding niet onafhankelijk kunnen afwijken. Social images moeten absolute URL’s gebruiken op basis van Astro.site; relatieve paden zijn een veelvoorkomende reden waarom previews op de ene service werken en op de andere falen.

Genereer canonicals vanuit production origin en het huidige pad

Astro exposeert de twee waarden die je nodig hebt voor een canonical. Astro.site geeft een URL terug op basis van de geconfigureerde production site, terwijl Astro.url de huidige request-URL representeert.

De officiële API Reference geeft dit patroon:

Dit combineert het huidige pad met de production origin en voorkomt dat een development- of preview-hostname canonical wordt doordat die toevallig de request serveerde (preview-hosts moeten geen stem krijgen).

Let op dat het patroon Astro.url.pathname gebruikt, niet de volledige request-URL. Daardoor worden queryparameters weggelaten. Dat is meestal correct voor trackingparameters en gewone contentpagina’s, maar niet universeel. Pagination, gefilterde collections en echt verschillende pagina’s op basis van parameters hebben een expliciet canonical-beleid nodig.

Een canonical is geen generieke “SEO aangezet”-markering. Het is een verklaring over welke URL geldt als de gezaghebbende versie van een pagina. Inspecteer de uiteindelijke waarde.

Maak trailing slashes tot een bewuste keuze

Astro’s trailingSlash-optie heeft standaard ignore. De always- en never-instellingen forceren een vorm voor production on-demand routes, terwijl de default in development en bij on-demand rendering beide varianten accepteert.

Bij static output beïnvloeden ook gegenereerde bestanden en het gedrag van de host het resultaat. Kies één canonical-vorm, genereer interne links in die vorm en test hoe de ingezette host met beide varianten omgaat. Alleen de Astro-setting aanpassen garandeert niet dat elke static host de redirects toepast die je verwacht.

Het doel is overeenstemming: interne links, canonicals, sitemap-vermeldingen en redirects moeten allemaal naar dezelfde URL-vorm wijzen. Onze SEO for developers guide behandelt de bredere implementatiediscipline achter die keuze.

Installeer de officiële sitemap-integratie

Voer npx astro add sitemap uit om Astro’s officiële @astrojs/sitemap-integratie te installeren.

Volgens de officiële sitemapdocumentatie heeft de integratie de deployed site-URL nodig, beginnend met http:// of https://. Zonder site genereert het geen sitemap.

Na een build voegt Astro sitemap-index.xml en sitemap-0.xml toe aan de outputdirectory. De index verwijst naar de genummerde sitemapbestanden. De standaardlimiet is 45.000 entries per bestand; daarna worden er extra genummerde bestanden gemaakt (45.000 is een split-drempel, geen advies om pagina’s te gaan fabriceren).

Inspecteer na deployment meerdere entries. Controleer protocol, hostname, paden, slash-conventie en of er private of utility-pagina’s tussen zijn geslopen. Open ook de sitemap-index en volg de child-links. Ik heb technisch geldige sitemapbestanden zien deployen onder paden die niemand had getest.

Een sitemap helpt bij ontdekking; het dwingt geen indexing af. Voor de rest van dat proces: zie hoe Google indexing werkt.

De Astro island-valkuil gaat specifiek over client:only

Astro islands zijn niet inherent slecht voor SEO. Zeggen dat ze dat zijn, verwart selective hydration met client-only rendering.

Astro’s directives reference zegt dat client:only “HTML server-rendering overslaat en alleen op de client rendert.” Alles binnen dat component ontbreekt dan in de initiële server-rendered HTML en is afhankelijk van het uitvoeren van JavaScript.

Plaats geen artikelcopy, productbeschrijvingen, FAQ-antwoorden, primaire navigatie, interne links of andere indexeerbare content in client:only. Reserveer het voor interfaces die niet op de server kunnen renderen en waarvan de inhoud niet in de initiële response hoeft te verschijnen.

client:load, client:idle en client:visible zijn iets anders. Die server-renderen de initiële HTML en sturen vervolgens wanneer de hydratatie plaatsvindt. Het probleem zit niet in React, Vue, Svelte of islands zelf. Het probleem is het overslaan van server-rendering of het uitsluitend ophalen van essentiële copy in de browser.

Op basis van wat we zien bij sites die we met SEOJuice hebben gecontroleerd, is de onthullende faalfactor bij JavaScript-framework-bouwsels vaak niet een ontbrekende sitemap. Het is een pagina die er volledig uitziet in de browser, terwijl de betekenisvolle bodycopy ontbreekt in de ruwe HTML-response. Op Astro is één client:only-grens een voor de hand liggende eerste plek om te checken, al kan browser-only data fetching hetzelfde resultaat opleveren.

Ik heb deze fout gemaakt door alleen de gerenderde pagina te beoordelen. Concreter: ik beoordeelde wat de browser reconstrueerde, niet wat de server terugstuurde. Als je de response source bekijkt, was het onderzoek veel eerder klaar geweest. Het is dezelfde app-shell failure die we ook bespreken in onze SPA SEO best practices.

Gebruik static output, tenzij request-time rendering echt een probleem oplost

“Standaard wordt je hele Astro-site vooraf gerenderd en worden statische HTML-pagina’s naar de browser gestuurd.”

Dit komt uit Astro’s On-demand rendering guide. De default output: 'static' modus genereert pagina’s op build-tijd. Dat is de logische keuze voor documentatie, artikelen, landing pages en productcontent die niet afhankelijk is van request-specifieke data.

output: 'server' rendert pagina’s on demand en vereist een adapter voor de target runtime, zoals Node, Netlify, Vercel of Cloudflare. Server-side rendering kan volledige HTML teruggeven en is op zichzelf niet slechter voor SEO. Het voegt alleen runtime-infrastructuur, latency en een extra faalvlak toe. Gebruik het omdat de pagina het nodig heeft, niet omdat SSR klinkt alsof het ‘krachtiger’ is.

Je kunt beide gedragingen combineren. In static mode kun je prerender = false exporteren vanuit een pagina die on demand moet renderen. In server mode kun je prerender = true exporteren voor een pagina die vooraf gegenereerd moet worden.

Oudere tutorials kunnen output: 'hybrid' aanraden. Astro 5 heeft het oude hybrid-gedrag samengevouwen in 'static'; de Astro 5 upgrade guide beschrijft 'hybrid' en 'static' als samengevoegd tot één enkele static configuratie. Nieuwe projecten moeten static of server gebruiken met per-pagina prerender overrides.

Voeg RSS toe als de site terugkerende content publiceert

Astro biedt het officiële @astrojs/rss-pakket voor feeds die via API-endpoints worden gegenereerd. Installeer het met npm install @astrojs/rss en maak vervolgens een endpoint zoals src/pages/rss.xml.js dat de RSS-helper teruggeeft met site: context.site en de feed-items.

De Astro RSS-documentatie vereist dat er een site is geconfigureerd, omdat die origin wordt gebruikt om artikel-links te genereren. Nog een reden om site te behandelen als basisconfiguratie en niet als een sitemap-specifieke optie.

Inspecteer de ingezette site, niet alleen de broncomponenten

Astro-componenten kunnen er correct uitzien terwijl de deployed output fout is. Bouw en deploy, en verifieer daarna:

1. De ruwe HTML-response bevat de hoofdcontent en belangrijke links.
2. Elke indexeerbare pagina heeft een passende title en meta description.
3. De canonical is absoluut, gebruikt HTTPS, en wijst naar de production hostname.
4. Canonicals, interne links, redirects en sitemap-URL’s volgen allemaal dezelfde slash-conventie.
5. Open Graph- en Twitter-images gebruiken absolute production-URL’s.
6. sitemap-index.xml bestaat en verwijst naar bereikbare child-sitemaps.
7. Er bestaat geen indexeerbare content alleen binnen client:only-componenten.
8. Pagina’s die bedoeld zijn als static verschijnen in de gegenereerde build-output.
9. Preview- en staging-hosts publiceren zichzelf niet als canonical.
10. Redirects gedragen zich zoals verwacht op het echte hostingplatform.

Gebruik “view source”, haal de URL op zonder afhankelijk te zijn van browser-executie, en inspecteer de deployed bestanden. Het Elements-panel van DevTools toont de DOM na uitvoering—handig, maar het beantwoordt een andere vraag (ik betrap mezelf er nog steeds op dat ik eerst naar de verkeerde kijk).

Astro regelt de rendering-basis goed. Het terugkerende werk is het onderhouden van metadata, interne links, schema en paginaconsistentie terwijl je site groeit. SEOJuice kan op Astro draaien via een JavaScript-snippet en continu fixes toepassen op de site, zoals interne links, meta titles en descriptions, schema-markup en alt-teksten van afbeeldingen. De gratis SEO-audit is daarnaast een manier zonder signup om meegestuurde metadata en canonicals te inspecteren.

Het is geen vervanging voor het instellen van site, het genereren van een sitemap of het behouden van indexeerbare content in de initiële HTML. Automatisering hoort bovenop een correcte build te staan.

Veelgestelde vragen

Is Astro goed voor SEO?

Ja. Astro prerendert statische HTML en verwijdert standaard client-side JavaScript, waardoor content aanwezig kan zijn in de initiële response in plaats van afhankelijk te zijn van Google’s vertraagde JavaScript-renderfase. Ranking blijft echter afhangen van nuttige content, metadata, interne linking, canonicals en andere implementatiekeuzes.

Hoe voeg ik meta titles en descriptions toe in Astro?

Voeg standaard title- en meta-description-tags toe aan een gedeelde layout, en geef vervolgens unieke waarden door via Astro.props voor elke pagina. Het community astro-seo-pakket is een alternatief, maar het is geen officiële Astro-integratie.

Hoe voeg ik een sitemap toe aan een Astro-site?

Voer npx astro add sitemap uit en zet site op de ingezette URL in astro.config.mjs. Bij een build worden dan sitemap-index.xml en sitemap-0.xml gegenereerd. Zonder site-configuratie kan de integratie de sitemap niet maken.

Hoe zet ik canonical URL’s in Astro?

Gebruik het door Astro gedocumenteerde patroon: maak een URL met new URL(Astro.url.pathname, Astro.site), en geef die waarde vervolgens door in een canonical-link-tag. Zet site eerst, omdat Astro.site anders undefined is.

Wat is het verschil tussen static en SSR output in Astro?

output: 'static' is de default en prerendert pagina’s naar HTML op build-tijd. output: 'server' rendert on demand en vereist een adapter. Je kunt het gedrag per pagina mixen met prerender = false in static mode of prerender = true in server mode.

Waarom werkt mijn Astro sitemap of canonical URL niet?

Check als eerste site. Het is standaard undefined, terwijl sitemapgeneratie, Astro.site, canonical-opbouw, RSS-artikel-links en veel absolute social-URL’s ervan afhankelijk zijn. Zet het op de uiteindelijke HTTPS-origin, rebuild en inspecteer de gegenereerde output.