TL;DR: Als je site minder dan 10.000 pagina's heeft, is crawl budget vrijwel zeker niet je probleem. Stop met optimaliseren. Maar als je een webshop runt met 500K productpagina's, een advertentiesite met oneindige URL-parameters, of iets met gefacetteerde navigatie — dan sloopt crawl budget stilletjes je indexering. Deze gids behandelt hoe je vaststelt of je daadwerkelijk een crawl budget probleem hebt, en hoe je het oplost als dat zo is. Het antwoord is meestal saai: snellere servers, schonere URL's, betere robots.txt.
Je werkelijke crawl budget is de kleinste van deze twee. Als Google vandaag echt 50.000 van je pagina's wil crawlen (hoge vraag), maar je server maar 5.000 verzoeken aankan zonder te vertragen (lage rate limit), krijg je 5.000. Als je server 100.000 verzoeken aankan maar Google maar 2.000 van je pagina's interessant vindt (lage vraag), krijg je 2.000.
Dit is het deel waar de meeste gidsen de fout in gaan. Ze behandelen crawl budget als een vast budget dat je moet "sparen" door onbelangrijke pagina's te blokkeren. In werkelijkheid is het dynamisch, verandert het dagelijks, en voor de meeste sites is het helemaal niet de bottleneck.
Ik moet dit duidelijk zeggen, want ik heb bureaus crawl budget optimalisatie zien verkopen aan sites met 200 pagina's.
Als je site minder dan ongeveer 10.000 unieke URL's heeft, is crawl budget optimalisatie vrijwel zeker verspilde moeite.
Gary Illyes heeft dit zelf meerdere malen gezegd, onder meer op Google I/O en op Twitter. Zijn exacte formulering: "If your site has a few thousand URLs, most of the time it will be crawled efficiently." Martin Splitt, Google's Developer Advocate, bevestigde dit in een JavaScript SEO office hours-aflevering toen hij zei dat crawl budget pas echt een zorg wordt "once you get into the tens of thousands of pages or more."
Google crawlt miljarden pagina's per dag. Je WordPress-blog met 500 pagina's is een afrondingsfout. Google crawlt alles binnen een paar dagen na elke wijziging, zonder dat je iets speciaals hoeft te doen.
Waar crawl budget wél uitmaakt:
Als geen van deze op jou van toepassing is, scroll dan naar de FAQ-sectie onderaan en ga verder met je leven. Ik meen het. Besteed je tijd aan contentkwaliteit en interne linkbuilding. Ik denk nog steeds dat 90% van de mensen die aan "crawl budget optimalisatie" doen dit moeten horen: je probleem zit waarschijnlijk ergens heel anders.
2. Controleer je indexeringsgat. Vergelijk het aantal pagina's in je sitemap met het aantal geïndexeerde pagina's in het "Pagina's"-rapport van GSC. Als je 100.000 URL's in je sitemap hebt maar slechts 40.000 geïndexeerd, dan slokt iets je crawl budget op voordat het bij de pagina's komt die ertoe doen.
3. Bekijk je serverlogs. Dit is de echte diagnose. GSC geeft je geaggregeerde data. Serverlogs geven je de waarheid — elk verzoek dat Googlebot heeft gedaan, wanneer, naar welke URL, en welk antwoord het kreeg. Als je ziet dat Googlebot 60% van zijn crawl besteedt aan gepagineerde archiefpagina's of gefilterde URL's, dan is dat je probleem, zwart op wit.
Ik wil hier eerlijk zijn over een beperking: ik ben er niet van overtuigd dat het GSC crawl stats-rapport altijd accuraat is. We hebben discrepanties gezien tussen wat GSC rapporteert en wat de serverlogs van onze klanten laten zien. Soms aanzienlijke discrepanties — 30-40% verschil. Ik weet niet of dat een steekproefprobleem is aan Google's kant, een caching-artefact, of iets anders. Dus ik raad altijd aan om te verifiëren met serverlogs als er veel op het spel staat.
| Diagnostisch signaal | Gezond | Waarschuwing | Kritiek |
|---|---|---|---|
| Nieuwe pagina geïndexeerd binnen | 1-3 dagen | 1-2 weken | 4+ weken of nooit |
| GSC crawlverzoeken/dag vs totaal pagina's | > 50% van pagina's gecrawld per week | 10-50% per week | < 10% per week |
| Gemiddelde serverresponstijd | < 200ms | 200-500ms | > 500ms |
| % van crawl op niet-indexeerbare URL's | < 10% | 10-30% | > 30% |
| Redirect chains in crawl | Geen | < 5% van verzoeken | > 5% raakt chains |
| 5xx error rate tijdens crawl | 0% | < 1% | > 1% |
Let op: deze drempelwaarden zijn ervaringsrichtlijnen gebaseerd op patronen uit SEOJuice-klantdata, niet officiële cijfers van Google. Je resultaten kunnen variëren afhankelijk van sitegrootte, niche en serverarchitectuur.
Als de meeste van je signalen in de kolom "Gezond" vallen, heb je geen crawl budget probleem. Ga iets anders optimaliseren.
Dit is de crawl budget factor met de meeste impact en de minste aandacht. Iedereen wil het hebben over robots.txt en sitemaps. Niemand wil het hebben over waarom hun server 1,2 seconden nodig heeft om op een simpel HTML-verzoek te reageren.
Googlebot is beleefd. Het monitort de responstijd van je server in realtime. Als je server begint te vertragen, verlaagt Googlebot zijn crawlsnelheid om je niet te overbelasten. Dit is de crawl rate limit in actie. Een server die in 100ms reageert, wordt aanzienlijk vaker gecrawld dan een die 800ms nodig heeft.
"If the site is really fast, Googlebot will be able to use more connections and crawl the site faster. If the site slows down or responds with server errors, it will slow down and crawl less."
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
Dat is een direct citaat uit de officiële crawl budget blogpost. "Really fast" betekent voor Google een TTFB (time to first byte) onder de 200ms. Niet de laadtijd van de pagina — TTFB. De tijd die je server nodig heeft om het HTML-antwoord te beginnen verzenden.
Quick wins voor serverresponstijd:
Op de site van een SEOJuice-klant (een meubelwebshop, ongeveer 80K productpagina's) zagen we hun crawl rate in GSC dalen van 15.000 verzoeken/dag naar 3.000 in twee weken. Geen wijzigingen aan content of structuur. De oorzaak? Hun hostingprovider migreerde ze naar een nieuw servercluster en TTFB ging van 180ms naar 900ms. Zodra ze de hosting repareerden, herstelde de crawl rate binnen vier dagen. Geen robots.txt wijzigingen. Geen sitemap updates. Gewoon snellere servers.
URL-parameters zijn de meest voorkomende bron van crawlverspilling. En het probleem is verraderlijk omdat je vaak niet weet dat het gebeurt.
Neem een webshop met filtermogelijkheden. Een gebruiker bladert door schoenen en selecteert: maat 42, kleur zwart, merk Nike, gesorteerd op prijs, pagina 2. Dat is een URL als:
/shoes?size=10&color=black&brand=nike&sort=price&page=2Vermenigvuldig dat nu met elke mogelijke combinatie. 8 maten, 12 kleuren, 40 merken, 4 sorteeropties, 50 resultatenpagina's. Dat is 8 x 12 x 40 x 4 x 50 = 768.000 URL's. Van één categoriepagina. En de content op de meeste van die pagina's overlapt aanzienlijk — maat 42 zwarte Nike-schoenen gesorteerd op prijs zijn grotendeels dezelfde producten als maat 42 zwarte Nike-schoenen gesorteerd op nieuwste.
Googlebot weet dat niet. Het ziet 768.000 unieke URL's en begint ze te crawlen. Je eigenlijke productpagina's — de pagina's die moeten ranken — staan in de wachtrij achter honderdduizenden gefilterde variaties waar nooit iemand naar zoekt.
Dit is wat mensen bedoelen met "gefacetteerde navigatie creëert crawl traps." Het is niet dat Google vastloopt in een oneindige lus (hoewel dat kan gebeuren bij bepaalde paginering-setups). Het is dat Google zijn beperkte crawl budget toewijst aan URL's die geen unieke waarde bieden.
Ik wil hier precies zijn over iets: de URL-parameter tool in Google Search Console is in 2022 afgeschaft en verwijderd. Google liet je ooit aangeven welke parameters genegeerd moesten worden. Die optie is weg. Je hebt nu drie tools om dit aan te pakken:
Elk heeft trade-offs. Ik behandel robots.txt en canonicals in hun eigen secties hieronder.
Je robots.txt is het eerste bestand dat Googlebot controleert voordat het je site crawlt. Het is ook het meest verkeerd begrepen bestand in SEO. Mensen laten het leeg (gemiste kans) of overdrijven (blokkeren wat ze niet moeten blokkeren).
Het kernprincipe: blokkeer dingen die crawl budget verspillen, niet dingen die "onbelangrijk" zijn. Er is een verschil. Een "onbelangrijke" pagina moet misschien nog steeds geïndexeerd worden. Een pagina die crawl budget verspilt is er een die geen unieke waarde biedt voor zoekmachines en in duizenden parametervariaties bestaat.
# Blokkeer gefacetteerde navigatie-parameters
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Blokkeer interne zoekresultaten
Disallow: /search?
Disallow: /search/
# Blokkeer sessie-gebaseerde URL's
Disallow: /*?sessionid=
Disallow: /*?ref=
# Blokkeer admin-, winkelwagen- en accountpagina's
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Blokkeer print- en PDF-versies
Disallow: /*?print=
Disallow: /*?format=pdf
# Blokkeer GEEN CSS, JS of afbeeldingen
# Googlebot heeft deze nodig om je pagina's te renderen
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlKritieke fouten die ik heb gezien:
/products/ omdat ze /products?filter= willen blokkeren en deïndexeert per ongeluk hun hele catalogus.Dat laatste punt is het herhalen waard omdat het zelfs ervaren SEO's in de war brengt. Robots.txt blokkeert crawlen. Het blokkeert geen indexering. Als je indexering wilt voorkomen, gebruik dan <meta name="robots" content="noindex"> of een X-Robots-Tag HTTP-header. Maar onthoud: om een noindex-tag te zien, moet Google de pagina eerst crawlen. Dus als je crawlen blokkeert met robots.txt EN noindex toevoegt, ziet Google de noindex-tag nooit. Dit creëert een paradox die mensen al jaren in verwarring brengt.
Een sitemap garandeert geen indexering. Het garandeert zelfs geen crawl. Wat het doet is Google een hint geven over welke URL's bestaan, wanneer ze voor het laatst zijn gewijzigd, en (betwistbaar) hoe belangrijk ze zijn ten opzichte van elkaar.
De fouten die mensen met sitemaps maken gaan bijna altijd over te veel opnemen, niet te weinig.
Wat in je sitemap hoort:
<lastmod>-datums — niet de datum van vandaag, niet dezelfde datum op elke pagina, maar de werkelijke laatste wijzigingsdatumWat niet in je sitemap hoort:
Ik heb sitemaps gezien met 500.000 URL's waarvan er slechts 80.000 daadwerkelijk indexeerbaar waren. De andere 420.000 waren redirects, noindex-pagina's, parametervariaties en kapotte URL's. Die sitemap helpt Google niet — het stuurt Google op een speurtocht waar 84% van de schatkaart fout is.
Martin Splitt heeft <lastmod> "one of the most abused tags in sitemaps" genoemd, omdat zoveel CMS-platformen het op de huidige datum zetten bij elke pagina. Wanneer elke pagina zegt "ik ben zojuist gewijzigd," leert Google het signaal volledig te negeren. Als je CMS geen echte wijzigingsdata bijhoudt, los dat dan op voordat je je druk maakt over wat dan ook met betrekking tot sitemaps.
Ik geef gefacetteerde navigatie een eigen sectie omdat het het snijvlak is van crawl budget, duplicate content en technische architectuur — en het fout doen kan de SEO van een site stilletjes maandenlang ondermijnen.
Het probleem: gefacetteerde navigatie (filters op webshops, advertentiesites, vacaturebanken) genereert exponentiële URL-combinaties. We hebben het rekenwerk hierboven behandeld. Maar de oplossing is niet zo simpel als "blokkeer alles met robots.txt" omdat sommige gefacetteerde pagina's echte zoekwaarde hebben.
Denk er eens over na: "Nike hardloopschoenen maat 42" is een echte zoekopdracht die een echt persoon in Google typt. Een gefacetteerde pagina die daarmee overeenkomt zou ervoor kunnen ranken. Alle gefacetteerde URL's blokkeren betekent dat je die kans verliest.
Het framework dat ik aanbeveel (en dat we implementeren voor SEOJuice-klanten met dit probleem):
| Facettype | Voorbeeld | Zoekwaarde | Aanbevolen aanpak |
|---|---|---|---|
| Categorie + Merk | /shoes/nike/ | Hoog — mensen zoeken op merk+categorie | Indexeren, opnemen in sitemap, schone URL gebruiken |
| Categorie + 1 filter | /shoes?color=black | Gemiddeld — hangt af van zoekvolume | Controleer zoekvolume. Indexeer bij >100 maandelijkse zoekopdrachten, anders canonical naar parent |
| Categorie + 2+ filters | /shoes?color=black&size=10 | Laag — te specifiek voor de meeste zoekopdrachten | Canonical naar het meest relevante enkele filter of de parentcategorie |
| Sorteervariaties | /shoes?sort=price-asc | Geen — niemand zoekt naar "schoenen gesorteerd op prijs" | Blokkeer met robots.txt of noindex |
| Diepe paginering | /shoes?page=47 | Geen na pagina 2-3 | Noindex na pagina 3-5, houd crawlbaar |
| Sessie-/trackingparameters | /shoes?utm_source=email | Geen | Blokkeer met robots.txt, strip op serverniveau |
De canonical tag-implementatie voor multi-filterpagina's ziet er zo uit:
<!-- Op /shoes?color=black&size=10&sort=price -->
<link rel="canonical" href="https://example.com/shoes?color=black" />
<!-- Op /shoes?sort=price -->
<link rel="canonical" href="https://example.com/shoes" />
<!-- Op /shoes (de schone categoriepagina) -->
<link rel="canonical" href="https://example.com/shoes" />Een fout die ik heb gemaakt en nog niet volledig heb opgelost: wat je moet doen met gefacetteerde pagina's die backlinks hebben verzameld. Een klant had duizenden externe links naar gefilterde URL's. Canonicaliseren naar de parentpagina zou de equity naar boven moeten laten stromen — klinkt prima in theorie.
In de praktijk zagen we een daling van 15% in de rankings van de parentpagina na het implementeren van canonicals. Ik weet nog steeds niet precies waarom. Mijn beste gok is dat de plotselinge consolidatie van duizenden signalen Google's evaluatie in de war bracht, maar dat is speculatie. We hebben de canonicals teruggedraaid op de meest gelinkte gefilterde pagina's en ze indexeerbaar gelaten. Het is een compromis waar ik niet helemaal tevreden mee ben.
Korte versie: rel="next" en rel="prev" zijn verouderd. Google bevestigde in 2019 dat ze het signaal al jarenlang niet meer gebruikten. Dus wat doe je in plaats daarvan?
Drie opties, gerangschikt naar mijn voorkeur:
Optie 1: Load-more of infinite scroll met pushState. Dit is de schoonste aanpak voor nieuwe sites. Gebruikers zien één URL. Google crawlt de volledige content. Geen paginering-URL's die crawl budget verspillen. Maar het vereist JavaScript, wat zijn eigen crawl budget-kosten met zich meebrengt (meer hierover verderop).
Optie 2: Traditionele paginering met noindex op pagina 2+. Houd de gepagineerde URL's crawlbaar (zodat Google de producten/artikelen kan ontdekken die erop gelinkt staan) maar noindex ze zodat Google niet probeert identieke templatepagina's te indexeren. De canonical op elke gepagineerde pagina moet zelf-refererend zijn — maak niet alle pagina's canonical naar pagina 1, want de content is anders.
Optie 3: Alles-op-één-pagina. Als je gepagineerde content in totaal minder dan ~200 items bevat, overweeg dan één pagina met alles erop die de gepagineerde serie canonicaliseert. Google heeft historisch de voorkeur gegeven aan zulke pagina's. Het nadeel: laadtijd. Als je alles-op-één-pagina 8 seconden nodig heeft om te laden, doet het meer kwaad dan goed.
<!-- Pagina 2 van blogarchieven -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Belangrijk: gebruik "noindex, follow" — niet "noindex, nofollow"
Je wilt dat Google de links op gepagineerde pagina's volgt
om de daadwerkelijke contentpagina's te ontdekken -->Let op de follow-instructie. Dit is cruciaal. Je wilt de gepagineerde pagina niet in de index, maar je wilt absoluut dat Google de links erop volgt om je werkelijke content te vinden. nofollow hier gebruiken zou elk artikel of product verwezen maken dat alleen gelinkt is vanaf pagina 2+ van je archief.
Deze sectie is relevant voor iedereen met een JavaScript-heavy site (React, Vue, Angular, Next.js zonder goede SSR). Als je site traditioneel server-rendered HTML is, sla dit dan over.
Google crawlt in twee golven. Eerste golf: het downloadt en verwerkt de ruwe HTML. Tweede golf: het rendert de pagina met een headless Chromium-browser om JavaScript uit te voeren en de uiteindelijke content te zien. De tweede golf komt later — soms uren later, soms dagen.
Martin Splitt heeft dit uitgebreid uitgelegd in zijn JavaScript SEO office hours. Het kernpunt: renderen is duur voor Google. Het kost meer resources dan een simpele HTML-fetch. Google moet een Chromium-instantie opstarten, je JavaScript uitvoeren, wachten tot API-calls zijn opgelost, en dan de gerenderde DOM verwerken. Dit betekent dat JavaScript-afhankelijke pagina's minder efficiënt gecrawld worden dan server-rendered pagina's.
De impact op crawl budget:
De oplossing: server-side rendering (SSR) of static generation (SSG). Next.js, Nuxt, SvelteKit ondersteunen dit allemaal. Als je geen volledige SSR kunt doen, gebruik dan dynamic rendering: serveer pre-rendered HTML aan Googlebot en de volledige JS-ervaring aan gebruikers. Google ontmoedigt het technisch gezien, maar begin 2026 werkt het in de praktijk. We hebben de SPA-specifieke uitdagingen behandeld in onze gids over SPA SEO best practices.
Waar je op moet letten in je logs:
Tooling: Screaming Frog Log Analyzer is de populairste dedicated tool. Je kunt logs ook parsen met command-line tools (grep voor de Googlebot user agent, pipe door awk). Voor doorlopende monitoring verwerkt SEOJuice's crawler analytics-functie serverlogs automatisch en signaleert crawl budget-problemen.
Een echt voorbeeld uit onze data: een klant had een WordPress-site met ~25.000 gepubliceerde berichten. Goede content, behoorlijk verkeer. Maar hun serverlogs lieten zien dat Googlebot 40% van zijn crawl budget besteedde aan /wp-json/ API-endpoints en /feed/-URL's. Dat zijn geen pagina's waar iemand naar zoekt. Twee regels toevoegen aan robots.txt maakte die 40% vrij voor daadwerkelijke contentpagina's. Binnen drie weken steeg hun crawl rate op artikelpagina's met 60%, en ze zagen 12 nieuwe pagina's geïndexeerd worden die al maanden in het "Discovered — currently not indexed"-vagevuur zaten.
# WordPress-specifieke crawl budget besparingen
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/Interne links zijn het sterkste signaal dat je in eigen hand hebt om Google te vertellen welke pagina's belangrijk zijn. Niet meta tags. Niet sitemap priority-waarden (die Google toch negeert). Interne links.
Elke link is een stem. Een pagina die gelinkt is vanaf je homepage, je navigatie en 50 andere pagina's wordt vaker gecrawld dan een pagina die gelinkt is vanaf één archiefpagina drie klikken diep. Dit is simpele PageRank-distributie, en het is hoe Googlebot beslist waar het zijn crawl budget aan besteedt.
De praktische implicatie: als pagina's niet geïndexeerd worden en ze 3+ klikken van je homepage verwijderd zijn, vergroot het toevoegen van interne links vanuit goed verbonden pagina's hun crawlfrequentie. We hebben dit consistent gezien — pagina's die van 0-1 interne links naar 5+ gaan, krijgen hun eerste Googlebot-bezoek binnen 48 uur, zelfs op grote sites waar nieuwe pagina's normaal weken wachten.
Dit is waarom we automatische interne linkbuilding in SEOJuice hebben ingebouwd. Handmatig interne links beheren over 10.000+ pagina's is onmogelijk. Maar het crawl-prioriteitsvoordeel maakt het een van de technische SEO-activiteiten met de hoogste ROI.
Platte architectuur (elke pagina bereikbaar in 3 klikken of minder) is beter voor crawl budget dan diepe hiërarchieën. Maar "plat" betekent niet "link alles naar alles." Het betekent strategische linkbuilding — topic clusters, hubpagina's, contextuele links — die duidelijke crawl-paden creëert naar je belangrijkste pagina's.
Ik wil specifiek zijn over wat we daadwerkelijk doen, in plaats van vage marketingtaal.
SEOJuice volgt crawlgedrag via drie inputs: GSC crawl stats (via de Search Console API), onze eigen crawldata (we crawlen klantsites om de interne linkgrafiek op te bouwen), en optioneel, serverlog-integratie.
Wat we in beeld brengen:
We doen nog geen volledige logbestandanalyse in het product (het parsen van willekeurige serverlogformaten op schaal is een technische uitdaging die ik nog niet naar tevredenheid heb opgelost). Maar GSC-data plus onze eigen crawler geeft de meeste sites genoeg om crawl budget-problemen te identificeren en op te lossen zonder een logbestand aan te raken.
Als je tot hier gelezen hebt en vastgesteld hebt dat je daadwerkelijk een crawl budget probleem hebt, is dit wat je moet repareren, op volgorde van impact:
Stappen 1-3 lossen het probleem op voor de meerderheid van sites die daadwerkelijk crawl budget optimalisatie nodig hebben. Stappen 4-9 zijn voor de rest — sites met complexe architecturen waar de basis niet genoeg is.
Nee. Crawl budget beïnvloedt of je pagina's gecrawld en geïndexeerd worden, niet hoe ze ranken zodra ze geïndexeerd zijn. Maar een pagina die nooit gecrawld wordt, wordt nooit geïndexeerd, en een pagina die nooit geïndexeerd wordt kan niet ranken. Crawl budget is dus een voorwaarde, geen rankingfactor. Het optimaliseren ervan verbetert geen rankings voor al geïndexeerde pagina's — het helpt pagina's die helemaal niet geïndexeerd worden.
Bijna nooit. De crawl rate-instellingen in GSC laten je Googlebot's crawlsnelheid verlagen, niet verhogen. De enige reden om dit te gebruiken is als Googlebot je server letterlijk overbelast. Als je server het verkeer aankan, laat het met rust. Ik heb mensen het zien verlagen in de veronderstelling dat het Google zou "focussen" op belangrijke pagina's. Zo werkt het niet — Google crawlt gewoon minder van alles.
Populaire, frequent bijgewerkte pagina's: meerdere keren per dag. Statische pagina's die al maanden niet gewijzigd zijn: elke paar weken. Het gemiddelde is ruwweg elke 1-2 weken per pagina, maar varieert enorm. Nieuwssites worden binnen minuten gecrawld. Een zelden bijgewerkte "Over ons"-pagina kan een maand tussen bezoeken zitten. De <lastmod>-tag kan hinten dat een pagina is gewijzigd, maar alleen als je hem accuraat gebruikt — Google negeert hem als hij altijd op de datum van vandaag staat.
Je kunt je crawl rate limit verhogen (snellere server) en crawlverspilling verminderen (zodat meer budget naar belangrijke pagina's gaat). Maar je kunt Google niet direct vertellen je vaker te crawlen. Crawl demand is Google's beslissing op basis van waargenomen contentwaarde. De beste indirecte aanpak: publiceer regelmatig, bouw backlinks, maak content die oprecht nuttig is. Waardevolle sites worden automatisch agressiever gecrawld.
Ja. Google crawlt de pagina nog steeds om de noindex-tag te zien. 100.000 noindex-pagina's betekent 100.000 crawl budget-hits (zij het minder frequent dan geïndexeerde pagina's). Als die pagina's echt nooit geïndexeerd hoeven te worden, is robots.txt crawl-efficiënter — maar robots.txt-blokkades voorkomen dat Google iets op de pagina ziet, inclusief links. Gebruik noindex+follow wanneer je linkontdekking wilt maar geen indexering. Gebruik robots.txt wanneer je niet wilt dat de pagina überhaupt gecrawld wordt.
Dit artikel maakt deel uit van onze technische SEO-serie. Als je bezig bent met crawl budget-problemen, helpen deze gerelateerde gidsen verder:
Als je een grote site runt en geautomatiseerde crawl budget monitoring wilt, volgt SEOJuice crawlverspilling, indexeersnelheid en serverresponstijd over al je pagina's. Het vervangt geen logbestandanalyse voor complexe architecturen, maar het brengt de meerderheid van crawl budget-problemen die ertoe doen in beeld — continu, niet alleen wanneer iemand eraan denkt een audit uit te voeren. Start een gratis proefperiode en zie binnen minuten waar je crawl budget naartoe gaat.
no credit card required
No related articles found.