Una ricerca su GitHub per "facebook scraper" restituisce 475 repository. Solo 62 di questi sono stati aggiornati negli ultimi sei mesi.
La distanza tra "disponibile" e "davvero funzionante" racconta tutta la storia del Facebook scraping su GitHub nel 2026.
Ho passato parecchio tempo a esaminare issue, lamentele su Reddit e output reali di questi strumenti. Il quadro è sempre lo stesso: la maggior parte dei progetti più stellati è ormai rotta senza dirlo apertamente, i maintainer hanno smesso di seguirli e le difese anti-scraping di Facebook diventano ogni giorno più sofisticate. Sviluppatori e utenti business finiscono sempre sugli stessi risultati di ricerca, installano gli stessi repository e si scontrano con lo stesso output vuoto. Questo articolo è un check realistico al 2026 — una valutazione onesta di quali repo meritano ancora il tuo tempo, di cosa fa Facebook per bloccarli e di quando conviene saltare GitHub del tutto.
Perché le persone cercano un Facebook scraper su GitHub
I casi d’uso dietro questa ricerca sono sempre gli stessi da anni, anche se gli strumenti continuano a rompersi:
- Generazione lead: estrarre i contatti delle pagine business (email, numeri di telefono, indirizzi) per attività commerciali
- Monitoraggio marketplace: tenere sotto controllo inserzioni, prezzi e venditori per ecommerce o arbitraggio
- Ricerca nei gruppi: archiviare post e commenti per analisi di mercato, OSINT o gestione community
- Archiviazione contenuti e post: salvare post pubblici delle pagine, reazioni, immagini e timestamp
- Raccolta eventi: recuperare titoli, date, luoghi e organizzatori degli eventi
L’attrattiva di GitHub è evidente: codice visibile, costo zero, manutenzione comunitaria almeno in teoria e pieno controllo su campi e pipeline.
Il problema è che stelle e fork non dicono nulla su quanto un progetto sia ancora funzionante. Tra i 10 repository con la corrispondenza esatta più stellati, tutti e 10 erano fermi da oltre 12 mesi ad aprile 2026. Non è un’eccezione: è la norma.
Un utente Reddit, in un thread di novembre 2025, l’ha detto senza giri di parole dopo sei mesi di tentativi: era "impossibile senza pagare un’app esterna per il data scraping" oppure senza usare Python più rendering JS più una potenza di calcolo significativa. Un altro, in una discussione di aprile 2026, l’ha riassunto così: "Facebook è uno dei siti più difficili da scrapare perché blocca aggressivamente l’automazione" e l’automazione browser è "fragile, perché Facebook cambia continuamente il DOM".
I casi d’uso sono reali. La domanda è reale. La frustrazione è molto reale. Il resto dell’articolo serve proprio a orientarsi in quel divario.
Cos’è esattamente un repository Facebook scraper su GitHub?
Un "Facebook scraper" su GitHub è uno script open source — di solito in Python — che estrae in modo programmatico dati pubblici da pagine, post, gruppi, Marketplace o profili Facebook. Non tutti funzionano allo stesso modo. Le tre architetture più comuni sono:
Scraper con automazione del browser vs wrapper API vs scraper HTTP diretto
| Approccio | Stack tipico | Punto di forza | Punto debole |
|---|---|---|---|
| Automazione del browser | Selenium, Playwright, Puppeteer | Gestisce i login wall e imita meglio il comportamento reale | Lento, pesante in termini di risorse, facile da individuare se non configurato bene |
| Wrapper per API ufficiali | Meta Graph API / Pages API | Stabile, documentato, conforme quando approvato | Fortemente limitato: gran parte dei dati pubblici di post/gruppi non è più disponibile |
| Scraper HTTP diretto | requests, parsing HTML, endpoint non documentati | Veloce e leggero quando funziona | Si rompe ogni volta che Facebook cambia struttura o misure anti-bot |
kevinzg/facebook-scraper è l’esempio classico di approccio HTTP diretto: estrae pagine pubbliche "senza API key" usando richieste dirette e parsing. apurvmishra99/facebook-scraper-selenium è invece un esempio di automazione browser. minimaxir/facebook-page-post-scraper rappresenta l’era della vecchia Graph API, quando gli script potevano leggere post di pagine e gruppi tramite endpoint ufficiali che oggi non sono più accessibili in modo esteso.
I dati tipicamente estratti in questi repo includono testo dei post, timestamp, conteggi di reazioni/commenti, URL delle immagini, metadati della pagina (categoria, telefono, email, numero di follower), campi delle inserzioni Marketplace e metadati di gruppi o eventi.
Nel 2026, il vero compromesso non è il linguaggio di programmazione. È il tipo di fallimento che sei disposto a tollerare.
Audit 2026 sulla freschezza dei Facebook scraper su GitHub: quali repository funzionano davvero?
Ho analizzato i repository Facebook scraper più stellati e più consigliati su GitHub confrontandoli con dati reali del 2026 — non con le promesse nei README, ma con date di commit, code di issue e report della community. Questa è la sezione che conta davvero.
Tabella completa dell’audit di freschezza
| Repo | Stelle | Ultimo push | Issue aperte | Linguaggio / runtime | Cosa riesce ancora a scrapare | Stato |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3.157 | 2024-06-22 | 438 | Python ^3.6 | Post pubblici limitati, alcuni commenti/immagini, metadati della pagina | ⚠️ Parzialmente rotto / obsoleto |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | Come kevinzg + helper per Marketplace | ⚠️ Fork parzialmente rotto / obsoleto |
| minimaxir/facebook-page-post-scraper | 2.128 | 2019-05-23 | 53 | Epoca Python 2/3, dipendente da Graph API | Solo come riferimento storico | ❌ Abbandonato |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Automazione browser per scraping delle pagine | ❌ Abbandonato |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Inserzioni Marketplace via automazione browser | ⚠️ Fragile / di nicchia |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Scraping generico con Selenium | ❌ Abbandonato |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Orientato all’automazione | ❌ Rischioso / poca evidenza |
Saltano subito all’occhio alcune cose:
- Anche il fork "attivo" (moda20) non viene aggiornato da giugno 2024.
- Le code di issue raccontano la realtà molto più velocemente dei README.
- Sia kevinzg sia moda20 dichiarano ancora Python ^3.6 nei loro file pyproject.toml — un segnale che la base delle dipendenze non è stata modernizzata.
kevinzg/facebook-scraper
È il più noto Facebook scraper in Python su GitHub. Il suo README descrive lo scraping di pagine, gruppi, il login tramite credenziali o cookie e campi a livello di post come comments, image, images, likes, post_id, post_text, text e time.
Il segnale operativo però è debole:
- Ultimo push: 22 giugno 2024
- Issue aperte: 438 — tra cui titoli come "Example Scrape does not return any posts"
- Il maintainer non ha risposto alle issue più recenti
Verdetto: Parzialmente rotto. Ha ancora un po’ di valore per esperimenti su piccole pagine pubbliche e come riferimento per i nomi dei campi, ma non è affidabile per l’uso in produzione.
moda20/facebook-scraper (fork della community)
È il fork più visibile di kevinzg, con opzioni aggiuntive e helper orientati al Marketplace come extract_listing (documentati nel suo README).
La coda delle issue rende la situazione chiarissima:
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
Quando l’interfaccia semplificata mbasic cambia o scompare, un’intera categoria di scraper smette di funzionare correttamente.
Verdetto: Il fork più rilevante, ma nel 2026 è comunque obsoleto e fragile. Vale la pena provarlo per primo se vuoi restare su una soluzione GitHub-based, ma non aspettarti stabilità.
minimaxir/facebook-page-post-scraper
Un tempo era uno strumento Graph API molto pratico per raccogliere post, reazioni, commenti e metadati dalle Pagine pubbliche e dai gruppi aperti in CSV. Il suo README spiega ancora come usare App ID e App Secret di un’app Facebook.
Nel 2026 è ormai un reperto storico:
- Ultimo push: 23 maggio 2019
- Issue aperte: 53 — tra cui "HTTP 400 Error Bad Request" e "No data retrieved!!"
Verdetto: Abbandonato. Strettamente legato a un modello di permessi API che Meta ha poi ristretto in modo significativo.
Altri repository da notare
- passivebot/facebook-marketplace-scraper: utile per casi d’uso su Marketplace, ma la sua coda issue include "login to view the content", "CSS selectors outdated" e "Getting blocked". Un mini case study di tutto ciò che si rompe nello scraping del Marketplace.
- apurvmishra99/facebook-scraper-selenium: ha una issue che chiede letteralmente "Does it work with new Facebook layout?" da settembre 2020. Dice quasi tutto da sola.
- Mhmd-Hisham/selenium_facebook_scraper e anabastos/faceteer: non hanno abbastanza attività recente per meritare fiducia.
Le difese anti-scraping di Facebook: contro cosa combatte ogni scraper GitHub
La maggior parte degli articoli su questo tema offre il solito disclaimer vago sul "controllare i ToS". Poco utile.
Facebook ha uno dei sistemi anti-scraping più aggressivi tra le grandi piattaforme. Capire questi livelli di difesa è la differenza tra uno scraper che funziona e un pomeriggio di output vuoto.
Un post tecnico ufficiale di Meta del febbraio 2025 descrive un "Anti Scraping team" che usa analisi statica su tutto il codice per individuare i vettori di scraping, invia diffide, disabilita account e si affida a sistemi di rate limiting. Non è teoria: è una scelta organizzativa precisa.
DOM e nomi delle classi CSS randomizzati
Facebook randomizza di proposito gli ID degli elementi HTML, i nomi delle classi e la struttura delle pagine. Come ha scritto un commentatore di r/webscraping: "Nessuno scraper normale può funzionare su Facebook. L’HTML cambia tra un refresh e l’altro."
Cosa si rompe: gli XPath e i selettori CSS che funzionavano la scorsa settimana oggi non restituiscono nulla.
Contromisura: quando possibile, usa selettori basati su testo o attributi. Il parsing basato su AI, che legge il contenuto della pagina invece di affidarsi a selettori rigidi, gestisce meglio questa situazione. Considera la manutenzione dei selettori come un costo ricorrente.
Login wall e gestione della sessione
Molte aree di Facebook — profili, gruppi, alcune inserzioni Marketplace — richiedono il login per essere viste. I browser headless vengono reindirizzati o ricevono HTML semplificato. La scheda issue dello scraper Marketplace di passivebot ha proprio "login to view the content" tra le lamentele principali.
Cosa si rompe: le richieste anonime non vedono i contenuti oppure vengono reindirizzate del tutto.
Contromisura: usa cookie di sessione presi da un browser reale, oppure strumenti di scraping browser-based che operano dentro la tua sessione autenticata. Ruotare gli account è possibile, ma rischioso.
Fingerprinting digitale
Il post tecnico di Meta spiega che gli scraper non autorizzati "spesso si nascondono imitando il modo in cui gli utenti usano normalmente un prodotto" — una formulazione che di fatto indica come browser quality e behavior quality siano centrali nel rilevamento. Le discussioni della community di marzo e aprile 2026 continuano a raccomandare anti-detect browser e fingerprint coerenti.
Cosa si rompe: le configurazioni standard di Selenium o Puppeteer vengono riconosciute facilmente.
Contromisura: usa strumenti come undetected-chromedriver o profili browser anti-detect. Sessioni realistiche e fingerprint coerenti contano più del semplice spoofing dello user-agent.
Rate limiting e blocco basati su IP
Il post tecnico di Meta parla esplicitamente del rate limiting come parte della strategia difensiva, incluso il limite sui conteggi delle liste follower per costringere a fare più richieste e far scattare poi i controlli di rate. In pratica, gli utenti segnalano rate limit già dopo aver pubblicato su 10 gruppi a intervalli di 10 secondi.
Cosa si rompe: richieste massive dallo stesso IP vengono rallentate o bloccate nel giro di pochi minuti. Gli IP dei proxy datacenter sono spesso già bloccati a monte.
Contromisura: rotazione di proxy residenziali, non proxy datacenter, con un ritmo di richieste sensato.
Cambiamenti dello schema GraphQL
Alcuni scraper si appoggiano agli endpoint GraphQL interni di Facebook perché restituiscono dati strutturati più puliti dell’HTML grezzo. Ma Meta non pubblica alcuna garanzia di stabilità per GraphQL interni, quindi queste query si rompono senza avvisi — tornando dati vuoti invece di errori.
Cosa si rompe: l’estrazione strutturata restituisce silenziosamente nulla.
Contromisura: aggiungi controlli di validazione, monitora gli endpoint dello schema e blocca le query note come funzionanti. Metti in conto manutenzione continua.
Riepilogo delle difese anti-scraping
| Livello di difesa | Come rompe lo scraper | Contromisura pratica |
|---|---|---|
| Cambi di layout / selettori instabili | XPath e selettori CSS non restituiscono nulla o solo campi parziali | Preferisci ancoraggi resilienti, valida rispetto all’output visibile della pagina, metti in conto manutenzione |
| Login wall | Le richieste da non autenticato non vedono i contenuti o vengono reindirizzate | Usa cookie di sessione validi o strumenti che lavorano dentro la sessione browser |
| Fingerprinting | L’automazione standard sembra sintetica | Usa browser reali, qualità di sessione coerente, misure anti-detect |
| Rate limiting | Output vuoto, blocchi, throttling | Ritmo più lento, batch più piccoli, rotazione di proxy residenziali |
| Cambiamenti nelle query interne | L’estrazione strutturata torna dati vuoti senza errori | Aggiungi controlli di validazione, metti in conto manutenzione delle query |
Quando i repository GitHub falliscono: scegli un’alternativa consentita
Un repository rotto non è un motivo per cercare un altro modo per aggirare i controlli della piattaforma. Prima chiarisci la domanda di business: ti servono analytics a livello di pagina, trasparenza pubblicitaria, un elenco pubblico di contatti o un catalogo prodotti? Molti di questi bisogni si possono soddisfare con un prodotto ufficiale Meta, una API autorizzata o una fonte pubblica non Meta.
Per esempio, usa la Graph API solo quando app e caso d’uso dispongono dei permessi necessari, usa i programmi di ricerca Meta solo se sei idoneo e usa Meta Ad Library per le informazioni pubblicitarie che rende disponibili. Per lead research, prezzi e scoperta di attività locali, preferisci siti pubblici indipendenti, di cui puoi valutare direttamente termini e obblighi sulla privacy.
Esempi reali di output: cosa ottieni davvero
Tutti gli articoli concorrenti mostrano snippet di codice, ma mai l’output reale. Qui sotto trovi ciò che puoi aspettarti in pratica da ciascun approccio.
Esempio di output: kevinzg/facebook-scraper (o fork attivo)
Dall’esempio nel README, un post pubblico estratto restituisce JSON come questo:
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
Nota i campi nullable come comments_full. Nel 2026 aspettati che più campi tornino vuoti o mancanti: di solito è un segnale di blocco, non un piccolo glitch innocuo. L’output è JSON grezzo e richiede post-processing.
Esempio di output: Facebook Graph API
La Pages API attuale di Meta documenta richieste di informazioni sulla pagina come GET /<PAGE_ID>?fields=id,name,about,fan_count. La reference della Page include campi come followers_count, fan_count, category, emails, phone e altri metadati pubblici — ma solo con i permessi corretti, come Page Public Content Access o Page Public Metadata Access.
È una struttura dati molto più limitata di quella che la maggior parte degli utenti di scraper GitHub si aspetta. È centrata sulla pagina, vincolata ai permessi e non sostituisce lo scraping arbitrario di post pubblici o gruppi.
Matrice tipo di dato Facebook × percorso di accesso
| Tipo di dato Facebook | Punto di partenza consigliato | Limite principale |
|---|---|---|
| Asset amministrati dalla tua organizzazione | Strumenti ufficiali di gestione Meta e API approvate | I permessi e i campi disponibili variano |
| Osservazioni pubblicitarie | Meta Ad Library | Usa solo i campi e i filtri esposti |
| Dati business pubblici necessari per lead research | Una directory o un sito editore non Meta e autorizzato | Verifica termini e obblighi sulla privacy della fonte |
| Materiale privato, di gruppi chiusi, protetto da login o accessibile solo con account | Non automatizzare la raccolta | Cerca invece un percorso autorizzato |
Passo dopo passo: come configurare un Facebook scraper da GitHub (quando ha senso)
Se hai letto l’audit sulla freschezza e vuoi comunque passare da GitHub, va bene. Ecco il percorso pratico — con note sincere su dove si inceppa.
Passo 1: scegli il repository giusto (usa l’audit di freschezza)
Torna alla tabella dell’audit. Scegli il repo meno obsoleto che corrisponde alla superficie che vuoi raggiungere. Prima di installare qualsiasi cosa, controlla la scheda Issues: i titoli delle issue recenti ti dicono molto più del README sul funzionamento attuale.
Passo 2: prepara l’ambiente Python
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Problema comune: conflitti di versione con le dipendenze, soprattutto Selenium/Playwright. Sia kevinzg sia moda20 dichiarano Python ^3.6 nel loro pyproject.toml — una base vecchia che può entrare in conflitto con librerie più recenti. Lo scraper Marketplace di passivebot blocca playwright==1.40.0, cosa accettabile per sperimentare ma non come prova di durabilità.
Passo 3: configura proxy e anti-detection
Se fai qualcosa di più di un test rapido:
- imposta una rotazione di proxy residenziali (cerca provider con pool di IP specifici per Facebook)
- se usi automazione browser, installa undetected-chromedriver o configura misure anti-fingerprinting
- non saltare questo passaggio: Selenium o Puppeteer standard vengono individuati molto in fretta
Passo 4: esegui un test ridotto e valida l’output
Parti da una singola pagina pubblica, non da un batch grande. Controlla bene l’output:
- campi vuoti o dati mancanti di solito significano che le difese di Facebook ti stanno bloccando
- confronta l’output con ciò che vedi davvero nella pagina dal browser
- un test positivo su una sola pagina conta più di un README bello da vedere
Passo 5: gestisci errori, rate limit e manutenzione
- integra retry e gestione degli errori
- aspettati di dover aggiornare spesso selettori o configurazioni: è manutenzione continua, non una soluzione da impostare una volta sola
- se passi più tempo a mantenere lo scraper che a usare i dati, è un segnale che vale la pena riconsiderare un percorso no-code
Considerazioni legali ed etiche sullo scraping di Facebook
Termini della piattaforma, regole sulla privacy, obblighi contrattuali e leggi sulla protezione dei dati possono tutti entrare in gioco. La visibilità pubblica non equivale a un’autorizzazione generale alla raccolta automatica. Riduci al minimo i dati raccolti, documenta finalità e base giuridica e chiedi consulenza legale per programmi commerciali o su larga scala.
Non considerare un’estensione browser, una sessione con login o la dicitura “pubblico” come permesso ad automatizzare la raccolta dai prodotti Meta.
Punti chiave: cosa funziona davvero per il Facebook scraping nel 2026
L’attività del repository, le code di issue e le regole correnti della piattaforma contano più del numero di stelle o di un vecchio README. Quando la domanda di business riguarda un asset che gestisci tu, parti dagli strumenti ufficiali Meta e dalle API approvate. Per ricerche di mercato, lead generation e pricing, spesso è più semplice documentare e governare una fonte pubblica non Meta autorizzata.
FAQ
Esiste un Facebook scraper funzionante su GitHub nel 2026?
Sì, ma le opzioni sono limitate. La più nota è il fork moda20/facebook-scraper del repository originale di kevinzg — controlla la tabella dell’audit di freschezza sopra per lo stato aggiornato. Può scrapare in modo parziale post pubblici e alcuni metadati, ma la sua coda issue mostra rotture strutturali su mbasic e output vuoto. La maggior parte degli altri repository è abbandonata o completamente rotta.
Posso scrapare Facebook senza programmare?
Per ricerche manuali, usa gli strumenti di ricerca e gestione di Facebook. Per attività ripetibili o programmatiche, valuta l’API ufficiale e i suoi permessi, oppure riprogetta il flusso attorno a una fonte pubblica non Meta consentita. La comodità del no-code non elimina obblighi di piattaforma, privacy o contratto.
È legale scrapare Facebook?
I Termini di servizio di Facebook vietano la raccolta automatizzata di dati senza autorizzazione. Meta fa rispettare questa regola in modo attivo tramite ban degli account, diffide e azioni legali. La legalità varia in base alla giurisdizione e al caso d’uso. Attieniti ai dati business pubblicamente disponibili, evita i profili personali e consulta un legale se operi su larga scala.
Quali dati posso ancora ottenere dalla Facebook Graph API?
Nel 2026 la Graph API è fortemente limitata. Puoi accedere a dati limitati a livello di pagina — campi come id, name, about, fan_count, emails, phone — con i permessi corretti, come Page Public Metadata Access. La maggior parte dei dati dei post pubblici, dei gruppi (la Groups API è deprecata) e dei dati a livello utente non è più disponibile via API.
Ogni quanto si rompono i repository Facebook scraper su GitHub?
Spesso. Facebook cambia continuamente la struttura del DOM, le misure anti-bot e le API interne: non esiste una cadenza pubblicata, ma i report della community mostrano rotture ogni poche settimane per gli scraper attivi. La coda issue del fork moda20 attorno alla scomparsa di mbasic è un esempio recente. Se fai affidamento su un repository GitHub, prevedi manutenzione regolare e validazione dell’output.
Scopri di più
