Da logfilerne afslørede, at spillet havde ændret sig

Kapitel 4 i serien SEO’s glemte historie

Jeg har gennem årene arbejdet med mange forskellige programmer, scripts, databaser og tekniske løsninger.

Men hvis jeg skal pege på ét værktøj, der har haft større betydning end de fleste andre, er svaret overraskende enkelt:

En tekstfil.

Logfilen blev et af de vigtigste analyseværktøjer, jeg nogensinde kom til at arbejde med.

Den så ikke imponerende ud. Den bestod blot af linje efter linje med datoer, IP-adresser, filnavne, statuskoder, henvisninger og User-Agents.

En enkelt linje fortalte næsten ingenting.

Men når hundredtusinder af linjer blev analyseret samlet, begyndte mønstre at vise sig.

Man kunne se, hvordan en søgemaskine bevægede sig gennem et website. Man kunne finde gamle adresser, ingen længere vidste eksisterede. Man kunne opdage fejl, følge hackingforsøg og se, når nogen forsøgte at undersøge et website uden at fortælle, hvem de i virkeligheden var.

Logfilerne blev derfor langt mere end teknisk dokumentation.

De blev et værktøj til at forstå, hvad der faktisk skete.

Domæneloggen var mit daglige arbejdsredskab

Jeg arbejdede både med logfiler på domæneniveau og med de større serverlogs, men de havde forskellige formål.

Til det daglige arbejde med SEO og teknisk analyse anvendte jeg næsten altid loggen for det enkelte domæne.

Den indeholdt kun trafikken til det pågældende website og var derfor langt mere overskuelig end den samlede log for hele serveren.

En server kunne på det tidspunkt rumme mange forskellige websites og tjenester. Den samlede serverlog kunne derfor blive enorm. Her blev al trafik registreret på tværs af domæner, systemer og funktioner.

Hvis opgaven alene var at forstå ét bestemt website, var det unødigt besværligt at arbejde i den samlede mængde.

Domæneloggen gjorde det muligt at isolere netop den trafik, jeg var interesseret i.

Her kunne jeg blandt andet se:

• hvordan Google og andre søgemaskiner gennemgik websitet
• hvilke sider og filer der blev hentet
• hvilke adresser der returnerede fejl
• hvilke gamle URL’er der fortsat modtog trafik
• hvilke bots og værktøjer der besøgte sitet
• hvordan bestemte IP-adresser bevægede sig gennem indholdet

Det gjorde loggen hurtigere at analysere og langt lettere at anvende som et praktisk arbejdsredskab.

Sådan kunne en loglinje se ud

En klassisk registrering kunne eksempelvis se sådan ud:

66.249.66.1 - - [14/Jul/2007:10:15:46 +0200] "GET /sitemap.xml HTTP/1.1" 200 10482 "-" "Googlebot/2.1"

Ved første øjekast virker linjen måske kryptisk. Men den indeholder en række præcise oplysninger om hændelsen.

Det er vigtigt at bemærke formuleringen oplyste identifikation.

En User-Agent var ikke et bevis på, hvem der stod bag en forespørgsel.

Den fortalte kun, hvilken identitet klienten selv valgte at oplyse.

1999-2006: Det danske SEO-marked var cowboyland

Frem til 2007 oplevede jeg det danske SEO-marked som et teknisk pionerområde.

Google udviklede naturligvis løbende sine algoritmer, og der var ingen garanti for, at en løsning fortsatte med at virke. Men man mærkede ikke nogen nævneværdig manuel kontrol af danske websites i det daglige arbejde.

Der blev udviklet, testet og eksperimenteret i stort omfang.

Grænserne blev afprøvet.

Nye tekniske muligheder blev undersøgt.

Nogle løsninger fungerede kun kortvarigt. Andre kunne fungere i årevis.

Det var på mange måder cowboyland.

Ikke i betydningen, at der ingen regler fandtes. Google havde retningslinjer, og algoritmerne kunne reagere. Men det danske marked var lille, og efter min erfaring var der frem til 2007 ikke den samme manuelle opmærksomhed, som senere opstod.

I disse år blev logfilerne først og fremmest brugt til at forstå søgemaskinerne.

