Voor- en nadelen van het Cloudflare Crawl Endpoint bij Shopify-winkels

Wat is het Cloudflare /crawl Endpoint?

Cloudflare’s /crawl endpoint maakt deel uit van hun Browser Rendering API, momenteel in open bèta. Het scrapt content vanaf een start-URL, volgt links over de site tot een configureerbare diepte of paginalimiet, en retourneert de resultaten als HTML, Markdown of gestructureerde JSON aangedreven door Workers AI. Cloudflare positioneert het als een tool voor het trainen van modellen, het bouwen van RAG-pipelines en het onderzoeken of monitoren van content op een site.

Het endpoint functioneert als een signed-agent die standaard robots.txt en Cloudflare’s AI Crawl Control respecteert, wat een opmerkelijke ontwerpkeuze is. Het is bedoeld om het voor ontwikkelaars gemakkelijk te maken om websiteregels na te leven en het voor crawlers moeilijker te maken om richtlijnen van site-eigenaren te negeren.

Het endpoint bevindt zich op:

https://api.cloudflare.com/client/v4/accounts/<account_id>/browser-rendering/crawl

Je hebt een Cloudflare API-token nodig met Browser Rendering Edit-toestemming om het te gebruiken.

Hoe het werkt

De crawl draait als een asynchrone taak in twee stappen:

1. Start de crawl met een POST-verzoek dat een start-URL bevat. De API retourneert onmiddellijk een taak-ID.
2. Poll voor resultaten met GET-verzoeken met dat taak-ID. Wanneer de taakstatus verandert van running naar completed, zijn je gecrawlde gegevens klaar.

Taken kunnen tot zeven dagen draaien. Resultaten worden 14 dagen na voltooiing opgeslagen.

Wat je verstuurt

Minimaal stuur je een URL:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }'

Belangrijke parameters

Wat je terugkrijgt

Elke gecrawlde pagina wordt geretourneerd als een record met de URL, status, content in het gekozen formaat en basismetadata (HTTP-statuscode, paginatitel, definitieve URL na redirects). Met render: true krijg je ook Open Graph-tags. Het antwoord bevat ook browserSecondsUsed voor factureringsinzicht, en een cursor voor het pagineren van resultaten die 10 MB overschrijden.

Hier is het daadwerkelijke taakniveau-antwoord van een gerenderde crawl van 24 pagina’s van een live Shopify-winkel:

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "completed",
  "total": 24,
  "finished": 24,
  "browserSecondsUsed": 58.38,
  "record_count": 24,
  "records": [
    {
      "url": "https://www.example-store.com/products/premium-widget-bundle",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Premium Widget Bundle | Example Store",
        "url": "https://www.example-store.com/products/premium-widget-bundle",
        "lastModified": "",
        "og:type": "product",
        "og:site_name": "Example Store",
        "og:title": "Premium Widget Bundle | Example Store",
        "og:image": "https://www.example-store.com/cdn/shop/files/product-image.jpg",
        "og:description": "Our best-selling bundle with everything you need..."
      },
      "markdown": "Store\n\nexample-store\n\nURL\n\nhttps://www.example-store.com\n\nCurrency\n\nUSD\n\n# Premium Widget Bundle\n\nOur best-selling bundle with everything you need..."
    }
  ]
}

Met render: true bevat het metadata-object de volledige set Open Graph-velden: type, sitenaam, titel, afbeeldings-URL en beschrijving. Deze worden uit de OG-metatags van de pagina gehaald tijdens de browserrender. Met render: false bevat de metadata alleen de HTTP-statuscode, paginatitel en definitieve URL. Er worden geen Open Graph-velden geëxtraheerd.

Het markdown-veld bevat de volledige pagina-output, niet alleen de hoofdcontent. Navigatiemenu’s, mega-menu’s, footers en herhaalde templateblokken zijn in elk record opgenomen. In onze tests retourneerde de gemiddelde pagina ongeveer 158 KB aan markdown, waarvan ongeveer 90% herhaalde boilerplate was. Als je dit in een LLM of RAG-pipeline invoert, heb je je eigen content-extractielogica nodig om de template te verwijderen en de daadwerkelijke paginacontent te isoleren.

Hier is wat dezelfde winkel retourneerde toen we render: false draaiden:

