Ce este web scraping și cum funcționează un pipeline de date

Web scraping înseamnă să extragi automat date dintr-o pagină web, fără să le copiezi manual. Un program cere pagina, citește conținutul și scoate exact câmpurile de care ai nevoie — prețuri, anunțuri, specificații, recenzii — apoi le pune într-un format pe care îl poți folosi mai departe.

Sună simplu. În practică, un scraper care merge azi poate să returneze pagini goale mâine, fără ca tu să fi schimbat o linie de cod. Site-ul țintă și-a actualizat apărarea anti-bot sau și-a rearanjat structura paginii. De aceea web scraping-ul fiabil nu e despre o singură funcție de extragere, ci despre un pipeline: un lanț de pași prin care datele trec de la pagina brută la un set curat, structurat și livrabil.

Articolul ăsta îți arată ce e web scraping-ul, cum arată un pipeline de date end-to-end, unde merită să-l folosești și unde nu, și ce anume îl face fragil — inclusiv ce e legal și ce nu în România și în UE.

Ce este web scraping, mai exact

Web scraping e procesul automat de a colecta date de pe site-uri și de a le transforma din HTML, gândit pentru ochi umani, în date structurate, gândite pentru cod. Diferența față de o vizită obișnuită pe site e că un scraper face asta la scară: zeci, mii sau milioane de pagini, repetat, după un program.

Două lucruri se confundă des cu scraping-ul:

• Accesul prin API. Dacă site-ul oferă un API oficial, îl folosești pe acela. E mai stabil, mai rapid și clar permis. Scraping-ul intervine tocmai când nu există API sau când API-ul nu expune datele de care ai nevoie.
• Crawling-ul. Un crawler descoperă și parcurge linkuri ca să găsească pagini (cum face Googlebot). Scraping-ul extrage datele dintr-o pagină odată ce ai ajuns la ea. În pipeline-uri reale, cele două lucrează împreună: crawling ca să găsești paginile, scraping ca să scoți datele din ele.

Anatomia unui pipeline de date end-to-end

Un scraper de o singură pagină e un script. Un sistem care livrează date de încredere, zi după zi, e un pipeline. Are patru etape, fiecare cu propriile probleme.

1. Extragere

Aici ceri pagina și primești conținutul brut. Pentru pagini server-rendered (HTML complet în răspuns), o cerere HTTP simplă e de ajuns. Pentru pagini care își construiesc conținutul din JavaScript după încărcare, ai nevoie de un browser headless care chiar randează pagina. Tot aici decizi ritmul: câte cereri pe secundă trimiți, ca să nu suprasoliciți serverul țintă și să nu fii blocat.

2. Parsare

Ai HTML-ul; acum scoți din el doar câmpurile utile. Folosești selectori CSS sau XPath ca să țintești elementele — titlul produsului, prețul, data — și un parser care navighează structura paginii. Pentru text liber, regex-ul ajută la extras pattern-uri (un cod, un număr de telefon). Uneori datele sunt deja într-un API intern pe care pagina îl apelează, și e mai curat să iei JSON-ul direct de acolo.

3. Curățare și structurare

Datele brute sunt murdare: prețuri ca text cu simbol valutar, date în formate diferite, câmpuri lipsă, duplicate. Aici le normalizezi (un preț devine număr, o dată devine dată), le pui într-o schemă clară cu tipuri, elimini duplicatele și marchezi înregistrările cu erori în loc să le arunci. Etapa asta decide dacă datele tale sunt utilizabile sau doar un morman de string-uri.

4. Stocare și livrare

La final, pui datele unde se folosesc: un fișier JSON sau CSV, o bază de date, un API intern, un feed către altă aplicație. Dacă datele alimentează un sistem AI, aici intri în zona de embeddings pentru o bază de cunoștințe sau un sistem RAG.

Peste cele patru etape stă un strat pe care îl uită mulți: monitorizarea. Un pipeline serios reîncearcă automat cererile eșuate, te alertează când o pagină își schimbă structura și ține evidența ratei de succes. Fără el, afli că scraperul e stricat abia când raportul de luni e gol.

Cu ce extragi datele: peisajul de unelte

Nu există o singură unealtă de web scraping; există straturi, și alegi câte una pentru fiecare. Un mod util de a privi piața din 2026 e pe cele patru straturi ale pipeline-ului:

• Acces (fetch, randare, deblocare). Aici trăiesc clienții HTTP rapizi precum requests și httpx, browserele headless precum Playwright (Microsoft), Puppeteer (Google) și Selenium, plus serviciile managed care ascund proxy-uri, randare și ocolirea anti-bot în spatele unui apel API (Apify, Bright Data, Scrapfly, Zyte, Firecrawl și altele).
• Parsare (HTML în date). BeautifulSoup și lxml în Python, Cheerio în Node transformă HTML-ul murdar în obiecte din care selectezi câmpuri.
• Orchestrare (cozi, reîncercări, scară). Framework-urile precum Scrapy (Python) și Crawlee (JavaScript/TypeScript, de la Apify) țin starea unui crawl mare: cozi de cereri, reîncercări, rotație de sesiuni, persistența datelor. Scrapy domină ecosistemul Python pentru crawl-uri masive de HTML server-rendered; Crawlee comută automat între cereri HTTP rapide și browser când pagina cere randare.
• Stocare și export. De obicei codul tău: o bază de date, fișiere sau direct aplicația din aval.

