Der er en status i Google Search Console, som mange hjemmesideejere har stiftet bekendtskab med: Gennemgået – ikke indekseret i øjeblikket. På engelsk: Crawled – currently not indexed.
Google har altså gennemgået en URL, men har ikke valgt at medtage den i søgeindekset. Og så kommer forklaringerne: Indholdet er for tyndt, der mangler backlinks, siden har for få ord, eller Google skal bare have lidt mere tid.
Efter mange års arbejde med teknisk SEO synes jeg, man skal være varsom med den slags hurtige diagnoser. Statusmeddelelsen fortæller os resultatet, men ikke den præcise årsag.
Crawling, rendering og indeksering er tre forskellige ting
Google skal først opdage og hente en URL. Hvis siden anvender JavaScript, kan Google efterfølgende rendere indholdet. Til sidst vurderer Google, om URL’en skal indekseres. Ingen af disse trin er en garanti for det næste.
En side kan returnere HTTP 200, være med i et XML-sitemap og have et korrekt canonical-tag uden at blive indekseret. Google er ikke forpligtet til at optage enhver URL, systemet finder.
Et konkret eksempel fra en webshop
Jeg har for nylig undersøgt en ny webshop med problemer med indekseringen. Domæneopsætning og viderestillinger var blevet rettet, og et crawlerværktøj kunne efterfølgende finde undersider, som tidligere ikke blev opdaget.
Google Search Consoles live-test returnerede HTTP 200 og rapporterede ingen JavaScript-konsolfejl. Alligevel manglede en hel sektion med varekort i Googles visuelle skærmbillede. Header, footer og brødtekst var der – men ikke produktkortene.
Det ville være nærliggende at konkludere, at Googlebot aldrig havde hentet produkterne. Men da jeg undersøgte den renderede HTML fra samme live-test, fandt jeg færdige produktnavne, priser og almindelige produktlinks.
Webshoppen anvendte AngularJS til dele af produktvisningen med attributter som data-ng-show og data-ng-hide. Forskellen mellem HTML og skærmbillede kunne derfor hænge sammen med visningsstyring, CSS eller tidspunktet for skærmbilledet. Den konkrete årsag var ikke fastslået.
Da tegnsættet blev udpeget som synderen
Under undersøgelsen viste serveren Content-Type: text/html; charset=ISO-8859-1. En AI-analyse udpegede straks dette som årsagen til både JavaScript- og indekseringsproblemerne.
Men kontrol af den hentede HTML viste, at dokumentet kunne læses som ASCII, at danske specialtegn i vid udstrækning var skrevet som HTML-entiteter, og at skabelonen angav windows-1252. I HTML-behandling fortolkes ISO-8859-1 normalt som Windows-1252. Samtidig viste Googles renderede HTML, at produktdataene faktisk var indsat.
Der var altså ikke belæg for at hævde, at tegnkodningen havde forhindret Google i at læse produkterne. Det er et godt eksempel på forskellen mellem en teknisk hypotese og en dokumenteret fejl.
Praktisk SEO-fejlfinding med cURL på Mac og Windows
Man behøver ikke begynde med et dyrt SEO-værktøj. Med Terminal på Mac eller PowerShell/Windows Terminal på en Windows-PC kan man undersøge serverens svar og den oprindelige HTML. Brug dit eget domæne i stedet for www.eksempel.dk.
1. Kontroller HTTP-status og serverheadere
Mac Terminal:
curl -sI https://www.eksempel.dk/Windows PowerShell:
curl.exe -sI https://www.eksempel.dk/Et eksempel på et svar er:
HTTP/2 200
content-type: text/html; charset=UTF-8HTTP 200 fortæller, at serveren har returneret et vellykket svar. Det er ikke dokumentation for indeksering. Bemærk, at -I sender en HEAD-anmodning; enkelte servere kan svare anderledes på HEAD end på GET.
2. Undersøg viderestillinger
Mac:
curl -sIL https://www.eksempel.dk/gammel-side/Windows:
curl.exe -sIL https://www.eksempel.dk/gammel-side/-L følger viderestillingerne. Se efter, om en gammel underside lander på den tilsvarende nye underside – og ikke blot på forsiden.
3. Gem den oprindelige HTML
Mac:
curl -sL https://www.eksempel.dk/ -o seo-test.html
wc -c seo-test.html
head -c 500 seo-test.htmlWindows PowerShell:
curl.exe -sL https://www.eksempel.dk/ -o seo-test.html
(Get-Item .\seo-test.html).Length
(Get-Content .\seo-test.html -Raw).Substring(0, [Math]::Min(500, (Get-Content .\seo-test.html -Raw).Length))Du får en lokal kopi af den HTML, serveren sender. cURL udfører ikke JavaScript, så dokumentet er ikke nødvendigvis det samme som browserens færdige visning.
4. Find produktnavne, links og canonical
Mac:
grep -in 'Produktnavn' seo-test.html
grep -oiE 'href="[^"]+"' seo-test.html | head -30
grep -in 'canonical' seo-test.htmlWindows PowerShell:
Select-String -Path .\seo-test.html -Pattern 'Produktnavn'
Select-String -Path .\seo-test.html -Pattern 'href="[^"]+"' -AllMatches | Select-Object -First 30
Select-String -Path .\seo-test.html -Pattern 'canonical'Det er enkle tekstsøgninger, ikke fuldstændige HTML-parsere. Hvis produktnavne mangler i den oprindelige HTML, kan de stadig blive indsat via JavaScript.
5. Kontroller tegnkodningen – uden at ændre noget
Mac:
file -I seo-test.html
iconv -f UTF-8 -t UTF-8 seo-test.html >/dev/null && echo 'Gyldig UTF-8' || echo 'Ikke gyldig UTF-8'Windows PowerShell: Undersøg først dokumentets deklaration og serverens Content-Type. En streng validering af UTF-8-bytes kan eksempelvis foretages med:
$bytes = [System.IO.File]::ReadAllBytes((Resolve-Path .\seo-test.html))
$utf8 = [System.Text.UTF8Encoding]::new($false, $true)
try { $null = $utf8.GetString($bytes); 'Gyldig UTF-8' }
catch [System.Text.DecoderFallbackException] { 'Ikke gyldig UTF-8' }En fil med ren ASCII er også gyldig UTF-8. Testen beviser derfor ikke alene, hvilket tegnsæt dokumentet er tiltænkt. HTML-entiteter som ø, æ og å kan desuden forklare, hvorfor et dansk dokument fremstår som ASCII.
6. Sammenlign med Googles renderede HTML
Åbn URL-inspektion i Google Search Console, gennemfør en live-test, og undersøg den renderede HTML. Søg efter de samme produktnavne og links som i din lokale HTML-fil. Sammenlign også med Googles skærmbillede.
Hvis HTML indeholder produkterne, men skærmbilledet ikke viser dem, er det en anden problemstilling, end hvis produktdataene mangler i begge dele. Og live-testen fortæller ikke nødvendigvis, hvad Google så ved en tidligere crawling.
cURL kan ikke afgøre, om Google har indekseret siden. Til det skal vi bruge Search Console og eventuelt supplerende crawl- og loganalyse.
Indhold, interne links og Googles prioritering
Teknisk tilgængelighed er kun en del af billedet. Hvis flere URL’er har næsten samme indhold, hvis canonical-signalerne peger i forskellige retninger, eller hvis en side næsten ikke har relevante interne links, bør det undersøges.
Et XML-sitemap er nyttigt, men erstatter ikke en meningsfuld intern linkstruktur. Google kan også vælge ikke at indeksere en teknisk velfungerende side. Derfor giver det ikke mening at stemple enhver ikke-indekseret URL som dårligt indhold.
Hvad kan serverloggen fortælle?
Serverlogs kan dokumentere, hvornår Googlebot har anmodet om en URL, og hvilke HTTP-svar serveren returnerede. De kan ikke alene fortælle, om JavaScript blev udført korrekt, eller hvorfor Google valgte ikke at indeksere siden. Logdata bør sammenholdes med Search Console og den tekniske analyse.
Skal alle URL’er indekseres?
Nej. Filtre, dubletter og tekniske URL-varianter har ikke nødvendigvis selvstændig værdi i søgeresultaterne. Målet er ikke flest mulige indekserede sider, men at de væsentlige sider bliver fundet, forstået og indekseret.
Konklusion: Undersøg først – ret bagefter
Når Search Console viser Gennemgået – ikke indekseret i øjeblikket, er det fristende straks at ændre indhold, links eller scripts. Men uden en dokumenteret årsag risikerer man at rette det forkerte.
Begynd med det, der kan efterprøves: HTTP-svar, viderestillinger, oprindelig og renderet HTML, canonical, interne links og eventuelle serverlogs. Først derefter bør man beslutte, hvad der skal ændres.
Jeg har samlet den mere systematiske fremgangsmåde på Google indekserer ikke din hjemmeside – teknisk fejlfinding. Se også mine sider om teknisk SEO og Google Search Console.