{
  "job_id": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
  "status": "completed",
  "total": 266,
  "finished": 266,
  "browserSecondsUsed": 0,
  "record_count": 256,
  "records": [
    {
      "url": "https://www.example-store.com/products/classic-knit-sweater",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Classic Knit Sweater | Example Store",
        "url": "https://www.example-store.com/products/classic-knit-sweater",
        "lastModified": ""
      },
      "markdown": "Skip to content\n\nFree Shipping $150+\n\n# Classic Knit Sweater\n\nOur best-selling sweater made from premium natural fibers..."
    }
  ]
}

Nul browserseconden, 256 records van 266 pagina’s. De metadata is minimaal vergeleken met de gerenderde versie: geen Open Graph-velden, alleen de HTTP-status, paginatitel en URL. Maar de markdown bevat nog steeds de volledige paginacontent inclusief navigatie, productdetails en footer. Voor server-gerenderde Shopify-winkels heeft de statische HTML al alles wat je nodig hebt.

URL-ontdekking

De crawler ontdekt URL’s via drie bronnen (wanneer source is ingesteld op all):

1. De start-URL die je opgeeft
2. Sitemap-links gevonden op het domein
3. Interne links gevonden op gecrawlde pagina’s

Je kunt dit beperken tot alleen sitemaps of alleen paginalinks met de source parameter. excludePatterns heeft altijd voorrang op includePatterns, dus je kunt breed beginnen en vervolgens secties wegsnijden die je niet nodig hebt.

Renderen vs. snelle fetch

render: true (de standaard) start een headless browser, voert JavaScript uit en wacht tot de pagina volledig is geladen. Dit is nodig voor single-page applicaties en JavaScript-gerenderde content, maar het gebruikt browserseconden die worden gefactureerd.

render: false doet een snelle HTML-fetch zonder JavaScript uit te voeren. Tijdens de bèta worden deze fetches niet gefactureerd. Dit is de juiste keuze voor statische sites of server-gerenderde pagina’s waar de content al in de initiële HTML staat.

Facturering en beschikbaarheid

Het endpoint is beschikbaar op zowel Workers Free als Paid plannen. Gerenderde crawls worden gefactureerd onder Cloudflare’s Browser Rendering-prijzen van $0,09 per browseruur boven je inbegrepen toewijzing.

Workers Free: 10 minuten browsertijd per dag. Het /crawl endpoint is beperkt tot 5 opdrachten per dag, 100 pagina’s per crawl en 6 API-verzoeken per minuut.

Workers Paid ($5/maand): 10 uur browsertijd per maand inbegrepen. Geen per-crawl paginalimiet. 600 API-verzoeken per minuut. Extra browseruren kosten $0,09 per stuk.

Crawls met render: false gebruiken nul browsertijd. Ze zijn gratis tijdens de bèta, maar zullen uiteindelijk onder standaard Workers-prijzen vallen.

Wat is wall clock-tijd?

Wall clock-tijd is de totale verstreken tijd vanaf het moment dat een crawl start tot het eindigt, gemeten op dezelfde manier als met een stopwatch. Het omvat alles: netwerklatentie, Cloudflare’s interne wachttijd, DNS-lookups, serverresponstijd en (als rendering is ingeschakeld) browserexecutietijd.

Wall clock-tijd verschilt van browsertijd. Browsertijd telt alleen de seconden dat Cloudflare’s headless browser actief pagina’s rendert. Een crawl kan 22 minuten browsertijd gebruiken maar 25 minuten wall clock duren vanwege wachtrij- en netwerkoverlast. Crawls zonder rendering gebruiken nul browsertijd maar hebben nog steeds wall clock-tijd van het fetch- en wachtrijproces.

In onze benchmarks rapporteren we beide getallen, zodat je kunt zien waarvoor je betaalt (browsertijd) versus hoe lang je daadwerkelijk wacht (wall clock-tijd).

De kleine lettertjes

Het endpoint respecteert robots.txt-richtlijnen inclusief crawl-delay. Het identificeert zichzelf als CloudflareBrowserRenderingCrawler/1.0. Het omzeilt geen CAPTCHAs, Turnstile-uitdagingen of andere botbescherming. Als je je eigen site crawlt en geblokkeerd wordt, moet je een WAF-uitzonderingsregel maken om de crawler toe te staan.

Hoe Cloudflare /crawl zich gedraagt bij vijf Shopify-winkels