Jeg kunne følge, hvilke områder de besøgte, hvor ofte de vendte tilbage, hvilke filer de hentede, og hvordan ændringer på et website påvirkede deres adfærd.

Det gav en indsigt, som almindelige statistikprogrammer ikke kunne levere.

En graf viste resultatet – loggen viste hændelserne

Datidens analyseværktøjer kunne vise antal besøg, populære sider og henvisende websites.

Det var nyttigt, men utilstrækkeligt, hvis man ville forstå de tekniske sammenhænge.

En graf kunne vise, at trafikken faldt.

Loggen kunne vise, hvilke bots der var holdt op med at komme, hvilke sider de tidligere havde hentet, og præcis hvornår ændringen begyndte.

En rapport kunne vise en stigning i fejl.

Loggen kunne vise de konkrete URL’er, statuskoder, IP-adresser og User-Agents bag dem.

Det var forskellen mellem statistik og analyse.

Statistikken beskrev udviklingen.

Loggen gjorde det muligt at undersøge hændelsesforløbet.

Logfilerne huskede de sider, alle andre havde glemt

En af de mest værdifulde egenskaber ved logfilerne var, at de bevarede spor efter indhold, som ingen længere kunne huske.

Det kunne være gamle kampagnesider.

Produkter, der var blevet fjernet.

Artikler fra en tidligere version af websitet.

Fejlstavede adresser, som andre websites stadig linkede til.

Gamle links fra kataloger, fora og samarbejdspartnere.

Hvis en adresse fortsat blev besøgt, fandtes der som regel en årsag.

Ved at gennemgå loggen kunne man finde de gamle URL’er og etablere redirects til de mest relevante nye sider.

På den måde kunne værdifulde links og historisk trafik bevares, selv om websitet var blevet bygget om flere gange.

Logfilerne blev dermed også en form for hukommelse for websitet.

2007 blev et vendepunkt

I 2007 ændrede situationen sig.

Som beskrevet i kapitel 2 begyndte Google på dette tidspunkt at rette et langt skarpere fokus mod det danske marked.

Før 2007 havde Danmark i praksis været et forholdsvis uforstyrret område. Men da Google først fik øje på markedet, begyndte manuelle kontroller at få en reel betydning.

Google anvendte ikke falske Googlebot-identiteter til de manuelle gennemgange.

De manuelle medarbejdere besøgte websites som almindelige brugere fra almindelige browsere og kunne derfor ikke identificeres ved blot at lede efter en bestemt User-Agent.

Det var i stedet adfærden, sammenhængen og de historiske data, som gjorde besøgene interessante.

En almindelig besøgende fulgte typisk indholdet ud fra et konkret behov.

En person, der gennemgik et website teknisk, bevægede sig ofte anderledes.

Vedkommende kunne besøge bestemte sider i en usædvanlig rækkefølge, vende tilbage flere gange, afprøve forskellige adresser og lede systematisk efter forskelle eller tekniske spor.

Det var ikke én enkelt forespørgsel, der fortalte historien.

Det var mønstret over tid.

Loganalysen blev en aktiv del af løsningen

Da de manuelle kontroller begyndte at få betydning, blev loganalysen koblet tættere sammen med de øvrige tekniske systemer.

Databasen indeholdt allerede verificerede oplysninger om kendte søgemaskiner og deres adresser.

Hvis en forespørgsel kom fra en kendt og valideret søgemaskine, kunne systemet behandle den på den måde, der var fastlagt for denne trafik.

Hvis den kom fra en almindelig besøgende, blev den behandlet som almindelig trafik.

Og hvis besøget ikke passede ind i de kendte mønstre, kunne det håndteres særskilt.

Den besøgende kunne eksempelvis få vist en side, som kun blev anvendt til denne type forespørgsel.

Selve opbygningen og de tekniske spor i løsningen er beskrevet i kapitel 3.

Det afgørende i denne sammenhæng var, at logfilerne leverede den nødvendige viden.

De gjorde det muligt at se, at et besøg fandt sted, hvilke sider der blev åbnet, hvilken rækkefølge de blev besøgt i, og om den samme adresse vendte tilbage.

Kapitel 3 beskriver teknikken.

Dette kapitel handler om analysen, der gjorde teknikken anvendelig.

