Serverlogs gebruiken voor een gerichte SEO-diagnose

Serverlogs kunnen laten zien welke adressen zijn opgevraagd, welke status uw infrastructuur terugstuurde en wanneer dat gebeurde. Voor SEO helpen ze een concrete vraag onderzoeken, zoals herhaald bezoek aan verwijderde adressen of ontbrekende verzoeken naar een belangrijk paginatype. Ze bewijzen geen indexering, ranking of menselijk bezoek.

Begin met één diagnosevraag en een afgebakende periode. Een volledige export van alle ruwe logs is zelden de beste eerste stap. Vraag uw beheerder welke gegevens beschikbaar zijn, op welk infrastructuurniveau ze ontstaan en welke persoonsgegevens daarin kunnen voorkomen.

Bepaal welk deel van de keten u ziet

Een verzoek kan door een CDN, cache, proxy en applicatieserver gaan. Een applicatielog bevat mogelijk alleen verzoeken die niet al eerder uit een cache zijn beantwoord. Een ontbrekende regel bewijst dan niet dat het adres nooit is opgevraagd.

Noteer bron, tijdzone, meetperiode, ontbrekende intervallen en eventuele steekproeven. Controleer of redirects en foutantwoorden in hetzelfde bestand staan. De betekenis van HTTP-statuscodes is vastgelegd in RFC 9110. Toch blijft lokale documentatie nodig om te weten welke status uw logveld werkelijk beschrijft: het antwoord van de oorsprong of het uiteindelijke antwoord aan de verzoeker.

Kies gegevens die de vraag beantwoorden

Voor een analyse van foutpatronen kunnen datum, genormaliseerd pad, status en een onderbouwde crawlercategorie voldoende zijn. Volledige querystrings, cookies, tokens en formulierinhoud zijn daarvoor meestal overbodig en kunnen gevoelige informatie bevatten.

De AVG-beginselen omvatten doelbinding, minimale gegevensverwerking en opslagbeperking. Dit betekent niet dat iedere loganalyse verboden is; het vraagt een passende grondslag en beheerkeuze voor uw situatie. Laat die beoordelen wanneer persoonsgegevens worden verwerkt. Gebruik voor rapportages bij voorkeur afgeleide tellingen en deel geen ruwe adressen met persoonlijke parameters via een openbare SEO-presentatie.

Vertrouw een botnaam niet zonder controle

Een user-agent is een opgegeven naam en kan worden nagebootst. Een regel met “Googlebot” is daarom nog geen bevestigd verzoek van Google. De primaire documentatie over Googlebot verifiëren beschrijft controle via beschikbare netwerkgegevens en ondersteunde verificatiemethoden.

Laat die controle door iemand met de juiste technische toegang uitvoeren. Bewaar daarna in de analyse een categorie zoals bevestigd, onbevestigd of onbekend. Doe geen automatische reverse-DNS- of IP-conclusie op basis van een toevallig gevonden lijst. IP-ranges en infrastructuur kunnen veranderen. Een onjuist gelabelde bot maakt een fraaie grafiek inhoudelijk waardeloos.

Groepeer naar beslisbare patronen

Een lange lijst losse URL's helpt minder dan groepen met een gedeelde oorzaak. Splits bijvoorbeeld bestaande artikelen, oude productadressen, filterparameters en technische bestanden. Houd succesvolle verzoeken, redirects, ontbrekende pagina's en tijdelijke serverproblemen uit elkaar.

Verbind de groepen met uw crawlfoutendiagnose. Een kleine hoeveelheid oude 404-verzoeken vraagt mogelijk geen herstel; een actieve interne link naar een belangrijke verdwenen dienst wel. Tel ook unieke adressen naast verzoeken. Eén hardnekkig foutadres met veel herhalingen is een ander probleem dan duizenden eenmalige varianten. Gebruik beide maten om de oorzaak beter te begrijpen.

Een fictieve week met tweeduizend verzoeken

Een fictieve website heeft een export van 2.000 bevestigde crawlerverzoeken uit één volledige week. Daarvan gaan 1.300 naar bestaande pagina's, 400 naar filtervarianten, 200 naar redirects en 100 naar ontbrekende adressen. De som is 2.000; het bestand bevat geen bezoekers- of omzetgegevens.

Van de honderd ontbrekende verzoeken blijken er tachtig naar twee oude dienstadressen te gaan. De overige twintig zijn verspreide onbekende paden. De eerste werkopdracht onderzoekt daarom die twee diensten en hun verwijzingen, niet alle mogelijke fouten tegelijk.

Dit is een fictief rekenvoorbeeld. Vierhonderd filterverzoeken bewijzen niet op zichzelf dat belangrijke pagina's minder worden gecrawld. Daarvoor is aanvullende context nodig over siteomvang, verloop en ontdekking.

Leg logwaarneming naast publicatiegegevens

Vergelijk een verdacht adres met het actuele antwoord, interne links, sitemap en eventuele informatie in Search Console. Elk geeft een ander stukje bewijs. Een server kan een pagina correct leveren terwijl een verkeerde canonical haar elders laat groeperen.

De gids over Search Console helpt de reikwijdte van dat tweede instrument begrijpen. Schrijf bij tegenstrijdigheden op wat werkelijk bekend is: “verzoek gezien met 200” is preciezer dan “pagina goed geïndexeerd”. Controleer ook of de site sinds de gemeten periode is gewijzigd. Oude logs vergelijken met een nieuw sjabloon kan anders een schijnbaar onverklaarbaar verschil opleveren.

Maak van de analyse een beperkte werkopdracht

Een bruikbaar rapport noemt patroon, bewijsperiode, vermoedelijke oorzaak, eigenaar en controlemethode na herstel. Voeg enkele representatieve voorbeelden toe zonder geheime parameters. Laat herstel van interne links, redirects of infrastructuur volgen uit de vastgestelde oorzaak.

Vermijd gelijktijdige grote contentwijzigingen wanneer u een technische fout probeert te isoleren. Een herstelcontrole gaat eerst over de bedoelde respons en bereikbaarheid, zoals bij controle na publicatie. Een latere daling van foutverzoeken kan ondersteunend bewijs zijn, maar crawlers kunnen oude adressen nog blijven opvragen. Geef dus geen onrealistische eis dat iedere oude logregel onmiddellijk verdwijnt.

Leg de toegepaste normalisatie en categorisatieregels vast. Vermeld bijvoorbeeld of meerdere queryvarianten als één pad worden geteld en waarom. Anders kan een volgende maand andere parameters wegstrepen en een onvergelijkbare trend produceren. Noteer wanneer een dataset onvolledig is. Vul ontbrekende uren niet met verzonnen gemiddelden om een mooiere reeks te maken.

Gebruik de regels uit meten zonder schijnzekerheid voor uw conclusie: verzoeken zijn geen personen, crawling is geen indexering en een technische reparatie is geen toegeschreven omzet. Verwijder tijdelijke exports volgens de afgesproken bewaartermijn en beperk toegang tot wie de diagnose uitvoert. Geaggregeerde herstelnotities kunnen vaak langer bruikbaar blijven dan het ruwe materiaal.

Bronnen en grenzen

De primaire bronnen zijn HTTP Semantics, RFC 9110, Google's Googlebot-verificatie en de AVG. Het logvoorbeeld is fictief. Dit artikel geeft geen juridische beoordeling van uw infrastructuur en bevat geen analyse van echte serverlogs.