We hebben het /crawl endpoint getest op vijf live Shopify-winkels om snelheid, slagingspercentage, kosten en de interactie van de crawler met elke site te meten. Elke winkelnaam is geanonimiseerd. Dit zijn echte cijfers van echte crawls. Wall clock-tijden zijn geschatte waarden. Sommige vroege tests gebruikten scripts met beperkte foutafhandeling, wat de gerapporteerde slagingspercentages bij bepaalde winkels beïnvloed kan hebben. Waar dit van toepassing is, vermelden we het hieronder.

Dit is geen endpoint dat je instelt en vergeet. Elke winkel reageerde anders op endpoint-verzoeken. Sommige hadden resource-blokkering nodig om een gerenderde crawl te voltooien. Andere retourneerden 429-fouten op de ene modus maar werkten prima op de andere. Crawl-delay-richtlijnen, pagina-aantallen en winkelarchitectuur veranderden allemaal het resultaat. Reken erop dat je de instellingen voor elke site die je crawlt moet testen en afstemmen.

Test 1: grote e-commerce catalogus (Store A)

We hebben het /crawl endpoint gericht op een grote Shopify-winkel met bijna 3.000 pagina’s. Content kwam snel terug, de markdown was bruikbaar en het endpoint had geen moeite met het ophalen van productpagina’s, collectiepagina’s en blogcontent. Geen proxy-problemen, geen blokkades, geen rate limiting.

We hebben meerdere crawls uitgevoerd op verschillende schalen:

Crawlen zonder JavaScript-rendering behaalde 100% succes op beide schalen. Volledige browserrendering retourneerde 4 van de 5 pagina’s in een kleine steekproeftest. Bij zo’n kleine steekproef kan de enkele ontbrekende pagina een browser-timeout, een tijdelijke fout of een scriptprobleem zijn.

Test 2: kleine Shopify-winkel (Store D, 24 pagina’s)

Een kleinere winkel waar we de volledige workflow testten:

Crawlen zonder rendering retourneerde fouten. Onze eerste test retourneerde 429-responses op de platte HTML-fetch. We hebben deze winkel niet opnieuw getest met verbeterde foutafhandeling, dus we kunnen niet bevestigen of de 429s afkomstig waren van de rate limiting van de winkel of van tijdelijke problemen tijdens de test.

Volledig renderen met op sitemap gebaseerde ontdekking was een volledig succes. 24 van de 24 pagina’s gecrawld, 100% voltooid.

Een belangrijke ontdekking: de standaard URL-ontdekkingsmodus vond slechts 1 pagina omdat de homepage bijna geen interne links had. Overschakelen naar op sitemap gebaseerde ontdekking vond alle 24. Als je homepage minimaal of JavaScript-heavy is, kan de crawler mogelijk geen pagina’s vinden via alleen links.

Test 3: middelgrote kledingwinkel (Store B, 256 pagina’s), met en zonder rendering

Onze meest gedetailleerde test. Een middelgrote kledingwinkel met 256 indexeerbare pagina’s: producten, collecties, blogposts en informatiepagina’s. We hebben beide modi op de volledige site gedraaid om het werkelijke verschil te meten.

Test 4: gezondheids- en supplementenretailer (Store C), gedeeltelijk succes op schaal

Een grote retailer in gezondheidsproducten met een enorme catalogus. We hebben twee crawls zonder rendering uitgevoerd op verschillende schalen:

Het gedeeltelijke slagingspercentage kan erop wijzen dat de infrastructuur van deze winkel sommige niet-browserverzoeken laat vallen, maar onze eerste test miste robuust foutherstel, dus sommige van deze mislukkingen waren mogelijk herstelbaar met betere retry-afhandeling aan onze kant. Het slagingspercentage verbeterde van 40% naar 89% op grotere schaal. We hebben deze winkel niet opnieuw getest met verbeterde foutafhandeling om de oorzaak te isoleren.

Test 5: grote multicategorie-winkel (Store E, ~1.200 pagina’s)

Onze grootste en meest onthullende test. Een Shopify-winkel met ongeveer 1.200 URL’s verdeeld over vier sitemaps: 521 producten, 626 collecties, 22 pagina’s en 31 blogposts.

De no-render crawl behaalde 100% succes over alle 1.200 pagina’s met nul browserkosten. De gerenderde crawl werd uitgevoerd op een steekproef van 100 pagina’s met resource-blokkeeroptimalisaties ingeschakeld.