Konkurrenterne efterlod et andet mønster

Google var ikke de eneste, der interesserede sig for de tekniske løsninger.

Konkurrenter og andre i branchen forsøgte også at kortlægge, hvordan bestemte websites fungerede.

Nogle anvendte scanningsværktøjer.

Andre foretog manuelle undersøgelser.

Og nogle forsøgte at skjule deres aktivitet ved at ændre User-Agent-strengen fra forespørgsel til forespørgsel.

Den ene anmodning kunne udgive sig for at komme fra Googlebot.

Den næste fra MSNBot.

Derefter fra Yahoo, en almindelig browser eller et af datidens analyseværktøjer.

Hvis man kun så på User-Agenten, kunne det ligne forskellige besøgende.

Men IP-adressen og adfærden fortalte ofte en anden historie.

Når den samme IP-adresse på kort tid anvendte en række forskellige identiteter og besøgte de samme teknisk interessante adresser, var der sjældent tale om uafhængige besøgende.

Det var typisk én person eller ét værktøj, som afprøvede forskellige identiteter.

En User-Agent var let at forfalske

Det var teknisk enkelt at ændre en User-Agent.

Derfor kunne man aldrig stole på denne oplysning alene.

En klient kunne kalde sig Googlebot uden at have nogen forbindelse til Google.

Den kunne kalde sig en browser, et SEO-værktøj eller en helt anden bot.

Derfor blev de oplyste identiteter sammenholdt med de adresser og mønstre, der allerede var verificeret i databasen.

Hvis en forespørgsel hævdede at komme fra en kendt søgemaskine, men IP-adressen ikke stemte overens med de kendte adresser, var identiteten ikke troværdig.

Det var et tidligt eksempel på en grundregel, som stadig gælder:

Man bør ikke stole på det navn, en klient giver sig selv.

Et forenklet eksempel på falske bot-identiteter

Et mønster kunne i forenklet form se sådan ud:

12.34.56.78 - - [14/Jul/2007:10:15:46 +0200] "GET /produkt.html HTTP/1.1" 200 10482 "-" "Googlebot/2.1"
12.34.56.78 - - [14/Jul/2007:10:16:03 +0200] "GET /produkt.html HTTP/1.1" 200 10482 "-" "msnbot/1.1"
12.34.56.78 - - [14/Jul/2007:10:16:19 +0200] "GET /robots.txt HTTP/1.1" 200 642 "-" "Mozilla/5.0"
12.34.56.78 - - [14/Jul/2007:10:16:41 +0200] "GET /ukendt-adresse HTTP/1.1" 404 512 "-" "WebsiteScanner/2.0"

Fire forskellige User-Agents kunne ved første øjekast ligne fire forskellige besøgende.

Men forespørgslerne kom fra samme IP-adresse med få sekunders mellemrum og var rettet mod det samme website.

Det var ikke et bevis på, hvilken fysisk person der sad ved computeren.

Men det var et tydeligt teknisk mønster, som viste, at forespørgslerne sandsynligvis hang sammen.

Når besøgsmønstre kunne sammenholdes med datidens fora

SEO-branchen var mindre dengang, og en stor del af den faglige diskussion foregik i fora.

Der blev diskuteret teknikker, observationer, mistanker og resultater fra forskellige undersøgelser.

Ved længerevarende loganalyse kunne bestemte besøgsforløb i nogle tilfælde sammenholdes med det, der kort efter blev skrevet offentligt.

Hvis en IP-adresse gennemgik bestemte sider, afprøvede en række User-Agents og søgte efter særlige tekniske forhold, og en person kort efter beskrev tilsvarende observationer i et forum, kunne tidspunkt, metode og detaljer pege i samme retning.

Det gjorde det muligt at kæde tekniske hændelser sammen med de diskussioner, der foregik i branchen.

Det er dog vigtigt at holde fast i forskellen mellem en stærk indikation og et sikkert bevis.

En IP-adresse identificerer ikke nødvendigvis én bestemt fysisk person. Adressen kan være delt af flere, tilhøre en arbejdsplads eller være anvendt gennem en mellemstation.

Formålet var derfor ikke at offentliggøre navne eller udstille enkeltpersoner.

Formålet var at forstå, hvad der blev undersøgt, og hvordan systemerne kunne beskyttes.

