Lovable basics · 6 min leestijd
Next.js SEO check: ziet Google je content, tags en links echt?
Next.js rendert soms anders voor bots dan voor bezoekers. Zo controleer je metadata, canonical en robots voordat je live gaat.
“Google haat JavaScript.” Je hoort het in elke vibe-coder Discord, en het is grotendeels onzin. Google rendert JavaScript prima. Het echte probleem zit bijna altijd ergens anders: jouw site levert de content, de meta-tags of de links pas áf nadat de browser werk heeft gedaan dat Google soms niet of pas later doet. Een goede Next.js SEO-check draait dus niet om “JS aan of uit”, maar om één simpele vraag: ziet Google jouw content, tags en links écht zoals een bezoeker ze ziet?
In dit artikel loop ik de concrete checklist langs waarmee je dat verifieert. No-nonsense, geen bijgeloof. Aan het eind weet je precies waar je Next.js SEO lekt — en hoe je het dichttimmert.
Het echte Next.js SEO-probleem: client-only rendering
De klassieke valkuil bij Next.js SEO is content die uitsluitend client-side rendert. Je bouwt een mooie pagina, maar de hoofdtekst, de titel of de productdata laden pas in de browser via een fetch of een client component. Voor een mens die de pagina opent maakt dat niets uit. Voor Google maakt het alles uit: de eerste HTML die de crawler binnenkrijgt is leeg, en of en wanneer de gerenderde versie wordt opgepikt, is onbetrouwbaar.
Met de App Router heb je server components als standaard — gebruik dat. Zorg dat je hoofdcontent server-rendered is, zodat hij al in de initiële HTML zit. Bewaar "use client" voor interactiviteit (knoppen, formulieren, state), niet voor de inhoud die moet ranken. Dat ene principe lost de meeste Next.js SEO-problemen op nog voordat je aan tags begint.
De Next.js SEO-checklist
Loop deze punten één voor één af. Elk punt is een plek waar Next.js SEO in de praktijk misgaat.
1. App Router metadata correct ingesteld
Gebruik de Metadata API: exporteer een metadata-object (of generateMetadata voor dynamische pagina’s) per route. Daarmee staan je title en description gewoon in de server-HTML. Zet ze nooit via een client-side effect — dan komen ze te laat. Per unieke pagina een unieke, beschrijvende title en description.
2. Eén canonical per pagina
Geef elke pagina een expliciete canonical via alternates.canonical in je metadata. Let op trailing slashes, hoofdletters en query-parameters: laat de canonical altijd naar de schone, definitieve URL wijzen. Eén canonical per pagina, niet meer.
3. Robots-instellingen die kloppen met je bedoeling
Controleer dat je niet per ongeluk een noindex meegeeft aan pagina’s die je juist wilt laten ranken — een veelgemaakte fout bij geërfde layouts of een te brede robots-config. En andersom: pagina’s die níét in de index horen (filters, interne zoekpagina’s) krijgen wél een noindex. Twijfel je over wanneer je noindex of canonical inzet? Lees dan het verschil tussen noindex en canonical.
4. Server-rendered hoofdcontent
Dit is de kern. View source van je pagina (Ctrl/Cmd+U) of een fetch zonder JavaScript moet je belangrijkste tekst, koppen en data al bevatten. Is de body grotendeels leeg met een <div id="root"> en verder niets? Dan rendert je content client-only en heb je een Next.js SEO-probleem dat je moet oplossen.
5. Interne links als echte <a href>
Google volgt links die in de HTML staan als <a href="...">. Een onClick-handler die via JavaScript navigeert is voor de crawler geen link. Gebruik daarom de Next.js <Link>-component (die rendert een echte anchor) en vermijd navigatie die alleen op een klik-event draait. Zonder echte links krijg je geen interne linkstructuur en geen doorgegeven autoriteit.
6. GTM zonder SEO-bijgeloof
Google Tag Manager is voor tracking, niet voor SEO. Injecteer geen content, canonicals of meta-tags via GTM in de hoop dat het “helpt” — dat laadt te laat en is fragiel. Houd je SEO-essentials in de server-HTML en laat GTM doen waarvoor het bedoeld is.
7. Render-check: vertrouwen is goed, verifiëren is beter
Aannames zijn de vijand van Next.js SEO. Verifieer altijd wat Google daadwerkelijk ziet:
- URL-inspectie in Search Console → klik op “Live URL testen” → bekijk de gerenderde HTML. Staat je content erin? Staan je tags erin?
- Rich Results Test → toont ook de gerenderde HTML en valideert meteen je structured data.
- View source vs. gerenderde DOM → vergelijk de rauwe HTML met wat je in de browser ziet. Het verschil is precies wat client-side wordt bijgeladen — en dus risico loopt.
Veelgemaakte Next.js SEO-fouten op een rij
| Fout | Gevolg | Oplossing |
|---|---|---|
| Content in client component | Lege initiële HTML | Server component voor hoofdcontent |
| Title via useEffect | Tag komt te laat | Metadata API gebruiken |
| Navigatie via onClick | Geen crawlbare links | <Link> met echte href |
| Geen canonical | Dubbele-URL-verwarring | alternates.canonical per pagina |
| Per ongeluk noindex | Pagina valt uit index | Robots-config controleren |
| SEO-tags via GTM | Onbetrouwbaar, traag | In server-HTML zetten |
Hoe je dit structureel borgt
Een Next.js SEO-check is geen eenmalige actie. Elke nieuwe route, elke refactor van server naar client component, elke layout-wijziging kan stilletjes iets breken. Bouw daarom een vaste gewoonte: na elke deploy minstens je belangrijkste templates door de live URL-inspectie halen en je view source controleren. Het kost vijf minuten en het scheelt weken aan onverklaarbaar achterblijvende rankings.
Merk je dat je rankings niet kloppen en wil je zekerheid? Een grondige technische audit kijkt verder dan deze checklist: render-gedrag, indexeerbaarheid, interne linkstructuur en structured data in samenhang. Vraag een technische SEO-audit aan en je weet exact waar jouw Next.js SEO lekt — zonder gokken, zonder bijgeloof.
Is Next.js goed voor SEO, en beter dan React?
Ja op beide, maar niet automatisch. React op zichzelf levert een lege HTML-pagina die pas in de browser gevuld wordt. Next.js kan diezelfde React-code op de server uitvoeren en de HTML volledig ingevuld terugsturen. Dat verschil is het hele SEO-verhaal.
De valkuil: Next.js dwingt dat niet af. Zet je een component op client-rendering, dan krijg je precies dezelfde lege pagina als bij kale React, alleen met een duurder framework eromheen. Next.js geeft je de mogelijkheid, niet de garantie.
| Opzet | Wat Google krijgt |
|---|---|
| React zonder server-rendering | een lege div; inhoud pas na JavaScript |
| Next.js met server-rendering | volledige HTML bij het eerste antwoord |
| Next.js met client-componenten op de belangrijke inhoud | weer een lege div, ondanks Next.js |
Is Next.js nog relevant?
Ja, en de vraag komt vooral door de opkomst van alternatieven zoals TanStack Start, Astro en Remix. Die doen hetzelfde probleem op hun eigen manier. Voor SEO maakt de keuze weinig uit zolang je server-rendering aanstaat; het verschil zit in ontwikkelgemak, niet in wat Google ziet.
Voor wie met Lovable bouwt is dit relevant omdat Lovable sinds mei 2026 op TanStack Start draait, met server-rendering als standaard. Wat dat betekent staat in Lovable en TanStack Start.
Zo controleer je het in twee minuten
Geen tools nodig, alleen je terminal of je browser.
- Haal de pagina op zonder JavaScript. In de browser: rechtermuisknop, paginabron bekijken. Dat is de HTML zoals Google hem krijgt, niet wat de inspector toont.
- Zoek naar een zin die midden op je pagina staat. Vind je hem niet in de bron, dan ziet Google hem ook niet.
- Controleer of je title en meta description er staan, en of ze per pagina verschillen.
- Doe hetzelfde voor je canonical-tag.
Staat de inhoud er niet, dan is dat je enige probleem en hoef je verder nergens naar te kijken. De routes om het op te lossen staan in prerenderen: gratis of betaald.