Tendința din 2026 e dublă. Pe de o parte, un val de unelte orientate spre AI (Crawl4AI, Firecrawl) scot direct Markdown sau JSON curat, gata de băgat în embeddings — pentru că tot mai multe pipeline-uri hrănesc modele, nu oameni. Pe de altă parte, modelele de preț s-au fragmentat în credite, lățime de bandă, plată-per-succes și unități de calcul, ceea ce face comparațiile dificile. Prețurile se schimbă des, așa că verifică pagina fiecărui furnizor înainte să te bazezi pe o cifră. Care strat și care unealtă ți se potrivesc e subiectul articolului următor din serie, despre alegerea abordării.

Unde merge web scraping-ul — și unde nu

Scraping-ul strălucește când ai nevoie de date publice, la scară, pe care nimeni nu ți le dă structurat:

• Monitorizarea prețurilor și a concurenței — urmărești prețuri, stoc și oferte pe site-uri de e-commerce.
• Generare de lead-uri și îmbogățire de date — completezi profiluri de firme din surse publice (atenție la datele personale, vezi mai jos).
• Market intelligence — agregi anunțuri, listări și recenzii ca să vezi o piață întreagă.
• Date proaspete pentru AI — alimentezi o bază de cunoștințe sau un agent autonom care are nevoie de informație actuală, nu de ce știa modelul la antrenare.

Și unde nu e răspunsul potrivit:

• Când există un API oficial. Folosește-l. E mai stabil și clar permis.
• În spatele login-ului sau al paywall-ului. Aici intri în zona de risc contractual și legal — ocolirea unei autentificări e altă discuție decât citirea unei pagini publice.
• Pentru date personale fără temei legal. Faptul că un profil e public nu înseamnă că ai voie să-l procesezi (revenim imediat).
• La scară minusculă, în timp real. Dacă ai nevoie de o singură valoare, o singură dată, un scraper complet e prea mult.

Ce face scraping-ul fragil

Trei lucruri strică scrapere în producție, în ordinea în care le vei întâlni.

Sistemele anti-bot. În 2026, ăsta e zidul principal. Site-urile valoroase nu se mai mulțumesc să blocheze adrese IP — analizează handshake-ul TLS, mediul browserului, mișcările mouse-ului și ritmul cererilor, ca să decidă dacă ești om sau program. Furnizori ca Cloudflare, DataDome, Akamai, HUMAN (fost PerimeterX) și Kasada stivuiesc cinci straturi de detecție, iar o cerere trebuie să treacă de toate simultan.

Presiunea a crescut vizibil. Cloudflare a început să blocheze implicit scraping-ul pentru AI din iulie 2025. Raportul Global Bot Security pe 2025 al DataDome a constatat că traficul de boți a crescut de 4,5 ori în 2025, iar traficul generat de crawlerele de LLM-uri s-a multiplicat — de la circa 2,6% din boții verificați în ianuarie la peste 10% în august. Concret pentru tine: un script HTTP simplu are o amprentă TLS recunoscută instant ca automată, iar IP-urile de datacenter sunt semnalate din start; pe ținte protejate ai nevoie de browsere fortificate și de IP-uri rezidențiale.

Schimbările de structură a paginii (selector rot). Selectorii tăi depind de structura HTML a țintei. Site-ul își reface layout-ul, iar selectorii nu mai prind nimic. Scraperul nu dă o eroare zgomotoasă — returnează tăcut câmpuri goale. De aceea monitorizarea și alertele nu sunt lux, ci parte din pipeline.

Rate limits și costul de proxy. Trimiți prea multe cereri prea repede și primești throttling sau ban. Soluția — rotație de IP-uri rezidențiale, backoff, reîncercări — costă bani și complexitate. La scară, factura de proxy poate depăși costul unui serviciu managed, înainte să pui la socoteală orele de inginerie.

Ce e legal și ce nu: GDPR, ToS și robots.txt în România și UE

Web scraping-ul nu e ilegal în sine, dar legalitatea depinde de ce colectezi, cum colectezi și ce faci cu datele. Pentru cineva care operează din România, contează trei straturi.

Date publice vs. date din spatele autentificării. Linia care contează cel mai mult nu e adresa paginii, ci dacă datele sunt accesibile fără login. Jurisprudența recentă din SUA merge în direcția asta: în hiQ v. LinkedIn, instanța a stabilit că accesarea unor profiluri publice nu încalcă legea privind accesul neautorizat (CFAA) — dar cazul s-a încheiat cu hiQ plătind 500.000 de dolari pentru încălcarea termenilor de utilizare. În Meta v. Bright Data (2024), judecătorul a reținut că termenii Meta nu interzic scraping-ul de date publice atâta vreme cât ești delogat. Mesajul: datele publice, fără login, sunt zona cu risc mic; login-urile și paywall-urile mută discuția în drept contractual.

