Facebook Scraper GitHub: Wat nog werkt en wat niet

Een GitHub-zoekopdracht naar "facebook scraper" levert op. Slechts zijn in de afgelopen zes maanden nog gepusht.

Dat gat tussen "beschikbaar" en "werkt echt" vertelt eigenlijk het hele verhaal van Facebook-scraping op GitHub in 2026.

Ik heb veel tijd gestoken in het doorspitten van issue-tabs van repositories, klachten op Reddit en de daadwerkelijke output van deze tools. Het patroon is steeds hetzelfde: de meeste projecten met veel sterren zijn stilletjes kapot, maintainers zijn ermee gestopt en Facebooks anti-scrapingverdediging wordt alleen maar strenger. Ontwikkelaars en zakelijke gebruikers komen telkens op dezelfde zoekresultaten uit, installeren dezelfde repos en lopen tegen exact dezelfde lege output aan. Dit artikel is een realiteitscheck voor 2026 — een eerlijke audit van welke repos je tijd nog waard zijn, wat Facebook doet om ze te breken en wanneer je GitHub beter helemaal kunt overslaan.

Waarom mensen op GitHub zoeken naar een Facebook scraper

De use cases achter deze zoekopdracht zijn al jaren hetzelfde — ook al vallen de tools steeds uit elkaar:

• Leadgeneratie: Contactgegevens van bedrijfspagina’s extraheren, zoals e-mails, telefoonnummers en adressen, voor outreach
• Marketplace-monitoring: Productvermeldingen, prijzen en verkopersinformatie volgen voor e-commerce of arbitrage
• Groeponderzoek: Berichten en reacties archiveren voor marktonderzoek, OSINT of communitybeheer
• Content- en postarchivering: Openbare pagina-posts, reacties, afbeeldingen en tijdstempels opslaan
• Evenementenaggregatie: Titels, data, locaties en organisatoren van evenementen ophalen

De aantrekkingskracht van GitHub is duidelijk: zichtbare code, geen kosten, community-onderhoud (in theorie) en volledige controle over velden en pipelines.

Het probleem is dat sterren en forks niet correleren met "momenteel functioneel". Onder de top 10 repositories met de exacte term op basis van sterren waren . Dat is geen toeval — dat is de norm.

Een Reddit-gebruiker zei in een heel direct na zes maanden proberen dat het "onmogelijk" was zonder óf te betalen voor een externe data scraping-applicatie, óf Python te gebruiken met JS-rendering en flinke rekenkracht. Een ander vatte het in een samen als: "Facebook is een van de lastigste om te scrapen, omdat ze automatisering agressief blokkeren" en browserautomatisering is "kwetsbaar omdat Facebook hun DOM voortdurend wijzigt."

De use cases zijn echt. De vraag is echt. De frustratie is dat ook. De rest van dit artikel gaat over hoe je met dat gat omgaat.

Wat is een Facebook scraper GitHub-repo eigenlijk?

Een "Facebook scraper" op GitHub is een open-source script — meestal in Python — dat programmatisch openbare gegevens extraheert van Facebook-pagina’s, posts, groepen, Marketplace of profielen. Ze werken niet allemaal op dezelfde manier. Drie architecturen domineren:

Browserautomatiseringsscrapers vs. API-wrappers vs. directe HTTP-scrapers

is het klassieke voorbeeld van directe HTTP: het scrapt openbare pagina’s "zonder API-key" via directe requests en parsing. is een voorbeeld van browserautomatisering. vertegenwoordigt het oude Graph API-tijdperk, waarin scripts via officiële endpoints posts van pagina’s en groepen konden ophalen — iets wat nu niet meer breed beschikbaar is.

Typische doeldata in deze repos zijn posttekst, tijdstempels, aantallen reacties en likes, afbeeldings-URL’s, paginametadata (categorie, telefoon, e-mail, volgeraantal), velden voor Marketplace-vermeldingen en metadata van groepen of evenementen.

In 2026 zit de echte afweging niet in taalvoorkeur. Het gaat om welk type storing je kunt verdragen.

De GitHub-versheidsaudit van Facebook scrapers in 2026: welke repos werken echt?

Ik heb de meest sterrenrijke en meest aanbevolen Facebook scraper-repos op GitHub vergeleken met echte data uit 2026 — niet met beweringen in README’s, maar met daadwerkelijke commitdatums, issue-queues en meldingen uit de community. Dit is het belangrijkste deel.