Resource-blokkering maakte het verschil tussen een vastgelopen crawl en een schone. Zonder resource-blokkering bleef de gerenderde crawl hangen op 99 van de 100 pagina’s en verbruikte 649 seconden browsertijd voor die 99 pagina’s. Het inschakelen van resource-blokkering (afbeeldingen, media, lettertypen, stylesheets) met een domcontentloaded-wachtconditie voltooide alle 100 pagina’s in 475 seconden, een reductie van 27% in browsertijd zonder vastlopen.

Crawl-delay in robots.txt veroorzaakte zichtbare stagnaties. Store E’s robots.txt specificeert een crawl-delay van 10 seconden voor bepaalde bots. In onze no-render pollingdata verscheen dit als plateaus van meerdere minuten waar het paginaaantal stagneerde voordat het hervatte. De Cloudflare-crawler respecteert crawl-delay-richtlijnen, wat de wall clock-tijd direct verlengt bij sites die deze instellen.

Wat het /crawl endpoint daadwerkelijk accepteert

Het endpoint neemt één start-URL, geen lijst. Het ontdekt pagina’s door naar buiten te spideren vanaf die URL via sitemaps, paginalinks of beide. Als je al een URL-lijst hebt van een Scrapy-crawl en Cloudflare wilt gebruiken voor markdown-conversie, moet je de aparte /markdown of /scrape endpoints afzonderlijk per URL aanroepen.

Wat doet Cloudflare /crawl daadwerkelijk aan de serverzijde?

We hebben de volledige serverlogs opgehaald tijdens een volledig gerenderde crawl van Store D (25 pagina’s) om de werkelijke verkeersfootprint te analyseren. De resultaten onthullen fundamentele verschillen tussen browser-gerenderd crawlen en traditioneel bot-crawlen, met onbedoelde neveneffecten voor analytics, serverbelasting en monitoring van botverkeer.

Hoeveel verkeer genereert een volledig gerenderde Cloudflare /crawl daadwerkelijk?

De grootste bevinding: slechts 1,1% van de 2.234 verzoeken was daadwerkelijke paginacontent. De overige 98,9% bestond uit JavaScript, CSS, analytics-beacons, trackingpixels en checkout-preloads die werden geactiveerd doordat de browser elke pagina laadde zoals een echte bezoeker dat zou doen.

Een niet-gerenderde bot zoals Amazonbot of ChatGPT-User genereert 1 verzoek per pagina. De Cloudflare browserrenderer genereert er 89.

Verhoogt Cloudflare /crawl Shopify Analytics kunstmatig?

De 163 POST-verzoeken in onze logs waren volledig Shopify analytics- en tracking-endpoints die tijdens de crawl werden geactiveerd. Dit zijn dezelfde events die worden geactiveerd wanneer een echte klant je winkel bezoekt. Vanuit het perspectief van Shopify Analytics lijkt de Cloudflare-crawler op een bezoeker die in 2 minuten elke pagina op je site bekijkt.

Hoe snel raakt Cloudflare /crawl je server?

Alle 2.234 verzoeken landden in een venster van 134 seconden. Piekdoorvoer bereikte 82 verzoeken per seconde. De crawler renderde de volledige site van 25 pagina’s in iets meer dan 2 minuten, maar de server zag een aanhoudende burst van verkeer die er niet uitziet als organische browsepatronen.

Voor kleine winkels is dit beheersbaar. Voor grotere winkels met duizenden pagina’s kan de verzoekversterking (89x per pagina) gecombineerd met aanhoudende doorvoer aanzienlijke belasting op de origin server creëren, vooral als je op een gedeeld hostingplan zit of agressieve rate limiting hebt ingesteld.

Waar komt Cloudflare /crawl vandaan?

De crawl werd verdeeld over 5 Cloudflare-datacenters in de VS:

Dit is niet één server die verzoeken doet. Cloudflare verdeelt de renderingwerklast over zijn edge-netwerk. Alle 23 IP’s vielen in het 104.28.x.x-bereik en de user-agent was CloudflareBrowserRenderingCrawler/1.0 bij elk verzoek.

Welke browserfingerprint laat Cloudflare /crawl achter?

De renderer stuurt correcte Sec-Fetch-headers die een echte Chrome-browser nabootsen:

