SEO Log File Analyzer

Een crawler vertelt u wat er op uw site staat. Uw serverlogboeken vertellen u wat Google er werkelijk mee doet. SEO Log File Analyzer leest uw toegangslogboeken. Hij laat zien welke bots langskomen, hoe vaak en op welke adressen. Hij laat ook zien hoeveel crawlbudget in fouten verdwijnt. Analyseer nu uw logboeken: upload een bestand of plak een paar duizend regels, er wordt niets bewaard.

Dit is de enige gegevensbron in SEO die je niet kunt raden. Posities, vertoningen en crawlstatistieken bereiken u altijd uit de tweede hand. Toegangslogboeken zijn de ruwe vastlegging van elk verzoek dat uw server echt heeft beantwoord. Uw eigen machine schrijft ze.

Wat de logboeken laten zien

Na het uploaden scheidt het hulpmiddel echt crawlerverkeer van de rest. Daarna splitst het dat uit in cijfers waarmee u kunt werken.

• Welke crawlers er waren. Elke bekende bot met zijn bezoeken, de unieke adressen en de verdeling van de ontvangen statuscodes.
• Hoe vaak ze kwamen. Crawlfrequentie per dag, zodat een daling of een piek zichtbaar wordt in plaats van vermoed.
• Waar ze tijd aan besteedden. Uw meest gecrawlde adressen, en dat is zelden de lijst die u had verwacht.
• Waar het crawlen verloren gaat. Omleidingen, 404's, snelheidsbeperkingen en serverfouten, elk als aandeel van de verzoeken, met de bijbehorende adressen.

Crawlers van kunstmatige intelligentie krijgen een eigen overzicht

GPTBot, ClaudeBot en PerplexityBot zijn inmiddels goed voor een reëel deel van het automatische verkeer. En ze gedragen zich heel anders dan Googlebot. Ze staan apart vermeld, met het aantal bezoeken en de datum waarop ze voor het laatst langskwamen.

De activiteit van crawlers met kunstmatige intelligentie laat zien of die bekende crawlers uw inhoud vinden en ophalen. Waar de beheerder dat documenteert, wordt elke crawler aangeduid als trainingscrawler, zoekcrawler of ophaalactie op verzoek van een gebruiker. Een bezoek garandeert geen opname of vermelding in antwoorden van kunstmatige intelligentie.

Crawl-efficiëntie en waar het crawlen heen gaat

Over crawl-efficiëntie valt alleen te praten met bewijs, en de logboeken zijn dat bewijs. Elk antwoord wordt ingedeeld naar wat het betekent. Geslaagd, niet gewijzigd (304 is geen verspilling), omleidingen, 404 en 410, snelheidsbeperking, serverfouten. Elke klasse is een aandeel van de verzoeken van de bot, met de adressen erbij.

Op een grote site zit de verrassing meestal hier. Parameters in adressen, patronen van lijsten en archieven en oude omleidingen kunnen een groot deel van het crawlen opslokken. Het hulpmiddel groepeert ze per patroon en toont het aandeel, het aantal verzoeken en het aantal unieke adressen. Het merkt ze aan als mogelijke inefficiënties, niet als bevestigde problemen. Het oordeel blijft bij u.

Logboeken naast een crawl leggen

Gebruikt u ook DiagnoSEO Website Audit, kies dan een gecrawld project. De analyser legt dan beide gegevensbronnen naast elkaar. Uit die vergelijking komen twee lijsten, en allebei zijn ze nuttig.

Adressen die de bot opvroeg en die de crawl niet ontdekte, zijn mogelijk verweesde adressen, meer niet. Het hulpmiddel deelt ze in waarschijnlijke categorieën in, zoals parameters of oude omleidingen. De conclusie is aan u. Adressen die de crawl vond maar de bot niet opvroeg, staan als niet gezien in deze periode. Een kort logvenster zegt niets over het negeren van een pagina.

Deze functie is optioneel. Zonder geïnstalleerde Website Audit verschijnt het keuzeveld eenvoudigweg niet en werkt de logboekanalyse precies hetzelfde.

Waar u uw toegangslogboeken vindt

