SEO voor met AI gebouwde websites: wat er echt toe doet
Een met AI gebouwde website kan net zo goed scoren als elke andere: zoekmachines beoordelen wat de pagina bevat en hoe goed die de bezoeker helpt, niet welke tool de code heeft geschreven. De adder onder het gras is technisch. Veel AI-builders maken single-page apps die de browser een bijna lege HTML-file sturen en de inhoud met JavaScript tekenen, wat elke pagina moeilijker maakt om te lezen en te delen voor crawlers. Los dat op met prerendering of server-side rendering, geef elke pagina een eigen titel, beschrijving en URL, voeg een sitemap toe, houd de site snel, en doe dan het deel dat geen tool voor je doet — schrijf inhoud waar mensen naar zoeken.
Waarom single-page apps het in zoekmachines moeilijk kunnen hebben
Een traditionele website stuurt de volledige tekst van elke pagina in haar HTML. Een single-page app (SPA) — de standaarduitvoer van veel AI-builders, meestal React met een tool als Vite — stuurt een kleine HTML-schil, iets als een lege <div id="root">, plus een JavaScript-bundel. De browser voert het JavaScript uit, dat daarna de pagina opbouwt.
Dat is op drie manieren belangrijk voor zoekmachines:
- Renderen is een extra stap. Google beschrijft drie fasen voor JavaScript-pagina’s: de HTML crawlen, die renderen in een headless Chromium-browser en daarna het gerenderde resultaat indexeren. De eigen richtlijnen van Google zeggen dat server-side rendering of prerendering nog steeds een goed idee is, omdat het sneller is voor gebruikers en crawlers, en omdat niet alle bots JavaScript kunnen uitvoeren.
- Andere lezers van je pagina renderen helemaal niet. Linkvoorbeelden in chatapps en sociale netwerken, en veel andere crawlers, lezen meestal alleen de initiële HTML. Als je titel en voorbeeldafbeelding na het laden door JavaScript worden gezet, tonen die voorbeelden de standaardwaarden van de lege schil — vaak dezelfde titel op elke pagina.
- Alles deelt één HTML-file. Tenzij de app die bijwerkt, hebben alle URL’s dezelfde
<title>en beschrijving, wat zoekmachines weinig vertelt over elke pagina.
Niets hiervan betekent dat een SPA niet geïndexeerd kan worden. Het betekent dat je afhankelijk bent van de crawler die meer werk doet, en dat je de controle verliest over wat niet-renderende lezers zien.
Kies een renderingaanpak
Er zijn vier gangbare manieren om echte HTML bij crawlers te krijgen. Op volgorde van hoeveel ze je app veranderen:
| Aanpak | Hoe het werkt | Geschikt voor | Afweging |
|---|---|---|---|
| Statische site | Pagina’s zijn vooraf gebouwde platte HTML-files | Marketingsites, portfolio’s, documentatie, blogs | Minder geschikt voor pagina’s met login of gepersonaliseerde inhoud |
| Prerendering (statische sitegeneratie) | Bij de build wordt elke openbare route naar een HTML-file gerenderd; JavaScript neemt het in de browser over | SPA’s met een bekende set openbare pagina’s | Pagina’s worden alleen bijgewerkt als je opnieuw bouwt |
| Server-side rendering (SSR) | De server rendert HTML voor elk verzoek (Next.js, Remix, Nuxt en vergelijkbare) | Grote of vaak wijzigende openbare inhoud, bijv. advertenties | Heeft een draaiende server nodig; meer bewegende delen |
| Dynamische rendering | Geprerenderde HTML naar bots, de SPA naar mensen | Verouderde workaround | Google noemt het nu een workaround, geen langetermijnoplossing, en raadt SSR, statische rendering of hydratatie aan |
Een praktische vuistregel: het openbare, doorzoekbare deel van je site moet statisch of geprerenderd zijn; de ingelogde app erachter mag een gewone SPA blijven. Zoekmachines moeten dashboards toch al niet indexeren.
Als je vanaf nul begint en SEO belangrijk is, zeg dat dan in de eerste prompt zodat de AI een geschikte opzet kiest:
Bouw een marketingsite voor een fysiotherapiepraktijk met pagina’s voor Home, Diensten (één pagina per dienst), Over ons, Prijzen en Contact. SEO is belangrijk: elke pagina moet de volledige inhoud en een eigen titel en meta-beschrijving in de initiële HTML leveren — gebruik een statische of geprerenderde opzet, geen alleen-client single-page app.
Als je al een Vite-SPA hebt, vraag dan om prerendering van de openbare routes:
Houd deze React-app zoals hij is, maar prerender de openbare routes (/, /pricing, /about, /blog en elke /blog/:slug) naar statische HTML bij de build, elk met een eigen titel, meta-beschrijving, canonieke URL en Open Graph-tags. De ingelogde /app-routes mogen client-side gerenderd blijven.
Controleer daarna het resultaat zelf: open een pagina, kies Paginabron bekijken (niet het Elements-paneel van de devtools, dat de gerenderde pagina toont) en bevestig dat de tekst en titel in de ruwe HTML staan.
Regel de basis op de pagina goed
Dit geldt ongeacht de renderingaanpak.
Titels en meta-beschrijvingen
- Eén unieke
<title>per pagina, met het hoofdonderwerp van de pagina vooraan. Ongeveer 50–60 tekens is een gangbare richtlijn, omdat langere titels in de resultaten vaak worden afgekapt. - Eén unieke meta-beschrijving per pagina — een zin waarop een persoon wil klikken, geen zoekwoordenlijst. Google kan die herschrijven, maar een goede wordt vaak gebruikt.
- Sla meta-keywords over. Google zegt dat de tag geen effect heeft op indexering of ranking.
URL’s, koppen en links
- Echte URL’s voor echte pagina’s. Elk stuk inhoud heeft een eigen pad nodig (
/services/sportmassage), geen tab of modal die alleen bestaat na een klik. Vermijd#-fragmentroutering voor inhoud die je wilt laten indexeren. - Eén
h1per pagina, daarna een verstandigeh2/h3-opbouw. AI-gegenereerde ontwerpen gebruiken soms koppen voor de opmaak; vraag om semantische koppen. - Crawlbare links. Gebruik echte
<a href>-links voor navigatie. Knoppen die de pagina met JavaScript veranderen, zijn onzichtbaar voor crawlers die links volgen. - Canonieke tags die elke pagina naar haar voorkeurs-URL wijzen, zodat
?utm=-varianten en duplicaten met een slash aan het eind elkaar niet beconcurreren. - Beschrijvende alt-tekst bij betekenisvolle afbeeldingen.
Previews op sociale media
Voeg Open Graph-tags (og:title, og:description, og:image, og:url) toe aan elke openbare pagina, in de initiële HTML. Dit is het deel dat SPA’s het vaakst verkeerd doen, omdat bots voor linkvoorbeelden geen JavaScript uitvoeren.
Sitemaps en robots.txt
Een sitemap is een XML-file met de URL’s die je geïndexeerd wilt hebben. Hij helpt zoekmachines pagina’s te vinden, vooral op nieuwe sites met weinig inkomende links. Volgens de documentatie van Google, vanaf september 2026:
- Een enkele sitemap kan maximaal 50.000 URL’s of 50 MB ongecomprimeerd bevatten; splits grotere sites met een sitemapindex.
- Google negeert
<priority>en<changefreq>. - Google gebruikt
<lastmod>alleen als die consistent klopt, dus werk die bij voor echte inhoudswijzigingen, niet bij elke build.
Een robots.txt-file vertelt crawlers welke paden ze niet moeten crawlen. Gebruik die om crawlers uit /app, /admin en API-routes te houden, en verwijs er vanuit naar de sitemap. Onthoud dat robots.txt het crawlen stopt, niet het indexeren: om een pagina uit de resultaten te houden, gebruik je een noindex-robotsmeta-tag en laat je de pagina wel crawlen.
Dien de sitemap in via Google Search Console zodra de site op haar definitieve domein staat. Search Console toont ook welke pagina’s geïndexeerd zijn en waarom andere dat niet zijn — de nuttigste gratis SEO-tool die er is.
Gestructureerde data
Gestructureerde data is machine-leesbare markup die beschrijft wat een pagina is: een organisatie, een lokaal bedrijf, een product, een artikel, een evenement. Google raadt het JSON-LD-formaat aan en is duidelijk over twee punten:
- Het kan pagina’s in aanmerking laten komen voor rich results, maar garandeert ze niet.
- Het moet informatie beschrijven die zichtbaar is op de pagina. Markeer geen recensies, prijzen of FAQ’s die bezoekers niet zien.
Verstandige startpunten: Organization of LocalBusiness op de homepage, Product op productpagina’s, Article op blogposts, BreadcrumbList op diepere pagina’s. Test met de Rich Results Test van Google.
Voeg JSON-LD-gestructureerde data toe: LocalBusiness op de homepage met het adres, telefoonnummer en openingstijden die al op de pagina staan, en Article op elke blogpost. Voeg geen beoordelingen of recensies toe.
Snelheid en mobiel
Google gebruikt signalen van paginaervaring, waaronder Core Web Vitals, en snelheid is hoe dan ook belangrijk voor bezoekers. Googles “goed”-drempels, gemeten op het 75e percentiel van paginaladingen, zijn:
| Metriek | Meet | Goed |
|---|---|---|
| Largest Contentful Paint (LCP) | Hoe snel de hoofdinhoud verschijnt | 2,5 s of minder |
| Interaction to Next Paint (INP) | Hoe snel de pagina reageert op invoer | 200 ms of minder |
| Cumulative Layout Shift (CLS) | Hoeveel de lay-out verspringt tijdens het laden | 0,1 of minder |
De gebruikelijke oplossingen voor met AI gebouwde sites:
- Afbeeldingen — verklein ze, comprimeer ze, gebruik moderne formaten, stel breedte en hoogte in (dat voorkomt lay-outverschuiving) en lazy-load alles onder de vouw.
- JavaScript — een grote bundel vertraagt alles op een SPA. Prerendering helpt; het opsplitsen van code per route ook.
- Lettertypen — beperk het aantal families en gewichten en preload degene die boven de vouw wordt gebruikt.
- Scripts van derden — elk chatwidget en elke trackingpixel kost snelheid. Houd alleen die je echt gebruikt.
Test de live-URL met PageSpeed Insights of Lighthouse in de mobiele modus.
Inhoud is nog steeds het grootste deel
Technische SEO haalt obstakels weg; het creëert geen vraag. Pagina’s scoren omdat ze een zoekopdracht beter beantwoorden dan de alternatieven. Voor de meeste kleine sites betekent dat:
- Eén pagina per onderwerp waarnaar mensen zoeken. Een loodgieter heeft een pagina per dienst en per werkgebied nodig, niet één pagina “Diensten” met alles erop.
- Specifieke, originele details — prijzen, werkwijze, foto’s van echt werk, antwoorden op de vragen die klanten aan de telefoon stellen.
- Bijgewerkt als er iets verandert. Verouderde openingstijden en oude prijzen verliezen snel vertrouwen.
AI kan pagina’s snel concipiëren, wat de verleiding oproept om veel dunne, vergelijkbare pagina’s te publiceren. De richtlijnen van Google richten zich op inhoud die vooral is gemaakt om te ranken in plaats van om mensen te helpen, hoe die ook is gemaakt. Gebruik AI om een concept te maken en voeg daarna toe wat alleen jij weet. Directory-achtige sites krijgen hier het meest mee te maken; zie hoe je een directorywebsite bouwt om vermeldingspagina’s de moeite van het indexeren waard te maken.
Lanceringschecklist
- Openbare pagina’s leveren de volledige inhoud in de initiële HTML (controleer met Paginabron bekijken)
- Unieke titel, meta-beschrijving en canonieke URL op elke pagina
- Open Graph-tags en een deelafbeelding op elke openbare pagina
- Eén
h1per pagina, echte<a href>-links, alt-tekst bij afbeeldingen -
sitemap.xmlmet echte URL’s;robots.txtdie app- en API-paden blokkeert - Gestructureerde data alleen voor zichtbare inhoud, getest
- LCP, INP en CLS in het “goed”-bereik op mobiel
- Site op het definitieve domein met HTTPS en ingediend bij Search Console
Verhuizen naar je eigen domein voordat je zoekverkeer begint op te bouwen voorkomt later redirects — zie hoe je een eigen domein koppelt. Voor het bredere bouwproces lees je hoe je een website met AI bouwt, en voor pagina’s die bezoekers moeten omzetten, hoe je een landingspagina bouwt die converteert.
SEO op Mythex
Mythex heeft geen apart SEO-paneel; je verbetert SEO door de app via chat of code te veranderen. Nieuwe webapps zijn standaard een Vite- en React-single-page-app, dus als zoekmachines belangrijk zijn, vraag dan vanaf het begin om een statische of geprerenderde site, of om Next.js. De documentatie heeft een startprompt voor titels, Open Graph-tags, sitemap en robots.txt in SEO voor je app, en statische websites behandelt op inhoud gerichte sites. Publiceer na wijzigingen opnieuw, zodat de live site ze oppikt. Eigen domeinen zijn beschikbaar op Pro.
Veelgestelde vragen
Zijn met AI gebouwde websites slecht voor SEO?
Niet per definitie. Zoekmachines beoordelen de pagina, niet de tool die haar heeft geschreven. Het gangbare probleem is technisch: veel AI-builders maken single-page apps waarvan de inhoud pas verschijnt nadat JavaScript is uitgevoerd, wat sommige crawlers slecht verwerken. Prerendering of server-side rendering lost dat op.
Kan Google een React single-page app indexeren?
Google kan JavaScript renderen, dus het kan een client-side gerenderde React-app vaak wel indexeren. Maar renderen is een extra stap, en Google zelf merkt op dat niet alle bots JavaScript kunnen uitvoeren. Daarom raadt het server-side rendering of prerendering aan waar dat kan.
Doen meta-keywords er nog toe?
Nee. Google zegt dat het de meta-keywordtag niet gebruikt voor indexering of ranking. Steek je energie liever in een unieke titel en meta-beschrijving voor elke pagina.
Verbetert gestructureerde data de rankings?
Gestructureerde data helpt zoekmachines een pagina te begrijpen en kan haar in aanmerking laten komen voor rich results, maar garandeert die niet. Ze moet inhoud beschrijven die daadwerkelijk zichtbaar is op de pagina.