Varenda guide om "Scrapy vs. Selenium" på nätet säger ungefär samma sak: Scrapy är snabbare, Selenium klarar JavaScript, välj din gift. Riktningen stämmer oftast, men påståenden om ett universellt antal sidor per minut håller sällan. Genomströmningen beror på målsidan, nätverket, samtidighet, webbläsarens livscykel, väntetider och anti-bot-skydd.
Den här guiden jämför arkitekturerna och de praktiska avvägningarna som faktiskt spelar roll från projekt till projekt. Vi går också igenom sådant som ofta lämnas ute i jämförelser: hur Webbläsarautomatisering ändrar resursbilden, varför selektiv rendering ofta slår en ren webbläsarcrawl och när ett hanterat extraktions-API är ett bättre val än båda ramverken.
Snabbt omdöme: Scrapy vs. Selenium år 2026
Kort version: Scrapy vinner på hastighet, skala och resurseffektivitet för allt som renderas på serversidan. Selenium vinner när du behöver en riktig webbläsare som gör riktiga webbläsargrejer — klicka, skriva, vänta på att en modal animera in. Ingen av dem är särskilt bra mot moderna anti-bot-skydd direkt ur lådan, och Playwright har i tysthet tagit över de flesta användningsfall där man tidigare valde Selenium.
Här är den beslutsmatris jag faktiskt använder:
| Din situation | Välj |
|---|---|
| Statiska eller server-renderade sidor, hög volym | Scrapy |
| JS-tung SPA med inloggning, klick och flerstegsflöden | Selenium eller Playwright |
| Blandad sajt — mest statisk, vissa sektioner endast med JS | Scrapy-Playwright-hybrid |
| Kända URL:er, du behöver bara strukturerad data och minimalt underhåll | AI-extraktions-API (Thunderbit och liknande) |
I mitten av 2026 finns Scrapy 2.17.0 tillgänglig, Selenium 4 fortsätter att utöka stödet för WebDriver BiDi, och scrapy-playwright erbjuder ett underhållet sätt att skicka utvalda Scrapy-begäranden via en webbläsare. Ha den där matrisen i bakhuvudet — resten av artikeln förklarar varför den fungerar.
Vad är Scrapy och Selenium (och varför diskuterar utvecklare dem fortfarande?)
Att jämföra Scrapy med Selenium är lite som att jämföra en lastbil med en personbil. Båda tar saker från A till B, men den ena är byggd för att frakta stora volymer effektivt och den andra är byggd för att köras av en människa som faktiskt behöver interagera med vägen. Debatten fortsätter eftersom båda verktygen kan skrapa — de är bara byggda för olika jobb, och många team väljer fel innan de inser det.
Scrapy: den asynkrona crawl-motorn
Scrapy är ett Python-baserat ramverk byggt på Twisted och dess händelsestyrda, icke-blockerande I/O-modell. Det är inte en webbläsare — det har aldrig varit det — det skickar bara HTTP-begäranden och tolkar den HTML som kommer tillbaka. Det är hela tricket. Eftersom det aldrig behöver vänta på att en webbläsare ska rendera något kan det skicka iväg dussintals förfrågningar samtidigt utan att blockera.
Direkt ur lådan levererar Scrapy spiders, item pipelines, feed exporters, retry middleware och rate limiting. Det här är alltså inte ett ramverk där du måste bygga allt själv — mycket av det som krävs i produktion finns redan där. Scrapy:s arkitekturdokumentation beskriver Engine, Scheduler, Downloader och Item Pipeline som separata, utbytbara komponenter, vilket är precis varför ramverket åldrats väl: du kan bygga ut det utan att skriva om kärnan.
Nackdelen: ingen webbläsare betyder ingen JavaScript-exekvering. Om din data laddas via ett klient-side fetch-anrop efter att sidan renderats ser Scrapy inget av det. Det läser den initiala HTML-svaret, punkt slut.
Selenium: webbläsaren du kan programmera
Selenium styr riktiga webbläsare — Chrome, Firefox, Edge — via W3C WebDriver-protokollet, den standardiserade specifikationen som gör Selenium språk- och webbläsaroberoende i stället för att vara någon Chrome-specifik nödlösning. Det renderar JavaScript, kör AJAX-anrop och kan klicka, scrolla och skriva precis som en människa.
Det gör Selenium rätt val för allt som kräver interaktion: flerstegs-inloggningar, guider, oändlig scroll, dropdown-menyer som triggar API-anrop. Men varje webbläsarsession är tung. Seleniums egen vägledning för Grid-storlek rekommenderar ungefär 1 GB RAM per webbläsarsession bara som tumregel — och då har du inte ens räknat med CPU-belastningen från själva renderingens arbete.
En detalj som ställer till det för många: att sidan är färdigladdad betyder inte att gränssnittet är redo. Seleniums dokumentation varnar dessutom för att blanda implicita och explicita väntetider eftersom tidsgränserna då snabbt blir oförutsägbara. Om ditt Selenium-skript är instabilt är det ofta därför.
Scrapy vs. Selenium: prestanda utan fejkade universalsiffror
En trovärdig benchmark måste redovisa målsidorna, cache-status, nätverksförhållanden, samtidighet, strategi för återanvändning av webbläsare, väntelogik och komplett kod. Utan den kontexten är siffror för sidor per minut marknadsföring, inte bevis. Den arkitektoniska jämförelsen är däremot fortfarande nyttig:
| Arbetsbelastning | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| Server-renderad HTML | Direkt HTTP-väg | Full webbläsarväg | Använd Scrapy:s direkta väg |
| Innehåll renderat med JavaScript | Kräver ytterligare renderer | Inbyggd webbläsarkörning | Selektiv webbläsarrendering |
| Samtidighetsmodell | Asynkron begärandeschemaläggare | Webbläsarsessioner hanteras av din kod eller Grid | Scrapy-schemaläggare plus webbläsarkontexter |
| Resursprofil | Ingen webbläsarrendering | Webbläsarens CPU- och minneskostnad | Webbläsarkostnad bara för markerade förfrågningar |
| Bästa mått | Objekt per minut vid säker felfrekvens | Slutförda flöden per minut vid säker felfrekvens | Separat mätning av statisk och renderad trafik |
Scrapy:s standardinställning för samtidiga begäranden är ett övre tak, inte ett löfte om faktisk genomströmning. Den verkliga hastigheten styrs av latens, begränsningar per domän, throttling, retries, svarsstorlek, parse-arbete och målsidans accepterade anropshastighet. Selenium kan återanvända en webbläsarsession, så det är inte i sig begränsat till en helt ny webbläsare per sida, men varje aktiv session kör och renderar fortfarande en webbläsarmiljö.
Hybridmodellen är lockande eftersom den låter vanliga förfrågningar gå via Scrapy:s HTTP-väg och bara skickar sidor som behöver rendering genom en webbläsare. Det minskar ofta webbläsarbelastningen, men det är inte automatiskt snabbare: mät statiska och renderade vägar var för sig, räkna med fel- och retry-frekvens och trimma samtidigheten utifrån både målsidans säkerhet och tillgängligt minne.
De viktigaste skillnaderna som påverkar ditt val
Hastighet är inte den enda variabeln. Några praktiska faktorer spelar minst lika stor roll när du kör detta i produktion.
JavaScript-rendering och dynamiskt innehåll
Scrapy ensam är blind för allt som renderas på klientsidan. Selenium ser allt eftersom det är en riktig webbläsare. Mellanläget — Scrapy-Splash (äldre, Lua-skriptbart) och scrapy-playwright (modern, rekommenderad) — låter dig rendera JS selektivt inom Scrapy:s crawl-loop i stället för att binda upp varje begäran till en full webbläsare. Om 80–90 % av målsidorna är statisk HTML och bara några få behöver JS är selektiv rendering den självklara arkitekturen. Att rendera allt i webbläsaren bara för att några sidor kräver det är slöseri med resurser.
Skalbarhet och samtidighet
Att skala Scrapy från 1 000 sidor till 1 000 000 är mest en fråga om drift: öka antalet samtidiga förfrågningar, kanske fördela över flera workers med Redis. Att skala Selenium betyder att du linjärt lägger till webbläsarinstanser, vilket innebär linjärt mer RAM och CPU, vilket i sin tur betyder att du nu driver en webbläsarflotta med Selenium Grid och måste hantera återhämtning efter krascher. Det är inte så att Selenium inte kan skala — det är bara att skalningen är ett infrastrukturprojekt, inte en konfigurationsändring.
Datapipelines och export
Scrapy:s item pipeline hanterar validering, deduplicering och export till JSON, CSV eller databas som en inbyggd funktion. Selenium ger dig inget av det här — du får skriva din egen serialisering och lagringslogik från grunden. Om datakvalitet och vidare integration är viktigt för dig (och det borde det vara) är det här ett tydligt försprång Scrapy ger dig gratis.
Underhåll och långsiktig tillförlitlighet
Ett mönster jag har lagt märke till: Scrapy-spiders tenderar att åldras ganska bra eftersom den middleware-baserade arkitekturen tvingar fram viss struktur. Selenium-skript blir lätt sköra — webbläsaruppdateringar bryter drivrutiner, timingproblem skapar instabila körningar och varje DOM-ändring kräver uppdaterade selektorer. Jag har sett utvecklare i forum säga rakt ut att en Selenium-baserad scraper "inte verkar vara det bästa valet för något vi ska sälja till en kund", och ärligt talat är den magkänslan korrekt om projektet ska överleva mer än några månader utan beröring.
Verkligheten kring anti-bot: hur varje verktyg står sig mot 2026 års skydd
Det här är delen som alla andra jämförelser ofta hoppar över, och det är just den delen som avgör om din scraper fungerar alls. Varken Scrapy eller Selenium byggdes med modern anti-bot-infrastruktur i åtanke, och att låtsas något annat bäddar bara för en obehaglig överraskning i produktion.
| Skyddsnivå | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS-rendering | ❌ Kräver middleware | ✅ | ✅ | ✅ Inbyggt |
| TLS-fingeravtryck | ⚠️ Upptäckbart | ⚠️ Upptäckbart | ⚠️ Bättre, men inte löst | ✅ Hanteras |
| CAPTCHA-lösning | ❌ Manuellt | ❌ Manuellt | ❌ Manuellt | ✅ Inbyggt |
| Rotering av rate limit | ⚠️ Egen proxyhantering | ⚠️ Egen proxyhantering | ⚠️ Egen proxyhantering | ✅ Hanterat |
Scrapy misslyckas direkt med browser fingerprint-kontroller eftersom det inte finns någon webbläsare att fingerprinta från början — det är bara en HTTP-klient, och många anti-bot-leverantörer flaggar trafik som inte ser ut att komma från en riktig webbläsare. Selenium passerar grundläggande JS-kontroller eftersom det är en riktig webbläsare, men det går att upptäcka via signaler som navigator.webdriver, en standardiserad flagga som är sann vid automatisering. Patcher som undetected-chromedriver försöker maskera detta, men de spelar ständigt katt-och-råtta med detektorer som uppdaterar sina signaturer regelbundet.
Smugglingsarmkapplöpningen (och varför egen lösning är skör)
Här är den obekväma sanningen om anti-detektion-patcher: de är ett löpband av underhåll, inte en lösning. undetected-chromedriver och playwright-stealth fungerar tills Cloudflare Turnstile eller DataDome släpper en uppdatering som fångar tekniken de använde. Sedan patchar du igen. Jag har sett team lägga mer ingenjörstid på att hålla stealth-lagret vid liv än de lade på att bygga själva scrapen.
Rate limiting förtjänar också ett eget omnämnande. När en server svarar med 429 Too Many Requests är Retry-After-headern en rekommendation, inte ett tvång — många sajter skickar den inte alls, och vissa stryper dig genom andra signaler helt och hållet. Scrapy:s AutoThrottle hjälper genom att justera fördröjning baserat på observerad latens, men det är reaktivt, inte förebyggande.
Det är här ett hanterat extraktions-API verkligen förtjänar sin plats — anti-bot-hanteringen blir någon annans problem i stället för ditt. Mer om det längre fram.
Playwright-faktorn: varför "Scrapy vs. Selenium" inte längre räcker som ram
Att göra detta till en tvåpartsdebatt missar det som faktiskt hänt i scraper-världen de senaste åren. Utvecklarforum är fulla av personer som säger någon variant av "jag bytte från Selenium till Playwright och blev mycket nöjd" — och ändå nämner de flesta jämförelseartiklar Playwright bara i förbifarten, om alls.
Playwright, byggt av Microsoft, styr Chromium, Firefox och WebKit via ett enda API. Dess actionability-modell väntar tills element är synliga, stabila och faktiskt interaktiva innan en åtgärd utförs — vilket minskar den timing-baserade instabilitet som plågar många Selenium-skript. Det hanterar också browser contexts effektivare, så att du kan spinna upp isolerade sessioner utan kostnaden av att starta en helt ny webbläsare varje gång.
När Playwright helt ersätter Selenium
För just scraping — inte webbläsartestning där man redan har Selenium-infrastruktur — är Playwright ofta helt enkelt det bättre verktyget år 2026. Snabbare skapande av kontexter, lägre resursförbrukning per sida, inbyggt async-stöd och nätverksinterception direkt i verktyget. Om du startar ett scraping-projekt från noll och inte har någon befintlig Selenium-testsvit att bevara finns det inte mycket som talar för att börja med Selenium.
Undantaget: om teamet redan har Selenium-baserad testinfrastruktur, eller om du behöver mycket specifik anpassning av webbläsarprofiler som Playwright inte stödjer lika smidigt, har Selenium fortfarande sin plats.
Så fungerar scrapy-playwright
scrapy-playwright är en download handler för Scrapy som skickar endast förfrågningar märkta meta={"playwright": True} genom en riktig webbläsare — allt annat stannar på Scrapy:s snabba asynkrona HTTP-väg. Här är ett förenklat exempel på en spider som crawlar en paginerad katalog där produktkort renderas via klient-side JS:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Bara sidor som faktiskt behöver rendering går genom webbläsaren. Det är hela poängen med hybridmodellen — du betalar inte webbläsarskatten för varje enda begäran, bara för de som kräver det.
Scrapy-Splash vs. Scrapy-Playwright: vilken middleware ska du använda?
Scrapy-Splash kräver att du kör en separat Splash Docker-tjänst och skriver Lua-skript för interaktion — det fungerar, men det är en tyngre och äldre lösning. scrapy-playwright integreras direkt i Scrapy:s asynkrona event loop, stöder alla tre stora webbläsarmotorer och hanterar komplexa interaktioner utan att du måste haka på ett andra skriptspråk. Om du startar ett nytt projekt år 2026 finns det i praktiken ingen anledning att välja Splash längre.
Hybridarkitektur redo för produktion
De flesta artiklar säger "du kan kombinera Scrapy och Selenium" och lämnar det där. Det är inte en arkitektur. Det är ett förslag. Så här ser en riktig produktionslösning ut.
Flödet: en Scrapy-schemaläggare skickar begäranden genom en URL-router som avgör om en sida är statisk eller dynamisk. Statiska begäranden går direkt genom Scrapy:s vanliga downloader. Dynamiska begäranden märks upp och skickas till Playwright-middleware, som hanterar en pool av webbläsarkontexter. Båda vägarna möts sedan i samma item pipeline för validering, deduplicering och export — oavsett om datan kom från rå HTML eller en renderad DOM hamnar den i samma JSON-, CSV- eller databasoutput.
Några driftanvisningar om du tar detta till produktion: containerisera med Docker så att Playwrights webbläsarbinaries följer med konsekvent mellan miljöer, sätt ett tak för samtidiga Playwright-kontekster baserat på tillgängligt RAM (jag skulle inte gå över 8–10 kontexter på en vanlig maskin med 4 GB), och kör schemalagda jobb via cron eller en CI/CD-pipeline i stället för att låta en process stå och snurra för evigt.
Den här lösningen ger maximal kontroll. Den innebär också att du nu ansvarar för uppdateringar av webbläsarbinärer, buggar i kontextlivscykeln (öppna sidor som aldrig stängs stoppar en crawl), proxyrotation och de anti-bot-patchar du behöver lägga ovanpå. Det är ett rejält ingenjörsåtagande, och det är värt att vara ärlig med det innan du säger ja.
För team som vill ha strukturerad output utan att äga den infrastrukturen tar Thunderbit:s CLI ett annat grepp om samma problem:
thunderbit batch extract --schema schema.json --file urls.txt
Samma strukturerade JSON-output. Ingen spider-kod, ingen browser pool, inget anti-bot-plumbing att underhålla. Du byter en del anpassningsmöjligheter mot snabbare väg till produktion — det är en legitim avvägning, inte en universell uppgradering, och den beror helt på hur mycket kontroll projektet faktiskt kräver.
Vägen där du hoppar över ramverket: när ett AI-skrapnings-API slår båda
Förr eller senare inser en utvecklare att de egentligen inte behöver ett crawl-ramverk. De behöver strukturerad data från 500 kända URL:er, och att bygga en spider, en browser pool och ett anti-bot-lager för det känns som överkurs — för det är det oftast också.
Det är just det gapet Thunderbit är byggt för att fylla, och jag säger det direkt: det ersätter inte Scrapy i en komplex, rekursiv crawl med egen logik. Det är ett annat verktyg för ett annat, smalare problem.
Open API: POST /extract tar ett JSON Schema och returnerar strukturerad data som matchar det — inte rå HTML och inte en hög Markdown du själv måste tolka. POST /distill gör motsatsen och returnerar ren Markdown som är redo att matas in i en RAG-pipeline eller en LLM. Den hanterade tjänsten stödjer JavaScript-rendering och anti-bot-hantering, så du behöver inte sköta den infrastrukturen själv. Den aktuella Distill vs. Extract-guiden anger 1 kredit per Distill-sida och 20 per Extract-sida; kontrollera alltid live-dokumentationen innan du budgeterar, eftersom produktvillkor kan ändras.
MCP Server: för AI-agenter som Claude eller Cursor exponerar Thunderbits MCP-server distillering, strukturerad extraktion, fältförslag och batchjobb som verktyg, så att en agent kan hämta färska webbdata mitt i en uppgift utan att lämna sin miljö.
CLI: den dokumenterade Thunderbit CLI stödjer kommandon som thunderbit extract <url> --schema schema.json och passar bra i terminalflöden och schemalagda jobb. Du kan även skicka destillerad Markdown vidare till ett annat verktyg för snabba engångsuppgifter i research.
Om du hellre vill hoppa över kod helt täcker Thunderbit Chrome Extension samma område med ett klickgränssnitt, vilket är värt att titta på om teamet inkluderar icke-utvecklare som behöver data utan att röra terminalen. Jag har skrivit mer om det bredare landskapet för AI web scraping och web scraping utan kod om du vill ha hela bilden.
Var ärlig med dig själv om vilket läger du faktiskt tillhör: Scrapy är fortfarande rätt val för komplexa crawl över flera sajter med egen logik och rekursiv länkföljning. Selenium eller Playwright passar för interaktionstunga flöden. Men "jag behöver strukturerad data från de här kända URL:erna" är ett smalare problem än något av verktygen egentligen designades för, och ett API kan på riktigt eliminera spider-koden, anti-bot-plumbingen och det löpande underhåll som följer med att äga den infrastrukturen själv.
Scrapy vs. Selenium vs. Playwright vs. AI API: sida vid sida
| Funktion | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Språkstöd | Endast Python | Python, Java, C#, JS, Ruby | Python | REST (alla språk) |
| JS-rendering | Nej (kräver middleware) | Ja | Ja | Ja, inbyggt |
| Async/samtidighet | Inbyggt, hög | Begränsat per instans | Inbyggt via Scrapy | Hanteras på serversidan |
| Anti-bot-hantering | Egen lösning | Egen lösning | Delvis | Inbyggt |
| Datapipeline/export | Inbyggt | Egen lösning | Inbyggt | Strukturerad JSON ut |
| Installationskomplexitet | Måttlig | Låg att börja med, hög i skala | Måttlig till hög | Minimal |
| Underhållsbörda | Låg till måttlig | Hög | Måttlig | Nästan noll |
| Bäst för | Stora statiska crawls | Interaktionsintensiva flöden | Blandade statiska/dynamiska sajter | Kända URL:er, strukturerad output |
Om du väger andra scraper-alternativ utöver dessa fyra kan det också vara värt en titt på hur Instant Data Scraper-alternativ och de bästa AI-webscraparna står sig — landskapet har blivit trångt, och alla verktyg löser inte samma problem.
Juridiska och etiska aspekter för web scraping år 2026
Kort här eftersom det inte är huvudfokus, men det är viktigt. Scrapy:s inställning ROBOTSTXT_OBEY gör att din spider följer robots.txt-regler — god praxis, men det är bra att känna till att Robots Exclusion Protocol uttryckligen säger att dess regler inte är ett juridiskt tillstånd att få tillgång. Selenium och Playwright har inget inbyggt stöd för robots.txt-efterlevnad alls — det är helt upp till dig att implementera. Oavsett verktyg bör du kontrollera sajtens villkor och tillämplig lag i din jurisdiktion innan du skrapar och återanvänder data; "det är offentligt synligt" är inte automatiskt ett juridiskt frikort överallt.
Att välja rätt verktyg för ditt scraping-projekt år 2026
Beslutet kokar egentligen ner till fyra frågor: vilken typ av innehåll det gäller, vilken skala du behöver, hur mycket interaktion som krävs och hur mycket löpande underhåll du är beredd att ta på dig. Statiska sidor i riktig skala? Välj Scrapy. JS-tunga sidor med faktisk interaktion? Välj Selenium eller Playwright. En blandning av båda? Bygg hybridlösningen. Kända URL:er där du bara behöver strukturerad data med minimalt underhåll? Ett API som Thunderbits sparar sannolikt mer tid än det kostar.
"Scrapy vs. Selenium" var aldrig hela frågan — det var bara den enda ramen som fanns då. Playwright förändrade mellanläget, och AI-baserade extraktions-API:er skapade en helt ny bana för dem som insåg att de byggde infrastruktur i stället för att lösa ett affärsproblem. Värt att testa den kostnadsfria nivån innan du låser dig vid något av spåren — suggest-fields är gratis och distill kostar bara en kredit, så du kan snabbt se om API-vägen passar innan du skriver en enda rad spider-kod.
Vanliga frågor
Är Scrapy snabbare än Selenium för web scraping? Enligt mina tester: ja — ofta med en ordningens skillnad på statiska sidor, eftersom Scrapy:s asynkrona arkitektur hoppar över webbläsarens overhead helt. Gapet blir mindre när Scrapy använder Playwright-middleware för JS-tunga sidor, men Scrapy vinner ändå på total genomströmning i blandade arbetslaster eftersom de sidor som inte kräver JS ligger kvar på den snabba vägen.
Kan Scrapy hantera sidor som renderas med JavaScript?
Inte på egen hand — Scrapy ser bara den initiala HTML-svaret. Genom att lägga till scrapy-playwright eller den äldre Scrapy-Splash som middleware kan du rendera utvalda förfrågningar via en riktig webbläsare medan resten av crawlen fortsätter på Scrapy:s inbyggda, snabbare väg.
När ska jag använda Selenium i stället för Scrapy? När du behöver full webbläsarinteraktion — flerstegs-inloggningar, klicka sig igenom guider, fylla i formulär — och sidantalet är måttligt snarare än enormt. Det är också det rimliga valet om du redan har Selenium-baserad testinfrastruktur som du vill återanvända för scraping.
Är Playwright bättre än Selenium för scraping år 2026? För scraping specifikt, oftast ja — Playwright brukar ge bättre prestanda, inbyggd auto-wait och lägre resursförbrukning per webbläsarkontext. Selenium behåller dock ett övertag för team som redan kör etablerade testsviter för flera webbläsare som Playwright inte var byggt för att ersätta.
Vad är ett AI scraping API och när ersätter det Scrapy eller Selenium? Ett AI scraping API, som Thunderbits Open API, hanterar JS-rendering, anti-bot-skydd och dataextraktion på serversidan och skickar tillbaka strukturerad JSON som matchar ett schema du definierar. Det är rätt val när du har kända URL:er och behöver strukturerad output utan att bygga eller underhålla crawl-infrastruktur — det ersätter inte Scrapy för komplexa, rekursiva crawls med egen logik.
Läs mer
