Scrapy wordt vaak afgedaan als een tool die “geen moderne websites aankan”, omdat het geen JavaScript uitvoert. Die reputatie klopt niet. Juist het niet renderen van de pagina is het hele idee, en zodra je dat in actie ziet, voelt het niet meer als een ontbrekende functie.
Ik heb dat mezelf in één test bewezen. Ik bouwde een catalogusfixture die via JavaScript wordt gerenderd, zette Scrapy op de pagina die een browser zou tonen, en kreeg 0 productkaarten terug. Daarna wees ik dezelfde spider naar het JSON-eindpunt dat de pagina op de achtergrond stilletjes aanriep — en haalde ik 8/8 items binnen, netjes en schoon. Dezelfde tool, dezelfde sessie, tegenovergestelde uitkomst — en precies dat verschil staat centraal in deze review.
Wat Scrapy echt is (en wat niet)
Scrapy is een Python-framework om sites te crawlen en gestructureerde data eruit te halen. Dat is ook hoe de maintainers het zelf omschrijven in de overzichtsdocumentatie, en na ermee gewerkt te hebben blijkt dat gewoon te kloppen — zonder marketingpraat die je moet bijstellen. Het bestaat lang genoeg en is gevestigd genoeg om het standaardantwoord te zijn wanneer een Python-ontwikkelaar vraagt waarmee serieuze mensen scrapen, en de repository bevestigt dat: ongeveer 62.981 GitHub-stars op 2026-07-07 (scrapy/scrapy), met 11.773 forks en 590 open issues op dezelfde dag. BSD-3-Clause-licentie, Python 3.10 of nieuwer, en de versie die ik heb getest was 2.17.0 — toevallig exact de versie die die ochtend uitkwam. Dus hier geen achterhaalde-versie-asterisk.
Dit is de grens die Scrapy onderscheidt van de nieuwere AI-crawlers: Scrapy is standaard alleen HTTP. Geen browser. Geen rendering engine. Het haalt HTML via het netwerk op, geeft die aan een parser en laat je velden pakken met CSS-selectors of XPath. Dat als beperking beschrijven is maar half waar en mist de ontwerpkeuze volledig. Scrapy vertrekt vanuit het idee dat het opstarten van een headless Chrome voor een routineklus meestal de verkeerde keuze is — slimmer is het om de data-aanvraag te vinden die de pagina al doet en die direct op te vragen.
Dat is geen interpretatie van mijn kant. De officiële documentatie over dynamische content zegt het expliciet: zoek eerst de onderliggende data-aanvraag op en reproduceer die; pas als dat niet praktisch is, schakel je over op een headless browser. De meeste scrapers openen eerst de browser en denken nooit meer aan de API. Scrapy draait die standaard om.
Belangrijkste functies, en de ontwerpkeuze daarachter
Onder de motorkap is Scrapy een stapel onderdelen die allemaal uitgaan van één ding: jij bent een ontwikkelaar die controle wil, geen no-code wizard die op één knop klikt.
Spiders. Je schrijft een klasse, geeft start-URL’s mee en definieert een parse-callback die items oplevert of verder navigeert via links. Dat is meer werk dan een no-code extractor — de extractieregels schrijf je zelf — maar daar krijg je volledige controle voor terug over wat wordt vastgelegd en waar de crawl daarna naartoe gaat.
Selectors. De parsing draait op parsel, met lxml eronder. CSS en XPath zijn beide volwaardige opties, geen toevoeging achteraf. Dankzij die lxml-basis blijft selecteren snel en leest de extractiecode als intentie in plaats van als een rommelige reeks string-manipulaties.
Feed exports. Richt een spider op een bestand en Scrapy schrijft je items zonder extra code weg naar JSON, JSON Lines, CSV of XML. In mijn test maakte één spider zowel JSON als CSV aan zonder dat ik ook maar één exportregel hoefde te schrijven — de feed export-functionaliteit doet echt wat hij belooft.
AutoThrottle en crawl-controls. Requests worden asynchroon ingepland via Twisted, en je krijgt concurrency-limieten, downloadvertragingen, dieptelimieten, AutoThrottle voor adaptieve rate limiting en respect voor robots.txt. Dit zijn precies de schakels die voorkomen dat een brede crawl verandert in een serverbestorming.
Alleen HTTP, maar dan als voordeel. Geen browser betekent weinig geheugenverbruik, hoge throughput en geen rendering engine die je moet onderhouden — zolang de data die je zoekt gewoon via HTTP bereikbaar is. En dat is, vaker dan de browser-first-wereld denkt, inderdaad het geval.
Installatie: de afhankelijkhedenstapel waar niemand screenshots van maakt
De installatie verliep zonder drama, en voor een framework van deze omvang is dat het vermelden waard. pip install Scrapy==2.17.0 rondde netjes af in een schone virtuele omgeving op macOS arm64, met binary wheels en zonder dat iets zichzelf te pletter hoefde te compileren. Geen spektakel — en dat is precies de bedoeling.
Kijk wel even naar wat er allemaal wordt meegetrokken. scrapy version -v meldde Scrapy 2.17.0 bovenop lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 en cryptography 49.0.0, met parsel, cssselect en tldextract als aanvulling. Dat is een serieuze footprint — de complete afhankelijkheden van een crawlframework, niet van een losse HTML-parser. Op mijn machine waren voor alles wheels beschikbaar en bleef de installatie pijnloos. Op andere systemen waarschuwen de officiële docs nog steeds voor platform-specifieke afhankelijkheidsproblemen, en historisch zitten de meeste schuurpunten in het deel rond cryptography en Twisted, dus houd daar rekening mee als je op een ongebruikelijk platform werkt. Hier verliep de setup soepel; de omvang van wat er geïnstalleerd wordt is nog steeds iets om vooraf te weten, want je haalt een framework binnen en dat weegt ook als een framework.
Praktijk: wat overeind bleef
Zodra het draaide, was het statische pad probleemloos. Volledige dekking, niets gemist.
| Test | Resultaat | Runtime |
|---|---|---|
| Lokale statische catalogus + paginering | 12/12 producten | 0.557s |
| CSV-export van statische catalogus | 12 rijen weggeschreven | (zelfde run) |
| Artikel-extractie | titel + 3/3 alinea’s | 0.416s |
| Crawlgraph, DEPTH_LIMIT=2 | 11 pagina’s over dieptes 0/1/2 | 0.904s |
| Lokale 500-pagina | status 500 vastgelegd, geen crash | 0.424s |
| Books to Scrape (publiek) | 20 producten | 2.053s |
| Quotes to Scrape spider (publiek) | 12 quote-items | 3.465s |
De spider voor de statische catalogus liep van pagina één naar pagina twee en ving 12/12 verwachte records, waarna hij ze in dezelfde run als JSON én CSV wegschreef. De artikel-fixture is het waard om even bij stil te staan. Scrapy deed geen poging om de pagina automatisch op te schonen tot nette Markdown — in plaats daarvan liet het me expliciet article-velden selecteren en zette het navigatie- en footertekst in aparte velden, waardoor ik 3/3 body-alinea’s kreeg en de standaardteksten netjes afgeschermd bleven in plaats van door de output heen te lopen. Dat is de afweging: jij schrijft de selectors, en je krijgt precies terug wat je hebt gevraagd, niet meer en niet minder.
Crawlcontrole werkte prima op kleine schaal. Met DEPTH_LIMIT=2, een korte downloadvertraging, concurrency per domein en robots.txt ingeschakeld, zag de crawlgraph 11 pagina’s op dieptes 0, 1 en 2, en de dieptetelling werkte zoals verwacht. Ook foutafhandeling verliep zonder drama. De opzettelijke 500-pagina kwam terug als een gestructureerd item waarbij status 500 via handle_httpstatus_list zichtbaar werd gemaakt — geen exception, geen vastgelopen run. Scrapy behandelt een foutstatus als iets wat je in spider-logica afhandelt, niet als een verrassing die je crawl onderuit haalt.
Praktijk: de JavaScript-muur en de deur ernaast
Nu het resultaat waar deze review om draait.
Ik liet Scrapy’s HTTP-fetcher los op een catalogusfixture die via JavaScript wordt gerenderd. Het haalde de bron-HTML op, vond 0 .product-card-nodes en ging door — omdat het nooit het script uitvoerde dat die kaarten zou tekenen. De publieke Quotes to Scrape JS-pagina liet hetzelfde zien: 0 gerenderde quote-nodes. Als je de test daar zou stoppen, zou je Scrapy afschrijven als ongeschikt voor alles wat na 2010 is gebouwd.
Maar stop daar niet. Die JS-catalogus werd op de achtergrond gevuld via een JSON API, zoals de meeste van dit soort pagina’s. Ik wees dezelfde Scrapy spider naar dat eindpunt en kreeg 8/8 producten terug in 0.416s — geen browser, geen rendering, alleen een request naar de URL die de pagina toch al aanriep en een parse van de teruggekomen JSON.
Die vergelijking naast elkaar is de filosofie van “reproduceer de request” in het klein. De gerenderde pagina is een afleiding; de data zat de hele tijd achter een API. Scrapy stuurt je er direct naartoe in plaats van je te laten betalen voor een headless browser die toekijkt hoe een pagina zich opbouwt. Het is sneller, lichter en breekt minder snel — een API-contract is stabieler om op te vertrouwen dan een stapel client-side DOM. De keerzijde is dat dit handwerk is. Je moet de network-tab openen, de request vinden en de headers en parameters zelf namaken. Scrapy ontdekt de API niet voor je; het maakt het alleen triviaal om hem aan te roepen zodra je hem hebt.
Twee grenzen, helder geformuleerd. Als er echt geen onderliggende request is om te reproduceren — data die volledig client-side wordt opgebouwd zonder API erachter — dan heb je bij Scrapy een headless-browserintegratie nodig die je zelf inbouwt, en dat pad heb ik in deze test niet meegenomen. En alles hierboven draaide op kleine fixtures en publieke demopagina’s. Ik heb geen crawl van 100 tot 1.000 pagina’s gedaan, dus ik doe geen uitspraken over geheugenverbruik, throughput of retry-gedrag op schaal — de async-kern en crawl-controls zijn sterke signalen, maar een signaal is nog geen meting.
Voor- en nadelen
Voordelen:
- Alleen-HTTP-ontwerp is snel en licht — 12/12 statische dekking in ongeveer een halve seconde, 8/8 via een JSON API in 0.416s, zonder browseroverhead.
- De aanpak “reproduceer de request” werkt echt: een JS-pagina die 0 teruggaf, leverde via de onderliggende API alle 8 items op.
- CSS- en XPath-selectors op basis van
lxmlhouden extractiecode leesbaar en snel. - Feed exports naar JSON/CSV/XML zonder extra exportcode.
- Expliciete foutafhandeling — een 500 komt terug als status die je opvangt, niet als crash.
- Volwassen crawl-controls: concurrency, vertraging, dieptelimieten, AutoThrottle en robots.txt.
- Soepele BSD-3-Clause-licentie; een schone installatie op een moderne machine.
Nadelen:
- Rendert JavaScript niet uit zichzelf — 0 nodes op een client-gerenderde pagina totdat je de API zelf vindt.
- De onderliggende request vinden is handmatig; Scrapy wijst je niet naar het eindpunt.
- Een forse afhankelijkhedenstapel (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — hier probleemloos, maar historisch gevoelig op afwijkende platforms.
- Meer code dan no-code of auto-extractietools; de spiders moet je zelf schrijven en onderhouden.
- Mijn tests betroffen kleine fixtures en demowebsites, geen grote crawls — schaalbaarheid is in deze run niet bewezen.
Voor wie het geschikt is, en voor wie niet
Scrapy is er voor ontwikkelaars die code-niveau controle willen en denken in requests, niet in pagina’s. Als jouw eerste gedachte bij een trage JavaScript-site is: “hier zit vast ergens een API onder”, dan is dit gereedschap precies voor dat instinct gebouwd. Het beloont mensen die comfortabel selectors schrijven, een network-tab kunnen lezen en hun extractielogica end-to-end zelf willen beheren. Voor statische sites, catalogi met paginering en alles wat achter een vindbaar JSON-eindpunt zit, werkt het snel en nauwkeurig.
Sla het over — of gebruik het in elk geval samen met iets anders — als je geen zin hebt om spidercode te schrijven en te onderhouden, of als je doelwitten hun data puur client-side renderen zonder reproduceerbare request en je geen headless browser wilt inbouwen. En als je hoopte dat je gewoon een URL kon invoeren en vanzelf schone, gestructureerde output kreeg zonder extractieregels te schrijven, dan was dat nooit de taak van Scrapy, en het heeft ook nooit gedaan alsof dat wel zo was.
Alternatieven, en waar Thunderbit past
Probeer Thunderbit voor webdata-extractie
Begin bij wat je echt kiest: een gratis open-source framework dat je zelf draait en onderhoudt. Jij bezit de spiders, de afhankelijkhedenstapel en het werk om per site de data-request te vinden. Daar staat tegenover dat je niets per request betaalt, alles in eigen beheer houdt en volledige controle hebt. Voor veel teams is dat precies de juiste keuze, en deze review probeert niemand daarvan af te praten.
De afweging zit in het probleem van rendering en verandering, en het antwoord van Scrapy is dat jij dat oplost: je vindt de API, reproduceert de request en regelt het geval zonder API door zelf een browser in te bouwen. Een beheerde AI-scraping-API neemt die laag juist van je bord. Daar zit de plek waar Thunderbit voor technische lezers in past — een AI-scraping API plus MCP-server plus CLI, niet de browserextensie die sales- en operations-teams gebruiken. POST /distill zet een pagina om in schone, LLM-klare Markdown; POST /extract levert gestructureerde JSON op basis van een schema dat jij definieert; en beide handelen JavaScript-rendering, anti-botmaatregelen en dynamische content server-side af — inclusief het client-side gerenderde geval waarvoor Scrapy je naar een browser laat grijpen. Er is een MCP-server voor AI-agents en coding assistants (met een gratis thunderbit_suggest_fields om eerst het veldgebruik te bepalen voordat je iets uitgeeft), en een CLI via npx @thunderbit/thunderbit-cli voor terminal-, CI- of cron-werk.
Het verschil zit niet in kwaliteit, maar in eigenaarschap. Scrapy is een expliciet engineering-framework: jij beheert de spider, de pipeline en de JS-strategie, en je krijgt volledige controle zonder kosten per call. Thunderbit’s stack neemt de render- en extractielaag als beheerde dienst over, zodat je geen netwerk-tab hoeft uit te pluizen en per call betaalt in plaats van per taak. Klein, code-first en bereid om elke stap zelf te beheren? Dan past Scrapy beter. Moet je opschalen over honderd sites en wil je niet per site handmatig een request namaken? Dan haalt de beheerde route die hele categorie werk weg.
Voor het bredere speelveld behandelen deze benchmarkartikelen de buren: de volledige open-source scrapervergelijking, de review van Colly’s no-browser Go-crawler en de review van Scrapling met adaptieve selectors.
Oordeel
Moet je Scrapy gebruiken? Ja — als je ontwikkelaar bent, controle wilt en in de filosofie meegaat: render de pagina niet, maar vind de request erachter. In de tests werkte dat precies zoals beloofd. Een JavaScript-catalogus gaf de HTTP-fetcher 0 kaarten; de JSON API erachter leverde alle 8 items aan dezelfde spider. Statische extractie haalde 12/12 binnen, artikel-selectors hielden 3/3 alinea’s schoon van boilerplate, de crawlgraph hield zich aan de dieptelimiet over 11 pagina’s en een 500 kwam terug als een afgehandelde status in plaats van een crash.
Formuleer de claims wel correct. Scrapy rendert geen JavaScript en vindt de API niet voor je — dat moet je zelf aanleren. De afhankelijkhedenstapel is die van een volwaardig framework en kan op vreemde platforms tegen je werken, ook al ging het hier schoon. En ik testte fixtures en demopagina’s, geen crawl van duizend pagina’s, dus beschouw het schaalverhaal als veelbelovend maar nog onbewezen. Binnen die grenzen is Scrapy de tool die het sterkst vasthoudt aan een stilletjes radicale gedachte: de snelste weg door een webpagina loopt meestal helemaal niet via die webpagina.
Probeer Thunderbit voor webdata-extractie Get Started Free
Veelgestelde vragen
Kan Scrapy JavaScript-gerenderde pagina’s scrapen? Niet met de standaard HTTP-fetcher — het gaf 0 nodes terug op zowel een JS-fixture als de publieke Quotes JS-pagina, omdat het HTML downloadt zonder browser uit te voeren. De bedoelde route is om de onderliggende data-request van de pagina te vinden en die direct op te vragen; in mijn test leverde de JSON API achter een JS-catalogus alle 8 items op. Voor pagina’s zonder reproduceerbare request moet je zelf een headless browser integreren.
Wat betekent “de request reproduceren” precies? De meeste dynamische pagina’s laden hun data op de achtergrond uit een JSON API en renderen die daarna client-side. In plaats van een browser te laten zien hoe dat gebeurt, open je de network-tab, zoek je die API-call op en wijs je Scrapy direct naar dat eindpunt. Het is sneller en stabieler dan renderen — een API-contract breekt minder snel dan een DOM — maar het is handwerk, en Scrapy vindt het eindpunt niet voor je.
Is Scrapy lastig te installeren?
Voor mij niet — pip install Scrapy==2.17.0 draaide zonder compileerfouten in een schone venv op macOS, met binary wheels. Maar het trekt wel een flinke stack mee (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), en de officiële docs waarschuwen nog steeds voor platform-specifieke frictie op sommige systemen, dus houd daar rekening mee als je op een ongebruikelijke setup werkt.
Welke outputformaten ondersteunt Scrapy? Feed exports ondersteunen standaard JSON, JSON Lines, CSV en XML — wijs een spider naar een bestand en hij serialiseert je items zonder extra code. In mijn run produceerde één spider zowel JSON als CSV in één pass. Let op: het exporteert de velden die jij selecteert; het maakt geen automatische Markdown-opmaak van een pagina.
Is Scrapy gratis voor commercieel gebruik? Ja, BSD-3-Clause is permissief en commercieel vriendelijk. Controleer zoals altijd de huidige licentie in de repo voordat je erop bouwt, en wees verantwoordelijk met je user-agent, proxy’s en rate limits — kunnen betekent niet automatisch dat het ook mag.
