JavaScript-SEO: se till att länkarna överlever renderingen
Google renderar JavaScript med en evergreen Chromium. Problemet handlar sällan om själva renderingen. Det handlar om länkar som aldrig blir ankare och sidor som är beroende av ett tillstånd som en crawler inte har.
ArchiLinks forskningsgrupp ·
Vad en crawler ser
Googlebot har använt en evergreen Chromium sedan maj 2019. Det löste frågan om huruvida det kan köra modernt JavaScript.
De praktiska riskerna är de gamla bekanta: rendering sker efter crawlingen och kan försenas, innehåll bakom klick eller inloggningar visas aldrig, och en länk som byggs från en onclick-händelse på en div är ingen länk. Innan du kontrollerar baklänkar på webbplats-sidor som du natelytt flyttat till ett React-frontänd, bekräfta att dessa sidor visar sitt innehåll i det råa svaret eller i den renderade HTML-koden.
SSR, SSG, CSR: vad som ändras för länkar
| Tillvägagångssätt | Innehåll i första svaret | Internt länkar som ankare | Bra för |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Ja | Ja, om du använder riktiga ankare | Publika sidor med ändrande data |
| SSG eller förrendering | Ja | Ja | Dokumentation, bloggar, marknadsföringssidor |
| CSR single-page app | Nej, tom skal | Endast efter rendering | Dashboardar bakom inloggning |
| Hybrid (SSR startsida, CSR app) | Per rutt | Per rutt | De flesta produkter med en publik del |
Test ett: rå HTML jämfört med renderad HTML
Om de viktiga länkarna syns i första svaret är frågan avgjord. Om inte, jämför med en headless-rendering.
# 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 '
Var externa länkar kommer in
Ett renderingsfel döljer ditt innehåll. Det tar inte bort de länkar andra webbplatser redan gett dig.
Efter en flytt till Next.js, Vite eller en headless CMS, kör toppages för värden och testa de 20 mest länkade URL:erna för status, canonical och synligt innehåll. Gör det först. Om en sida med 40 länkande domäner returnerar en tom skal eller ett klient-sidigt 404, fixa det innan något annat, eftersom det är där din auktoritet landar. Sidan om intern vs extern länkekvitet visar hur du jämför den listan med dina interna länkar, och flyttchecklistan placerar testet i en lanseringsplan.
Ramverk betyder mindre än disciplin. Express med en mallmotor, ett WordPress-tema och en Next.js-approuter kan alla leverera grävbara länkar. Varje en kan också misslyckas om ett team levererar ankare som bara finns efter ett klick.
Länk- och renderingschecklista
- Navigering och paginering använder
<a href>, inte händelsehanterare på andra element. - Varje rutt returnerar en riktig statuskod. Mjuk 404-skärmar måste returnera 404.
- En
noindexeller canonical som injiceras av JavaScript matchar den i serversvaret. - Fallback-innehåll i första svaret är den riktiga sidan, inte en spinner som Google kan indexera.
- Autentiseringskod omdirigerar inte crawlers på publika rutter.
- CSS- och JS-filer som behövs för rendering är inte blockerade i robots.txt.
- Laddning vid behov använder IntersectionObserver eller inbyggda laddningsegenskaper, inte scroll-händelser.
Att läsa bevisen från Search Console
Search Console besvarar de flesta renderingsfrågor om du ställer rätt rapport. Använd URL-inspektion, sedan Visa gruvad sida.
Jämför tre saker: HTML:n Google hämtade, skärmbilden och de sidresurser som inte kunde laddas. En sida som ser komplett ut i din webbläsare men tom i skärmbilden är oftast blockerad av ett skriptfel eller en blockerad resurs, och lösningen finns i ditt bygg, inte i ditt innehåll.
Kom ihåg fördröjningen. En ändring du släpper idag syns i inspektionsverktyget först efter att Google har crawlat URL:en igen, vilket kan ta dagar.
När SSR är värt det
Publika sidor som måste rangordnas: ja. Dashboardar: nej.
Om en rutt ska dra organisk trafik, leverera innehållet i första svaret. Om den sitter bakom en inloggning, hoppa över komplexiteten. Välj per rutt och inte per projekt, och dokumentera beslutet så att nästa utvecklare inte ångrar det.
- Använd testet för rika resultat och URL-inspektion för att jämföra det renderade utfallet.
- Testa med live-testet i Search Console efter varje ramverksuppgradering.
Krävs serverrendering, eller räcker förrendering?
Serverrendering är valfritt. Det är ett sätt att få första svaret att bära det en crawler behöver. Många publika webbplatser kommer dit med förrendering, en statisk bygg eller en serverrendering för sidorna som betyder något, och lämnar de inloggade delarna ifred.
Säg att dina produktsidor och dokumentation är publika, medan dashboarden sitter bakom en inloggning. Förrendera den första gruppen. Låt dashboarden vara klient-sidig. De publika sidorna bär då sina länkar i första svaret, och dashboarden kan vara så komplex som den behöver vara.
Att förrendera endast startsidan
Att förrendera startsidan löser den första crawlingen, men det lämnar alla andra rutter att vänta på webbläsaren. Om startsidan länkar till klient-renderade kategorisidor, beror länkarna på dessa sidor fortfarande på rendering. Kontrollera varje mall du äger, inte bara dörrmattan.
Behåll en kort lista över publika rutter med deras renderingsmetod. Listan kommer att visa luckor snabbare än en crawlrappor.
Ändrar serverrendering lokal synlighet
Serverrendering kan ändra hur snabbt första innehållet visas, och läsare märker det. Det gör inte en sida relevant för en lokal fråga i sig själv. De signalerna kommer från sidinnehållet, företagsuppgifterna och länkarna som pekar mot den.
Behandla rendering som det sätt som dessa signaler blir läsbara för en crawler, och mät länkarna separat med API:t.
Vite- och React-appar som levererar en skal
En Vite-bygg som levererar en HTML-skal för varje sökväg lägger allt arbete på klienten. En sådan app kan fortfarande rangordnas för vissa frågor, men varje publik rutt behöver en plan: förrendera den, rendera den på servern, eller acceptera förlusten och skriv ner det.
Innan du kontrollerar baklänkar på webbplats-rutter efter en ombyggnad, bestäm hur varje publik rutt får sitt innehåll. Annars kommer länkdata att visa externa länkar som landar på sidor med ingenting i dem.
Att testa om en rutt visar sina länkar
Två tester besvarar de flesta frågor. Det råa svaret visar vad en crawler får innan något skript körs. Den renderade DOM:n visar vad en webbläsare bygger efteråt. En länk som bara syns i den andra är fortfarande en länk, men den beror på att renderingen går bra.
Att läsa live-testet i Search Console
Kör live-testet från URL-inspektion på en rutt i taget. Titta på den renderade HTML-koden, sedan på listan över resurser som inte kunde laddas. Ett blockerat skript kan ta bort hela navigeringsblocket, och sidan ser tunn ut utan att visa någon synlig felmeddelande.
Upprepa testet efter en ramverksuppgradering, eftersom en ny standard kan ändra huruvida länkar renderas innan eller efter ett skript körs. Guiden sidor som inte indexeras täcker vad du ska göra när en renderad sida fortfarande stannar borta.
När en rutt renderar men innehållet är en spinner
Fallback i första svaret betyder mer än de flesta team förväntar sig. En spinner eller en tom behållare betyder att sidan inte bär någon text för crawlen vid det tillfället. Lägg titeln, intro och de huvudsakliga länkarna i första svaret, även om en detaljerad lista laddas senare.
En fallback som är den riktiga sidan kan vara enkel. Dess enda uppgift är att hålla innehållet tills resten anländer.
Att flytta en klient-sidig webbplats utan att förlora dess länkar
Lista rutterna med externa länkar
Kör toppages för värden och notera de 50 främsta URL:erna. Testa dessa rutter först, innan kodändringarna, så att du vet vad ombyggnaden måste behålla.
Jämför rått och renderat utfall
För varje rutt, kontrollera den råa HTML-koden och den renderade DOM:n i den gamla och den nya byggn. Notera alla länkar som finns i ena men inte i den andra.
Ersätt händelsehanterare med ankare
Gör navigering till riktiga ankare med en korrekt adress. Hastighetsarbete kan vänta en sprint, medan en saknad kostar ruttens väg in i webbplatsen.
Upprepa testet efter lansering
En vecka efter lansering, kör live-testet på samma rutter och jämför resultaten med de tidigare. Skillnader visar var ombyggnaden ändrade utfallet.
Statuskoder och omdirigeringar i en klient-sidig app
En single-page-app visar ofta en inte-hittad-skärm medan servern returnerar status 200. Google kan behandla en sådan sida som en mjuk 404, och de externa länkarna som pekar mot den saknade URL:en gör då lite för dig. Fixen tillhör servern.
Okända rutter som fortfarande returnerar 200
Returnera en riktig 404 från servern för alla rutter som inte finns, och behåll appens inte-hittad-skärm för besökare som anländer via en klient-sidig rutt. Där en ersättning finns, skicka en 301 istället.
Kontrollera några uppfunna adresser på den live-värden efter varje lansering. Svars koden är det du ska läsa, inte sidan du ser i webbläsaren.
Omdirigeringar som körs i webbläsaren
En omdirigering som utlöses efter att sidan laddats, till exempel genom att läsa en URL-parameter inuti en komponent, är en annan sak än en serveromdirigering. En crawler kan indexera första svaret innan omdirigeringen körs. Där en rutt har flyttat för gott, returnera en 301 från servern och behåll parametrarna som ändrar innehåll. Omdirigeringskartans recept visar hur du testar dessa regler.