Twee fingerprint-hiaten vallen op: de renderer laat sec-ch-ua Client Hints-headers volledig weg (een echte Chrome-browser verzendt deze altijd), en alle verzoeken gebruiken HTTP/1.1 in plaats van HTTP/2 of HTTP/3. Als je botdetectieregels bouwt, zijn dit betrouwbare signalen om Cloudflare’s browserrenderer te onderscheiden van echt bezoekersverkeer.

Hoe verhoudt Cloudflare /crawl zich tot andere AI-bots in serverlogs?

We hebben de Cloudflare-crawl vergeleken met andere bots die dezelfde winkel in hetzelfde 12-uursvenster bezochten:

Amazonbot en ChatGPT-User halen ruwe HTML op: één verzoek, één pagina, geen JavaScript-executie. AhrefsBot crawlt sitemaps voor ontdekking. De Cloudflare browserrenderer voert een volledige Shopify-storefront uit op elke pagina, waarbij elk script, pixel en preload wordt geactiveerd alsof een echte klant aan het browsen was.

Cloudflare /crawl snelheid en kosten: de volledige benchmark

Elke crawl die we hebben uitgevoerd, in één tabel. Alle winkels geanonimiseerd, alle cijfers van echte tests. Wall clock-tijden zijn geschat. Slagingspercentages voor Stores C en D kunnen zijn beïnvloed door beperkte foutafhandeling in onze eerste testscripts.

Hoe snel is Cloudflare /crawl met vs. zonder rendering?

De duidelijkste vergelijking komt van Store B, waar we beide modi op exact dezelfde 256 pagina’s hebben gedraaid:

Het patroon over alle elf crawls is consistent: crawlen zonder rendering is dramatisch sneller. Wall clock-tijd zonder rendering is voornamelijk Cloudflare’s interne wachtrij- en fetch-overhead. Volledig renderen voegt ruwweg 5 seconden browsertijd per pagina toe bovenop die basislijn.

Hoeveel kost een volledig gerenderde Cloudflare-crawl per pagina?

Cloudflare’s Browser Rendering-prijzen zijn gebaseerd op browseruren, de tijd die hun headless browser besteedt aan het actief renderen van je pagina’s. Crawlen zonder rendering gebruikt nul browseruren en is gratis tijdens de bèta.

Workers Free-plan: 10 minuten browsertijd per dag. Het /crawl endpoint is verder beperkt tot 5 crawl-opdrachten per dag, met maximaal 100 pagina’s per crawl.

Workers Paid-plan ($5/maand): 10 uur browsertijd per maand inbegrepen. Daarboven betaal je $0,09 per extra browseruur. Geen per-crawl limieten op het /crawl endpoint. Tot 600 API-verzoeken per minuut.

Hier is wat onze testcrawls daadwerkelijk kostten bij $0,09/uur:

Bij ruwweg 5 seconden browsertijd per pagina vallen al deze kosten ruim binnen de 10 uur die bij het betaalde plan zijn inbegrepen. Een gerenderde crawl van 3.000 pagina’s zou ongeveer 4 van je 10 inbegrepen uren gebruiken, wat betekent dat je twee volledige crawls per maand kunt uitvoeren voordat je iets boven de $5 basis betaalt. Crawlen zonder rendering is gratis en heeft geen browsertijdkosten op beide plannen.

Wanneer moet je rendering overslaan vs. volledig renderen bij Cloudflare /crawl?

De conclusie

Voor de meeste Shopify-winkels met server-gerenderde content levert crawlen zonder rendering je meer dan 90% van de bruikbare content op, zonder kosten en in een fractie van de tijd.

Wat we hebben geleerd bij het testen van Cloudflare /crawl op Shopify-winkels

Na het uitvoeren van 11 crawls bij 5 live Shopify-winkels en het analyseren van volledige serverlogs, zijn dit de bevindingen die er het meest toe doen.

90% van de content komt binnen zonder rendering

Voor Shopify-winkels met standaard server-gerenderde pagina’s ving crawlen zonder JavaScript-rendering meer dan 90% van de bruikbare content op. De 14% toename in content door volledig renderen kwam bijna volledig van JavaScript-geladen elementen op homepagina’s en indexpagina’s. Individuele productpagina’s en blogartikelen waren hoe dan ook nagenoeg identiek. Tenzij je winkel is gebouwd als een single-page app, heb je waarschijnlijk geen volledig renderen nodig.

Volledig renderen creëert een 89x verkeersvermenigvuldiger