De volledige versheidsaudit-tabel

Een paar dingen springen eruit:

• Zelfs de "actieve fork" (moda20) is sinds juni 2024 niet meer gepusht.
• De issue-queue vertelt het echte verhaal sneller dan de README.
• Zowel kevinzg als moda20 vermelden nog steeds Python ^3.6 in hun -bestanden — een signaal dat de afhankelijkhedenbasis niet is gemoderniseerd.

kevinzg/facebook-scraper

De bekendste Python Facebook scraper op GitHub. De beschrijft het scrapen van pagina’s en groepen, inloggen met credentials of cookies, en postniveau-velden zoals comments, image, images, likes, post_id, post_text, text en time.

Het operationele signaal is echter zwak:

• Laatste push: 22 juni 2024
• Open issues: — inclusief titels als "Example Scrape does not return any posts"
• De maintainer heeft niet gereageerd op recente issues

Oordeel: Gedeeltelijk stuk. Nog nuttig voor experimenten met openbare pagina’s op kleine schaal en als referentie voor veldnamen, maar niet betrouwbaar voor productie.

moda20/facebook-scraper (community fork)

De meest zichtbare fork van kevinzg, met extra opties en Marketplace-helpers zoals extract_listing (gedocumenteerd in de ).

De 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, stort een hele klasse scrapers tegelijk in.

Oordeel: De meest noemenswaardige fork, maar in 2026 ook verouderd en kwetsbaar. Het proberen waard 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 pagina’s en open groepen naar CSV’s te halen. De legt nog steeds uit hoe je de App ID en App Secret van een Facebook-app gebruikt.

In 2026 is het 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 sindsdien aanzienlijk heeft aangescherpt.

Andere noemenswaardige repos

• passivebot/facebook-marketplace-scraper: Nuttig voor Marketplace-usecases, maar de bevat "login to view the content", "CSS selectors outdated" en "Getting blocked". Een case study in één regel van wat er misgaat bij Marketplace-scraping.
• apurvmishra99/facebook-scraper-selenium: Heeft een issue dat letterlijk vraagt uit september 2020. Dat zegt eigenlijk al genoeg.
• Mhmd-Hisham/selenium_facebook_scraper en anabastos/faceteer: Geen van beide heeft genoeg recente activiteit om vertrouwen te rechtvaardigen.

Facebooks anti-scrapingverdediging: waar elke GitHub-scraper tegenaan loopt

De meeste artikelen over dit onderwerp geven vage waarschuwingen als "check de ToS". Daar heb je weinig aan.

Facebook heeft een van de agressiefste anti-scrapingsystemen van alle grote platforms. Begrijpen welke verdedigingslagen er zijn, is het verschil tussen een werkende scraper en een middag vol lege output.

Meta’s eigen beschrijft een "Anti Scraping team" dat via statische analyse over de codebase heen scrapingvectoren opspoort, cease-and-desist-brieven verstuurt, accounts uitschakelt en vertrouwt op rate-limiting. Dat is geen theoretisch verhaal — het is een expliciete organisatorische aanpak.

Willekeurige DOM en CSS-klassen

Facebook randomiseert bewust HTML-element-ID’s, klassennamen en de paginastructuur. Zoals een commenter op het verwoordde: "Geen enkele normale scraper kan op Facebook werken. De HTML muteert tussen verversingen."

Wat breekt: XPath- en CSS-selectors die vorige week nog werkten, leveren vandaag niets op.

Tegenmaatregel: Gebruik waar mogelijk tekstgebaseerde of attribuutgebaseerde selectors. AI-gebaseerde parsing die de paginainhoud leest in plaats van op rigide selectors te leunen, doet het hier beter. Houd rekening met selectoronderhoud als terugkerende kostenpost.

Login-muren en sessiebeheer

Veel Facebook-delen — profielen, groepen, sommige Marketplace-vermeldingen — vereisen inloggen om ze te bekijken. Headless browsers worden omgeleid of krijgen uitgeklede HTML voorgeschoteld. In de 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 van een echte browsersessie, of browsergebaseerde scrapingtools die binnen je ingelogde sessie werken. Accounts roteren kan, maar is riskant.

Digitale fingerprinting

Meta’s engineering-post zegt dat ongeautoriseerde scrapers — feitelijk een aanwijzing dat browserkwaliteit en gedragskwaliteit centraal staan bij detectie. Communitygesprekken in en bevelen nog steeds anti-detect-browsers en consistente fingerprints aan.

Wat breekt: Standaard Selenium- of Puppeteer-opstellingen zijn eenvoudig te herkennen.

Tegenmaatregel: Gebruik tools zoals undetected-chromedriver of anti-detect-browserprofielen. Realistische sessies en consistente fingerprints zijn belangrijker dan alleen user-agent-spoofing.

Rate limiting en blokkering op IP-basis

Meta’s engineering-post bespreekt rate limiting expliciet als onderdeel van de verdedigingsstrategie, inclusief het begrenzen van volgerlijsten om meer requests uit te lokken die vervolgens . In de praktijk melden gebruikers dat ze al rate-limited worden na het posten in .

Wat breekt: Bulk requests vanaf hetzelfde IP worden binnen minuten afgeremd of geblokkeerd. Datacenter-proxy’s zijn vaak al vooraf geblokkeerd.

Tegenmaatregel: Rotatie via residential proxies (niet via datacenter-proxy’s), met een verstandig request-tempo.

GraphQL-schemawijzigingen

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 vallen stilletjes uit — ze leveren lege data in plaats van fouten.

Wat breekt: Gestructureerde extractie geeft stilletjes niets terug.

Tegenmaatregel: Voeg validatiecontroles toe, monitor schema-endpoints en pin op queries waarvan je weet dat ze werken. Reken op onderhoud.

Samenvatting van anti-scrapingverdediging

Als GitHub-repos falen: de no-code uitweg

Een groot deel van de mensen die op "facebook scraper github" uitkomen, zijn geen developers. Het zijn salesmedewerkers die e-mails van bedrijfspagina’s zoeken, e-commerce-operators die Marketplace-prijzen volgen, of marketeers die concurrentieonderzoek doen. Zij willen geen Python-omgeving beheren, kapotte selectors debuggen of proxies roteren.

Klinkt dat als jij? Dan is de keuze vrij kort:

Facebook-paginacontactgegevens scrapen (e-mails, telefoonnummers)

Als het doel is om e-mails en telefoonnummers uit de "Over"-secties van pagina’s te halen, is een GitHub-repo overkill. Thunderbit’s gratis en scannen een webpagina en exporteren resultaten naar Sheets, Excel, Airtable of Notion. De AI leest de pagina telkens opnieuw, dus DOM-wijzigingen van Facebook breken het niet.

Gestructureerde data uit Marketplace of bedrijfspagina’s scrapen

Voor het extraheren van productvermeldingen, prijzen, locaties of bedrijfsgegevens laat Thunderbit’s AI-webscraper je op "AI stelt velden voor" klikken — de AI leest de pagina en stelt kolommen voor zoals prijs, titel en locatie — en daarna klik je op "Scrapen". Geen onderhoud van XPath, geen code-installatie. Exporteer direct naar .

Geplande monitoring (Marketplace-prijsalerts, concurrentietracking)

Voor doorlopende monitoring — "waarschuw me als een Marketplace-vermelding binnen mijn prijsklasse valt" — laat Thunderbit’s je de interval in gewone taal beschrijven (zoals ) en URL’s instellen. Het draait automatisch, zonder cronjob.

Wanneer GitHub-repos nog steeds de juiste keuze zijn

Als je diepe programmatische controle, grootschalige extractie of aangepaste datapipelines nodig hebt, zijn GitHub-repos (of voor gestructureerde extractie) de juiste tool. De afweging is simpel: zakelijke gebruikers met eenvoudige extractiebehoeften → eerst no-code; developers die datapipelines bouwen → GitHub-repos of API.

Echte outputvoorbeelden: wat je daadwerkelijk krijgt

Elke concurrentieblog toont codefragmenten, maar nooit de echte output. Hieronder zie je wat je realistisch kunt verwachten van elke aanpak.

Voorbeeldoutput: kevinzg/facebook-scraper (of actieve fork)

Volgens het levert een gescrapete openbare post JSON op zoals:

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "Laat deze kleine versie niet...",
9  "text": "Laat deze kleine versie niet...",
10  "time": "2019-04-30T05:00:01"
11}

Let op de nullable velden zoals comments_full. In 2026 moet je verwachten dat meer velden leeg of afwezig terugkomen — dat is meestal een blokkadesignaal, geen onschuldige storing. De output is ruwe JSON en vereist nabewerking.

Voorbeeldoutput: Facebook Graph API

Meta’s huidige documenteert paginaverzoeken zoals GET /<PAGE_ID>?fields=id,name,about,fan_count. De bevat velden zoals followers_count, fan_count, category, emails, phone en andere openbare metadata — maar alleen met de juiste permissies, zoals .

Dat is een veel smaller datamodel dan de meeste gebruikers van GitHub-scrapers verwachten. Het is pagina-georiënteerd, afgeschermd met permissies en geen vervanging voor willekeurige openbare post- of groepsscraping.

Voorbeeldoutput: Thunderbit AI Web Scraper

De door AI voorgestelde kolommen voor een Facebook-bedrijfspagina leveren een nette, gestructureerde tabel op:

Voor posts en reacties ziet de output er zo uit:

Gestructureerde kolommen, opgemaakte telefoonnummers, direct bruikbare data — zonder nabewerkingsstap. Het contrast met ruwe JSON uit GitHub-tools is moeilijk te missen.

Matrix voor Facebook-datatype × beste tool

Geen enkele tool doet alles goed op Facebook in 2026.

Met deze matrix kun je direct naar jouw use case springen in plaats van het hele artikel te lezen in de hoop het juiste antwoord te vinden.

Welke aanpak past bij jouw team?

• Salesteams die leads extraheren: Begin met Thunderbit’s E-mail-/Telefoon-extractor of AI Scraper. Geen setup, direct resultaat.
• E-commerce teams die Marketplace monitoren: Thunderbit’s Geplande scraper of een custom Scrapy-opzet met residential proxies (als je de engineeringcapaciteit hebt).
• Developers die datapipelines bouwen: GitHub-repos (actieve forks) + residential proxies + onderhoudsbudget. Reken op doorlopend werk.
• Onderzoekers die groepscontent archiveren: Alleen browsergebaseerde workflow (Thunderbit of Selenium met login), met compliance-review.

De eerlijke conclusie — en degene waar — is dat er geen enkele betrouwbare totaaloplossing is. Koppel je specifieke databehoefte aan de juiste tool.

Stap voor stap: hoe je een Facebook scraper uit GitHub opzet (als het zin heeft)

Als je de versheidsaudit hebt gelezen en toch voor de GitHub-route wilt gaan, prima. Hier is de praktische route — met eerlijke opmerkingen over waar het misgaat.

Stap 1: Kies de juiste repo (gebruik de versheidsaudit)

Ga terug naar de audit-tabel. Kies de minst verouderde repo die past bij jouw doel. Controleer vóór installatie altijd de Issues-tab — recente issue-titels vertellen je meer over de huidige werking dan de README.

Stap 2: Zet je Python-omgeving op

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

Veelvoorkomende valkuil: versieconflicten met dependencies, vooral met Selenium-/Playwright-versies. Zowel kevinzg als moda20 vermelden Python ^3.6 in hun — een oudere basis die kan conflicteren met nieuwere libraries. passivesbots Marketplace-scraper pin’t , 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 via 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 gesignaleerd

Stap 4: Draai een kleine testrun 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 echt op de pagina 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
• Verwacht dat je selectors of configuraties 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 gebruiken van de data, is dat een teken dat je de no-code-route opnieuw moet overwegen

Juridische en ethische overwegingen bij Facebook-scraping

Dit deel is kort en feitelijk. Het is niet de focus van het artikel, maar het negeren ervan zou onverantwoord zijn.

Facebooks stellen dat gebruikers "geen gegevens van onze Producten mogen openen of verzamelen met geautomatiseerde middelen (zonder onze voorafgaande toestemming)." Meta’s , bijgewerkt op 3 februari 2026, maken duidelijk dat handhaving kan bestaan uit schorsing, intrekking van API-toegang en maatregelen op accountniveau.

Dit is niet theoretisch. Meta’s beschrijft actief onderzoek naar ongeautoriseerde scraping, cease-and-desist-brieven en het uitschakelen van accounts. Meta heeft ook tegen scrapingbedrijven (bijvoorbeeld de rechtszaak tegen Voyager Labs).