De meeste hostingpanelen bieden ze aan onder een naam als «raw access logs». Op een server die u zelf beheert, schrijft Apache standaard naar /var/log/apache2/access.log en Nginx naar /var/log/nginx/access.log.

De opmaak moet de gebruikelijke combined-indeling zijn, en dat is precies wat beide standaard schrijven. Cloudflare, een CDN of een load balancer vóór uw oorspronkelijke server verandert wat die te zien krijgt. Haal de logboeken op bij de laag die de crawler werkelijk antwoordt.

Wat er met het bestand gebeurt

De verwerking gebeurt op de server, in het geheugen. Het logboek zelf wordt niet naar schijf of naar een database geschreven. Er is geen project om op te slaan en geen geschiedenis. Het enige wat bewaard blijft, is een kortstondige cache met de uitkomsten van de IP-controle. Die bevat geen adressen, clientkenmerken of verzoekgegevens.

Bestanden boven 12 MB worden afgekapt tot de eerste 12 MB. Op een middelgrote site is dat meestal enkele dagen verkeer. Wordt het uploaden meteen geweigerd, dan beperkt de post_max_size van uw server u en niet het hulpmiddel.

Log File Analyzer vergeleken met andere hulpmiddelen

Logboekanalyse is doorgaans een oefening in een rekenblad of een module diep weggestopt in een duur platform. Hier is het één pagina die een bestand leest en u de tabellen teruggeeft. De vermelding «hangt ervan af» betekent dat de mogelijkheid in sommige hulpmiddelen of in hogere pakketten bestaat.

Veelgestelde vragen

• Welke logboekindeling wordt geaccepteerd?

  De gebruikelijke combined-indeling die Apache en Nginx standaard schrijven. Elke regel heeft een IP-adres, een tijdstempel, het verzoek, een statuscode en een aanduiding van de client nodig. Onleesbare regels worden overgeslagen en geteld, zodat u ziet of het bestand is begrepen.

• Wordt er iets bewaard?

  Nee. De verwerking gebeurt op de server in het geheugen en het resultaat gaat terug naar uw browser. Er wordt niets naar schijf of naar een database geschreven, en er is geen geschiedenis omdat het hulpmiddel geen toestand bijhoudt.

• Hoe groot mag het bestand zijn?

  Tot 12 MB per keer en tot 300 000 regels. Grotere bestanden worden afgekapt in plaats van geweigerd. Mislukt het uploaden al voordat het hulpmiddel iets ziet, dan is de post_max_size van uw server de grens die u moet verhogen.

• Hoe weet ik of de bots echt zijn?

  Bots worden herkend aan de aanduiding van de client, en die kan iedereen vervalsen. Beschouw de cijfers als een sterke aanwijzing, niet als bewijs. Toont één bot ongeloofwaardige aantallen, controleer dan een steekproef van die IP-adressen met een omgekeerde DNS-opzoeking voordat u erop reageert.

• Waarom staan er helemaal geen bots in mijn logboek?

  Meestal komen de logboeken uit de verkeerde laag. Staat Cloudflare of een CDN vóór uw oorspronkelijke server, dan beantwoordt die laag de meeste verzoeken zelf en ziet de oorsprong ze nooit. Haal de logboeken dan aan de rand op.

• Heb ik Website Audit er ook bij nodig?

  Nee. De logboekanalyse is op zichzelf volledig. Website Audit voegt alleen de vergelijking toe, die de logboeken naast een crawl legt en mogelijk verweesde adressen opsomt, evenals adressen die in de logperiode niet zijn gezien.

• Welk pakket heb ik nodig?

  Logboekanalyse is beschikbaar vanaf het Pro-pakket. Open het hulpmiddel om de huidige stand van uw account te zien.

• Hoe vaak moet ik hiernaar kijken?

  Bij een stabiele site is eens per maand genoeg. Kijk eerder na een migratie, een herontwerp of een plotselinge verkeersdaling, want het logboek toont de reactie van de crawler voordat de posities die weerspiegelen.

Posities vertellen de uitkomst. Logboeken vertellen het gedrag dat die uitkomst opleverde. Upload een logbestand en zie wat de crawlers hebben gedaan.