Data mining før ordet blev hverdag

I dag taler man om Big Data, datamining, adfærdsanalyse og kunstig intelligens.

Dengang anvendte vi ikke nødvendigvis de samme ord, men arbejdsmetoden var grundlæggende den samme.

Store datamængder blev bearbejdet for at finde:

• gentagelser
• afvigelser
• tidsmæssige sammenhænge
• fælles IP-adresser
• skiftende identiteter
• bestemte bevægelsesmønstre
• tekniske forespørgsler, som skilte sig ud

Det var ikke tilstrækkeligt at se på én oplysning.

IP-adressen kunne være delt.

User-Agenten kunne være falsk.

En enkelt forespørgsel kunne være tilfældig.

Men når mange forhold pegede i samme retning, blev mønstret stærkere.

Det var her, loganalysen blev til egentlig viden.

Serverloggen havde en anden styrke

Selv om jeg primært anvendte domæneloggen i det daglige arbejde, var den samlede serverlog vigtig ved større tekniske hændelser.

Den kunne afsløre aktivitet på tværs af mange websites og tjenester.

Det var især værdifuldt ved:

• hackingforsøg
• scanninger efter kendte sårbarheder
• gentagne loginforsøg
• pludselige trafikstigninger
• overbelastning
• nedbrud
• mistanke om kompromittering

Hvis et website blev hacket eller gik ned, kunne loggen bruges til at undersøge hændelserne umiddelbart før problemet opstod.

Her kunne man se, hvilke adresser der blev forsøgt åbnet, hvilke filer der blev kaldt, og hvilke IP-adresser der var aktive i perioden op til hændelsen.

I nogle tilfælde kunne et bestemt angrebsmønster eller en adresse identificeres.

Websitet kunne derefter gendannes fra en ren sikkerhedskopi, den udnyttede sårbarhed kunne lukkes, og kendte adresser kunne udelukkes.

At blokere en enkelt IP-adresse var naturligvis ikke en fuldstændig sikkerhedsløsning. En angriber kunne skifte adresse eller anvende kompromitterede systemer.

Men loggen gav et konkret grundlag for at rekonstruere hændelsesforløbet og forhindre en umiddelbar gentagelse.

Loggen kunne vise, hvad der skete før et nedbrud

Når et website var blevet kompromitteret, var spørgsmålet ofte ikke kun, hvordan det kunne gendannes.

Det vigtigste spørgsmål var:

Hvad skete der lige før?

Hvis man alene gendannede websitet uden at forstå årsagen, risikerede man, at det samme skete igen kort efter.

Ved at gennemgå loggen baglæns kunne man ofte se de sidste usædvanlige forespørgsler før nedbruddet.

Det kunne være gentagne kald til en bestemt komponent, forsøg på at åbne en kendt administrativ adresse eller mange næsten identiske forespørgsler med små variationer.

På den måde fungerede serverloggen som en teknisk tidslinje.

Den viste ikke nødvendigvis hele forklaringen, men den viste rækkefølgen af de hændelser, der var registreret.

Da de rå logfiler blev mindre tilgængelige

I takt med at delte webhoteller, cloudløsninger og moderne kontrolpaneler overtog markedet, blev adgangen til komplette logfiler gradvist mindre.

Mange websiteejere fik i stedet dashboards med grafer, rapporter og standardiserede oversigter.

Det var lettere at bruge.

Men det betød også, at de rå hændelser ofte ikke længere var tilgængelige i samme omfang.

Man kunne se, at trafikken var steget eller faldet.

Men man kunne ikke altid se de enkelte requests, de præcise IP-adresser, rækkefølgen af hændelser eller de tekniske detaljer bag udviklingen.

Efter min opfattelse mistede mange dermed et vigtigt analyseværktøj.

Den moderne løsning er lokal applikationslogging

At den traditionelle domæne- eller serverlog ikke altid er tilgængelig, betyder ikke, at metoden er forældet.

Den kan flyttes ind i selve applikationen.

Et website kan i dag registrere indgående trafik lokalt på fil- eller requestniveau.

Logningen kan omfatte alle forespørgsler eller begrænses til de hændelser, som har særlig analyseværdi.