Het renderen van 25 pagina’s genereerde 2.234 serververzoeken. Slechts 25 daarvan waren daadwerkelijke paginacontent. De overige 98,9% bestond uit JavaScript-bestanden (75%), analytics-beacons (6,3%), CSS (4,3%), trackingpixels (3,4%) en checkout-preloads (3,3%). Elke gerenderde pagina activeert de volledige Shopify client-side stack alsof een echte klant aan het browsen was.

Je Shopify Analytics worden waarschijnlijk kunstmatig opgeblazen

Gerenderde crawls activeren de volledige analytics-stack van Shopify: monorail-beacons, tracking-events, Shop Pay-preloads en web-pixel scripts. Wij geloven dat dit betekent dat Shopify Analytics deze als echte bezoekersessies telt. Als dat het geval is, kan een enkele gerenderde crawl je sessieaantallen, paginaweergaven en conversietrechtergegevens opblazen. We hebben dit niet rechtstreeks bevestigd in Shopify’s rapportage, maar de serverlogs tonen alle dezelfde analytics-events die worden geactiveerd als bij een echte klant.

Volledig renderen kan rate limits van de winkel omzeilen

Store D retourneerde 429-fouten op elke pagina zonder rendering. Overschakelen naar volledig renderen op dezelfde winkel produceerde 100% succes. Als je rate limits tegenkomt zonder rendering, is volledig renderen je oplossing.

Sitemap-ontdekking is betrouwbaarder dan linkontdekking

De standaard linkgebaseerde ontdekking vond bijna niets op Store D omdat de homepage heel weinig interne links had. Overschakelen naar op sitemap gebaseerde ontdekking vond alle 24 pagina’s. Gebruik altijd sitemap-ontdekking.

De crawler komt uit 5 Amerikaanse datacenters

Cloudflare verdeelt de renderingwerklast over zijn edge-netwerk. Onze crawl kwam van 23 unieke IP’s verdeeld over Atlanta (38%), Chicago (25%), Miami (23%), Newark (9%) en Washington DC (5%). Alle IP’s vallen in het 104.28.x.x-bereik.

Twee fingerprint-hiaten identificeren het als een bot

De renderer laat sec-ch-ua Client Hints-headers weg (echte Chrome verzendt deze altijd) en gebruikt HTTP/1.1 in plaats van HTTP/2 of HTTP/3. Als je botdetectieregels bouwt, zijn dit betrouwbare signalen.

Renderen kan juist minder content opleveren

Bij Store E retourneerde de no-render crawl 6,8% meer content per pagina dan de gerenderde crawl. Het blokkeren van afbeeldingen, lettertypen en stylesheets om browsertijd te optimaliseren verhinderde ook dat sommige JavaScript dynamische elementen vulde. De statische HTML had al alles. Voor server-gerenderde Shopify-winkels is het niet gegarandeerd dat renderen meer content opvangt.

Resource-blokkering voorkomt vastgelopen crawls

Zonder resource-blokkering bleef de gerenderde crawl op Store E hangen op 99 van de 100 pagina’s en werd nooit voltooid. Het inschakelen van blokkering voor afbeeldingen, media, lettertypen en stylesheets met een domcontentloaded-wachtconditie voltooide alle 100 pagina’s en verminderde de browsertijd met 27%. Als je gerenderde crawls stagneren voordat ze klaar zijn, is resource-blokkering de oplossing.

robots.txt crawl-delay verlengt wall clock-tijd

Store E’s robots.txt specificeert een crawl-delay van 10 seconden. In onze no-render pollingdata verscheen dit als plateaus van meerdere minuten waar het paginaaantal stagneerde voordat het hervatte. De Cloudflare-crawler respecteert crawl-delay-richtlijnen, dus sites met agressieve vertragingen zullen aanzienlijk langere wall clock-tijden hebben dan het paginaaantal alleen zou suggereren.

Kosten zijn laag, maar het gratis plan heeft limieten

Het renderen van 256 pagina’s kostte ongeveer $0,03 bij $0,09 per browseruur. Het renderen van 24 pagina’s kostte ongeveer $0,002. Het Workers Free-plan beperkt browsertijd tot 10 minuten per dag met maximaal 5 crawl-opdrachten en 100 pagina’s per crawl. Het Workers Paid-plan ($5/maand) bevat 10 uur browsertijd per maand zonder per-crawl limieten. Een gerenderde crawl van 3.000 pagina’s zou ongeveer 4 van die 10 inbegrepen uren gebruiken, dus de meeste winkels passen comfortabel in het betaalde plan zonder overschrijding. Crawlen zonder rendering gebruikt nul browsertijd en is gratis op beide plannen tijdens de bèta.

