Menu Luk

IP Delivery – hvordan en af datidens mest avancerede SEO teknikker fungerede

SEO historie 1999-2010 – Del 1

Da jeg begyndte at arbejde professionelt med SEO omkring årtusindskiftet, så internettet og søgemaskinerne helt anderledes ud end i dag.

Google var på vej frem, men markedet bestod stadig af en lang række søgemaskiner som AltaVista, FAST, Inktomi, AllTheWeb, Yahoo! og MSN Search. Algoritmerne var langt mindre avancerede, og meget af det arbejde, der blev udført inden for SEO, handlede om at forstå, hvordan de enkelte søgemaskiner analyserede websites.

En af de teknikker, der blev mest omtalt, var IP Delivery, også kendt som IP Cloaking.

Mange har hørt ordet cloaking, men de færreste ved, hvordan teknikken faktisk fungerede. Derfor vil jeg beskrive den ud fra mine egne erfaringer.

Den mere tekniske gennemgang af databaser, CGI scripts, loganalyse og automatisering gemmer jeg til en senere artikel.

Det er samtidig vigtigt at understrege, at dette er et historisk tilbageblik. De teknikker, der beskrives her, hører til en anden periode i SEO’s udvikling og anvendes ikke længere.

Ip delivery - seo fra 2000-2010

En receptionist som eksempel

Den letteste måde at forstå IP Delivery på er at forestille sig en virksomhed med en receptionist.

Når telefonen ringer, kan receptionisten se telefonnummeret i displayet.

Er det en kunde, bliver opkaldet stillet videre til sælgeren.

Er det virksomhedens revisor, bliver opkaldet sendt til bogholderiet.

Ringer en medarbejders kone og fortæller, at han skal hente børnene i børnehaven, bliver samtalen sendt videre til ham.

Alle ringer til det samme telefonnummer.

Men de bliver sendt forskellige steder hen afhængigt af, hvem de er.

IP Delivery fungerede efter præcis det samme princip.

I stedet for en receptionist stod et CGI script skrevet i Perl for beslutningen.

Scriptet identificerede den besøgendes IP adresse og afgjorde, hvilket indhold der skulle vises.

Kom besøget fra en almindelig bruger, blev den normale hjemmeside vist.

Kom besøget fra Google eller en anden kendt søgemaskine, kunne CGI scriptet enten vise en samling topoptimerede sider eller sende søgemaskinen direkte videre til kundens website, hvor der blev vist et andet indhold end det, en almindelig besøgende så.

Sidegeneratoren

De sider, som søgemaskinerne fik vist, var altid automatisk genereret.

Datidens søgemaskiner havde svært ved at skelne mellem gennemtænkt maskinskabt indhold og manuelt skrevet indhold, hvis siderne var opbygget korrekt.

Alle sider blev genereret ud fra de parametre, der var defineret på forhånd for den enkelte kunde.

Kunden leverede typisk en liste over de vigtigste søgeord, som virksomheden ønskede at blive fundet på.

Herefter blev generatoren konfigureret.

Jeg kunne blandt andet definere keyword density – eksempelvis 2,4 %. Generatoren fordelte herefter automatisk søgeordet i teksten ud fra denne værdi.

Samtidig kunne jeg styre tekstlængden, antallet af gentagelser, placeringen af søgeordene, overskrifter, ALT-tekster og kombinationen af hovedsøgeord og relevante long tail søgeord.

Det betød, at løsningen kunne tilpasses den enkelte branche og konkurrencen på markedet.

Nogle brancher krævede en mere forsigtig optimering end andre, og derfor blev parametrene justeret fra kunde til kunde.

Title-tags blev skrevet ud fra kundens ønsker og de søgeord, der skulle fokuseres på.

Overskrifter, ALT tekster og brødtekster blev herefter genereret ud fra de parametre, der var defineret i systemet.

Hvis et søgeord eksempelvis skulle forekomme fem til syv gange på siden, sørgede generatoren automatisk for den ønskede fordeling.

Den eneste del, der bevidst blev randomiseret, var meta descriptions.

Jeg skrev typisk omkring 10 – 75 forskellige metabeskrivelser, som generatoren fordelte mellem de enkelte sider.

På den måde undgik man, at tusindvis af sider fik helt identiske metabeskrivelser.

Tekstlængde, billeder og afsnitsopbygning blev ligeledes varieret automatisk for at undgå tydelige mønstre – de såkaldte footprints – hvis en konkurrent eller en medarbejder hos en søgemaskine manuelt gennemgik materialet.

