[{"@context":"https:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/blog.onlinemarketing.dk\/seos-glemte-historie-1999-2010-del-3.html#BlogPosting","mainEntityOfPage":"https:\/\/blog.onlinemarketing.dk\/seos-glemte-historie-1999-2010-del-3.html","headline":"Maskinrummet \u2013 hvordan jeg sikrede de k\u00f8rende dom\u00e6ner midt i Googles manuelle kontroller","name":"Maskinrummet \u2013 hvordan jeg sikrede de k\u00f8rende dom\u00e6ner midt i Googles manuelle kontroller","description":"\ud83d\udcd6 Historisk kontekst Denne artikel er en del af serien SEO’s glemte historie (1999-2010) og skal l\u00e6ses som historisk dokumentation. Artiklen beskriver en periode, hvor…","datePublished":"2026-07-20","dateModified":"2026-07-20","author":{"@type":"Person","@id":"https:\/\/blog.onlinemarketing.dk\/author\/admin#Person","name":"Ren\u00e9 Madsen","url":"https:\/\/blog.onlinemarketing.dk\/author\/admin","identifier":1,"description":"Jeg hedder Ren\u00e9 Madsen og grundlagde Online Marketing i 1995. Siden 1999 har jeg arbejdet professionelt med SEO og har fulgt udviklingen fra de f\u00f8rste s\u00f8gemaskiner til nutidens AI-baserede s\u00f8gning.\r\n\r\nJeg arbejder med teknisk SEO, GEO (Generative Engine Optimization), AI Discovery og digital synlighed. Gennem \u00e5rene har jeg r\u00e5dgivet b\u00e5de sm\u00e5 og store virksomheder i Danmark og internationalt med fokus p\u00e5 langsigtede l\u00f8sninger, teknisk kvalitet og dokumenterede resultater.\r\n\r\nP\u00e5 denne blog deler jeg analyser, erfaringer og historiske perspektiver fra mere end 25 \u00e5r i branchen. Mit m\u00e5l er at forklare, hvordan s\u00f8gemaskiner, AI og internettet udvikler sig \u2013 baseret p\u00e5 praktisk erfaring, dokumentation og egne erfaringer gennem branchens udvikling.\r\n\r\nVed siden af mit arbejde har jeg dyrket Kyokushin karate siden 1973 og er i dag Shihan, 5. dan. Karate har l\u00e6rt mig v\u00e6rdien af disciplin, vedholdenhed og konstant udvikling \u2013 principper, som ogs\u00e5 pr\u00e6ger mit arbejde med SEO og digital strategi.","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/ce65f41ecd392d9b2ef547aba58da9858a8cfb78bd54ce7a6acbffad581f31b2?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ce65f41ecd392d9b2ef547aba58da9858a8cfb78bd54ce7a6acbffad581f31b2?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Online Marketing","logo":{"@type":"ImageObject","@id":"https:\/\/blog.onlinemarketing.dk\/wp-content\/uploads\/2017\/05\/onlinemarketing_logo_mini.gif","url":"https:\/\/blog.onlinemarketing.dk\/wp-content\/uploads\/2017\/05\/onlinemarketing_logo_mini.gif","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/blog.onlinemarketing.dk\/wp-content\/uploads\/2026\/07\/seo-historie-3.png","url":"https:\/\/blog.onlinemarketing.dk\/wp-content\/uploads\/2026\/07\/seo-historie-3.png","height":1024,"width":1536},"url":"https:\/\/blog.onlinemarketing.dk\/seos-glemte-historie-1999-2010-del-3.html","about":["Historiske artikler"],"wordCount":5039,"articleBody":"\ud83d\udcd6 Historisk kontekstDenne artikel er en del af serien SEO’s glemte historie (1999-2010) og skal l\u00e6ses som historisk dokumentation.Artiklen beskriver en periode, hvor s\u00f8gemaskiner, websites og SEO udviklede sig meget hurtigt. Fokus er p\u00e5 de softwarearkitektoniske overvejelser, den tekniske udvikling og de erfaringer, som pr\u00e6gede perioden.De beskrevne systemer blev udviklet og anvendt i en helt anden teknologisk virkelighed end den, vi kender i dag. Form\u00e5let er at dokumentere et stykke dansk SEO-historie og de softwarearkitektoniske erfaringer, som perioden gav. De beskrevne teknologier har derfor f\u00f8rst og fremmest historisk interesse.Alle beskrivelser bygger p\u00e5 mine egne erfaringer, observationer og dokumentation fra perioden og skal l\u00e6ses i deres historiske kontekst.SEO\u2019s glemte historie (1999-2010) \u2013 Del 3I de to foreg\u00e5ende artikler fortalte jeg, hvordan IP-Delivery fungerede, og hvordan Google omkring 2007 begyndte en langt mere m\u00e5lrettet manuel kontrol af danske IP-cloakede websites.Denne artikel handler om, hvad der skete bagefter.Den handler ikke om cloaking som teknik og heller ikke om, hvordan s\u00e5danne systemer kunne bygges. Den handler om, hvad der skete i maskinrummet, da jeg midt i en presset periode m\u00e5tte gent\u00e6nke software, serverarkitektur og arbejdsgange, mens systemerne fortsat skulle holde kundernes trafik i gang.Den oprindelige version af mit IP-Delivery-system arbejdede med to logiske spor: \u00e9t til den almindelige bes\u00f8gende og \u00e9t til s\u00f8gemaskinens crawler.Da mine analyser af serverlogfilerne viste, at de manuelle kontroller opf\u00f8rte sig anderledes end den normale crawling, stod det klart, at den eksisterende arkitektur ikke l\u00e6ngere var tilstr\u00e6kkelig.Jeg udviklede derfor et tredje logisk spor, som udelukkende h\u00e5ndterede de manuelle kontroller.Det var ikke en l\u00f8sning, jeg havde hentet andre steder.Det var et eksperiment.Jeg havde ingen facitliste.Jeg vidste ikke, om det ville virke.Jeg vidste heller ikke, hvor l\u00e6nge det ville holde.En ting var jeg dog ikke i tvivl om. Hvis jeg ikke fandt en l\u00f8sning, risikerede en betydelig del af den organiske trafik til de websites, jeg arbejdede med, at forsvinde. Der var tale om flere hundrede tusinde organiske bes\u00f8g om m\u00e5neden fordelt p\u00e5 danske og internationale dom\u00e6ner. Derfor blev opgaven \u00f8jeblikkeligt min h\u00f8jeste prioritet.Det eneste, jeg vidste, var, at hvis de websites, der fortsat var i drift, skulle kunne forts\u00e6tte med at generere trafik, m\u00e5tte systemet t\u00e6nkes p\u00e5 en helt ny m\u00e5de.Det var samtidig f\u00f8rste gang, jeg for alvor oplevede, at arbejdet ikke l\u00e6ngere kun handlede om SEO. Det var blevet et egentligt softwareprojekt, hvor logik, databaser, serverrespons og l\u00f8bende kontrol skulle fungere som \u00e9t samlet system. Jeg vidste ikke, om l\u00f8sningen ville holde i m\u00e5neder eller \u00e5r, men jeg vidste, at den skulle bygges robust nok til at fungere fra dag \u00e9t.Faktaboks: Maskinrummet \u2013 den tekniske arkitekturFiguren nedenfor viser den overordnede arkitektur, som systemet arbejdede efter i perioden. Selvom diagrammet er forenklet, illustrerer det de centrale beslutningspunkter og g\u00f8r det lettere at forst\u00e5 resten af kapitlet.                         BES\u00d8GENDE                              \u2502                              \u25bc                 CGI SCRIPT #1 \u2013 GROVSORTERING                              \u2502        \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510        \u2502                     \u2502                     \u2502        \u25bc                     \u25bc                     \u25bc MANUEL KONTROL       ALMINDELIG BRUGER      KENDT S\u00d8GEMASKINE        \u2502                     \u2502                     \u2502        \u25bc                     \u25bc                     \u25bc Fejlside \/ visitkort      HTTP 302         CGI SCRIPT #2 \"Her flytter...\"          Redirect               \u2502                                                  \u25bc                                         IP-adresse kendt?                                          (IP-database)                                                  \u2502                           \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510                           \u2502                                            \u2502                           \u25bc                                            \u25bc                    JA \u2013 VERIFICERET                            NEJ \u2013 UKENDT                           \u2502                                            \u2502                           \u25bc                                            \u25bc                    HTTP 200 OK                                  HTTP 302                 Indekserbart indhold                       Registreres i log                           \u2502                                            \u2502                           \u2502                                            \u25bc                           \u2502                                  Daglig loganalyse                           \u2502                                            \u2502                           \u2502                                  Reverse DNS                           \u2502                                  Hostname                           \u2502                                  S\u00f8gemaskine                           \u2502                                            \u2502                           \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518                                                  \u25bc                                      IP tilf\u00f8jes databasen                                                  \u2502                                                  \u25bc                               Fremtidige bes\u00f8g \u2192 HTTP 200 OK CGI Script 1 \u2013 GrovsorteringenDet f\u00f8rste CGI-script fungerede som systemets portner. Her blev alle bes\u00f8gende vurderet, allerede inden de fik adgang til websitet.Scriptet fordelte trafikken i tre hovedgrupper:Manuelle kontroller \u2013 IP-adresser identificeret gennem serverloganalyse og knyttet til de manuelle kontroller. Almindelige bes\u00f8gendeVerificerede s\u00f8gemaskinerAllerede her blev den videre behandling af bes\u00f8get bestemt.Spor 1 \u2013 Manuelle kontrollerBes\u00f8gende, som blev vurderet til at v\u00e6re manuelle kontroller, blev ikke sendt videre til websitet.De blev i stedet m\u00f8dt af en simpel informationsside eller en fejlside, eksempelvis:“Her flytter en ny kunde ind.”Disse sider indeholdt ingen navigation og gav ingen mulighed for at udforske resten af websitet.Spor 2 \u2013 Almindelige bes\u00f8gendeAlmindelige brugere blev altid sendt videre via en HTTP 302 Redirect, f\u00f8r de n\u00e5ede frem til det rigtige website.Det var et bevidst designvalg.Hvis en ny crawler fra eksempelvis Google bes\u00f8gte websitet fra en endnu ukendt IP-adresse, ville den opleve pr\u00e6cis den samme behandling som en almindelig bruger. Set fra serverens side var der derfor ingen forskel mellem en ny crawler og enhver anden ukendt bes\u00f8gende.Spor 3 \u2013 Verificerede s\u00f8gemaskinerKendte crawlere fra blandt andet Google, Yahoo og MSN blev identificeret p\u00e5 baggrund af deres registrerede IP-adresser.Disse blev sendt videre til systemets andet CGI-script, som returnerede en HTTP 200 OK og leverede det indhold, som s\u00f8gemaskinen skulle indeksere.Hvorfor blev HTTP 302 anvendt?Valget af HTTP 302 (Found) var ikke tilf\u00e6ldigt.En 302-statuskode fort\u00e6ller, at en side er flyttet midlertidigt, hvilket var en helt legitim serverrespons.Nye crawlere, som endnu ikke var registreret i databasen, modtog derfor samme behandling som almindelige brugere. F\u00f8rst n\u00e5r deres IP-adresser var verificeret, blev de flyttet over til den gruppe, der modtog HTTP 200 OK.Dermed opf\u00f8rte systemet sig ens over for alle ukendte bes\u00f8gende.Daglig loganalyseAlle ukendte IP-adresser blev registreret i serverens logfiler.Logfilerne blev gennemg\u00e5et dagligt, hvor nye adresser blev kontrolleret ved hj\u00e6lp af blandt andet hostnavne, reverse DNS og oplysninger om, hvilken s\u00f8gemaskine de tilh\u00f8rte.N\u00e5r en IP-adresse var verificeret, blev den tilf\u00f8jet databasen og indgik fremover blandt de godkendte crawler-IP-adresser.Kort fortaltArkitekturen arbejdede med tre forskellige behandlingsforl\u00f8b:Bes\u00f8gstypeServerresponsManuel kontrolFejlside eller informationssideAlmindelig bes\u00f8gendeHTTP 302 RedirectVerificeret s\u00f8gemaskineHTTP 200 OK og indekserbart indholdSystemets styrke l\u00e5 ikke i \u00e9t enkelt script, men i samspillet mellem CGI-programmer, IP-databaser, serverlogfiler og den l\u00f8bende analyse af nye crawler-IP-adresser.Arkitekturen voksede videreSamtidig med arbejdet p\u00e5 IP-Delivery udviklede og testede jeg gennem flere \u00e5r en anden teknik, som dengang blev omtalt som DNS Cloaking.Grundideen var forholdsvis enkel. Et dom\u00e6ne kan tilg\u00e5s p\u00e5 flere m\u00e5der, eksempelvis som example.com og www.example.com. Teknisk er www-versionen et subdom\u00e6ne, og det samme g\u00e6lder andre navne foran dom\u00e6net, eksempelvis blog.example.com, test.example.com eller dev.example.com.Fra et serverperspektiv kan hvert subdom\u00e6ne pege p\u00e5 sin egen dokumentmappe eller sit eget website. Netop denne fleksibilitet gjorde det muligt at opbygge forskellige tekniske l\u00f8sninger omkring det samme dom\u00e6ne.For mig blev DNS Cloaking ikke en erstatning for IP-Delivery, men endnu et udviklingsspor. Erfaringerne fra de to teknologier blev efterh\u00e5nden samlet i \u00e9n f\u00e6lles softwareplatform, hvor Perl-programmer, CGI-scripts, databaser og loganalyse arbejdede sammen.Historisk eksempel: DNS Cloaking i praksisI mods\u00e6tning til klassisk IP Delivery blev indholdet ikke gemt som en lokal kopi p\u00e5 det DNS-cloakede website. I stedet hentede et PHP-script den aktuelle side direkte fra kundens almindelige website, hver gang siden blev kaldt.Scriptet udtog indholdet mellem sidens <body>-tags og indsatte det i en ny HTML-ramme. Samtidig blev kundens egne stylesheets indl\u00e6st direkte fra det oprindelige website. Relative links og billedadresser blev omskrevet, s\u00e5 de fortsat pegede p\u00e5 kundens egne filer. Resultatet var derfor ikke en side med et efterlignet design, men en visning baseret p\u00e5 kundens egen template og dens aktuelle indhold.Det DNS-cloakede dom\u00e6ne kunne derefter tilf\u00f8je sin egen interne navigation uden at \u00e6ndre kundens typografi, farver, billeder eller \u00f8vrige visuelle udtryk.Det bet\u00f8d ogs\u00e5, at indholdet fulgte kundens aktuelle hjemmeside. N\u00e5r kunden \u00e6ndrede en tekst, en pris eller en produktside, slog \u00e6ndringen igennem, n\u00e6ste gang siden blev hentet. Der skulle derfor ikke vedligeholdes separate kopier.Nedenst\u00e5ende kode er et anonymiseret historisk eksempel. Kundenavn, dom\u00e6ner, produkttekster og interne filnavne er \u00e6ndret. De forskellige adresser er erstattet med blandt andet example.dk og example.com, mens kodestrukturen og de mange konkrete URL-omskrivninger er bevaret.<?php    $url = $_GET['url']        ? $_GET['url']        : 'http:\/\/www.example.dk\/default.asp?pageid=499';    function fetch_body($url, $replace = 1) {        function check_for_http_and_replace($str1, $str2, $str3, $url) {            if (preg_match(\"#^([a-z]+):\/\/#i\", stripslashes($str2))) {                return stripslashes($str1 . $str2 . $str3);            }            return stripslashes($str1 . $url . $str2 . $str3);        }        $contents = implode(\"\", file($url));        if ($replace) {            $dir = dirname($url) . '\/';            $contents = preg_replace(                \"\/.*<body[^>]*>(.*)<\\\/body>.*\/sim\",                \"$1\",                $contents            );            $contents = preg_replace(                \"\/(<img[^>]+src=\\\")([^\\\"]+)(\\\")\/ei\",                \"check_for_http_and_replace('$1', '$2', '$3', '$dir')\",                $contents            );            $contents = preg_replace(                \"\/(<a[^>]+href=\\\")([^\\\"]+)(\\\")\/ei\",                \"check_for_http_and_replace('$1', '$2', '$3', '$dir')\",                $contents            );            $contents = str_replace(                \"example.dk\/\/\",                \"example.dk\/\",                $contents            );            $contents = str_replace(                \"\/global\/pre\/iframe\/\",                \"http:\/\/www.example.dk\/global\/pre\/iframe\/\",                $contents            );            $contents = str_replace(\"  \", \"\", $contents);            $contents = str_replace(\"
 \", \"\", $contents);            $contents = str_replace(                \"\/goto.asp\",                \"http:\/\/www.example.dk\/goto.asp\",                $contents            );            $contents = str_replace(                \"\/default.asp\",                \"http:\/\/www.example.dk\/default.asp\",                $contents            );            $contents = str_replace(                \"http:\/\/www.example.dkhttp:\/\/\",                \"http:\/\/\",                $contents            );            $contents = str_replace(                \"http:\/\/www.example.dkhttps:\/\/www.example.com\/\",                \"https:\/\/www.example.com\/\",                $contents            );        }        return $contents;    }?><html><head><meta http-equiv=\"Content-Type\"      content=\"text\/html; charset=iso-8859-1\" \/><title>Lorem ipsum dolor sit amet<\/title><meta name=\"description\"      content=\"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\" \/><meta name=\"keywords\"      content=\"lorem ipsum, dolor sit amet\" \/><link rel=\"stylesheet\"      href=\"http:\/\/www.example.dk\/example_internet.css\"      type=\"text\/css\" \/><link rel=\"stylesheet\"      href=\"http:\/\/www.example.dk\/example_colors.asp\"      type=\"text\/css\" \/><link rel=\"stylesheet\"      href=\"http:\/\/www.example.dk\/global\/example.css\"      type=\"text\/css\" \/><link rel=\"stylesheet\"      href=\"https:\/\/www.example.com\/assets\/layout.css\"      type=\"text\/css\" \/><\/head><body onLoad=\"drawTopMenu();\"><?php print fetch_body($url, 1); ?><br><p align=\"center\">    <font face=\"Arial\" color=\"#C0C0C0\" size=\"1\">        <?php include(\"nav\/_crosslinks-example.txt\"); ?>    <\/font>    <br>    <br><\/p><div class=\"historical-content\">    <h1>Lorem ipsum dolor sit amet<\/h1>    <p>        Lorem ipsum dolor sit amet, consectetur adipiscing elit.        Integer vitae justo eget magna fermentum iaculis.    <\/p>    <p>        Sed ut perspiciatis unde omnis iste natus error sit        voluptatem accusantium doloremque laudantium.    <\/p><\/div><\/body><\/html>Funktionsdiagram: S\u00e5dan arbejdede PHP-wrapperen                 BES\u00d8GENDE KALDER DEN LOKALE SIDE                                  \u2502                                  \u25bc                      URL-PARAMETER KONTROLLERES                                  \u2502                 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510                 \u2502                                 \u2502                 \u25bc                                 \u25bc          URL ER ANGIVET                    INGEN URL ANGIVET                 \u2502                                 \u2502                 \u25bc                                 \u25bc       Den valgte side bruges             Standardsiden bruges                 \u2502                                 \u2502                 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518                                  \u25bc                         fetch_body($url, 1)                                  \u2502                                  \u25bc               KUNDENS AKTUELLE HTML-SIDE HENTES                          med file($url)                                  \u2502                                  \u25bc                    KUN INDHOLDET I <body>                            BEVARES                                  \u2502                                  \u25bc            RELATIVE BILLEDER OG LINKS OMSKRIVES                                  \u2502                 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510                 \u2502                                 \u2502                 \u25bc                                 \u25bc          Relative billedstier              Relative links          g\u00f8res absolutte                   g\u00f8res absolutte                 \u2502                                 \u2502                 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518                                  \u25bc                  KONKRETE URL-FEJL KORRIGERES              dobbelte skr\u00e5streger, ASP-stier m.m.                                  \u2502                                  \u25bc                    DET BEARBEJDEDE INDHOLD                          RETURNERES                                  \u2502                                  \u25bc              INDS\u00c6TTES I DEN LOKALE HTML-RAMME                                  \u2502         \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510         \u2502                        \u2502                        \u2502         \u25bc                        \u25bc                        \u25bc  Lokal titel og           Kundens egne             Lokal menu,  metadata                 stylesheets              crosslinks og tekst         \u2502                        \u2502                        \u2502         \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518                                  \u2502                                  \u25bc                   \u00c9N SAMLET HTML-SIDE SENDES                          TIL BROWSERENS\u00e5dan fungerede koden i praksisKoden fungerede som et serverbaseret integrationslag mellem det DNS-cloakede dom\u00e6ne og kundens almindelige website. Den var ikke i sig selv den del af systemet, der identificerede s\u00f8gemaskiner eller manuelle kontroller. Den havde i stedet til opgave at hente, bearbejde og pr\u00e6sentere kundens aktuelle indhold inde i en lokalt styret HTML-ramme.F\u00f8rst blev den side, der skulle hentes, valgt. Hvis der blev sendt en URL med i kaldet, anvendte scriptet denne. Ellers blev en fast standardside hentet. Dermed kunne den samme PHP-fil bruges som beholder for flere forskellige undersider.Funktionen fetch_body() hentede derefter hele den eksterne HTML-side direkte fra kundens website. Indholdet blev ikke gemt som en lokal kopi. Hver gang siden blev kaldt, blev den aktuelle version hentet igen. N\u00e5r kunden \u00e6ndrede tekst, billeder, priser eller produktinformation p\u00e5 sit eget website, slog \u00e6ndringen derfor igennem ved n\u00e6ste visning.Efter hentningen blev alt uden for sidens <body>-omr\u00e5de fjernet. Kundens oprindelige titel, metabeskrivelse, \u00f8vrige metadata og ydre HTML-struktur blev dermed ikke anvendt. Kun selve indholdet fra body-sektionen blev bevaret og indsat i den nye lokale ramme.Relative billed- og linkadresser blev derefter omskrevet til fulde adresser. Et billede som eksempelvis images\/foto.jpg skulle fortsat hentes fra kundens server, selv om HTML-indholdet nu blev vist p\u00e5 et andet dom\u00e6ne. Det samme gjaldt interne links til ASP-sider og andre ressourcer.De mange efterf\u00f8lgende str_replace()-linjer var konkrete korrektioner til den HTML, som kundens system leverede. De rettede blandt andet dobbelte skr\u00e5streger, rodrelative adresser, links til bestemte ASP-filer og tilf\u00e6lde, hvor et dom\u00e6ne ved en fejl var blevet sat foran en adresse, der allerede var absolut.Den lokale HTML-side omkring det hentede indhold styrede selv sidens titel, metabeskrivelse, keywords og stylesheets. Kundens egne stylesheets blev fortsat indl\u00e6st, s\u00e5 det hentede indhold beholdt sit oprindelige visuelle udtryk. Samtidig kunne det DNS-cloakede dom\u00e6ne tilf\u00f8je sin egen menu, sine egne metadata og et separat lag af interne crosslinks.Crosslinks blev inkluderet fra en f\u00e6lles ekstern tekstfil. Det gjorde det muligt at \u00e6ndre det interne linklag centralt og lade de samme links indg\u00e5 p\u00e5 mange forskellige sider uden at redigere hver PHP-fil enkeltvis.Den samlede side bestod derfor af tre lag: en lokalt styret HTML-ramme, kundens dynamisk hentede body-indhold og et separat lag med navigation, crosslinks og eventuelt supplerende tekst.Teknisk var der alts\u00e5 tale om en specialbygget server-side HTML-wrapper eller content-proxy. Browseren modtog \u00e9n samlet HTML-side, men hovedindholdet var blevet hentet fra kundens website under PHP-eksekveringen.Det er samtidig vigtigt at skelne mellem dette pr\u00e6sentationslag og resten af systemet. Den viste PHP-kode udf\u00f8rte ikke selv den IP-baserede sortering. Identifikation af s\u00f8gemaskiner, manuelle kontroller, IP-databaser, serverrespons og loganalyse l\u00e5 i andre dele af den samlede platform.Det afg\u00f8rende i eksemplet er derfor samspillet mellem HTML, billeder, links, stylesheets og den lokale sidearkitektur: Scriptet hentede kundens eksisterende side, udtog dens centrale indhold og omskrev de relative adresser, s\u00e5 ressourcerne fortsat blev leveret fra kundens eget website.Koden anvender \u00e6ldre PHP-syntaks, herunder preg_replace()-modifieren e, som ikke underst\u00f8ttes i moderne PHP. Den er gengivet som historisk dokumentation af arkitekturen og ikke som vejledning til nutidig anvendelse.Historisk illustration af arkitekturen i mit IP Delivery-system (ca. 2007-2012)Arkitekturen skulle virke naturligDa jeg byggede systemet om, handlede det ikke kun om at tilf\u00f8je et tredje logisk spor. Lige s\u00e5 vigtigt var det at overveje, hvordan et almindeligt website normalt ville reagere.Den mest oplagte l\u00f8sning kunne have v\u00e6ret blot at blokere bestemte IP-adresser. Det er en metode, der ogs\u00e5 i dag anvendes mod hackerfors\u00f8g, spam og anden u\u00f8nsket trafik.Men den l\u00f8sning valgte jeg bevidst ikke.En ting stod klart for mig. Hvis en manuel kontrol kun kunne se det indhold eller de fejlmeddelelser, som blev vist til netop den IP-adresse eller den p\u00e5g\u00e6ldende IP-klasse, s\u00e5 var det ogs\u00e5 det eneste billede, kontroll\u00f8ren havde af websitet.Filosofien var derfor ikke blot at afvise bes\u00f8gende. Systemet skulle reagere p\u00e5 en m\u00e5de, som virkede naturlig. En hjemmeside kan v\u00e6re under ombygning, en side kan v\u00e6re slettet, en ny l\u00f8sning kan v\u00e6re p\u00e5 vej, eller serveren kan ganske enkelt have problemer. Fejlkoder, midlertidige omdirigeringer og korte beskeder er en helt naturlig del af internettets hverdag.Hvis jeg blot havde blokeret bestemte IP-adresser, ville det sende et tydeligt signal om, at de var blevet opdaget. Derefter kunne kontrollen i princippet blot forts\u00e6tte fra en anden IP-adresse, en dynamisk forbindelse eller via en VPN.Min vurdering var derfor, at et website, som reagerede markant anderledes over for enkelte bes\u00f8gende, i sig selv kunne komme til at virke unormalt.M\u00e5let var ikke at afvise bestemte bes\u00f8gende. M\u00e5let var, at systemet reagerede p\u00e5 en m\u00e5de, som et almindeligt website ogs\u00e5 kunne have gjort. Om det var en fejl, en flytning, en side under ombygning eller en midlertidig \u00e6ndring, kunne ingen udefra vide med sikkerhed. Netop den usikkerhed var en bevidst del af arkitekturen.Set i bakspejlet virker det m\u00e5ske indlysende. Omkring 2007 var denne type arkitektur imidlertid langt fra standard. For mig var det endnu en detalje, der skulle f\u00e5 systemet til at opf\u00f8re sig s\u00e5 naturligt som muligt.Allerede i den oprindelige arkitektur var hver underside matchet med en konkret landingsside p\u00e5 kundens eget dom\u00e6ne. Den struktur \u00e6ndrede jeg ikke p\u00e5, da systemet blev bygget om.Systemet sendte ikke alle bes\u00f8gende videre til forsiden. Hver underside fortsatte i stedet naturligt videre til den mest relevante landingsside p\u00e5 kundens eget website.Det var en bevidst designbeslutning. Brugerrejsen skulle h\u00e6nge logisk sammen, uanset hvilken side en bes\u00f8gende landede p\u00e5.Set i bakspejlet virker det m\u00e5ske indlysende. Omkring 2007 var det langt fra standard, og det var endnu en af de detaljer, som adskilte mine systemer fra mange af de l\u00f8sninger, der fandtes p\u00e5 markedet.Serverlogfilerne var mit vigtigste udviklingsv\u00e6rkt\u00f8jMange forbinder datidens SEO med s\u00f8geord, metatags og placeringer.For mig handlede en stor del af arbejdet om noget helt andet.Serverlogfiler.Det var her, historien gemte sig.Mine systemer var bygget op med to forskellige logniveauer.Kunderne havde deres egne bes\u00f8gslogfiler, hvor de kunne f\u00f8lge trafikken p\u00e5 deres websites. Samtidig havde jeg en samlet log over alle de websites, der indgik i systemet. Det var den f\u00e6lles log, der gjorde forskellen. N\u00e5r den samme crawler eller den samme ukendte bes\u00f8gende dukkede op p\u00e5 flere websites, begyndte m\u00f8nstrene langsomt at tegne sig.Det f\u00f8rste sp\u00f8rgsm\u00e5l var altid det samme:Var det en rigtig s\u00f8gemaskine \u2013 eller nogen, der blot udgav sig for at v\u00e6re det?En user-agent kunne eksempelvis pr\u00e6sentere sig som Googlebot, AltaVistas Scooter eller en anden kendt crawler.Men en user-agent er blot en tekststreng.Den kan relativt let \u00e6ndres.Derfor stolede mine systemer aldrig alene p\u00e5 user-agenten.Det n\u00e6ste skridt var altid at kontrollere IP-adressen.Ved hj\u00e6lp af et WHOIS-opslag kunne jeg se, hvem der ejede adressen. Hvis user-agenten fortalte, at den kom fra en s\u00f8gemaskine, men IP-adressen tilh\u00f8rte en tilf\u00e6ldig internetudbyder, vidste jeg, at noget ikke stemte. F\u00f8rst n\u00e5r user-agent og ejerskabet af IP-adressen stemte overens, blev crawleren betragtet som legitim og tilf\u00f8jet IP-databasen.Den f\u00e6lles log gjorde forskellenMine systemer registrerede alle bes\u00f8g p\u00e5 kundernes websites. Hver kunde havde adgang til sin egen bes\u00f8gslog og kunne f\u00f8lge med i, hvilke s\u00f8gemaskiner og bes\u00f8gende der havde v\u00e6ret forbi.Men den log var kun interessant for den enkelte kunde.For mig var det langt vigtigere at kunne se, hvad der skete p\u00e5 tv\u00e6rs af alle websites.Derfor byggede jeg en central logfunktion, hvor oplysninger fra samtlige websites blev samlet \u00e9t sted. Form\u00e5let var enkelt: Jeg ville undg\u00e5 at skulle logge ind p\u00e5 adskillige websites hver eneste dag for at lede efter nye crawlere eller us\u00e6dvanlige bes\u00f8gende.Den f\u00e6lles log gjorde det muligt hurtigt at opdage nye m\u00f8nstre.N\u00e5r en ukendt crawler dukkede op, blev den registreret centralt, og jeg kunne straks begynde at unders\u00f8ge, om der var tale om en legitim s\u00f8gemaskine eller blot en browser, der udgav sig for at v\u00e6re en crawler.I den oprindelige arkitektur blev kendte crawlere behandlet anderledes end ukendte bes\u00f8gende. De crawlere, der allerede var verificeret i systemets database, fortsatte som normalt. Ukendte crawlere blev derimod markeret i loggen og kunne efterf\u00f8lgende analyseres. Det var netop disse registreringer, der gjorde det muligt l\u00f8bende at identificere nye s\u00f8gemaskiner, kontrollere deres IP-adresser og opdatere databasen, n\u00e5r det var n\u00f8dvendigt.Set i bakspejlet var den centrale log sandsynligvis den vigtigste del af hele platformen. Den gjorde det muligt at vedligeholde systemet effektivt, selv om antallet af websites voksede, og den gav et samlet overblik, som jeg aldrig ville have f\u00e5et ved kun at analysere \u00e9t website ad gangen.Et godt historisk eksempel er AltaVistaDeres crawler Scooter fandtes i mange forskellige versioner, hostnavne og IP-adresser. Mine gamle oversigter indeholder blandt andet registreringer som disse:User-Agent : Scooter-W3.1.2Host       : trek11.sv.av.comIP         : 64.152.75.1User-Agent : Scooter-3.2Host       : scooter9.sv.av.comIP         : 64.152.75.4User-Agent : Scooter\/3.3Host       : buildrack90.sv.av.comIP         : 64.152.75.182Den komplette oversigt fyldte flere tusinde registreringer med forskellige hostnavne, user-agents og IP-adresser. Den var ikke interessant i sig selv \u2013 den var interessant, fordi den dokumenterede, hvilke servere der faktisk tilh\u00f8rte s\u00f8gemaskinen.Programmerne var i virkeligheden den lette del.Den virkelige udfordring var vedligeholdelsen.Nye user-agents dukkede op.IP-adresser blev \u00e6ndret.Nye crawlere kom til.Andre forsvandt igen.Alt skulle kontrolleres, dokumenteres og l\u00f8bende vedligeholdes. Hvis kontrollen blev fors\u00f8mt, begyndte systemet f\u00f8r eller siden at tr\u00e6ffe forkerte beslutninger.Det var systemets akillesh\u00e6l.Det var ikke programmeringen, der kostede mest tid.Det var kvalitetssikringen.Og det var netop under dette arbejde med logfiler, WHOIS-opslag og kontrol af crawlernes identitet, at jeg begyndte at se de m\u00f8nstre, som f\u00f8rte til den st\u00f8rste \u00e6ndring af hele arkitekturen.Systemet gik fra to logiske spor til tre.(Her f\u00f8lger illustrationen af de tre spor og den forenklede Perl-model.)===============================================================================HISTORISK SIMULATION: IP DELIVERY MED TRE LOGISKE SPOR===============================================================================Denne illustration viser den forenklede Perl-model bag det beslutningslag,som fordelte bes\u00f8gende mellem tre forskellige forl\u00f8b.Programmet udf\u00f8rer ingen virkelig IP-kontrol, ingen redirects og senderingen HTTP-statuskoder. Det er alene en historisk simulation af densoftwarearkitektur, der blev anvendt i perioden.-------------------------------------------------------------------------------#!\/usr\/bin\/perl## Historisk simulation af beslutningslaget i et IP Delivery-system.## Det oprindelige system anvendte IP-databaser, serverlogfiler,# crawlerkontrol og flere CGI-programmer.## Denne model viser kun den logiske opdeling i tre spor.#use strict;use warnings;use utf8;use open qw(:std :encoding(UTF-8));my %routes = (    visitor => {        title  => 'Almindelig bes\u00f8gende',        status => 'HTTP 302 Redirect',        action => 'Bes\u00f8gende sendes til den relevante landingsside p\u00e5 kundens website.',    },    crawler => {        title  => 'Verificeret s\u00f8gemaskine',        status => 'HTTP 200 OK',        action => 'Crawleren f\u00e5r adgang til den relevante cloakede underside.',    },    reviewer => {        title  => 'Manuel kontrol',        status => 'Neutral side eller fejlsvar',        action => 'Kontroll\u00f8ren m\u00f8des af en enkel informationsside uden navigation.',    },);print <<\"HEADER\";===============================================================================SIMULERET BESLUTNINGSLAG===============================================================================Den samlede platform arbejdede logisk med tre spor:  1. Almindelig bes\u00f8gende  2. Verificeret s\u00f8gemaskine  3. Manuel kontrolHEADERfor my $type (qw(visitor crawler reviewer)) {    print \"---------------------------------------------------------------\\n\";    print \"$routes{$type}{title}\\n\";    print \"---------------------------------------------------------------\\n\";    print \"Serverrespons: $routes{$type}{status}\\n\";    print \"$routes{$type}{action}\\n\\n\";}print <<\"FLOW\";-------------------------------------------------------------------------------FORENKLET FUNKTIONSFORL\u00d8B-------------------------------------------------------------------------------                         INDG\u00c5ENDE FORESP\u00d8RGSEL                                  |                                  v                    +---------------------------+                    |   CGI SCRIPT #1           |                    |   GROVSORTERING            |                    +---------------------------+                                  |          +-----------------------+-----------------------+          |                       |                       |          v                       v                       v   MANUEL KONTROL        ALMINDELIG BRUGER       KENDT S\u00d8GEMASKINE          |                       |                       |          v                       v                       v Neutral informationsside     HTTP 302              CGI SCRIPT #2 eller fejlside               Redirect                    |          |                       |                        v          |                       |               IP-adresse kendt?          |                       |                (IP-database)          |                       |                        |          |                       |          +-------------+-------------+          |                       |          |                           |          |                       |          v                           v          |                       |     JA \u2013 VERIFICERET            NEJ \u2013 UKENDT          |                       |          |                           |          |                       |          v                           v          |                       |     HTTP 200 OK                  HTTP 302          |                       |          |                    Registreres i log          |                       |          v                           |          |                       |   CLOAKET UNDERSIDE                  v          |                       |   MED INDEKSERBART            Daglig loganalyse          |                       |   INDHOLD                            |          |                       |                                     v          |                       |                               Reverse DNS          |                       |                               Hostname          |                       |                               S\u00f8gemaskine          |                       |                                     |          |                       |                                     v          |                       |                            IP tilf\u00f8jes databasen          |                       |                                     |          |                       |                                     v          |                       |                         Fremtidige bes\u00f8g \u2192 HTTP 200          |                       |          |                       v          |             RELEVANT LANDINGSSIDE          |              P\u00c5 KUNDENS WEBSITE          |          v Ingen adgang til de cloakede undersiderKort fortalt: - Almindelige bes\u00f8gende blev sendt videre til den relevante side   p\u00e5 kundens almindelige website. - Verificerede s\u00f8gemaskiner modtog HTTP 200 og fik adgang til   de relevante cloakede undersider. - Ukendte crawlere blev behandlet som almindelige bes\u00f8gende,   registreret i loggen og f\u00f8rst senere verificeret. - Manuelle kontroller blev m\u00f8dt af en neutral side eller et   fejlsvar uden adgang til systemets \u00f8vrige sider.Bem\u00e6rk:Denne illustration viser alene det forenklede beslutningslag.De faktiske systemer omfattede desuden IP-databaser, CGI-programmer,serverlogfiler, WHOIS-opslag, reverse DNS, automatiserede processerog l\u00f8bende kvalitetssikring.===============================================================================FLOWMere end IP DeliveryPerl illustrationen ovenfor er naturligvis ikke mit originale program. Den er en forenklet illustration af den arkitektur, jeg udviklede i perioden, og har alene til form\u00e5l at vise tankegangen bag systemet.Det interessante var efterh\u00e5nden ikke l\u00e6ngere den enkelte SEO teknik.Det interessante var arkitekturenSamtidig med, at jeg byggede IP-Delivery-systemet om, arbejdede jeg videre med DNS-Cloaking, som jeg gennem flere \u00e5r havde udviklet og testet parallelt. Oprindeligt betragtede jeg de to teknikker som selvst\u00e6ndige l\u00f8sninger, men efterh\u00e5nden begyndte de at smelte sammen.Erfaringerne fra de forskellige systemer blev gradvist samlet i \u00e9n f\u00e6lles softwareplatform. Perl-programmer, CGI-scripts, databaser, central loganalyse og automatiserede processer begyndte at arbejde sammen, og fokus flyttede sig fra den enkelte teknik til udviklingen af en egentlig arkitektur.De IP-adresser fra Googles irske netv\u00e6rk, som tidligere havde f\u00e5et alarmklokkerne til at ringe, dukkede fortsat op i logfilerne. De forsvandt ikke. Jeg kunne stadig se dem bes\u00f8ge nogle af de websites, der indgik i systemet.Forskellen var, at der efterf\u00f8lgende ikke l\u00e6ngere skete nogetHvor de tidligere havde v\u00e6ret et tydeligt faresignal, blev de med tiden blot endnu en linje i logfilen. Efter en periode holdt jeg helt op med at interessere mig for dem, fordi de ikke l\u00e6ngere havde nogen praktisk betydning i den daglige drift.Det er naturligvis alene en beskrivelse af mine egne observationer. Jeg ved ikke, hvilke interne procedurer Google anvendte, eller hvordan de vurderede de enkelte websites. Jeg kan blot konstatere, at de IP-adresser, som tidligere havde f\u00e5et min fulde opm\u00e6rksomhed, efter \u00e6ndringerne ikke l\u00e6ngere f\u00f8rte til de konsekvenser, jeg tidligere havde oplevet. L\u00f8sningen blev herefter anvendt i yderligere omkring fem \u00e5r, og jeg oplevede i den periode ingen n\u00e6vnev\u00e6rdige problemer eller tilf\u00e6lde, hvor de p\u00e5g\u00e6ldende dom\u00e6ner blev fjernet fra Googles indeks.Business as usualMens platformen blev bygget om og videreudviklet, fortsatte den daglige drift.For kunderne var der ingen dramatik. De k\u00f8bte fortsat abonnementer, og systemerne leverede den organiske trafik, de forventede. De s\u00e5 ikke arbejdet med Perl-programmer, CGI-scripts, databaser eller serverlogfiler. De oplevede blot, at trafikken fortsatte.Det var netop et af m\u00e5lene med ombygningen. Arkitekturen skulle \u00e6ndres i baggrunden, uden at kunderne blev ber\u00f8rt af det arbejde, der foregik i maskinrummet.Platformen blev anvendt af virksomheder inden for en lang r\u00e6kke brancher, blandt andet rejser, sommerhusudlejning, finans, gaming, underholdning og andre kommercielle omr\u00e5der, hvor organisk synlighed var en vigtig del af forretningen.Den anonymiserede faktura nedenfor viser \u00e9n m\u00e5neds levering til \u00e9n kunde i februar 2008. Den er ikke medtaget for at fremh\u00e6ve kunden, men som dokumentation for, at platformen fortsat var i normal kommerciel drift, efter at systemerne var blevet bygget om.Anonymiseret faktura fra februar 2008.Kunden er anonymiseret, men dokumentet viser, at platformen fortsat blev anvendt kommercielt som en abonnementsl\u00f8sning.Det er m\u00e5ske v\u00e6rd at n\u00e6vne, at hele platformen blev udviklet, drevet og vedligeholdt af mig alene. Der var ingen udviklingsafdeling, ingen driftsteam og ingen supportfunktion. Programmering, loganalyse, kundekontakt og den daglige vedligeholdelse var samlet hos \u00e9n person. Det var ogs\u00e5 en af \u00e5rsagerne til, at l\u00f8sningen med tiden blev stadig mere ressourcekr\u00e6vende at holde k\u00f8rende.S\u00e5dan fortsatte forretningen i flere \u00e5r. F\u00f8rst omkring 2012 begyndte det for alvor at st\u00e5 klart, at tiden var ved at l\u00f8be fra denne type systemer.\u00a0Stadig flere virksomheder \u00f8nskede langsigtede white hat-l\u00f8sninger, og kundegrundlaget for denne type systemer blev gradvist mindre. Samtidig voksede vedligeholdelsesarbejdet. Logfiler skulle gennemg\u00e5s, databaser opdateres, nye IP-adresser verificeres og systemerne vedligeholdes n\u00e6sten dagligt.P\u00e5 et tidspunkt stod det klart, at arbejdsindsatsen ikke l\u00e6ngere stod m\u00e5l med behovet.I 2012 slukkede jeg den sidste trafikserver.De havde v\u00e6ret i drift i mere end ti \u00e5r og leveret millioner af organiske bes\u00f8g til kunder i b\u00e5de Danmark og udlandet.Det blev afslutningen p\u00e5 et teknologisk kapitel.Men ikke afslutningen p\u00e5 de erfaringer, perioden havde givet mig.Tv\u00e6rtimod.Arbejdet med Perl, CGI-programmering, databaser, serverarkitektur, loganalyse og automatisering blev fundamentet for den m\u00e5de, jeg senere kom til at arbejde med teknisk SEO, softwareudvikling og \u2013 mange \u00e5r senere \u2013 AI.N\u00e5r jeg ser tilbage i dag, var IP Delivery derfor ikke det vigtigste, jeg tog med mig fra perioden.Det var maskinrummet.Det var m\u00e5den at t\u00e6nke p\u00e5: at observere, analysere m\u00f8nstre, bygge robuste systemer og forbedre dem p\u00e5 baggrund af data. Den tankegang har fulgt mig lige siden \u2013 fra teknisk SEO og softwareudvikling til de AI-l\u00f8sninger, jeg arbejder med i dag.N\u00e6ste artikel: Serverlogfilerne blev mit vigtigste v\u00e6rkt\u00f8j gennem hele perioden. Det var her, jeg kunne se, hvem der bes\u00f8gte et website, hvorn\u00e5r de gjorde det, og hvilke m\u00f8nstre der gentog sig p\u00e5 tv\u00e6rs af hundredvis af dom\u00e6ner. Historien handler ikke om avancerede SEO v\u00e6rkt\u00f8jer. Den handler om data, loganalyse og de observationer, der ofte fortalte mere end noget andet v\u00e6rkt\u00f8j p\u00e5 markedet.Kilder og historisk dokumentationDenne artikel bygger p\u00e5 mine egne erfaringer, observationer og dokumentation fra perioden 1999-2012.For at bevare artiklens fokus p\u00e5 historien har jeg valgt at samle den bagvedliggende dokumentation p\u00e5 en separat side. Her findes blandt andet historiske ordrebekr\u00e6ftelser, priseksempler, anonymiserede fakturaer, arkiverede websites og andet materiale, der dokumenterer mit arbejde med SEO siden 1999.L\u00e6s den historiske dokumentation her:SEO siden 1999 \u2013 historisk dokumentationDenne artikel er en del af serien SEO’s glemte historie (1999-2010)\u2713 Del 1: IP Delivery \u2013 hvordan en af datidens mest avancerede SEO-teknikker fungerede\u2713 Del 2: Da Google begyndte den manuelle jagt p\u00e5 danske IP-cloakede websites\u2713 Del 3: Maskinrummet \u2013 hvordan jeg sikrede de k\u00f8rende dom\u00e6ner midt i Googles manuelle kontroller (du l\u00e6ser den nu)\u25fb Del 4: Serverlogfilerne fortalte sandheden\u25fb Del 5: Google Cache \u2013 den oversete kampplads\u25fb Del 6: Det internationale SEO milj\u00f8 omkring \u00e5r 2000\u25fb Del 7: Fra IP Delivery til moderne SEO og AI\u25fb Del 8: SEO’s vilde \u00e5r 1999-2006 \u2013 erfaringerne bagefterRelaterede emner:IP Delivery \u2013 hvordan en af datidens mest avancerede SEO teknikker fungeredeDa Google begyndte den manuelle jagt p\u00e5 danske IP cloakede websitesNets.dk & PBS dom\u00e6neklagesagSEO og markedsf\u00f8ring anno 2013Gigahost foretager scanning for MySql data"},{"@context":"https:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Maskinrummet \u2013 hvordan jeg sikrede de k\u00f8rende dom\u00e6ner midt i Googles manuelle kontroller","item":"https:\/\/blog.onlinemarketing.dk\/seos-glemte-historie-1999-2010-del-3.html#breadcrumbitem"}]}]