Google kan kjøre JavaScript og se innhold som bygges i nettleseren. Spørsmålet er ikke om det går, men hva det koster i tid, pålitelighet og forsinkelse. Der ligger hele problemstillingen i JavaScript SEO.
Dette er en artikkel for deg som ikke bygger nettsteder selv, men som trenger å forstå nok til å stille de riktige spørsmålene når noe ikke blir indeksert.
Hvorfor det er en utfordring
En vanlig nettside leveres som ferdig HTML. Googlebot henter filen, leser innholdet og er ferdig. En JavaScript-drevet side leverer i praksis et tomt skall pluss instruksjoner om hva som skal hentes og bygges opp.
Google håndterer dette i to omganger. Først hentes og leses HTML-en. Deretter legges siden i en kø for rendering, der koden kjøres og det endelige innholdet blir synlig for indeksering.
Køen er poenget. Rendering krever langt mer ressurser enn å lese en tekstfil, og Google gjør det for milliarder av sider. Konsekvensen er at innhold som krever rendering kan bli indeksert senere enn resten, og at feil underveis fører til at innholdet aldri blir sett.
Hva som typisk går galt
- Innhold som først hentes ved brukerhandling. Tekst som lastes når noen trykker på en knapp eller ruller nedover finnes ikke for en crawler, som verken trykker eller ruller.
- Lenker som ikke er lenker. Navigasjon bygget på klikk-hendelser i stedet for vanlige
<a href>-elementer kan ikke følges. Googlebot leter etter href, ikke etter oppførsel. - Blokkerte ressurser. Er JavaScript-filene utestengt i robots.txt, kan siden ikke bygges opp. Da ser Google skallet.
- Metadata satt av skript. Titler og canonical som skrives inn av JavaScript virker ofte, men ikke alltid. De bør ligge i den opprinnelige HTML-en.
- Feil som stopper alt. En enkelt kodefeil kan hindre at resten av siden bygges. I nettleseren din merker du det kanskje ikke, fordi den har andre versjoner av filene i mellomlageret.
Slik sjekker du hva Google ser
Ikke gjett. Det finnes tre metoder som gir svar, og de er alle gratis:
- URL-inspeksjon i Search Console. Velg live-test og se på den rendrede HTML-en. Søk etter en setning du vet skal stå på siden. Finner du den ikke, er det den viktigste informasjonen du får den dagen.
- Slå av JavaScript i nettleseren. Last siden på nytt. Det du ser igjen er omtrent det Google har i første omgang.
- Se på kildekoden, ikke på inspektøren. «Vis kilde» viser HTML-en slik den kom fra serveren. Utviklerverktøyets elementfane viser siden etter at all kode har kjørt. De to er ofte helt ulike, og det er den første som er utgangspunktet.
Denne siste forskjellen er verdt å merke seg. Mange konkluderer med at alt er i orden fordi de ser innholdet i utviklerverktøyet. Det de ser er sluttresultatet, ikke råvarene.
Løsningene, fra enklest til mest omfattende
Ha det viktigste i HTML-en fra start. Hovedtekst, overskrifter, interne lenker, canonical og metadata bør ikke være avhengig av at kode kjører. Alt annet kan gjerne bygges i nettleseren.
Server-side rendering. Serveren bygger den ferdige HTML-en før den sendes. Crawleren får da samme opplevelse som med en vanlig side, og brukeren ser innhold raskere. Dette er standardvalget i moderne rammeverk av en grunn.
Statisk generering. Sidene bygges på forhånd og serveres som ferdige filer. Raskest og mest forutsigbart, og godt egnet for innhold som ikke endrer seg hvert minutt.
Dynamisk rendering. Ulikt innhold til crawlere og brukere. Dette ble tidligere anbefalt som en midlertidig løsning, men Google beskriver det nå som en nødløsning. Det er komplisert å vedlikeholde og ligger ubehagelig nær cloaking. Jeg ville unngått det.
Når dette angår deg, og når det ikke gjør det
Et vanlig WordPress-nettsted med et ordinært tema leverer ferdig HTML fra serveren. Da er dette i praksis ikke ditt problem, og du trenger ikke bekymre deg for det.
Det blir relevant når:
- nettstedet er bygget som en enkeltsideapplikasjon i React, Vue eller lignende
- du bruker WordPress som headless CMS med en egen frontend
- produktlister, filtre eller anmeldelser hentes inn etter at siden har lastet
- innhold ligger i tredjeparts widgeter, for eksempel booking eller anmeldelser
Det siste tilfellet er verdt en advarsel. Anmeldelser som lastes fra en ekstern tjeneste finnes ofte ikke i HTML-en din. Legger du da inn strukturert data om vurderinger, beskriver du innhold som ikke er synlig for Google. Det bryter med retningslinjene, se strukturert data og schema.org.
Spørsmålet du bør stille
Når en side ikke blir indeksert og nettstedet er JavaScript-basert, still dette til utvikleren: finnes hovedinnholdet i HTML-en som serveren returnerer, eller bygges det i nettleseren?
Svaret avgjør alt videre. Er svaret «i nettleseren», har du funnet en sannsynlig årsak. Er svaret «i HTML-en», er problemet et annet sted, og du kan lete videre i crawlability og indeksering i stedet for å bruke tid på rendering.