De voordelen

Snelheid

Pagina’s worden bijna onmiddellijk opgehaald versus een Scrapy-crawl van meerdere uren met autothrottle. Geen wachtrij, geen beleefdheidsvertragingen, geen wachten tot je spider duizenden verzoeken op een respectvol tempo heeft verwerkt.

Markdown-output

Het endpoint retourneert voorgeconverteerde HTML-naar-Markdown voor elke pagina. Dit is direct bruikbaar voor LLM-inname, RAG-pipelines en contentanalyse zonder enige nabewerking. Je slaat de volledige extractielaag over en gaat direct naar schone tekst. Voor teams die AI-toepassingen bouwen bovenop website-content, verwijdert dit een stap uit de pipeline.

Rendermodusoptie

Door render: true in te stellen wordt JavaScript uitgevoerd en worden automatisch Open Graph-metadata geëxtraheerd (og:title, og:description, og:image, og:site_name). Voor JavaScript-heavy sites waar content client-side wordt gerenderd, is dit het verschil tussen de echte pagina zien en een lege shell zien.

Geen proxy- of rate-limit-problemen

Cloudflare handelt anti-botmaatregelen en rate limiting af op hun eigen infrastructuur. Je hoeft geen proxy-pools te beheren, user agents te roteren of met CAPTCHAs om te gaan. Eén API-aanroep.

Incrementeel crawlen

De modifiedSince- en maxAge-parameters laten je pagina’s overslaan die niet zijn gewijzigd of recent zijn opgehaald. Voor terugkerende crawls waarbij je contentwijzigingen monitort, bespaart dit zowel tijd als kosten door alleen pagina’s te verwerken die daadwerkelijk nieuw of bijgewerkt zijn.

Eenvoud

Eén API-aanroep. JSON-response. Geen spider-code, geen middleware, geen item-pipelines, geen instellingenbestanden.

Standaard een nette bot

De crawler is een signed-agent die robots.txt, crawl-delay en Cloudflare’s AI Crawl Control respecteert. Hij identificeert zichzelf als CloudflareBrowserRenderingCrawler/1.0 en kan botbescherming of CAPTCHAs niet omzeilen. Je krijgt ethische crawling-compliance zonder de logica zelf te bouwen.

Wat het Cloudflare Crawl Endpoint niet ondersteunt

Hoe verschilt Cloudflare /crawl van een volledige crawl-pipeline?

De onderstaande tabel toont precies welke mogelijkheden aanwezig zijn in Cloudflare’s /crawl endpoint versus een productie Scrapy-pipeline. Dit is gebaseerd op onze echte tests bij Shopify-winkels.

Welke gestructureerde data extraheert Cloudflare /crawl?

Met render: false, geen. Geen JSON-LD, geen Microdata, geen OpenGraph-parsing.

Met render: true, alleen basis OG-tags (og:title, og:description, og:image, og:site_name). JSON-LD en schema.org-markup worden niet geparsed, geëxtraheerd of gevalideerd.

Ter vergelijking: onze Scrapy-pipeline produceert schemas_found, issues (ontbrekend contactPoint, address, etc.), top_level_schemas en nested_schemas voor elke URL. Je kunt zien welke pagina’s Product-schema hebben, welke Organization-markup missen en welke validatiefouten hebben die ervoor zorgen dat AI-systemen de content verkeerd lezen.

Welke HTTP-statuscodes retourneert Cloudflare /crawl?

Alleen 200-responses. Onze Scrapy-crawl van dezelfde site ving 2.547 404-fouten op, plus 403-responses en verbindingsfouten. 404-detectie is cruciaal voor spookpagina-analyse, reparatie van gebroken links en redirect-mapping. Zonder dit mis je de pagina’s die actief linkequity lekken en AI-crawlers in verwarring brengen.

Hoeveel URL’s kan Cloudflare /crawl verwerken?

Tot 100.000 per opdracht. Dit dekt de meeste sites, maar grote e-commerce catalogi met honderdduizenden productpagina’s, variant-URL’s en gefilterde collectiepagina’s zullen de limiet overschrijden. Scrapy heeft geen inherente URL-limiet.

