Google Cache: ven eller fjende?

Kapitel 5 – SEO’s glemte historie (1999–2010)

Google Cache var et af de værktøjer, de fleste almindelige brugere næsten ikke lagde mærke til. For os, der arbejdede med teknisk SEO, var det derimod guld værd. Det viste ikke bare, hvordan en side så ud, men hvad Google faktisk havde læst og gemt. Det gjorde cachen til både en ven og en fjende.

Da Google viste sit hjemmearbejde

Jeg savner stadig den synlige Google Cache.

Ikke fordi alt var bedre i gamle dage, men fordi Google dengang gav os adgang til noget, som ingen af nutidens SEO-værktøjer kan vise med samme sikkerhed: den version af en hjemmeside, som Google havde gemt i sin egen database.

Når Google havde besøgt en side, kunne man fra søgeresultatet åbne den cachede udgave. Her kunne man se den HTML-kode, Google havde registreret, og gennemgå den næsten linje for linje. Man kunne kontrollere tekster, links, overskrifter, metadata, navigation og forskellige områder af siden.

Det var ikke blot et skærmbillede af hjemmesiden. Det var et indblik i Googles egen behandling af dokumentet.

Når et website ikke blev indekseret korrekt, kunne jeg med meget stor sikkerhed finde årsagen ved at sammenligne den almindelige side med Googles cachede version. Cachen viste, hvad Google havde læst, hvad Google havde overset, og hvor fortolkningen af siden eventuelt var gået galt.

Den hurtigste fejlsøgning, jeg kendte

Når en kunde ringede og fortalte, at en hjemmeside ikke blev fundet ordentligt i Google, var cachen ofte det første sted, jeg kiggede.

På få minutter kunne jeg se, om hele dokumentet var blevet gemt, eller om Google var stoppet undervejs. Jeg kunne undersøge, om scripts var lukket korrekt, om der manglede afsluttende HTML-tags, om interne links kunne læses, og om vigtige dele af indholdet var forsvundet.

En enkelt manglende afslutning på et script kunne få resten af dokumentet til at blive fortolket forkert. Det samme kunne ske med en forkert lukket tabel, en fejlplaceret div eller en kodeblok, som browseren rettede pænt for brugeren, men som Googles parser behandlede anderledes.

Tegntabeller og tegnkodning var et andet tilbagevendende problem. Hvis serveren oplyste én tegnkodning, mens dokumentet reelt var gemt i en anden, kunne danske bogstaver og andre specialtegn blive ødelagt. Nogle gange var fejlen kun kosmetisk. Andre gange påvirkede den både tekst, links og den måde, resten af dokumentet blev forstået på.

Google Cache kunne også afsløre, om titler, beskrivelser og overskrifter var blevet registreret som forventet, eller om en teknisk fejl havde flyttet eller fjernet dem.

Det afgørende var forskellen på at hente siden selv og at se den version, Google havde gemt. Et almindeligt SEO-værktøj analyserer den HTML, værktøjet selv modtager. Google Cache viste den HTML, Google selv havde læst og valgt at gemme.

Det er en væsentlig forskel.

Når én lille fejl kunne koste store dele af indekseringen

Det behøvede ikke at være en stor eller dramatisk programmeringsfejl. Tværtimod var det ofte de små detaljer, der gjorde forskellen.

En manglende </script> kunne betyde, at Google opfattede resten af dokumentet som en del af scriptet. En forkert afsluttet HTML-struktur kunne få links, brødtekst eller hele sektioner til at forsvinde fra den version, Google gemte.

Browserne var ofte mere tilgivende. De forsøgte at reparere fejlene og vise brugeren en nogenlunde pæn side. Derfor kunne udvikleren eller kunden kigge på hjemmesiden og mene, at alt fungerede.

Google Cache viste noget andet.

Når den cachede version stoppede midt på siden, manglede vigtige links eller viste ødelagte tegn, vidste jeg, at problemet skulle findes i kildekoden, serverens headers eller den måde, CMS-systemet byggede dokumentet på.

Det var en praktisk arbejdsmetode, som gang på gang fandt fejl, automatiske systemer overså.

Da værktøjet ikke kunne det hele

I en periode arbejdede jeg tæt sammen med SEO-folkene hos Green Click og var jævnligt på kontoret i Aalborg, selv om jeg havde base i Helsingør. Samtidig fortsatte jeg mit arbejde i Online Marketing. De forskellige kunder og opgaver blev holdt klart adskilt, og det fungerede uden problemer.

Green Click arbejdede dengang med Searchmetrics, som var et af de store og anerkendte SEO-systemer. Platformen havde også uddannelsesforløb med betegnelser som Yellow Belt og Green Belt.

Jeg brugte ikke selv tid på certificeringerne. De medarbejdere, der havde lyst til det, kunne naturligvis tage dem. Jeg havde nok at gøre med den praktiske del – og havde i øvrigt allerede et sort bælte i Kyokushin, som var lidt mere hårdtslående.

