Din side ser færdig ud. Du åbnede den og læste den. Crawleren modtog noget helt andet — en menu, en footer og en indlæsningsanimation dér hvor dit indhold skulle stå.

Det her er den dyreste usynlige fejl vi ser, og den er helt og holdent et produkt af måden moderne websites bygges på. Et framework sender et næsten tomt HTML-dokument med et JavaScript-bundle. Browseren kører bundlet, kalder et API, modtager produktteksterne eller artiklen og skriver dem ind i siden. Når et menneske kigger, står alting der.

Om en crawler ser det samme, afhænger af om den også udførte alt det arbejde. Nogle gør. Mange gør ikke.

Hvorfor ser min side rigtig ud i browseren, men ikke for crawlere?

Fordi din browser kører JavaScriptet, og det gør crawleren måske ikke. Når du åbner siden, henter din browser skallen, kører scripts, henter data og samler den færdige side — og den færdige side er den eneste version, du nogensinde ser. Crawleren tager måske kun det første skridt. Forskellen kan ikke ses indefra, og derfor overlever den i årevis.

Den overlever også en gennemgang. Udvikleren tjekker siden, og den virker. Marketing tjekker siden, og den virker. Bureauet demonstrerer den på et møde, og den virker. Ingen i den kæde kigger nogensinde på det dokument serveren rent faktisk sendte, for der er ingen dagligdags grund til det.

Kan Google læse indhold der er lavet med JavaScript?

Google kan rendere JavaScript, men gør det i en anden omgang end den første crawl, og den omgang har sine egne begrænsninger. Indhold der kræver JavaScript, bliver derfor indekseret senere end serverrenderet indhold — og somme tider slet ikke, når renderingen fejler, timer ud eller afhænger af en forespørgsel crawleren ikke sender. Tekst der står i den HTML serveren sender, bliver indekseret ved første besøg, hver gang.

"Somme tider slet ikke" bærer meget i den sætning. Rendering fejler af helt almindelige grunde: et script blokeret af et samtykkebanner crawleren aldrig klikkede væk, et API-kald der kræver en session, et timeout på en langsom tredjepart, et bundle der kaster en fejl i et lidt andet miljø. Hver fejl er tavs. Siden bliver stående i indekset med det tynde indhold der nu overlevede.

Kører AI-crawlere JavaScript?

Som regel ikke, eller ikke pålideligt. Mange retrieval-crawlere læser HTML’en som den kommer fra serveren og kører ikke en fuld browser. En side hvis hovedindhold indsættes efter load, kan derfor være perfekt indekseret i Google og fuldstændig tom for den assistent der var ved at citere den. Det er en af de hyppigste grunde til at en velplaceret side aldrig optræder i AI-svar.

Den kombination — rangerer fint, bliver aldrig citeret — er værd at kunne genkende, for den ligner et indholdsproblem og er det ikke. Siden er relevant, siden er troværdig, siden bliver fundet. Den ankommer bare som en tom skal. Ingen omskrivning retter det; løsningen ligger i hvordan siden leveres. Den hører sammen med de øvrige AI-synlighedsfejl i sådan bliver du citeret i AI-svar.

Hvordan tjekker jeg hvad en crawler faktisk ser på min side?

Brug "vis kildekode" i stedet for inspektøren — kildekoden viser hvad serveren sendte, mens inspektøren viser det samlede resultat — og søg efter en sætning, du ved står i dit hovedindhold. Mangler sætningen, ser crawlere der ikke kører JavaScript, den heller ikke. TrustCtrl automatiserer sammenligningen: den henter både server-HTML og den renderede side ved hver crawl og markerer de sider hvor hovedindholdet kun findes i den renderede version.

At gøre det i hånden er en god måde at overbevise sig selv om, at problemet er virkeligt. At gøre det løbende er den eneste måde at holde det rettet, for det her falder let tilbage: en komponent bliver lavet om fra server- til klientrendering, et cache-lag ændres, et samtykkebanner begynder at holde et script tilbage, som før kørte frit. Ingen af de ændringer ligner SEO-arbejde, og ingen af dem bliver gennemgået som sådan.

Hvad du gør ved det

Retningen er altid den samme — få den vigtige tekst ind i den HTML serveren sender — men vejen derhen afhænger af opsætningen:

  • Server-side rendering eller statisk generering. Frameworket renderer siden på serveren og sender færdig HTML. Alle moderne frameworks understøtter det; spørgsmålet er om det blev slået til.
  • Prerendering til crawlere. En mellemvej hvor en render-tjeneste serverer færdig HTML til bots. Det virker, men kræver omtanke: at servere crawlere noget væsentligt andet end besøgende er præcis dér, utilsigtet cloaking begynder.
  • Flyt den kritiske tekst ud af klient-bundlet. Ofte det pragmatiske svar. Produkttekster, priser, overskrifter og brødtekst i HTML’en; de interaktive dele — filtre, karruseller, konfiguratorer — overladt til JavaScript.
  • Tjek halen, ikke kun forsiden. For- og landingssider er som regel serverrenderede, fordi nogen gik op i dem. Produkt-, kategori- og artikelsider er dér det gemmer sig, og det er dem der bærer den lange hale af trafik.

Den beslægtede fælde: sider der siger de er i orden, når de ikke er

Mens du alligevel kigger på hvad serveren returnerer, er der en fejl mere værd at tjekke, for den har samme form. En soft 404 er en side der ikke længere findes, men som svarer 200 OK med en "ikke fundet"-besked i stedet for en 404-status. For en besøgende er det en blindgyde. For en søgemaskine er det en rigtig side med tyndt indhold, så den bliver stående i indekset og bliver ved med at blive hentet.

Vi fandt den på vores eget website, mens vi testede TrustCtrl mod det — sammen med en 403 der blev rapporteret som et brudt link, selvom siden virkede bag adgangskontrol, og en afkortet liste der blev forvekslet med et samlet antal. Alle tre var kun synlige med ægte data på et ægte website, hvilket er et udmærket argument for at scanne sit eget site med det værktøj man sælger.

TrustCtrl besøger dine sider i en rigtig browser, op til den sidegrænse der er sat for sitet, sammenligner serverens svar med det renderede resultat og rapporterer de sider hvor dit indhold kun findes i den ene af dem. Hvert fund kommer med det præcise bevis — URL’en, svaret, hvad der manglede — i en enkel visning til ejeren og en teknisk visning til den der retter. Det kører sammen med sitemap-tjekket, titler og beskrivelser, hastighed og tilgængelighed, så én crawl besvarer hele spørgsmålet.