GDPR, când apar date personale. Aici e partea pe care o subestimează multă lume: un profil nu încetează să fie protejat doar pentru că e public. Sub GDPR — care se aplică oricărei persoane din UE, indiferent unde îți stă serverul — colectarea de date personale prin scraping te face operator de date și îți cere un temei legal. Cel mai folosit e interesul legitim, dar Opinia 28/2024 a Comitetului European pentru Protecția Datelor (EDPB) îl admite doar după un test strict în trei pași și recomandă explicit respectarea robots.txt și ai.txt ca măsură de atenuare. În practică: minimizează datele personale, documentează un test de interes legitim (LIA) înainte să procesezi identități din UE, și onorează dreptul oamenilor de a se opune și de a fi șterși. În România, autoritatea care supraveghează asta e ANSPDCP, iar amenzile GDPR ajung până la 20 de milioane de euro sau 4% din cifra de afaceri globală. Cazul Clearview AI — peste 91 de milioane de euro în amenzi în mai multe jurisdicții pentru colectarea de imagini faciale — arată că nu e o teorie.

Termeni de utilizare, robots.txt și drepturi conexe. Robots.txt nu e o lege, e o convenție. Nu te bagă la închisoare dacă îl ignori, dar ignorarea lui e folosită ca dovadă de rea-credință în instanță și e cea mai rapidă cale să-ți blochezi IP-ul. Termenii de utilizare sunt un contract: încălcarea lor poate atrage răspundere contractuală, cu rezultate care variază de la caz la caz. În plus, UE adaugă straturi pe care SUA nu le are — Directiva privind bazele de date (un drept sui generis asupra structurilor de date) și opt-out-ul pentru text and data mining din Directiva privind dreptul de autor, relevant mai ales dacă antrenezi modele. Un semnal recent: Reddit a dat în judecată Perplexity AI la final de 2025, invocând ocolirea unor măsuri tehnice precum rate limits și sisteme anti-bot.

Regula practică, indiferent de jurisdicție: rămâi pe date publice, nepersonale; respectă robots.txt și un ritm rezonabil; păstrează dovezi (versiunea termenilor, un snapshot al robots.txt, log-uri cu concurență mică); și, pentru orice proiect care atinge date personale sau antrenare de modele, cere o evaluare juridică. Articolul ăsta e orientativ, nu consultanță juridică.

Întrebări frecvente

Web scraping-ul e legal în România?

Da, în general, dacă rămâi pe date publice, nepersonale, nu ocolești autentificări și respecți robots.txt și un ritm rezonabil. Problemele apar la date personale (intră GDPR, supravegheat de ANSPDCP), la conținut din spatele login-ului și la încălcarea termenilor de utilizare. Pentru date personale sau antrenare de modele, cere o evaluare juridică.

Care e diferența dintre web scraping și crawling?

Crawling-ul descoperă și parcurge pagini urmărind linkuri (ce face un motor de căutare). Scraping-ul extrage datele dintr-o pagină după ce ai ajuns la ea. În pipeline-uri reale lucrează împreună: crawling ca să găsești paginile, scraping ca să scoți datele.

Am nevoie de browser headless ca să fac scraping?

Depinde de pagină. Pentru pagini server-rendered, cu HTML complet în răspuns, o cerere HTTP simplă e suficientă și mult mai rapidă. Pentru pagini care își construiesc conținutul din JavaScript, ai nevoie de un browser headless precum Playwright sau Puppeteer, care chiar randează pagina.

De ce se strică scraperele care funcționau ieri?

Două cauze frecvente: site-ul țintă și-a actualizat sistemul anti-bot și acum îți blochează cererile, sau și-a schimbat structura HTML și selectorii tăi nu mai prind nimic. A doua e insidioasă, pentru că scraperul returnează tăcut câmpuri goale. De asta un pipeline serios are monitorizare și alerte.

Scraping cu cod propriu sau cu un serviciu managed?

Cu cod (Scrapy, Playwright, Crawlee) ai control total, dar deții infrastructura, proxy-urile și mentenanța. Cu un serviciu managed (Apify, Bright Data și altele) plătești ca să ascunzi proxy-uri, randare și anti-bot în spatele unui API. La scară și pe ținte bine protejate, factura de proxy plus orele de inginerie pot face serviciul managed mai ieftin decât pare. Comparația în detaliu vine în articolul următor din serie.

Pasul următor

Web scraping-ul fiabil nu e un script, ci un pipeline cu patru etape, monitorizare deasupra și o disciplină de conformitate dedesubt. Dacă vrei să construiești o sursă de date proaspete — pentru monitorizare, pentru lead-uri sau ca să hrănești un sistem AI — vezi ce acoperă serviciul de web scraping și data pipelines și restul ghidurilor din Fundamente scraping. Urmează, în serie: cum alegi abordarea potrivită — cod, API sau serviciu no-code.