Ved en af mine ture til Aalborg var to af Searchmetrics’ konsulenter kommet for at tale om udviklingen af systemet, nye funktioner og mulighederne for at finde tekniske fejl.

Under gennemgangen kom vi ind på et website med et konkret indekseringsproblem. Systemet pegede på en bestemt fejl og præsenterede den som forklaringen.

Jeg sagde nej.

Efter min vurdering lå fejlen et andet sted. Det kunne de ikke umiddelbart forstå, fordi deres værktøj viste noget andet. Men Google Cache viste, hvordan Google rent faktisk havde behandlet dokumentet, og det pegede i en anden retning.

Da sagen blev undersøgt nærmere, måtte de erkende, at værktøjet ikke havde fanget den reelle årsag.

Det var ikke en kritik af Searchmetrics. Det var et af de bedste systemer på markedet, og gode værktøjer kan spare mange timers arbejde. Men intet værktøj kan alt.

En fagmand skal kunne se ud over rapporten. Værktøjet ser siden gennem sine egne regler. Google Cache viste den version, Google selv havde gemt. Derfor begyndte jeg ikke nødvendigvis med den længste rapport. Jeg begyndte ofte med cachen.

JavaScript og læsbar HTML

Google havde dengang store problemer med JavaScript-baserede websites. Det har Google i forskellig grad stadig, især når indhold, links eller navigation først bliver tilgængelige efter kompliceret afvikling i browseren.

Når et website byggede indholdet med JavaScript, kunne brugeren se en flot og velfungerende side, mens Googles almindelige crawler kun fandt en tom skal eller meget lidt tekst.

Derfor fandtes der løsninger, hvor det samme indhold blev leveret som læsbar HTML til søgemaskinen. Den afgørende betingelse var, at teksten og indholdet skulle være identisk med det, brugeren fik vist. Formålet var ikke at præsentere én historie for Google og en anden for brugeren, men at gøre det samme indhold teknisk læsbart.

Google Cache var et fremragende kontrolværktøj til den slags løsninger. Her kunne jeg se, om den HTML-baserede udgave faktisk var kommet med, om links kunne følges, og om Google havde gemt den tekst, brugeren også kunne se på den JavaScript-baserede side.

Det var på den måde muligt at skelne mellem en legitim teknisk løsning og egentlig cloaking. Forskellen lå ikke kun i teknikken, men i om indholdet var det samme.

Da Google Cache blev cloakernes værste fjende

Det samme værktøj, som var en ven i den tekniske fejlsøgning, var en potentiel fjende i cloaking-perioden.

Google Cache viste jo netop de sider, der blev gemt i Googles indeks. En konkurrent kunne åbne den cachede version og sammenligne den med den side, en almindelig besøgende fik vist. Resultatet var ikke altid kønt, men det kunne være meget effektivt i søgeresultaterne.

Det betød også, at forskellene kunne afsløres.

Mange, der arbejdede med cloaking – også de mere primitive løsninger, der ofte blev kaldt poor man’s cloaking – anvendte noarchive, så Google ikke viste den cachede udgave offentligt.

Andre forsøgte at gøre den cachede version mere spiselig. Jeg kendte blandt andet et anerkendt belgisk firma med to dygtige udviklere, som jeg gennem årene udvekslede software med. De anvendte på et tidspunkt JavaScript, som omdirigerede brugeren, når den cachede version blev åbnet. Andre lagde den oprindelige side ind i en iframe, så det synlige resultat lignede det normale website.

Problemet var, at mange af disse metoder efterlod spor.

Et noarchive-tag kunne i sig selv få en teknisk interesseret konkurrent til at spørge, hvorfor cachen var skjult. Bestemte scripts, redirects og ensartede kodebidder kunne blive til fingeraftryk, som gjorde det muligt at finde andre websites med samme løsning.

Min tilgang: ingen synlige fingeraftryk

Min egen tilgang var, at jeg ikke ville sætte et tydeligt skilt op, som fortalte, at der var noget at lede efter.

Derfor ønskede jeg ikke at bruge noarchive. Google måtte gerne gemme siden, og muligheden for at åbne cachen skulle være der. Det skulle bare ikke være muligt at se, hvad der lå under den præsentation, der blev vist.

Jeg byggede derfor en løsning med flere lag. Et hvidt lag lå oven på den underliggende side, så man kun så hvidt, selv hvis man forsøgte at stoppe indlæsningen på forskellige tidspunkter. Oven på dette kunne en iframe vise en mere almindelig og præsentabel version af hjemmesiden.

Det gjorde, at den cachede udgave fremstod som en normal side. Forsøgte man de metoder, der blev diskuteret i SEO-fora dengang, kunne man stadig ikke umiddelbart se det indhold, som lå nedenunder.