De veiligste insteek:

• Meta’s voorwaarden zijn expliciet anti-scraping
• Gebruik van een geautoriseerde API is veiliger dan ongeautoriseerde scraping
• Openbare beschikbaarheid heft privacyverplichtingen niet op (GDPR, CCPA, enz.)
• Raadpleeg juridisch advies als je op schaal werkt
• Thunderbit is ontworpen voor het scrapen van openbaar beschikbare data en omzeilt bij cloud scraping geen loginvereisten

Belangrijkste conclusies: wat in 2026 echt werkt voor Facebook-scraping

De meeste GitHub-repos voor Facebook scrapers zijn in 2026 kapot of onbetrouwbaar. Dat is geen bangmakerij — dat is wat commitdatums, issue-queues en meldingen uit de community consequent laten zien.

De paar actieve forks werken nog voor beperkte openbare paginad data, maar vereisen doorlopend onderhoud, anti-detectie-opzet en een realistische verwachting dat dingen opnieuw zullen stukgaan. De Graph API is nuttig, maar beperkt — hij dekt paginametadata met de juiste permissies, niet de brede openbare post- of groepsscraping die de meeste mensen willen.

Voor zakelijke gebruikers die Facebook-data nodig hebben zonder de overhead van development bieden no-code tools zoals een betrouwbaardere en onderhoudsarme route. De AI leest de pagina telkens opnieuw, dus DOM-wijzigingen breken je workflow niet. Je kunt de gratis proberen en exporteren naar Sheets, Excel, Airtable of Notion.

De praktische aanbeveling: begin met de versheidsaudit-tabel. Ben je geen developer? Probeer dan eerst de no-code-optie. Ben je wel developer? Investeer alleen in een GitHub-opzet als je de technische middelen — en het geduld — hebt om die te onderhouden. En ongeacht welke route je kiest: koppel je specifieke databehoefte aan de juiste tool in plaats van te hopen op één oplossing die alles doet.

Als je dieper wilt gaan op het scrapen van socialmediadata en aanverwante tools, hebben we gidsen over , en . Je kunt ook walkthroughs bekijken op het .

FAQ’s

Is er in 2026 een werkende Facebook scraper op GitHub?

Ja, maar de opties zijn beperkt. De meest noemenswaardige is de fork van het oorspronkelijke kevinzg-repo — zie de versheidsaudit-tabel hierboven voor de huidige status. Die kan gedeeltelijk openbare pagina-posts en sommige metadata scrapen, maar de issue-queue laat duidelijke breuken zien rond mbasic en lege output. De meeste andere repos zijn verlaten of volledig stuk.

Kan ik Facebook scrapen zonder te coderen?

Ja. Tools zoals en gratis E-mail-/Telefoon-extractors laten je Facebook-data met een paar klikken uit je browser halen, zonder Python- of GitHub-setup. De AI leest de pagina telkens opnieuw, dus je hoeft selectors niet te onderhouden wanneer Facebook de lay-out wijzigt.

Is het legaal om Facebook te scrapen?

Facebooks verbieden geautomatiseerde gegevensverzameling zonder toestemming. Meta handhaaft dit actief via accountblokkades, cease-and-desist-brieven en . De legaliteit verschilt per jurisdictie en use case. Houd je aan openbaar beschikbare bedrijfsdata, vermijd persoonlijke profielen en vraag juridisch advies als je op schaal werkt.

Welke data kan ik nog uit de Facebook Graph API halen?

In 2026 is de sterk beperkt. Je kunt beperkte paginaniveau-data benaderen — velden zoals id, name, about, fan_count, emails, phone — met de juiste permissies zoals . De meeste openbare postdata, groepsdata (de ) en gebruikersniveau-data zijn niet langer via de API beschikbaar.

Hoe vaak lopen Facebook scraper GitHub-repos stuk?

Vaak. Facebook wijzigt zijn DOM-structuur, anti-botmaatregelen en interne API’s voortdurend — er is geen officieel ritme, maar communitymeldingen laten zien dat actieve scrapers om de paar weken stukgaan. De issue-queue van de moda20-fork rond het verdwijnen van mbasic is een recent voorbeeld. Als je afhankelijk bent van een GitHub-repo, reserveer dan tijd en budget voor regelmatig onderhoud en outputvalidatie.

Meer lezen