Guida

Perché il tuo scraper no-code continua a rompersi (e cosa lo risolve davvero)

Gli scraper no-code sono perfetti per un proof of concept veloce. Ma un feed da cui dipendi davvero tende a rompersi qualche settimana dopo — in silenzio, nel momento peggiore. Ecco perché succede quando estrai da fonti pubbliche, e il setup mantenuto che tiene il flusso di dati attivo.

I quattro modi in cui uno scraper no-code si rompe

1. Il layout della pagina è cambiato

La maggior parte dei tool point-and-click funziona memorizzando dove si trova un elemento nella pagina: "il prezzo è il terzo span dentro questo div". Nel momento in cui il sito rilascia un redesign — o anche un piccolo A/B test — quel percorso non punta più al prezzo. Lo scraper non dà errore: restituisce tranquillamente la cella sbagliata, o niente del tutto. Te ne accorgi solo quando un report a valle sembra strano. Cataloghi pubblici e portali di annunci cambiano markup di continuo, quindi un selettore basato sulla posizione è la cosa più fragile su cui costruire un feed.

2. I dati sono renderizzati da JavaScript

Molti siti moderni inviano un guscio HTML quasi vuoto, poi caricano il contenuto vero con JavaScript dopo il caricamento della pagina. Un tool che si limita a scaricare l'HTML vede il guscio e conclude che "non ci sono dati". I valori sono pubblici e visibili in un browser normale — arrivano solo un passo dopo rispetto a quando il tool guarda. Senza un vero step di rendering (o un approccio più intelligente, vedi sotto), ottieni campi vuoti che vanno e vengono a seconda dei tempi.

3. L'handshake sembra automatizzato

Alcuni siti pubblici esaminano la firma tecnica del client che si connette — l'handshake TLS e gli header che un browser presenta — prima di renderizzare qualsiasi cosa. Una libreria di scripting standard ha una firma che non corrisponde a un browser reale, così il server restituisce una pagina vuota o minimale. Non è un muro di login e non è un CAPTCHA: è il sito che decide che la richiesta non sembrava arrivare da un normale visitatore. La soluzione è leggere la pagina pubblica con una sessione browser dall'impronta corretta, a un ritmo rispettoso, come farebbe un normale visitatore. (Lo approfondisco nella guida sui siti pubblici protetti da Cloudflare.)

4. Limiti di frequenza e problemi di IP

Lancia troppe richieste troppo in fretta da un solo indirizzo e un sito pubblico inizierà a rallentarti o a restituire errori — giustamente. I tool no-code raramente ti danno un controllo fine su ritmo, retry o back-off graduale. Così un feed che funzionava a cinque pagine al giorno crolla il giorno in cui lo porti a cinquecento. Rispettare robots.txt, onorare il crawl-delay e distribuire le richieste nel tempo non è opzionale: è ciò che tiene l'accesso stabile nel lungo periodo.

Cosa lo risolve davvero

L'affidabilità sui dati pubblici non è un trucco — è un piccolo sistema che si aspetta il cambiamento e lo assorbe.

Uno scraper mantenuto, non congelato. Selettori scritti in modo difensivo (match su testo e struttura stabili, non su posizioni fragili), più qualcuno che li ripara quando il sito rilascia un redesign. Un feed è una relazione, non un export una tantum.
Usare un'API nascosta dove esiste. Molti siti che renderizzano con JavaScript chiamano in silenzio il proprio endpoint JSON per ottenere i dati. Leggere quell'endpoint è enormemente più stabile che fare parsing dell'HTML, perché i campi JSON cambiano molto meno spesso del layout visivo. Vedi che cos'è una API nascosta.
Una sessione browser con l'impronta corretta per i siti che controllano l'handshake prima di renderizzare — così la pagina pubblica si carica come per qualsiasi visitatore, a un ritmo educato.
Monitoraggio e avvisi. La differenza più grande tra uno scraper amatoriale e un feed affidabile è che il feed ti avvisa nel momento in cui un campo si svuota o il numero di righe cala — prima che arrivi alla tua dashboard. Il guasto silenzioso è il vero nemico.
Disciplina di frequenza fin dal design. Ritmo, retry con back-off e rispetto di robots.txt integrati, così l'accesso resta sano mentre il volume cresce.

Il principio dietro tutto questo: mi concentro sull'affidabilità su dati pubblici e fattuali — prezzi prodotto, campi di annunci, voci di cataloghi pubblici. Tu gestisci e possiedi i dati risultanti. Lavoro entro i termini e i limiti di frequenza di ogni sito, e non tocco mai informazioni personali o dietro login.

Quando smettere di rattoppare e passare a un feed vero

Se hai ricostruito lo stesso flusso no-code tre volte in un trimestre, il problema non è il tool — è l'approccio. Uno scraper mantenuto, con un'API nascosta dove disponibile, monitoraggio e limiti di frequenza sensati, trasforma un export instabile in qualcosa su cui costruire con tranquillità. È tutto il senso di un feed di dati gestito: smetti di pensarci.