Jeg beskriver det her som en del af historien, ikke som en metode, der skal genbruges. Teknikken hører en anden tid til, og den blev senere lukket ned. Men den viser, hvor stor betydning Google Cache havde. Når en offentlig cache kunne afsløre forskellen mellem to versioner, blev det nødvendigt at forholde sig til den.

Da eksperterne fandt den forkerte udvikler

På et tidspunkt fulgte jeg en diskussion i et dansk SEO-forum. En af ejerne bag et kendt dansk cloaking-system havde fundet et af mine websites og mente, at han havde afsløret, hvem der stod bag.

Der var mange af mine sites, så det var ikke mærkeligt, at et af dem blev fundet og diskuteret.

Efter en længere debat præsenterede han navnet på den person eller virksomhed, som efter hans mening havde udviklet løsningen.

Det var CMS-leverandøren fra Odense.

Navnet stod ganske enkelt i footeren på hjemmesiden.

Jeg går ud fra, at mange i forummet klikkede sig ind og kom med det ene gode råd efter det andet. Selv sad jeg og fulgte diskussionen med et smil.

Hvis et miljø med erfarne SEO-folk endte med at udpege CMS-leverandøren fra sidens footer, var jeg rimelig sikker på, at de ikke havde fundet den egentlige løsning.

Mange år senere mødte jeg personen ved en SEO-reception og nævnte historien. Der kom ikke den helt store reaktion. Men for mig havde episoden dengang været en vigtig bekræftelse på, at systemet ikke kunne gennemskues uden en særlig adgang eller en meget målrettet teknisk undersøgelse.

Belgien, Sverige og et CGI-program

Kontakten til de belgiske udviklere fortsatte gennem en årrække. De havde deres egen cloaking-platform og ville gerne have en variant til et af deres CGI-programmer.

Jeg udviklede derfor et separat CGI-modul til dem, og vi udvekslede løbende software og erfaringer.

Mange år senere var det belgiske firma lukket, og jeg vidste ikke, hvad der var blevet af platformen. Pludselig ringede en svensker til mig. Han fortalte, at han havde købt hele systemet og opdateret det, men at han ikke kunne gennemskue mit CGI-modul.

Han spurgte, om jeg ville hjælpe med at sætte det op for virksomheden. Det gjorde jeg.

Som tak sendte han mig en komplet version af deres cloaking-engine. Jeg testede den for sjov og af teknisk nysgerrighed, men jeg tog den aldrig i brug.

Efter min vurdering havde den stadig nogle fingeraftryk i form af bestemte søgemønstre, som kunne bruges til at finde systemets sider. Det kunne sandsynligvis være rettet forholdsvis hurtigt, og jeg havde tidligere gjort udviklerne opmærksomme på problemet.

Jeg ved ikke, hvorfor de små detaljer aldrig blev ændret. Men netop de små detaljer kunne få stor betydning, når en løsning skulle holde sig under radaren.

Hvad gjorde noarchive?

Noarchive var en instruktion til søgemaskinen om ikke at vise en offentligt tilgængelig cachekopi af siden.

Google kunne fortsat crawle og indeksere dokumentet. Tagget var ikke i sig selv en instruktion om at fjerne siden fra søgeresultaterne. Det fjernede først og fremmest brugerens mulighed for at åbne den gemte version via Google.

For et almindeligt website kunne der være forskellige grunde til ikke at ønske en ældre kopi vist. I cloaking-miljøet blev noarchive ofte brugt for at gøre det vanskeligere at sammenligne Googles version med den side, almindelige brugere så.

Min vurdering var imidlertid, at tagget også kunne virke som et signal til nysgerrige konkurrenter: Her var en side, hvor ejeren ikke ønskede, at cachen skulle kunne ses.

Derfor foretrak jeg en løsning uden det synlige fingeraftryk.

Google Cache: ven eller fjende?

Svaret afhænger af, hvilken side af bordet man sad på.

Som teknisk SEO-specialist var Google Cache en af mine bedste venner. Den viste mig, hvad Google havde læst, og gjorde det muligt at finde fejl i scripts, HTML, links, tegnkodning og serveropsætning. Den gav et overblik, som ingen automatisk rapport kunne erstatte.

I cloaking-perioden var den samtidig en fjende. Den kunne afsløre den side, Google havde gemt, og gøre det muligt for konkurrenter at sammenligne den med den almindelige version.

Det var netop den dobbelte rolle, der gjorde værktøjet så interessant.

Da Google fjernede den synlige cachefunktion, mistede branchen et af de mest direkte indblik i Googles behandling af en hjemmeside. Vi har i dag avancerede crawlere, loganalyse, renderingstest, Search Console og en lang række specialværktøjer.

De kan meget.

Men de viser ikke nødvendigvis præcis det dokument, Google havde gemt i sit indeks på det pågældende tidspunkt.

Det gjorde Google Cache.

Derfor savner jeg den stadig.