Il parser ha funzionato per sei mesi, ma oggi nel database sono state inserite righe vuote. La prima idea è che sia stato bloccato, quindi è necessario cambiare proxy. Cambiate il pool, migliorate la qualità degli IP, pagate per quelli residenziali invece di quelli dei data center — eppure i campi rimangono vuoti. Perché la causa non era il blocco: il sito è passato a un nuovo layout, e il vostro selettore CSS non è più agganciato a nulla.
Questo è il tipo di guasto più costoso, perché rimane silenzioso. Il ban è visibile immediatamente: 403, captcha, redirect. La deriva del layout non fa cadere nulla — HTTP 200, pagina ricevuta, traffico pagato, ma in uscita None. Analizziamo come distinguere in cinque minuti l'uno dall'altro e come smettere di riscrivere i selettori manualmente dopo ogni redesign.
A chi serve
Guida per chi tiene il parser in produzione per più di uno sprint: monitoraggio dei prezzi dei concorrenti, raccolta di recensioni, aggregazione di offerte di lavoro, scaricamenti quotidiani per l'analisi. Se lanciate lo script una sola volta e lo buttate — la deriva del layout non vi riguarda. Se lo script gira tramite cron per mesi, questa è la vostra principale voce di spesa per il supporto.
La scala del problema non è inventata. Secondo gli analisti di GroupBWT, le modifiche strutturali incontrollate dei siti comportano circa 40–60% di costi ripetitivi per il supporto dei scraper nei grandi progetti. In alcuni settori, 10–15% dei crawler richiedono riparazioni settimanalmente — a causa degli spostamenti del DOM, fingerprinting e throttling degli endpoint. In altre parole, la riparazione dei selettori compete in costi con l'aggiramento degli anti-bot, ma riceve molte meno attenzioni.
Il contesto non è affatto buono: nel rapporto di Apify "State of Web Scraping 2026", 65,8% dei rispondenti ha aumentato l'uso dei proxy, 58,3% ha segnalato un aumento delle spese per i proxy anno su anno, e oltre 62% ha riportato un aumento generale dei costi infrastrutturali, principalmente a causa dell'intensificata protezione contro i bot. In questo contesto, bruciare traffico pagato su pagine da cui non estraete nulla è doppiamente frustrante.
Passo 1. Distinguere un ban dalla deriva del layout
La diagnosi richiede pochi minuti e deve essere eseguita rigorosamente in ordine — altrimenti è facile "riparare" il guasto sbagliato.
- Controllate il codice di risposta e la dimensione del corpo. 403, 429, 503, redirect su una pagina di verifica o corpo di 2–5 KB — questo è un anti-bot. HTTP 200 e una pagina completa di 200–800 KB — il sito vi ha accolto, non è un problema di proxy.
- Salvate l'HTML grezzo su disco e apritelo a occhio. Non nel debugger, ma nel browser. Se il prodotto/recensione/prezzo è presente, ma il parser non lo vede — è una deriva del layout.
- Trovate il testo necessario cercando nel file. È presente nell'HTML, ma non è accessibile tramite il vostro selettore — il markup è cambiato. Non è presente affatto — il contenuto viene caricato tramite script, è necessario un motore browser, non una richiesta HTTP.
- Confrontate con l'ultima estrazione riuscita. Differenziate il vecchio e il nuovo HTML dello stesso URL: di solito si vede subito una nuova classe di wrapper, un blocco spostato o la sostituzione di
idcondata-*. - Verificate se il sito ha restituito una versione diversa della pagina. Di questo parleremo separatamente più avanti, perché qui i proxy sono comunque coinvolti.
Se dopo il terzo punto la diagnosi è "il markup è andato", cambiare proxy è inutile. Serve un parser in grado di trovare l'elemento, anche quando il selettore è scaduto.
Passo 2. Cosa sono i selettori adattivi
L'idea è semplice: invece di legarsi rigidamente alla stringa .product-card > h3.title, la libreria memorizza una volta il "ritratto" dell'elemento desiderato e alla successiva esecuzione cerca l'elemento più simile a quel ritratto sulla pagina.
La realizzazione più pratica di questo è in Scrapling — un framework Python open source di Karim Shoair. Il progetto è stato lanciato nell'ottobre 2024 e entro settembre 2026 ha raccolto oltre 78.000 stelle su GitHub; l'ultima release al momento della scrittura è v0.4.15 del 23 agosto 2026, i commit avvengono quotidianamente. È richiesto Python 3.10+.
La meccanica della ricerca adattiva è strutturata in questo modo. Quando invocate il selettore con auto_save=True, Scrapling salva l'impronta dell'elemento:
- nome del tag, testo e tutti gli attributi con i loro valori;
- nomi dei tag vicini;
- percorso fino all'elemento — solo per nomi di tag;
- tag, attributi e testo del genitore.
L'impronta viene salvata in un database locale SQLite e indicizzata da una coppia "dominio + identificatore". Il dominio viene preso dall'URL della pagina (o impostato tramite il parametro adaptive_domain), l'identificatore di default è la stessa stringa del selettore — oppure il vostro, se passate identifier=.
Quando il layout cambia e il selettore normale restituisce vuoto, la chiamata con adaptive=True recupera l'impronta salvata e la esegue su tutti gli elementi della pagina, calcolando una valutazione sfocata della somiglianza — fino all'ordine degli attributi. Viene restituito l'elemento con la massima corrispondenza.
Il costo è basso. Secondo i benchmark ufficiali del progetto, il parsing richiede 1,99 ms contro 2,01 ms di Parsel/Scrapy, 22,93 ms di PyQuery, 80,57 ms di Selectolax e 1541 ms di BeautifulSoup con lxml. La ricerca adattiva di un elemento simile richiede 2,46 ms contro 13,3 ms di AutoScraper. In altre parole, l'assicurazione contro il redesign aggiunge circa due millisecondi alla richiesta, rispetto ai ritardi di rete di centinaia di millisecondi.
Passo 3. Installiamo e attiviamo
L'installazione dipende da se avete bisogno di un browser:
pip install scrapling— solo il parser, senza la parte di rete. Sufficiente se ricevete l'HTML con il vostro codice.pip install "scrapling[fetchers]", poiscrapling install— aggiunge i fetchers e scarica i browser con le dipendenze.- In aggiunta:
[ai]— server MCP,[rag]— wrapper per RAG,[shell]— console interattiva,[all]— tutto insieme. È disponibile un'immagine prontapyd4vinci/scrapling.
Successivamente, ci sono due esecuzioni. La prima su un layout di lavoro attivo salva l'impronta, la seconda è già in grado di sopravvivere a un redesign:
- Esecuzione di riferimento. Create un oggetto
Selectorconadaptive=Truee assicuratevi di passareurl— altrimenti il dominio andrà a finire nella chiave"default", e le impronte di diversi siti si mescoleranno. Invocate il selettore necessario conauto_save=True. - Esecuzione operativa. Lo stesso selettore, ma con
adaptive=True. Finché il markup è intatto, funzionerà il percorso normale. Quando si romperà — si attiverà la ricerca per somiglianza. - Registrate le discrepanze. Il momento in cui il selettore normale restituisce vuoto, mentre quello adattivo trova qualcosa, è un segnale "il sito è cambiato", deve essere visibile nel monitoraggio, non inghiottito in silenzio.
Un dettaglio importante sulla sovrascrittura: il salvataggio non si accumula. Un auto_save ripetuto per la stessa coppia "dominio + identificatore" sovrascrive l'impronta precedente. Pertanto, il riferimento viene preso su una pagina chiaramente corretta, e non in un ciclo su tutto il pool di URL.
Passo 4. Proxy: dove sono coinvolti
Siamo partiti dal presupposto che la deriva del layout non riguarda i proxy. Questo è vero solo a metà, e l'altra metà costa soldi.
Il sito può restituirvi un markup diverso a causa dell'uscita del proxy. La località, la lingua e il paese cambiano il modello della pagina: un diverso ordine dei blocchi, classi diverse, formati di prezzo e data diversi. Non è un'ipotesi — in Scrapling c'è una correzione esemplare: nella versione 0.4.12 da StealthyFetcher è stata rimossa la località forzata en-US, perché la località imposta non corrispondeva al reale geo e rompeva il comportamento. Da qui la regola operativa: prendete l'impronta di riferimento dallo stesso geo da cui poi raccogliete i dati. Un'impronta presa tramite un IP tedesco corrisponderà peggio alla pagina ricevuta tramite uno brasiliano — e riceverete un falso allerta "il sito ha cambiato layout".
Conseguenze pratiche:
- Se il pool è multistatale — separate le impronte tramite
adaptive_domain, impostando una chiave del tipo "dominio + paese". Altrimenti, una registrazione in SQLite verrà costantemente sovrascritta da versioni di diversi geo. - Per scenari lunghi mantenete un solo paese e una sola sessione per l'intero compito. Come organizzarlo è dettagliatamente trattato nel materiale su sessioni sticky e quando usarle.
- I test A/B e i rollout graduali forniscono contemporaneamente due layout attivi su un dominio. Qui la ricerca adattiva è particolarmente utile: estrarrà l'elemento da entrambi i rami, mentre un selettore rigido restituirà casualmente vuoto in metà delle richieste.
Impostare i proxy in Scrapling è possibile a tutti i livelli. Per richieste HTTP rapide, Fetcher e AsyncFetcher hanno un parametro proxies. Per le sessioni esiste ProxyRotator, a cui viene passato un elenco di indirizzi — viene inserito in FetcherSession. Le sessioni browser DynamicSession e StealthySession accettano proxy a livello di sessione, in modo che l'IP non cambi nel mezzo dello scenario.
Un'altra cosa che risparmia sia il pool che i nervi, è stata introdotta nella versione 0.4.12 — AutoThrottle: la libreria regola automaticamente le pause tra le richieste in base alle risposte del server, raddoppia il ritardo in caso di blocco e rispetta l'intestazione Retry-After. Questo è esattamente il comportamento che distingue una raccolta accurata da un'accelerazione dei ban tramite retry ingenui.
Insidie
- Non committate SQLite con impronte in git. Questo è esplicitamente avvertito dalla documentazione. Inoltre, non utilizzate
auto_savesu pagine con dati personali — nel'impronta finiscono testo e attributi dell'elemento. - La ricerca adattiva non sostituisce il monitoraggio. Restituirà l'elemento "più simile", ma il più simile non è sempre corretto. Se il sito ha scambiato il prezzo scontato con quello senza sconto, la somiglianza è alta, ma i dati sono errati. Mantenete controlli sul range di valori e sulla percentuale di campi vuoti nell'estrazione.
- Un guasto silenzioso è più costoso di uno rumoroso. Finché il selettore restituisce silenziosamente None, il pipeline continua a girare tra le pagine e a bruciare traffico pagato. C'è un'analisi separata su quanto realmente costi un gigabyte da cui non sono stati estratti dati — perché il prezzo dei proxy per GB mente.
- L'impronta invecchia. Dopo un redesign confermato, riprendete l'impronta di riferimento, altrimenti la prossima modifica del sito sarà considerata già da un ritratto obsoleto, e la precisione calerà.
- Se il contenuto non è affatto presente in HTML — l'adattività non aiuta, serve un fetcher browser. Nella versione 0.4.15 le schede del browser sono state riutilizzate tra le richieste, e il metodo
close_pages()le chiude forzatamente; lì sono stati anche risolti i blocchi in modalità headless e la soluzione Turnstile non dipende più dalla località del browser.
Quale tipo di proxy scegliere per questo compito
La scelta è dettata non dal parser, ma dal sito target:
- Proxy da data center — per siti senza un serio anti-bot: documentazione, registri statali, cataloghi aperti, feed RSS e CSV (per questi ultimi nella 0.4.13 sono stati aggiunti
XMLFeedSpidereCSVFeedSpidercon estrazione automatica gzip). Economici e veloci, e la stabilità del markup qui è generalmente superiore. - Proxy residenziali — per marketplace, aggregatori e tutto ciò che personalizza i risultati in base al geo. Qui è fondamentale prendere l'impronta di riferimento e raccogliere dati da un solo paese, altrimenti riparerete non un guasto, ma la vostra geografia.
- Proxy mobili — quando il sito restituisce un modello mobile e deve essere parsato così com'è, oppure quando la fiducia nell'IP è più importante del costo per gigabyte.
In breve
I campi vuoti nell'estrazione sono due diagnosi diverse con trattamenti diversi. Controllate prima il codice di risposta e l'HTML grezzo: se la pagina è arrivata interamente, non è necessario cambiare proxy, è il markup che è andato. I selettori adattivi di Scrapling risolvono questa classe di guasti in pochi millisecondi per richiesta — salvate l'impronta su un layout di lavoro, attivate adaptive=True in produzione e registrate i momenti di attivazione come segnale di redesign. E mantenete il geo stabile: metà dei "redesign improvvisi" si rivelano in pratica una diversa versione linguistica della pagina, arrivata a causa del cambio del paese di uscita.
Se un geo stabile e una sessione prevedibile sono proprio ciò di cui il vostro parser ha bisogno, date un'occhiata ai proxy residenziali di ProxyCove: scelta del paese, sessioni sticky e pagamento per il traffico realmente utilizzato.