Heeft Cloudflare /crawl een URL-resolutiebug?

We vonden 233 van de 908 links op een enkele productpagina met gebroken paden. De markdown-converter lost relatieve URL’s verkeerd op ten opzichte van de pagina-URL, wat dubbele-pad-URL’s oplevert zoals /products/slug//www.example.com/.... Dit is een bevestigde bug in Cloudflare’s converter die elke downstream linkanalyse beïnvloedt.

Hoeveel boilerplate zit er in de markdown-output van Cloudflare /crawl?

De gemiddelde pagina retourneerde 158 KB aan markdown. Ruwweg 90% is herhaalde templatecontent: volledige navigatie, mega-menu en footer in elk record. Voor contentanalyse betekent dit zware deduplicatiewerk, en voor LLM-tokengebruik lopen de kosten snel op. Je hebt je eigen content-extractielogica nodig bovenop de markdown om de daadwerkelijke paginacontent te isoleren.

Wat classificeert Cloudflare /crawl niet?

Er is geen contenttype-tagging. Productpagina’s, collectiepagina’s, blogposts en homepagina’s komen allemaal terug als ongedifferentieerde records. Scrapy classificeert elke URL op type, wat essentieel is om crawldekking per paginacategorie te begrijpen en om te identificeren welke contenttypes AI-bots prioriteren.

Welke finalisatiefuncties ontbreken bij Cloudflare /crawl?

Geen screenshots van spookpagina’s. Geen JavaScript-renderingvergelijking (wat de bot ziet versus wat de browser ziet). Geen robots.txt AI-botanalyse. Geen crawlkwaliteitsrapport. Geen clientmanifest. Geen CDN-synchronisatie. De Cloudflare-data is alleen ruwe content. Elk onderdeel van de rapportage- en analysepipeline zou apart gebouwd moeten worden.

Hoeveel kost Cloudflare /crawl voor grote sites?

Over onze tests heen kostte render: true gemiddeld ruwweg 5 seconden browserexecutie per pagina. Een crawl van 256 pagina’s gebruikte 1.338 browserseconden (22 minuten) en kostte ongeveer $0,03 bij $0,09 per browseruur. Een crawl van 24 pagina’s gebruikte 58 browserseconden en kostte ongeveer $0,002. Geëxtrapoleerd naar een catalogus van 3.000 pagina’s: ongeveer 4 uur browsertijd. Het Workers Free-plan is beperkt tot 10 minuten browsertijd per dag, 5 crawl-opdrachten per dag en 100 pagina’s per crawl. Het Workers Paid-plan ($5/maand) bevat 10 uur browsertijd per maand zonder per-crawl limieten, dus een crawl van 3.000 pagina’s zou ongeveer 4 van die 10 inbegrepen uren gebruiken. render: false gebruikt nul browsertijd en is gratis tijdens de bèta op beide plannen.

De conclusie

Cloudflare’s crawl endpoint is uitstekend voor:

• Snelle contentsnapshots wanneer je snel paginatekst nodig hebt
• LLM-klare markdown voor RAG-pipelines en contentinname
• Ad-hoc paginacontroles waar je de exacte URL’s kent die je nodig hebt
• Snelle sitewide contentpulls wanneer je markdown-tekst nodig hebt zonder een spider te bouwen

Het kan een volledige crawl-pipeline niet vervangen omdat de waarde van de pipeline ligt in:

• Volledige crawl-graaf met linktopologie, detectie van weespagina’s en 404-dekking
• Gestructureerde data-extractie en -validatie (JSON-LD, Microdata, OpenGraph)
• Contentclassificatie op paginatype
• De volledige finalisatiepipeline inclusief spookpagina-analyse, JavaScript-renderingvergelijking, schemarapporten en LLM-gereedheidsscoring

De beste hybride aanpak

Gebruik Cloudflare als aanvullende gegevensbron. Nadat een volledige crawl je URL’s heeft geïdentificeerd, gebruik je Cloudflare’s markdown-output om LLM-gereedheidsscoring of contentkwaliteitsanalyse te voeden waar je de daadwerkelijke paginatekst nodig hebt in plaats van gestructureerde metadata. De crawl-pipeline ontdekt en classificeert. Het Cloudflare-endpoint levert schone tekst voor de pagina’s die ertoe doen.

Veelgestelde vragen