Een GitHub-zoekopdracht naar "facebook scraper" levert 475 repositories op. Slechts 62 daarvan zijn in de afgelopen zes maanden nog bijgewerkt.
Dat verschil tussen "beschikbaar" en "echt werkend" zegt eigenlijk alles over Facebook scraping op GitHub in 2026.
Ik heb veel tijd gestoken in het doorspitten van issue-tabs van repositories, klachten op Reddit en de echte output van deze tools. Het patroon is steeds hetzelfde: veel van de populairste projecten zijn stilletjes stukgelopen, maintainers zijn afgehaakt en Facebooks anti-scrapingbeveiliging wordt steeds slimmer. Ontwikkelaars en zakelijke gebruikers komen telkens uit bij dezelfde zoekresultaten, installeren dezelfde repos en lopen vervolgens tegen dezelfde lege output aan. Dit artikel is een reality check voor 2026 — een eerlijke beoordeling van welke repositories nog de moeite waard zijn, wat Facebook doet om ze te breken en wanneer je GitHub gewoon moet overslaan.
Waarom mensen op GitHub zoeken naar een Facebook scraper
De redenen achter die zoekopdracht zijn al jaren vrijwel hetzelfde, ook al vallen de tools steeds vaker uit:
- Leadgeneratie: Contactgegevens van bedrijfspagina's verzamelen, zoals e-mails, telefoonnummers en adressen, voor outreach
- Marketplace-monitoring: Productaanbiedingen, prijzen en verkopersinformatie volgen voor e-commerce of arbitrage
- Groeponderzoek: Berichten en reacties archiveren voor marktonderzoek, OSINT of communitybeheer
- Content- en postarchivering: Publieke pagina-posts, reacties, afbeeldingen en tijdstempels bewaren
- Evenementen bundelen: Titels, data, locaties en organisatoren van evenementen ophalen
De aantrekkingskracht van GitHub is logisch: de code is zichtbaar, het kost niets, er is in theorie community-onderhoud en je houdt volledige controle over velden en pipelines.
Het probleem is dat sterren en forks niet hetzelfde zijn als "werkt nu ook echt". Van de top 10 repositories met de exacte zoekterm op basis van sterren waren alle 10 meer dan 12 maanden oud in april 2026. Dat is geen uitzondering, maar eerder de norm.
Een Reddit-gebruiker verwoordde het in een draad van november 2025 na zes maanden proberen heel direct: het was "onmogelijk zonder óf te betalen voor een externe data scraping-applicatie" óf Python te combineren met JS-rendering en flink wat rekenkracht. Een ander vat het in een gesprek uit april 2026 samen als: "Facebook is een van de lastigste platforms om te scrapen omdat ze automatisering agressief blokkeren" en browserautomatisering is "fragiel omdat Facebook zijn DOM voortdurend verandert."
De use-cases zijn echt. De vraag is echt. De frustratie is ook echt. De rest van dit artikel gaat over hoe je dat gat kunt overbruggen.
Wat is een Facebook scraper GitHub-repository precies?
Een "Facebook scraper" op GitHub is een open-source script — meestal in Python — dat openbare data van Facebook-pagina's, posts, groepen, Marketplace of profielen automatisch ophaalt. Ze werken niet allemaal op dezelfde manier. Er zijn drie dominante benaderingen:
Browser-automatisering, API-wrappers en directe HTTP-scrapers
| Aanpak | Typische stack | Sterkte | Zwakke plek |
|---|---|---|---|
| Browserautomatisering | Selenium, Playwright, Puppeteer | Kan inlogschermen aan en bootst echt gebruikersgedrag na | Traag, zwaar voor resources, en makkelijk te fingerprinten als je het niet goed instelt |
| Officiële API-wrapper | Meta Graph API / Pages API | Stabiel, gedocumenteerd, compliant als je toegang hebt | Sterk beperkt — de meeste openbare post-/groepdata is niet meer beschikbaar |
| Directe HTTP-scraper | requests, HTML-parsing, ongedocumenteerde endpoints | Snel en lichtgewicht als het werkt | Breekt zodra Facebook de paginastuctuur of anti-botmaatregelen aanpast |
kevinzg/facebook-scraper is het klassieke voorbeeld van een directe HTTP-aanpak: het scrapt openbare pagina's "zonder API-sleutel" via directe requests en parsing. apurvmishra99/facebook-scraper-selenium is een voorbeeld van browserautomatisering. minimaxir/facebook-page-post-scraper staat voor het oude Graph API-tijdperk, waarin scripts via officiële endpoints pagina- en groepsposts konden ophalen die tegenwoordig niet meer breed beschikbaar zijn.
Typische doeldata in deze repositories bestaat uit posttekst, tijdstempels, aantallen reacties en reacties, afbeeldings-URL's, paginametadata (categorie, telefoon, e-mail, aantal volgers), Marketplace-veldinformatie en groeps- of evenementenmetadata.
In 2026 gaat het echte compromis niet over taalvoorkeur. Het gaat over welk soort mislukking je kunt accepteren.
De 2026-versheidscheck voor Facebook scraper GitHub: welke repositories werken nog?
Ik heb de meest geliefde en meest aanbevolen Facebook scraper-repositories op GitHub getoetst aan echte data uit 2026 — niet aan README-claims, maar aan daadwerkelijke commitdata, issuequeues en communitymeldingen. Dit is het belangrijkste onderdeel.
De volledige versheidstabel
| Repo | Sterren | Laatste push | Open issues | Taal / runtime | Wat nog wordt gescrapet | Status |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3.157 | 2024-06-22 | 438 | Python ^3.6 | Beperkte openbare pagina-posts, sommige comments/afbeeldingen, paginametadata | ⚠️ Gedeeltelijk kapot / verouderd |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | Zelfde als kevinzg + Marketplace-helpermethoden | ⚠️ Gedeeltelijk kapot / verouderde fork |
| minimaxir/facebook-page-post-scraper | 2.128 | 2019-05-23 | 53 | Python 2/3-tijdperk, afhankelijk van Graph API | Alleen historisch referentiemateriaal | ❌ Verlaten |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Browserautomatisering voor pagina-scraping | ❌ Verlaten |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Marketplace-aanbiedingen via browserautomatisering | ⚠️ Kwetsbaar / niche |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Algemene Selenium-scraping | ❌ Verlaten |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Automatiseringsgericht | ❌ Risicovol / weinig bewijs |
Een paar dingen springen meteen in het oog:
- Zelfs de "actieve fork" (moda20) is sinds juni 2024 niet meer gepusht.
- De issuequeues vertellen sneller het echte verhaal dan de README's.
- Zowel kevinzg als moda20 gebruiken in hun pyproject.toml nog steeds Python ^3.6 — een teken dat de basis van de dependencies niet is gemoderniseerd.
kevinzg/facebook-scraper
De bekendste Python Facebook scraper op GitHub. De README beschrijft scraping van pagina's en groepen, inloggen met credentials of cookies, en post-velden zoals comments, image, images, likes, post_id, post_text, text en time.
Maar het operationele signaal is zwak:
- Laatste push: 22 juni 2024
- Open issues: 438 — waaronder titels als "Example Scrape does not return any posts"
- De maintainer reageert niet meer op recente issues
Oordeel: Gedeeltelijk kapot. Nog wel bruikbaar als referentie voor veldnamen en voor kleine experimenten met openbare pagina's, maar niet betrouwbaar genoeg voor productie.
moda20/facebook-scraper (community fork)
De meest zichtbare fork van kevinzg, met extra opties en Marketplace-gerichte helpers zoals extract_listing (beschreven in de README).
De issuequeue maakt de breuk duidelijk:
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
Wanneer de vereenvoudigde mbasic-frontend verandert of verdwijnt, valt in één klap een hele klasse scrapers uit.
Oordeel: De bekendste fork, maar in 2026 ook verouderd en fragiel. Het is de eerste die je kunt proberen als je per se een GitHub-oplossing wilt, maar reken niet op stabiliteit.
minimaxir/facebook-page-post-scraper
Ooit een heel praktische Graph API-tool om posts, reacties, comments en metadata van openbare Pages en open Groups naar CSV's te halen. De README legt nog steeds uit hoe je de App ID en App Secret van een Facebook-app gebruikt.
In 2026 is het vooral een historisch artefact:
- Laatste push: 23 mei 2019
- Open issues: 53 — waaronder "HTTP 400 Error Bad Request" en "No data retrieved!!"
Oordeel: Verlaten. Sterk gekoppeld aan een permissiemodel van de API dat Meta inmiddels aanzienlijk heeft ingeperkt.
Andere opvallende repositories
- passivebot/facebook-marketplace-scraper: Handig voor Marketplace-use-cases, maar de issuequeue bevat klachten als "login to view the content", "CSS selectors outdated" en "Getting blocked." Een casus in één regel van wat er misgaat bij Marketplace scraping.
- apurvmishra99/facebook-scraper-selenium: Er is letterlijk één issue met de vraag "Does it work with new Facebook layout?" uit september 2020. Dat zegt eigenlijk genoeg.
- Mhmd-Hisham/selenium_facebook_scraper en anabastos/faceteer: Beide hebben niet genoeg recente activiteit om vertrouwen te rechtvaardigen.
Facebooks anti-scrapingverdediging: waar elke GitHub scraper tegenaan loopt
De meeste artikelen hierover komen niet verder dan vage "check de ToS"-waarschuwingen. Daar heeft niemand iets aan.
Facebook heeft een van de meest agressieve anti-scrapingsystemen van alle grote platforms. Het begrijpen van die verschillende verdedigingslagen is het verschil tussen een werkende scraper en een middag vol lege output.
Meta's eigen engineering-post van februari 2025 beschrijft een "Anti Scraping team" dat met statische analyse door de codebase loopt om scrapingvectoren te vinden, cease-and-desist-letters verstuurt, accounts uitschakelt en vertrouwt op rate-limiting. Dat is geen theorie — het is een bewuste organisatie-inzet.
Willekeurige DOM- en CSS-classnamen
Facebook randomiseert bewust HTML-element-ID's, classnamen en paginastructuren. Zoals een commentator op r/webscraping het verwoordde: "Geen enkele normale scraper kan op Facebook werken. De HTML muteert tussen refreshes door."
Wat breekt: XPath- en CSS-selectors die vorige week nog werkten, geven vandaag niets terug.
Tegenmaatregel: Gebruik waar mogelijk tekstgebaseerde of attribuutgebaseerde selectors. AI-gebaseerde parsing die de paginainhoud leest in plaats van star op selectors te leunen, werkt hier beter. Zie selectoronderhoud als terugkerende kosten.
Inlogmuren en sessiebeheer
Veel Facebook-onderdelen — profielen, groepen en sommige Marketplace-aanbiedingen — vereisen een login. Headless browsers worden omgeleid of krijgen uitgeklede HTML terug. In de issue-tab van de passivebot Marketplace scraper staat "login to view the content" bovenaan de klachtenlijst.
Wat breekt: Anonieme requests missen content of worden volledig omgeleid.
Tegenmaatregel: Gebruik sessiecookies uit een echte browsersessie, of browsergebaseerde scrapingtools die binnen je ingelogde sessie werken. Wisselen van accounts kan, maar is risicovol.
Digitale fingerprinting
Meta's engineering-post zegt dat ongeautoriseerde scrapers "zich vaak verbergen door de manieren na te bootsen waarop gebruikers een product normaal gebruiken" — feitelijk een bevestiging dat browserkwaliteit en gedragskwaliteit centraal staan in detectie. Communitygesprekken in maart en april 2026 blijven anti-detect browsers en consistente fingerprints aanraden.
Wat breekt: Standaard Selenium- of Puppeteer-opstellingen worden gemakkelijk herkend.
Tegenmaatregel: Gebruik tools zoals undetected-chromedriver of anti-detect browserprofielen. Realistische sessies en consistente fingerprints zijn belangrijker dan simpel user-agent-spoofing.
IP-gebaseerde rate limiting en blokkades
Meta's engineering-post bespreekt rate limiting expliciet als onderdeel van de verdedigingsstrategie, inclusief het beperken van follower-lijstgroottes om meer requests uit te lokken die vervolgens rate controls triggeren. In de praktijk melden gebruikers dat ze al rate-limited worden nadat ze 10 groepen in intervallen van 10 seconden hebben gepost.
Wat breekt: Bulkrequests vanaf hetzelfde IP worden binnen minuten afgeremd of geblokkeerd. Datacenter-proxy-IP's zijn vaak al vooraf geblokkeerd.
Tegenmaatregel: Rotatie van residential proxies, niet van datacenterproxies, met een verstandig tempo van requests.
Wijzigingen in GraphQL-schema's
Sommige scrapers vertrouwen op Facebooks interne GraphQL-endpoints omdat die schonere, gestructureerde data teruggeven dan ruwe HTML. Maar Meta geeft geen stabiliteitsgarantie voor interne GraphQL, dus deze queries breken stilletjes — ze leveren lege data terug in plaats van fouten.
Wat breekt: Gestructureerde extractie levert stilzwijgend niets op.
Tegenmaatregel: Voeg validatiecontroles toe, monitor schema-endpoints en werk met bekende goed functionerende queries. Verwacht onderhoud.
Samenvatting van anti-scrapingverdediging
| Verdedigingslaag | Hoe het je scraper breekt | Praktische tegenmaatregel |
|---|---|---|
| Wisselende layout / instabiele selectors | XPath- en CSS-selectors geven niets of slechts deels velden terug | Gebruik robuuste ankers, valideer tegen zichtbare paginacontent, reken op onderhoud |
| Inlogmuren | Uitgelogde requests missen content of worden doorgestuurd | Gebruik geldige sessiecookies of tools die binnen een browsersessie werken |
| Fingerprinting | Standaardautomatisering oogt synthetisch | Gebruik echte browsers, consistente sessiekwaliteit en anti-detectmaatregelen |
| Rate limiting | Lege output, blokkades, afknijpen | Rustig tempo, kleinere batches, rotatie van residential proxies |
| Wijzigingen in interne queries | Gestructureerde extractie geeft stilzwijgend lege data terug | Voeg validatie toe en verwacht query-onderhoud |
Wanneer GitHub-repositories falen: kies een toegestane alternatieve route
Een kapotte repository is geen reden om een omweg te zoeken langs de controles van een platform. Breng eerst de zakelijke vraag scherp in beeld: heb je analytics op paginaniveau nodig, advertentietransparantie, een openbare contactdirectory of een productcatalogus? Veel van die behoeften kunnen worden ingevuld met een officieel Meta-product, een API met permissies of een openbare bron buiten Meta.
Gebruik bijvoorbeeld de Graph API alleen wanneer de app en use-case de vereiste rechten hebben, gebruik Meta-researchprogramma's alleen wanneer je daarvoor in aanmerking komt, en gebruik de Meta Ad Library voor de advertentie-informatie die daar beschikbaar is. Voor leadonderzoek, prijzen en lokale bedrijvengidsen zijn onafhankelijke publieke websites vaak eenvoudiger te beoordelen op voorwaarden en privacyverplichtingen.
Voorbeelden van echte output: wat je daadwerkelijk krijgt
Bij concurrerende artikelen zie je altijd code-snippets, maar nooit de echte output. Hieronder staat wat je realistisch kunt verwachten van elke aanpak.
Voorbeeldoutput: kevinzg/facebook-scraper (of actieve fork)
Uit het README-voorbeeld komt een gescrapete publieke post terug als JSON zoals:
{
"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"
}
Let op de nullable velden zoals comments_full. In 2026 kun je verwachten dat meer velden leeg of helemaal afwezig terugkomen — dat is meestal een signaal van blokkering, niet zomaar een onschuldige glitch. De output is ruwe JSON en heeft nabewerking nodig.
Voorbeeldoutput: Facebook Graph API
Meta's huidige Pages API documenteert verzoeken voor pagina-informatie zoals GET /<PAGE_ID>?fields=id,name,about,fan_count. De Page-reference bevat velden zoals followers_count, fan_count, category, emails, phone en andere openbare metadata — maar alleen met de juiste permissies, zoals Page Public Content Access of Page Public Metadata Access.
Dat is een veel smaller datamodel dan de meeste GitHub-gebruikers verwachten. Het is pagina-gericht, afhankelijk van rechten en geen vervanging voor willekeurige openbare posts of groep-scraping.
Matrix van Facebook-datatype × toegangsroute
| Facebook-datatype | Beste startpunt | Belangrijkste beperking |
|---|---|---|
| Assets die jouw organisatie beheert | Officiële Meta-managementtools en goedgekeurde API's | Rechten en beschikbare velden verschillen |
| Advertentie-observaties | Meta Ad Library | Gebruik alleen de velden en filters die daar worden aangeboden |
| Openbare bedrijfsgegevens voor leadonderzoek | Een toegestane directory of uitgeversite buiten Meta | Controleer de voorwaarden en privacyverplichtingen van de bron |
| Privé, besloten groepen, login-afgeschermde of account-only content | Collection niet automatiseren | Zoek in plaats daarvan een geautoriseerde route |
Stap voor stap: hoe je een Facebook scraper van GitHub opzet wanneer dat zinvol is
Als je de versheidscheck hebt gelezen en toch de GitHub-route wilt nemen, prima. Dit is de praktische aanpak — met eerlijke opmerkingen over waar het stukloopt.
Stap 1: Kies de juiste repo (gebruik de versheidscheck)
Ga terug naar de audit-tabel. Kies de minst verouderde repo die past bij jouw doeloppervlak. Controleer vóór installatie altijd de Issues-tab — recente issuetitels zeggen vaak meer over de actuele werking dan de README.
Stap 2: Stel je Python-omgeving in
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Veelvoorkomende valkuil: versieconflicten met dependencies, vooral Selenium-/Playwright-versies. Zowel kevinzg als moda20 gebruiken in hun pyproject.toml nog Python ^3.6 — een oudere basis die kan botsen met nieuwere libraries. passivebot's Marketplace scraper zet playwright==1.40.0 vast, wat prima is voor experimenten maar geen bewijs van duurzaamheid.
Stap 3: Configureer proxies en anti-detectie
Als je meer doet dan een snelle test:
- Stel rotatie van residential proxies in (zoek providers met Facebook-specifieke IP-pools)
- Gebruik je browserautomatisering, installeer dan undetected-chromedriver of configureer anti-fingerprinting
- Sla deze stap niet over — standaard Selenium of Puppeteer wordt snel gemarkeerd
Stap 4: Doe een kleine test-scrape en valideer de output
Begin met één openbare pagina, niet met een grote batch. Controleer de output zorgvuldig:
- Lege velden of ontbrekende data betekenen meestal dat Facebooks verdediging je blokkeert
- Vergelijk de output met wat je daadwerkelijk in je browser ziet
- Een geslaagde test op één pagina is belangrijker dan een mooie README
Stap 5: Ga om met fouten, rate limits en onderhoud
- Bouw retry-logica en foutafhandeling in
- Reken erop dat je selectors of configuratie regelmatig moet bijwerken — dit is doorlopend onderhoud, geen set-and-forget
- Als je meer tijd kwijt bent aan het onderhouden van de scraper dan aan het gebruik van de data, is dat een signaal om de no-code route opnieuw te overwegen
Juridische en ethische aandachtspunten bij Facebook scraping
Platformvoorwaarden, privacyregels, contractuele verplichtingen en gegevensbeschermingswetten kunnen allemaal van toepassing zijn. Zichtbaarheid voor het publiek is geen algemene toestemming voor geautomatiseerde verzameling. Houd data minimaal, documenteer het doel en de rechtsgrond, en vraag juridisch advies bij commerciële of grootschalige trajecten.
Beschouw een browserextensie, een ingelogde sessie of het label "public" niet als toestemming om automatisch data uit Meta-producten te verzamelen.
Belangrijkste conclusies: wat in 2026 echt werkt voor Facebook scraping
Activiteit van repositories, issuequeues en de huidige platformregels zijn belangrijker dan een sterrenaantal of een oude README. Gaat de zakelijke vraag over een asset die jij beheert, begin dan met officiële Meta-tools en goedgekeurde API's. Voor marktonderzoek, leadonderzoek en prijsvergelijking is een toegestane bron buiten Meta vaak eenvoudiger te documenteren en te beheren.
Veelgestelde vragen
Is er in 2026 een werkende Facebook scraper op GitHub?
Ja, maar de opties zijn beperkt. De bekendste is de moda20/facebook-scraper-fork van het oorspronkelijke kevinzg-repo — bekijk de versheidscheck hierboven voor de actuele status. Die kan gedeeltelijk openbare pagina-posts en sommige metadata scrapen, maar de issuequeue laat duidelijke problemen zien rond mbasic en lege output. De meeste andere repositories zijn verlaten of volledig kapot.
Kan ik Facebook scrapen zonder te programmeren?
Gebruik Facebooks eigen zoek- en beheertools voor handmatig onderzoek. Voor herhaalbaar of geautomatiseerd werk kun je de officiële API en bijbehorende permissies beoordelen, of de workflow herontwerpen rond een toegestane bron buiten Meta. No-code gemak neemt platform-, privacy- of contractuele verplichtingen niet weg.
Is het legaal om Facebook te scrapen?
Facebooks Terms of Service verbieden geautomatiseerde dataverzameling zonder toestemming. Meta handhaaft dit actief met accountblokkades, cease-and-desist-letters en rechtszaken. De legaliteit verschilt per rechtsgebied en use-case. Houd je aan openbaar beschikbare bedrijfsdata, vermijd persoonlijke profielen en vraag juridisch advies als je op grote schaal werkt.
Welke data kan ik nog uit de Facebook Graph API halen?
In 2026 is de Graph API sterk beperkt. Je kunt nog beperkte data op paginaniveau benaderen — velden zoals id, name, about, fan_count, emails, phone — met de juiste rechten, zoals Page Public Metadata Access. De meeste openbare postdata, groepdata (de Groups API is deprecated) en user-level data zijn niet meer via de API beschikbaar.
Hoe vaak breken Facebook scraper GitHub-repositories?
Regelmatig. Facebook wijzigt voortdurend zijn DOM-structuur, anti-botmaatregelen en interne API's — er is geen openbaar vast ritme, maar communitymeldingen laten zien dat actieve scrapers soms al binnen enkele weken stukgaan. De issuequeue van de moda20-fork rond het verdwijnen van mbasic is een recent voorbeeld. Als je op een GitHub-repo vertrouwt, reserveer dan tijd voor regelmatig onderhoud en outputvalidatie.
Meer lezen
