JavaScript-SEO: zorg dat links het renderen overleven
Google render JavaScript met een evergreen Chromium. Het probleem is zelden het renderen zelf. Het gaat om links die nooit tot anchors worden, en pagina’s die afhankelijk zijn van state die een crawler niet heeft.
ArchiLinks onderzoeksteam ·
Wat een crawler ziet
Googlebot gebruikt sinds mei 2019 een evergreen Chromium. Dat heeft de vraag of het moderne JavaScript kan uitvoeren, definitief beantwoord.
De praktische risico’s zijn ouderwets: rendering gebeurt na het crawlen en kan vertraagd zijn, content achter klikken of inloggen verschijnt nooit, en een link die uit een onclick-handler op een div komt, is geen link. Voordat u backlinks controleert op website-pagina’s die u recentelijk naar een React-frontend hebt verplaatst, bevestig dan dat die pagina’s hun content tonen in de ruwe response of in de gerenderde HTML.
SSR, SSG, CSR: wat verandert er voor links
| Benadering | Content in eerste response | Interne links als anchors | Geschikt voor |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Ja | Ja, als u echte anchors gebruikt | Publieke pagina’s met wisselende data |
| SSG of prerenderen | Ja | Ja | Docs, blogs, marketingpagina’s |
| CSR single-page app | Nee, lege shell | Pas na rendering | Dashboards achter een login |
| Hybride (SSR home, CSR app) | Per route | Per route | De meeste producten met een publieke kant |
Test één: ruwe HTML versus gerenderde HTML
Als de belangrijkste links in de eerste response verschijnen, is de vraag besloten. Zo niet, vergelijk dan met een headless render.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
Waar externe links binnenkomen
Een rendering-bug verbergt uw content. Hij verwijdert niet de links die andere sites u al hebben gegeven.
Na een verhuizing naar Next.js, Vite of een headless CMS, voer toppages uit voor de host en test de 20 meest gelinkte URL’s op status, canonical en zichtbare content. Doe dit eerst. Als een pagina met 40 linking domains een lege shell of een client-side 404 retourneert, los het dan eerst op, want daar komt uw authority terecht. De interne versus externe equity-pagina laat zien hoe u die lijst vergelijkt met uw interne links, en de migratiechecklist plaatst de test binnen een lanceringplan.
Frameworks zijn minder belangrijk dan discipline. Express met een template engine, een WordPress-thema en een Next.js app router kunnen allemaal crawlbare links serveren. Elk kan ook falen als een team anchors levert die pas bestaan na een klik.
Link- en renderingchecklist
- Navigatie en paginering gebruiken
<a href>, geen click-handlers op andere elementen. - Elke route retourneert een echte statuscode. Soft 404-schermen moeten 404 retourneren.
- Een
noindexof canonical ingevoerd door JavaScript komt overeen met die in de serverresponse. - Fallback-content in de eerste response is de echte pagina, geen spinner die Google kan indexeren.
- Auth-code leidt geen crawlers om op publieke routes.
- CSS- en JS-bestanden die nodig zijn voor rendering zijn niet geblokkeerd in robots.txt.
- Lazy loading gebruikt IntersectionObserver of native loading-attributen, geen scroll-events.
Het Search Console-bewijs lezen
Search Console beantwoordt de meeste renderingvragen als u het juiste rapport vraagt. Gebruik URL Inspection, dan View crawled page.
Vergelijk drie dingen: de HTML die Google heeft opgehaald, de screenshot en de page resources die niet zijn geladen. Een pagina die in uw browser compleet lijkt, maar leeg in de screenshot, is meestal geblokkeerd door een scriptfout of een verboden resource, en de oplossing zit in uw build, niet in uw content.
Houd rekening met de vertraging. Een wijziging die u vandaag deployt, verschijnt in de inspection tool pas nadat Google de URL opnieuw heeft gecrawld, wat enkele dagen kan duren.
Wanneer SSR de moeite waard is
Publieke pagina’s die moeten ranken: ja. Dashboards: nee.
Als een route organisch verkeer moet genereren, serveer dan de content in de eerste response. Als deze achter een login zit, sla de complexiteit over. Kies per route en niet per project, en documenteer de beslissing zodat de volgende ontwikkelaar deze niet ongedaan maakt.
- Gebruik de Rich Results test en URL Inspection om de gerenderde output te vergelijken.
- Test met de live test van Search Console na elke framework-upgrade.
Is server rendering vereist, of is prerenderen genoeg?
Server rendering is optioneel. Het is een manier om de eerste response te laten bevatten wat een crawler nodig heeft. Veel publieke sites bereiken dit met prerenderen, een statische build of een server render voor de pagina’s die ertoe doen, en laten de ingelogde delen met rust.
Stel dat uw productpagina’s en docs publiek zijn, terwijl het dashboard achter een login zit. Prerender de eerste groep. Laat het dashboard client-side. De publieke pagina’s dragen dan hun links in de eerste response, en het dashboard kan zo complex zijn als het nodig is.
Alleen de home page prerenderen
Het prerenderen van de home page lost de eerste crawl op, maar laat elke andere route wachten op de browser. Als de home page linkt naar client-gerenderde categoriepagina’s, zijn de links op die pagina’s nog steeds afhankelijk van rendering. Controleer elke template die u beheert, niet alleen de voordeur.
Houd een korte lijst bij van publieke routes met hun rendermethode. De lijst laat sneller gaten zien dan een crawlrapport.
Verandert server rendering de lokale zichtbaarheid
Server rendering kan veranderen hoe snel de eerste content verschijnt, en lezers merken dat. Het maakt een pagina niet automatisch relevant voor een lokale query. Die signalen komen van de paginacontent, de bedrijfsgegevens en de links die er naartoe wijzen.
Behandel rendering als de manier waarop die signalen leesbaar worden voor een crawler, en meet de links apart met de API.
Vite- en React-apps die één shell serveren
Een Vite-build die één HTML-shell voor elk pad serveert, verplaatst alle werk naar de client. Zo’n app kan nog steeds ranken voor sommige queries, maar elke publieke route heeft een plan nodig: prerender het, render het op de server, of accepteer het verlies en schrijf het op.
Voordat u backlinks controleert op website-routes na een rebuild, besluit hoe elke publieke route zijn content krijgt. Anders toont de linkdata externe links die op pagina’s zonder inhoud landen.
Testen of een route zijn links toont
Twee tests beantwoorden de meeste vragen. De ruwe response toont wat een crawler krijgt voordat een script draait. Het gerenderde DOM toont wat een browser daarna bouwt. Een link die alleen in de tweede verschijnt, is nog steeds een link, maar hij is afhankelijk van goed gaande rendering.
De live test in Search Console lezen
Voer de live test uit vanuit URL Inspection op één route tegelijk. Kijk naar de gerenderde HTML, en daarna naar de lijst met resources die niet zijn geladen. Een geblokkeerd script kan een hele navigatieblok verwijderen, en de pagina lijkt dun zonder een zichtbare fout te tonen.
Herhaal de test na een framework-upgrade, omdat een nieuwe default kan veranderen of links renderen voordat of nadat een script draait. De gids pages not indexed behandelt wat u moet doen als een gerenderde pagina toch buiten blijft.
Wanneer een route renderen maar de content een spinner is
De fallback in de eerste response is belangrijker dan de meeste teams verwachten. Een spinner of een lege container betekent dat de pagina op dat moment geen tekst draagt voor de crawler. Zet de titel, de intro en de belangrijkste links in de eerste response, ook als een gedetailleerde lijst later laadt.
Een fallback die de echte pagina is, kan eenvoudig blijven. Zijn enige taak is de content vasthouden tot de rest aankomt.
Een client-side site verplaatsen zonder zijn links te verliezen
Lijst de routes met externe links
Voer toppages uit voor de host en noteer de top 50 URL’s. Test die routes eerst, voordat de code verandert, zodat u weet wat de rebuild moet behouden.
Vergelijk ruwe en gerenderde output
Controleer voor elke route de ruwe HTML en het gerenderde DOM in de oude en de nieuwe build. Noteer elke link die in de ene wel en in de andere niet bestaat.
Vervang click-handlers door anchors
Maak navigatie tot echte anchors met een correct adres. Snelheidswerk kan een sprint wachten, terwijl een ontbrekende anchor de route zijn weg in de site kost.
Herhaal de test na release
Een week na de release, voer de live test uit op dezelfde routes en vergelijk de resultaten met de eerdere. Verschillen tonen waar de rebuild de output heeft veranderd.
Statuscodes en redirects in een client-side app
Een single-page app toont vaak een not-found-scherm terwijl de server status 200 retourneert. Google kan zo’n pagina behandelen als een soft 404, en de externe links die naar de ontbrekende URL wijzen, doen dan weinig voor u. De oplossing zit op de server.
Onbekende routes die nog steeds 200 retourneren
Retourneer een echte 404 van de server voor elke route die niet bestaat, en houd de in-app not-found-scherm aan voor bezoekers die via een client-side route aankomen. Waar een vervanging bestaat, stuur dan een 301.
Controleer een paar verzonnen adressen op de live host na elke release. De response code is wat u moet lezen, niet de pagina die u in de browser ziet.
Redirects die in de browser draaien
Een redirect die afvuurt nadat de pagina is geladen, bijvoorbeeld door een URL-parameter te lezen binnen een component, is iets anders dan een serverredirect. Een crawler kan de eerste response indexeren voordat de redirect draait. Waar een route voor goed is verplaatst, retourneer dan een 301 van de server en houd de parameters die content veranderen. De redirect map recipe laat zien hoe u die regels test.