Resultatet var, at tusindvis af sider kunne produceres automatisk, samtidig med at de fremstod forskellige nok til datidens søgemaskiner.

Produktion i stor skala

Når generatoren først var sat op, tog det under en time at producere, uploade og gøre et website klar til indeksering.

Her taler vi ikke om små websites.

Et projekt kunne uden problemer bestå af mellem 200 og 10.000 sider.

Det betød dog ikke, at alle sider blev brugt til cloaking.

Tværtimod.

Hvis kundens rigtige website eksempelvis bestod af omkring 100 sider, blev der måske kun produceret omkring 150 cloakede sider.

Målet var aldrig at overdrive.

Jo større forskel der var mellem det normale website og de sider, søgemaskinerne så, desto større var risikoen for, at nogen ville opdage, at noget ikke stemte.

Den største udfordring

Mange tror, at den svære del var at bygge sidegeneratoren.

Det var det ikke.

Den største udfordring var databasen over søgemaskinernes IP adresser.

Den blev vedligeholdt hver eneste dag.

Jeg gennemgik dagligt logfilerne fra alle de websites, der indgik i systemet.

Når en ny crawler besøgte et website, efterlod den både sin IP adresse og sin identifikation i User Agent feltet.

Hvis der dukkede en crawler op, som endnu ikke fandtes i databasen, blev adressen undersøgt nærmere.

Ejerskabet blev kontrolleret, og først derefter blev IP adressen tilføjet databasen.

Allerede omkring 2004-2006 omfattede databasen flere tusinde verificerede IP adresser fra Google og de øvrige søgemaskiner.

Den voksede næsten dagligt.

Det var ikke sidegeneratoren, der gjorde systemet avanceret.

Det var den løbende analyse og vedligeholdelse.

Derfor virkede teknikken

Set med nutidens øjne kan nogle af principperne virke enkle.

Det var de ikke.

Bag systemet lå CGI scripts skrevet i Perl, databaser, automatiske sidegeneratorer, loganalyse og en IP database med flere tusinde adresser, som konstant skulle opdateres.

Hele systemet var parameterstyret.

Hvis jeg ønskede en anden keyword density, ændrede jeg blot værdien i databasen.

Hvis en branche krævede en anden tekstlængde eller flere gentagelser af søgeordene, blev parametrene ændret, og generatoren producerede et helt nyt website ud fra de nye værdier.

Det var denne fleksibilitet, der gjorde systemet effektivt.

Ikke fordi det producerede mange sider.

Men fordi hele løsningen kunne tilpasses den enkelte kunde på få minutter.

En anden tid

I dag er IP Delivery en del af SEO’s historie.

Søgemaskinerne har udviklet sig markant, og den type teknikker fungerer ikke længere.

Men perioden var med til at forme SEO som fag.

Når jeg ser tilbage, var det ikke selve cloakingen, der var det mest interessante.

Det var softwareudviklingen.

Databaserne.

Automatiseringen.

Loganalyserne.

Og den måde, man allerede dengang arbejdede datadrevet på.

På mange måder minder tankegangen om de AI baserede workflows og automatiseringssystemer, vi ser i dag.

Teknologierne er helt anderledes.

Men ønsket om at analysere data, automatisere processer og forstå søgemaskinernes adfærd er præcis det samme.

 

Denne artikel er en del af serien SEO’s glemte historie (1999-2010)

✓ Del 1: IP Delivery – hvordan en af datidens mest avancerede SEO teknikker fungerede (du læser den nu)

◻ Del 2: Da Google begyndte den manuelle jagt på danske IP cloakede websites (udkommer snart)

◻ Del 3: Maskinrummet – CGI, databaser og automatiseringen bag IP Delivery (udkommer senere)

◻ Del 4: Serverlogfilerne fortalte sandheden

◻ Del 5: Google Cache – den oversete kampplads

◻ Del 6: Det internationale SEO miljø omkring år 2000 – 2006

◻ Del 7: Fra IP Delivery til moderne SEO og AI

◻ Del 8: SEO’s vilde år 1999-2010 – erfaringerne bagefter

Næste artikel: Historien om, hvordan Google begyndte den manuelle jagt på danske IP cloakede websites, og hvordan analyser af serverlogfiler afslørede et mønster, som ændrede mit arbejde med IP identifikation.

Posted in Historiske artikler

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *