Facebook Scraper GitHub: Hva som fortsatt fungerer, og hva som ikke gjør det

Et GitHub-søk etter "facebook scraper" gir . Bare har vært oppdatert i løpet av de siste seks månedene.

Avstanden mellom "tilgjengelig" og "faktisk fungerende" er hele historien om Facebook-scraping på GitHub i 2026.

Jeg har brukt mye tid på å gå gjennom issue-faner, klager på Reddit og faktisk output fra disse verktøyene. Mønsteret er konsekvent: De fleste prosjektene med høyest stjernevurdering er stille og rolig blitt ødelagt, vedlikeholderne har gått videre, og Facebooks anti-scraping-forsvar blir stadig skarpere. Utviklere og forretningsbrukere ender opp på de samme søkeresultatene, installerer de samme repositoriene og møter den samme tomme outputen. Denne artikkelen er en realitetskontroll for 2026 — en ærlig gjennomgang av hvilke repositorier som fortsatt er verdt tiden din, hva Facebook gjør for å knekke dem, og når du bør droppe GitHub helt.

Hvorfor folk søker etter en Facebook Scraper på GitHub

Bruksområdene bak søket er de samme som har eksistert i årevis — selv om verktøyene stadig faller fra hverandre:

• Leadgenerering: Hente kontaktinformasjon fra bedriftsider (e-post, telefonnummer, adresser) til outreach
• Overvåking av Marketplace: Følge produktannonser, priser og selgerinformasjon for e-handel eller arbitrage
• Gruppeanalyse: Arkivere innlegg og kommentarer til markedsundersøkelser, OSINT eller community management
• Innholds- og innleggarkivering: Lagre offentlige sideinnlegg, reaksjoner, bilder og tidsstempler
• Hendelsesinnsamling: Hente titler, datoer, steder og arrangører for arrangementer

GitHubs appell er åpenbar: synlig kode, null kostnad, vedlikehold fra fellesskapet (i teorien) og full kontroll over felt og pipelines.

Problemet er at stjerner og forks ikke sier noe om hva som faktisk fungerer akkurat nå. Blant de 10 repositoriene med eksakt frase og flest stjerner var per april 2026. Det er ikke et unntak — det er normalen.

En Reddit-bruker i en sa det rett ut etter seks måneder med forsøk: det var "umulig uten enten å betale for en ekstern dataskrapingsapp" eller bruke Python sammen med JS-rendering og betydelig regnekraft. En annen, i en , oppsummerte det slik: "Facebook er en av de vanskeligste å skrape fordi de blokkerer automatisering aggressivt", og nettleserautomatisering er "skjør fordi Facebook endrer DOM-en hele tiden."

Bruksområdene er reelle. Etterspørselen er reell. Frustrasjonen er veldig reell. Resten av denne artikkelen handler om hvordan du navigerer det gapet.

Hva er egentlig et Facebook Scraper GitHub-repo?

En "Facebook scraper" på GitHub er et åpen kildekode-skript — vanligvis i Python — som programmatisk henter offentlige data fra Facebook-sider, innlegg, grupper, Marketplace eller profiler. Ikke alle fungerer på samme måte. Tre arkitekturer dominerer:

Nettleserautomatisering kontra API-wrappere kontra direkte HTTP-scrapere

er det klassiske eksemplet på direkte HTTP: det skraper offentlige sider "uten API-nøkkel" ved å bruke direkte forespørsler og parsing. er et eksempel på nettleserautomatisering. representerer Graph API-æraen, da skript kunne hente innlegg fra sider og grupper via offisielle endepunkter som ikke lenger er bredt tilgjengelige.

Typiske måldata på tvers av disse repositoriene inkluderer innleggstekst, tidsstempler, antall reaksjoner/kommentarer, bilde-URL-er, sidemetadata (kategori, telefon, e-post, følgerantall), felt for Marketplace-annonser og metadata for grupper eller arrangementer.

I 2026 er det virkelige valget ikke språkpreferanse. Det er hvilken type feil du kan leve med.

Friskhetsgjennomgang av Facebook Scraper GitHub i 2026: Hvilke repos fungerer faktisk?

Jeg har gjennomgått de mest stjernemerkede og mest anbefalte Facebook-scraper-repositoriene på GitHub opp mot reelle data for 2026 — ikke README-påstander, men faktiske commit-datoer, issue-køer og rapporter fra fellesskapet. Dette er den viktigste delen.

Hele friskhetstabellen

Noen ting skiller seg ut med en gang:

• Selv den "aktive forken" (moda20) har ikke vært pushet siden juni 2024.
• Issue-køer forteller den egentlige historien raskere enn README-filer.
• Både kevinzg og moda20 oppgir fortsatt Python ^3.6 i -filene sine — et tegn på at avhengighetsbasen ikke har blitt modernisert.

kevinzg/facebook-scraper

Den mest kjente Python Facebook-scraperen på GitHub. beskriver sidescraping, gruppescraping, innlogging med legitimasjon eller cookies, og felter på innleggsnivå som comments, image, images, likes, post_id, post_text, text og time.

Driftssignalet er likevel svakt:

• Siste push: 22. juni 2024
• Åpne issues: — inkludert titler som "Example Scrape does not return any posts"
• Vedlikeholderen har ikke svart på nylige issues

Konklusjon: Delvis ødelagt. Fortsatt nyttig for små eksperimenter med offentlige sider og som referanse for feltnavn, men ikke pålitelig for produksjon.

moda20/facebook-scraper (fellesskapsfork)

Den mest synlige forken av kevinzg, med flere valg og hjelpefunksjoner rettet mot Marketplace, som extract_listing (dokumentert i ).

gjør sammenbruddshistorien tydelig:

• "mbasic is gone"
• "CLI 'Couldn't get any posts.'"
• "https://mbasic.facebook.com is no longer working"

Når den forenklede mbasic-frontenden endres eller forsvinner, blir en hel klasse scrapers dårligere samtidig.

Konklusjon: Den mest kjente forken, men også utdatert og skjør i 2026. Verdt å prøve først hvis du absolutt vil bruke en GitHub-basert løsning, men ikke forvent stabilitet.

minimaxir/facebook-page-post-scraper

En gang et veldig praktisk Graph API-verktøy for å samle innlegg, reaksjoner, kommentarer og metadata fra offentlige sider og åpne grupper til CSV-filer. forklarer fortsatt hvordan du bruker en Facebook-apps App ID og App Secret.

I 2026 er det et historisk artefakt:

• Siste push: 23. mai 2019
• Åpne issues: 53 — inkludert "HTTP 400 Error Bad Request" og "No data retrieved!!"

Konklusjon: Forlatt. Sterkt knyttet til en API-tillatelsesmodell Meta siden har strammet kraftig inn.

Andre relevante repositorier

• passivebot/facebook-marketplace-scraper: Nyttig for Marketplace-bruk, men inneholder "login to view the content", "CSS selectors outdated" og "Getting blocked". En énlinjers case study i hva som går galt med Marketplace-scraping.
• apurvmishra99/facebook-scraper-selenium: Har et issue som bokstavelig talt spør fra september 2020. Det sier stort sett alt.
• Mhmd-Hisham/selenium_facebook_scraper og anabastos/faceteer: Ingen av dem har nok nyere aktivitet til å gi tillit.

Facebooks anti-scraping-forsvar: Hva alle GitHub-scrapere må kjempe mot

De fleste artikler om dette temaet byr bare på vage "sjekk vilkårene"-forbehold. Det er ikke nyttig.

Facebook har et av de mest aggressive anti-scraping-systemene blant store plattformer. Å forstå de spesifikke forsvarslagene er forskjellen mellom en fungerende scraper og en ettermiddag med tom output.

Metas egen beskriver et "Anti Scraping team" som bruker statisk analyse på tvers av kodebasen for å identifisere scraping-vektorer, sender cease-and-desist-brev, deaktiverer kontoer og er avhengig av rate limiting-systemer. Dette er ikke hypotetisk — det er et organisasjonsmessig valg.

Tilfeldiggjort DOM og CSS-klassenavn

Facebook randomiserer bevisst HTML-element-ID-er, klassenavn og sidestruktur. Som en uttrykte det: "No normal scraper can work on Facebook. The HTML mutates between refreshes."

Hva som bryter: XPath- og CSS-selektorer som fungerte forrige uke, returnerer ingenting i dag.

Mottiltak: Bruk tekstbaserte eller attributtbaserte selektorer når det er mulig. AI-basert parsing som leser sideinnhold i stedet for å stole på rigide selektorer, håndterer dette bedre. Regn med selektorvedlikehold som en løpende kostnad.

Innloggingsvegger og sesjonshåndtering

Mange Facebook-områder — profiler, grupper og enkelte Marketplace-annonser — krever innlogging for å vises. Hodeløse nettlesere blir ofte omdirigert eller får redusert HTML. passivebot Marketplace-scraperens har "login to view the content" som en av de største klagene.

Hva som bryter: Anonyme forespørsler mister innhold eller blir omdirigert helt.

Mottiltak: Bruk session-cookies fra en ekte nettlesersesjon, eller nettleserbaserte skrapeverktøy som opererer innenfor den innloggede sesjonen din. Rotering av kontoer er mulig, men risikabelt.

Digital fingerprinting

Metas engineering-post sier at uautoriserte scrapers — som i praksis betyr at kvaliteten på nettleser og atferd er sentralt for deteksjon. Fellesskapsdiskusjoner i og anbefaler fortsatt anti-detect-nettlesere og konsistente fingerprints.

Hva som bryter: Standardoppsett med Selenium eller Puppeteer blir lett identifisert.

Mottiltak: Bruk verktøy som undetected-chromedriver eller anti-detect-nettleserprofiler. Realistiske sesjoner og konsistente fingerprints er viktigere enn enkel user-agent-spoofing.

IP-basert rate limiting og blokkering

Metas engineering-post omtaler eksplisitt rate limiting som en del av forsvarsstrategien, inkludert begrensning av følgelister for å tvinge fram flere forespørsler som deretter . I praksis rapporterer brukere at de blir rate-limitert etter å ha postet til .

Hva som bryter: Masseforespørsler fra samme IP blir strupet eller blokkert i løpet av minutter. Datacenter-proxyer er ofte allerede blokkert.

Mottiltak: Rotering av residential proxies, ikke datacenter-proxyer, med fornuftig forespørselstakt.

Endringer i GraphQL-skjema

Noen scrapers er avhengige av Facebooks interne GraphQL-endepunkter fordi de gir renere strukturert data enn rå HTML. Men Meta publiserer ingen stabilitetsgaranti for intern GraphQL, så disse spørringene bryter stille — de returnerer tom data i stedet for feil.

Hva som bryter: Strukturert uthenting returnerer stille og rolig ingenting.

Mottiltak: Legg inn valideringssjekker, overvåk skjemaendepunkter og lås deg til spørringer som er kjent fungerende. Regn med vedlikehold.

Sammendrag av anti-scraping-forsvar

Når GitHub-repositorier feiler: den no-code fluktveien

En stor andel av dem som søker på "facebook scraper github" er ikke utviklere. De er selgere som vil ha e-postadresser fra bedriftsider, e-handelsaktører som følger priser i Marketplace, eller markedsførere som driver konkurrentanalyse. De vil ikke administrere et Python-miljø, feilsøke ødelagte selektorer eller rotere proxyer.

Hvis det høres ut som deg, er beslutningstreet kort:

Skraping av kontaktinformasjon fra Facebook-sider (e-post, telefonnummer)

Hvis jobben er å hente e-postadresser og telefonnummer fra «Om»-seksjoner på sider, er et GitHub-repo overkill. 's gratis og skanner en nettside og eksporterer resultatene til Sheets, Excel, Airtable eller Notion. AI-en leser siden på nytt hver gang, så endringer i Facebooks DOM knekker den ikke.

Skraping av strukturert data fra Marketplace eller bedriftsider

For uthenting av produktannonser, priser, steder eller bedriftsdetaljer lar Thunderbits AI Web Scraper deg klikke på "AI Suggest Fields" — AI-en leser siden og foreslår kolonner som pris, tittel og sted — og så klikker du "Scrape." Ingen vedlikehold av XPath, ingen kodeinstallasjon. Eksporter direkte til .

Planlagt overvåking (prisvarsler i Marketplace, konkurransesporing)

For løpende overvåking — "varsle meg når en Marketplace-annonse matcher prisområdet mitt" — lar Thunderbits deg beskrive intervallet med vanlig språk (som ) og angi URL-er. Den kjører automatisk, uten behov for cron-jobb.

Når GitHub-repositorier fortsatt er riktig valg

Hvis du trenger dyp programmatisk kontroll, uthenting i stor skala eller egne datapipelines, er GitHub-repositorier (eller for strukturert uthenting) riktig verktøy. Valget er enkelt: forretningsbrukere med enkle behov → no-code først; utviklere som bygger datapipelines → GitHub-repositorier eller API.

Ekte output-eksempler: det du faktisk får

Hver konkurrentartikkel viser kodebiter, men aldri den faktiske outputen. Under ser du hva du realistisk kan forvente fra hver tilnærming.

Eksempel på output: kevinzg/facebook-scraper (eller aktiv fork)

Fra returnerer et skrapet offentlig innlegg JSON som dette:

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

Legg merke til nullable-feltene som comments_full. I 2026 må du forvente at flere felt kommer tilbake tomme eller mangler — det er som regel et tegn på blokkering, ikke en ufarlig feil. Outputen er rå JSON og krever etterbehandling.

Eksempel på output: Facebook Graph API

Metas nåværende dokumenterer forespørsler om sideinformasjon som GET /<PAGE_ID>?fields=id,name,about,fan_count. inkluderer felter som followers_count, fan_count, category, emails, phone og annen offentlig metadata — men bare med riktige tillatelser som .

Det er en mye smalere datastruktur enn de fleste brukere av GitHub-scrapere forventer. Den er side-sentrert, styrt av tillatelser, og ikke en erstatning for vilkårlig scraping av offentlige innlegg eller grupper.

Eksempel på output: Thunderbit AI Web Scraper

Thunderbits AI-forslåtte kolonner for en Facebook-bedriftsside gir en ren, strukturert tabell:

For innlegg og kommentarer ser outputen slik ut:

Strukturerte kolonner, formaterte telefonnumre, data klare til bruk — uten noe etterbehandlingstrinn. Kontrasten til rå JSON fra GitHub-verktøy er vanskelig å overse.

Facebook-datatype × beste verktøymatrise

Ett enkelt verktøy håndterer ikke alt godt på Facebook i 2026.

Denne matrisen lar deg hoppe direkte til brukstilfellet ditt i stedet for å lese hele artikkelen og håpe på å finne riktig svar.

Hvilken tilnærming passer teamet ditt?

• Salgs-team som henter leads: Start med Thunderbits Email/Phone Extractor eller AI Scraper. Ingen oppsett, umiddelbare resultater.
• E-handels-team som overvåker Marketplace: Thunderbits Scheduled Scraper eller et egendefinert Scrapy-oppsett med residential proxies (hvis du har ingeniørressursene).
• Utviklere som bygger datapipelines: GitHub-repositorier (aktive forks) + residential proxies + et vedlikeholdsbudsjett. Regn med løpende arbeid.
• Forskere som arkiverer gruppeinnhold: Kun nettleserbasert arbeidsflyt (Thunderbit eller Selenium med innlogging), med gjennomgang av etterlevelse.

Den ærlige konklusjonen — og den — er at det ikke finnes én pålitelig løsning. Match ditt spesifikke databehov med riktig verktøy.

Steg for steg: Slik setter du opp en Facebook Scraper fra GitHub (når det gir mening)

Hvis du har lest friskhetsgjennomgangen og fortsatt vil gå GitHub-veien, fair nok. Her er den praktiske ruten — med ærlige notater om hvor ting går i stykker.

Trinn 1: Velg riktig repo (bruk friskhetsgjennomgangen)

Se tilbake på tabellen over. Velg det minst utdaterte repoet som passer måloverflaten din. Før du installerer noe, sjekk Issues-fanen — nylige issuetitler forteller deg mer om nåværende funksjonalitet enn README-en gjør.

Trinn 2: Sett opp Python-miljøet ditt

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

Vanlig fallgruve: versjonskonflikter med avhengigheter, særlig Selenium-/Playwright-versjoner. Både kevinzg og moda20 oppgir Python ^3.6 i — et eldre utgangspunkt som kan kollidere med nyere biblioteker. passivebots Marketplace-scraper låser , som er greit for eksperimentering, men ikke bevis på varighet.

Trinn 3: Konfigurer proxyer og anti-deteksjon

Hvis du gjør noe mer enn en rask test:

• Sett opp rotasjon av residential proxies (se etter leverandører med Facebook-spesifikke IP-pooler)
• Hvis du bruker nettleserautomatisering, installer undetected-chromedriver eller konfigurer anti-fingerprinting
• Ikke hopp over dette trinnet — standard Selenium eller Puppeteer blir flagget raskt

Trinn 4: Kjør en liten testskraping og valider outputen

Start med én offentlig side, ikke en stor batch. Sjekk outputen nøye:

• Tomme felt eller manglende data betyr som regel at Facebooks forsvar blokkerer deg
• Sammenlign outputen med det du faktisk ser på siden i nettleseren din
• En vellykket test på én side er viktigere enn en pen README

Trinn 5: Håndter feil, rate limits og vedlikehold

• Bygg inn retry-logikk og feilhåndtering
• Forvent at du må oppdatere selektorer eller konfigurasjoner jevnlig — dette er løpende vedlikehold, ikke noe du setter opp én gang og glemmer
• Hvis du bruker mer tid på å vedlikeholde scrapersen enn på å bruke dataene, er det et signal om å vurdere no-code-veien på nytt

Juridiske og etiske hensyn ved Facebook-scraping

Denne delen er kort og faktabasert. Den er ikke hovedpoenget i artikkelen, men det ville vært uansvarlig å ignorere den.

Facebooks sier at brukere "may not access or collect data from our Products using automated means (without our prior permission)." Metas , oppdatert 3. februar 2026, gjør det klart at håndheving kan inkludere suspensjon, fjerning av API-tilgang og konto-tiltak.

Dette er ikke teori. Metas beskriver aktiv etterforskning av uautorisert scraping, cease-and-desist-brev og deaktivering av kontoer. Meta har også mot scrape-selskaper (for eksempel Voyager Labs-saken).

Den tryggeste rammen:

• Metas vilkår er uttrykkelig anti-scraping
• API-bruk med tillatelse er tryggere enn uautorisert scraping
• Offentlig tilgjengelighet opphever ikke forpliktelser etter personvernlovgivning (GDPR, CCPA osv.)
• Hvis du opererer i stor skala, bør du rådføre deg med juridisk rådgiver
• Thunderbit er laget for scraping av offentlig tilgjengelige data og omgår ikke innloggingskrav ved cloud scraping

Viktigste læringer: Hva som faktisk fungerer for Facebook-scraping i 2026

De fleste Facebook-scraper-GitHub-repositorier er ødelagte eller upålitelige i 2026. Det er ikke skremselspropaganda — det er det commit-datoer, issue-køer og rapporter fra fellesskapet konsekvent viser.

De få aktive forkene fungerer fortsatt for begrensede offentlige sidedata, men de krever løpende vedlikehold, oppsett for anti-deteksjon og en realistisk forventning om at ting vil knekke igjen. Graph API er nyttig, men smal — den dekker metadata på sidenivå med riktige tillatelser, ikke den brede offentlige innlegg- eller gruppescrapingen de fleste ønsker.

For forretningsbrukere som trenger Facebook-data uten utvikleroverhead, tilbyr no-code-verktøy som en mer pålitelig løsning med lavere vedlikeholdsbehov. AI-en leser siden på nytt hver gang, så endringer i DOM-en ødelegger ikke arbeidsflyten din. Du kan prøve gratis og eksportere til Sheets, Excel, Airtable eller Notion.

Det praktiske rådet: start med friskhetsgjennomgangstabellen. Hvis du ikke er utvikler, prøv no-code-alternativet først. Hvis du er utvikler, invester bare i et GitHub-oppsett hvis du har de tekniske ressursene — og tålmodigheten — til å vedlikeholde det. Og uansett hvilken vei du velger, bør du matche ditt konkrete databehov med riktig verktøy i stedet for å håpe på én løsning som gjør alt.

Hvis du vil gå dypere inn i scraping av sosiale medier og relaterte verktøy, har vi guider om , og . Du kan også se gjennomganger på .

Vanlige spørsmål

Finnes det en fungerende Facebook scraper på GitHub i 2026?

Ja, men alternativene er begrensede. Den mest relevante er forken av kevinzgs originale repo — se friskhetsgjennomgangstabellen ovenfor for nåværende status. Den kan delvis skrape offentlige sideinnlegg og noe metadata, men issue-køen viser kjernefeil rundt mbasic og tom output. De fleste andre repositorier er forlatt eller fullstendig ødelagt.

Kan jeg skrape Facebook uten å kode?

Ja. Verktøy som og gratis Email-/Phone Extractors lar deg hente Facebook-data fra nettleseren din med noen få klikk, uten behov for Python eller GitHub-oppsett. AI-en leser siden hver gang, så du slipper å vedlikeholde selektorer når Facebook endrer layout.

Er det lov å skrape Facebook?

Facebooks forbyr automatisk datainnsamling uten tillatelse. Meta håndhever dette aktivt gjennom kontoblokkeringer, cease-and-desist-brev og . Lovligheten varierer etter jurisdiksjon og brukstilfelle. Hold deg til offentlig tilgjengelige bedriftsdata, unngå personprofiler, og rådfør deg med juridisk rådgiver hvis du opererer i stor skala.

Hvilke data kan jeg fortsatt få fra Facebook Graph API?

I 2026 er kraftig begrenset. Du kan få tilgang til begrensede data på sidenivå — felter som id, name, about, fan_count, emails, phone — med riktige tillatelser som . De fleste offentlige innlegg, gruppedata ( ) og brukernivådata er ikke lenger tilgjengelige via API.

Hvor ofte går Facebook-scraper-repositorier på GitHub i stykker?

Ofte. Facebook endrer kontinuerlig DOM-strukturen, anti-bot-tiltakene og interne API-er — det finnes ingen publisert rytme, men rapporter fra fellesskapet viser at aktive scrapers knekker med noen ukers mellomrom. Issue-køen til moda20-forken rundt forsvinningen av mbasic er et nylig eksempel. Hvis du er avhengig av et GitHub-repo, må du sette av budsjett til regelmessig vedlikehold og output-validering.

Lær mer