Det kan eksempelvis være:

• almindelige sidevisninger
• redirects
• 404-fejl
• loginforsøg
• API-kald
• søgninger på websitet
• bestemte filer eller endpoints
• udvalgte bots og User-Agents
• forespørgsler med usædvanlige mønstre

Fordelen er, at logningen kan designes til det konkrete formål.

Man behøver ikke registrere hele serverens trafik, hvis man kun ønsker at analysere ét website.

Og man kan tilføje oplysninger, som en traditionel serverlog ikke nødvendigvis indeholder.

En moderne lokal log kan være enkel

En registrering i en lokal applikationslog kunne eksempelvis se sådan ud:

Tidspunkt........ 27-07-2026 09:18:22
IP-adresse....... 66.249.66.1
HTTP-metode...... GET
URL.............. /seo.html
Statuskode....... 200
Svartid.......... 148 ms
User-Agent....... Googlebot/2.1
Referer.......... -
Behandlet af..... Joomla-komponent
Cache............ Nej

Rent teknisk behøver systemet ikke være kompliceret.

Når applikationen modtager en forespørgsel, kan den registrere de relevante oplysninger i en tekstfil eller database.

Når svaret er leveret, kan registreringen suppleres med statuskode, svartid og andre interne oplysninger.

På den måde kan man opbygge en moderne domænelog, selv om hostingudbyderen ikke giver adgang til de traditionelle logfiler.

Det afgørende er analysen – ikke filformatet

En logfil har ingen værdi, hvis ingen læser den.

Og en stor datamængde skaber ikke automatisk indsigt.

Det afgørende er, hvilke spørgsmål man forsøger at besvare.

Er formålet at forstå søgemaskinernes crawling?

At finde gamle links?

At opdage falske bots?

At analysere et sikkerhedsbrud?

At undersøge, hvorfor et website blev langsomt?

Eller at se, hvilke automatiserede klienter der henter bestemte ressourcer?

Logningen bør indrettes efter formålet.

Ellers ender man blot med en ny stor tekstfil, som ingen har tid til at gennemgå.

AI er blot endnu en type klient

I dag besøges websites ikke kun af mennesker og traditionelle søgemaskiner.

Der kommer også AI-relaterede bots, agenter og andre automatiserede systemer.

De kan anmode om almindelige websider eller om særlige ressourcer som:

• llms.txt
• llms-full.txt
• Markdown-versioner af indhold
• Agent Skills
• API Catalog
• MCP Server Card
• andre strukturerede filer og endpoints

Men AI bør ikke behandles som et helt separat analyseprincip.

Det er blot endnu en type klient, som sender requests til et website.

Den samme metode gælder:

Forespørgslen registreres.

Identiteten vurderes.

Adfærden analyseres.

Mønstrene sammenholdes over tid.

Teknologien er ny.

Analyseprincippet er det samme.

Logfilerne afslørede, at spillet havde ændret sig

Når jeg ser tilbage, var 2007 ikke kun året, hvor Google for alvor fik øje på Danmark.

Det var også året, hvor logfilerne begyndte at fortælle en anden historie.

Før den tid handlede arbejdet primært om algoritmer, tekniske muligheder og søgemaskinernes automatiske adfærd.

Efter 2007 blev menneskelig kontrol, konkurrenters undersøgelser og mere målrettet overvågning en langt tydeligere del af billedet.

Det ændrede kravene til systemerne.

Men det ændrede ikke den grundlæggende arbejdsmetode.

Hver forespørgsel efterlod stadig et spor.

En IP-adresse.

Et tidspunkt.

En fil.

En statuskode.

En oplyst identitet.

Alene fortalte oplysningerne næsten ingenting.

Sammen begyndte de at fortælle en historie.

Afslutning

Internettet har ændret sig mange gange siden de første logfiler blev skrevet.

Søgemaskinerne er blevet mere avancerede.

Hostingmiljøerne er blevet mere komplekse.

Kunstig intelligens er blevet en del af internettets infrastruktur.

Men én ting har ikke ændret sig:

Hver eneste forespørgsel efterlader et spor.

Spørgsmålet er ikke kun, om data findes.

Spørgsmålet er, om man lærer at læse dem.

Det var det, logfilerne lærte mig.