Internal Link Analyzer

Probleem

Op een site van honderden pagina's zie je met het blote oog niet welke pagina's nergens vandaan gelinkt worden en waar alle interne waarde naartoe stroomt. Interne links met de hand leggen is bovendien nooit af: elke nieuwe pagina verandert het plaatje weer.

Diagnose

Het rekenwerk is mechanisch: een linkgraaf bouwen en per pagina uitrekenen hoeveel links er binnenkomen, hoe diep hij weggeklikt zit, hoeveel waarde er naartoe stroomt en of hij helemaal losstaat. Het oordeel is dat niet. Of een link ergens inhoudelijk thuishoort, en met welke woorden, is precies het stuk waar een model plausibele onzin oplevert. Dus rekent de machine, en beslist een mens.

Aanpak

1. De site crawlen vanaf de sitemap en de homepage, met één verzoek per seconde en een contactadres in de user-agent.
2. Een linkgraaf bouwen en per pagina vier dingen uitrekenen: inkomende links, klikdiepte, doorstromende waarde, en of de pagina losstaat.
3. Met een lokaal model inhoudelijk passende bronpagina's zoeken, en als ankertekst een woordgroep kiezen die al in die pagina staat.
4. Elk voorstel in de browser beoordelen, en alleen het goedgekeurde deel terugschrijven, met een kopie van het originele blok zodat een hele run terug te draaien is.

Afwegingen

• Het opslagformulier nabootsen, niet de browser aansturen

  Een browser aansturen kost hier seconden per pagina alleen al om het bewerkscherm te laten opstarten, en breekt zodra een beheerscherm verandert. Het opslagformulier bleek gewoon na te bootsen. De prijs is dat je alle tweeënnegentig velden moet meesturen: laat je er één weg, dan leest het CMS dat als "de gebruiker heeft dit veld leeggemaakt". Dus lezen, één veld wijzigen, en het complete formulier terugsturen. In de paginagenerator koos ik precies andersom, en terecht: daar wordt één pagina per keer aangemaakt via een importscherm, en doet de server bij het opslaan dingen die je niet kunt nabootsen. Hier gaat het om duizenden kleine wijzigingen, en dan weegt snelheid zwaarder.

• Twee filters tegen bijna identieke pagina's

  Het model stelde links voor tussen stadspagina's die op elkaar lijken als twee druppels water. Een filter op inhoudelijke gelijkenis loste dat maar half op, want één familie pagina's zat net onder de drempel. Er kwam een tweede filter bij dat puur naar de vorm van de URL kijkt. Twee simpele filters vangen hier meer dan één slimme.

• Weespagina's opgesplitst in twee eerlijke getallen

  De tool markeerde een groot deel van de site als weespagina, terwijl veel van die pagina's simpelweg nog niet gecrawld waren omdat de crawl bij een limiet stopte. Eén getal dat twee dingen door elkaar haalt, is erger dan geen getal. Nu staan "geen inkomende links gevonden" en "nog niet gecrawld" apart.

• Terug naar een lokaal model, na een blinde vergelijking

  De tool is drie keer van model gewisseld. Een gratis clouddienst bleek te klein voor een hele site, daarna draaide het op een cloudmodel omdat mijn laptop te weinig geheugen had. Toen dat geheugen er wel was, heb ik lokaal en cloud blind naast elkaar gelegd op echte Nederlandse alinea's, en won het lokale model. Sindsdien draait het lokaal: geen kosten per run, en geen klantteksten die de deur uitgaan.

Status en resultaat

De lees- en denkkant draait op echte sites: crawlen, analyseren en voorstellen doen werkt. Het daadwerkelijk terugschrijven naar een live site en de knop om een hele run ongedaan te maken staan nog open. De tests zitten waar het eng is, op de suggestiemotor en de koppeling met het CMS. En de keuze tussen het formulier nabootsen en toch een browser aansturen is nog niet definitief dicht: een echte browser zou doorverwijzende URL's vanzelf volgen, en dat punt ligt nog open.