De 10 Screaming Frog-rapporten die ik altijd eerst open

Een verse crawl van tienduizend URL’s is niet bruikbaar. Het is data, geen inzicht. De vaardigheid zit in weten waar je als eerste kijkt, zodat je binnen een uur weet of er iets ernstigs aan de hand is.

Dit is de volgorde die ik aanhoud. Van hard naar zacht: eerst wat de site kapot maakt, dan wat hem verzwakt, dan wat hem beter kan maken. Als je de eerste vier overslaat en begint bij ontbrekende meta descriptions, doe je het in de verkeerde volgorde.

Wie nog nooit een crawl heeft gedraaid, kan het beste eerst de basis van Screaming Frog doornemen. Hieronder ga ik ervan uit dat de crawl draait.

1. Response Codes: Client Error (4xx)

Kapotte links. Interne 4xx-links kosten je crawlbudget, breken de gebruikerservaring en laten interne autoriteit weglekken. Gebruik het tabblad Inlinks onderin om te zien vanaf welke pagina’s naar die 404 wordt gelinkt. Dat is je fixlijst, niet de 404 zelf.

2. Response Codes: Server Error (5xx)

Zelden veel, altijd urgent. Serverfouten tijdens een crawl betekenen ofwel echt kapotte pagina’s, ofwel een server die het crawlen niet aankan. Beide moet je weten. In het tweede geval verlaag je je crawlsnelheid en draai je opnieuw, want anders is je hele dataset onbetrouwbaar.

3. Response Codes: Redirection (3xx)

Ik kijk hier vooral naar interne links die naar een redirect wijzen. Elke interne link hoort direct naar de eindbestemming te gaan. Draai daarna het rapport Redirects: All Redirects met “Always Follow Redirects” aan, en zoek naar ketens van drie of meer hops. Die kosten crawlbudget en verwateren signalen. Ketens ontstaan sluipenderwijs na elke migratie.

4. Directives: Noindex

Het rapport waar ik de meeste echte rampen heb gevonden. Filter op noindex en loop de lijst regel voor regel na. Elke URL hier moet er bewust staan. Een noindex die per ongeluk op een categoriesjabloon staat, kan honderden pagina’s uit de index halen zonder dat iemand het merkt. Combineer dit direct met het rapport Blocked by Robots.txt: dezelfde vraag, ander mechanisme.

5. Canonicals: Canonicalised

Hier zie je pagina’s die naar een andere URL canonicaliseren. Dat is prima als het bedoeld is, en schadelijk als het niet zo is. Waar ik specifiek naar zoek: canonicals die naar de homepage wijzen, canonicals naar een redirect, en canonicals naar een pagina die zelf noindex is. Alle drie komen vaker voor dan je zou willen, en alle drie kosten indexatie.

6. Pagetitles: Missing, Duplicate en Over 60 Characters

Nu pas beginnen we aan on-page. Missing en Duplicate zijn de belangrijke twee. Grote aantallen duplicate titles wijzen bijna altijd op een sjabloonprobleem of op parameter-URL’s die gecrawld worden. De lengtefilters zijn secundair; een afgekapte titel is jammer, een dubbele titel is een structuurfout.

7. Internal: HTML gesorteerd op Crawl Depth

Dit rapport wordt het vaakst overgeslagen en levert het meeste strategische inzicht. Sorteer je HTML-pagina’s op crawldiepte en kijk wat er op vier klikken of dieper zit. Staan daar pagina’s die commercieel belangrijk zijn, dan heb je een structuurprobleem: je site vertelt zoekmachines dat die pagina’s er niet toe doen. Vergelijk die diepe lijst met de omzetpagina’s uit je analytics. De overlap is je werklijst voor interne links.

8. Orphan Pages

Pagina’s die in je sitemap of analytics staan maar waar geen enkele interne link naartoe gaat. Hiervoor moet je de crawl koppelen aan Search Console en Google Analytics, en je sitemap laten meecrawlen. Weespagina’s zijn een klassiek migratieresidu: de pagina leeft nog, de navigatie is eromheen verbouwd.

9. Images: Missing Alt Text

Snel af te vinken en het is niet alleen toegankelijkheid. Alt-teksten geven zoekmachines en AI-systemen context over wat er op de pagina staat. Ik kijk hierbij ook naar Images over 100kb: zware afbeeldingen zijn nog altijd een van de vaakst voorkomende oorzaken van trage pagina’s.

10. Structured Data: Validation Errors

Zet in de configuratie de structured data-validatie aan voordat je crawlt. Dit rapport laat zien waar je schema markup fouten of waarschuwingen bevat. Naarmate AI-systemen meer op expliciete, machineleesbare context leunen, wordt dit belangrijker, en het is een van de weinige plekken waar je zo direct kunt zien wat er stuk is. De achtergrond staat in schema markup voor AI-zichtbaarheid.

Twee dingen die je vooraf instelt

Voordat de crawl start, zet ik altijd twee dingen goed, omdat je ze achteraf niet kunt repareren.

JavaScript rendering. Draait de site op een framework dat content client-side opbouwt, zet dan JavaScript rendering aan. Doe je dat niet, dan crawl je een lege huls en trek je conclusies over een site die niet bestaat.

API-koppelingen. Verbind Search Console, Analytics en eventueel je backlinktool voordat je begint. Crawldata alleen vertelt je wat er stuk is. Crawldata plus prestatiedata vertelt je wat er stuk is en tegelijk geld waard. Dat verschil bepaalt of je een lijst met problemen oplevert of een lijst met prioriteiten.

Van rapport naar prioriteit

Aan het eind heb je tien lijsten. Die zijn nog geen plan. Ik sorteer ze op twee assen: hoeveel omzet raakt het, en hoeveel moeite kost het.

De praktijk levert vrijwel altijd dezelfde top drie op: een indexeringsblokkade die er niet hoort, een set commercieel belangrijke pagina’s die veel te diep in de structuur zitten, en een berg redirectketens en 404’s die is blijven liggen na de laatste verbouwing. Los die drie op en je hebt meer effect dan met tweehonderd meta descriptions.

De rest is onderhoud. Belangrijk, maar niet eerst.

Wil je zo’n crawl laten draaien en de uitkomst als concrete, geprioriteerde werklijst terugkrijgen in plaats van een export? Dat is wat ik als SEO-consultant oplever.