Facebook Scraper GitHub: Hvad virker stadig, og hvad gør ikke

En GitHub-søgning efter "facebook scraper" giver . Kun er blevet opdateret inden for de seneste seks måneder.

Afstanden mellem "tilgængelig" og "faktisk virker" er hele historien om Facebook-scraping på GitHub i 2026.

Jeg har brugt rigtig meget tid på at gennemgå issue-faner, Reddit-klager og faktisk output fra disse værktøjer. Mønstret er tydeligt: de fleste projekter med mange stjerner er stille og roligt gået i stykker, vedligeholderne er videre, og Facebooks anti-scraping-forsvar bliver hele tiden skarpere. Udviklere og forretningsbrugere ender igen og igen på de samme søgeresultater, installerer de samme repos og møder det samme tomme output. Denne artikel er et realitetstjek for 2026 — en ærlig gennemgang af, hvilke repos der stadig er din tid værd, hvad Facebook gør for at få dem til at bryde sammen, og hvornår du helt bør springe GitHub over.

Hvorfor folk søger efter en Facebook Scraper på GitHub

Baggrunden for den her søgning er de samme brugsscenarier, som har eksisteret i årevis — selv om værktøjerne bliver ved med at falde fra hinanden:

• Leadgenerering: Udtræk af kontaktoplysninger fra virksomhedsider (e-mails, telefonnumre, adresser) til outreach
• Overvågning af marketplace: Sporing af produktlister, priser og sælgeroplysninger til ecommerce eller arbitrage
• Gruppeanalyse: Arkivering af opslag og kommentarer til markedsresearch, OSINT eller community management
• Arkivering af indhold og opslag: Gemning af offentlige opslag, reaktioner, billeder og tidsstempler fra sider
• Event-indsamling: Udtræk af eventtitler, datoer, lokationer og arrangører

GitHubs appel er oplagt: synlig kode, ingen omkostning, fællesskabsvedligeholdelse (i teorien) og fuld kontrol over felter og pipelines.

Problemet er, at stjerner og forks ikke siger noget om, om noget faktisk virker lige nu. Blandt de 10 repos med den præcise frase, som havde flest stjerner, var pr. april 2026. Det er ikke et tilfælde — det er normalen.

En Reddit-bruger i en formulerede det meget direkte efter seks måneders forsøg: det var "umuligt uden enten at betale for et eksternt data scraping-program" eller bruge Python plus JS-rendering plus betydelig regnekraft. En anden i en opsummerede det sådan: "Facebook er en af de sværere at scrape, fordi de aggressivt blokerer automation" og browser-automation er "skrøbelig, fordi Facebook hele tiden ændrer deres DOM."

Brugsscenarierne er reelle. Efterspørgslen er reel. Frustrationen er meget reel. Resten af artiklen handler om at navigere i det gab.

Hvad er et Facebook Scraper GitHub-repo egentlig?

En "Facebook scraper" på GitHub er et open source-script — normalt i Python — som programmatisk udtrækker offentlige data fra Facebook-sider, opslag, grupper, Marketplace eller profiler. Ikke alle virker på samme måde. Tre arkitekturer dominerer:

Browser-automatiserede scrapers vs. API wrappers vs. direkte HTTP-scrapers

er det klassiske eksempel på direkte HTTP: den scraper offentlige sider "uden en API-nøgle" via direkte requests og parsing. er et eksempel på browser-automation. repræsenterer Graph API-æraen, hvor scripts kunne hente opslag fra sider og grupper via officielle endpoints, som ikke længere er bredt tilgængelige.

Typiske mål-data på tværs af disse repos omfatter opslagstekst, tidsstempler, antal reaktioner/kommentarer, billed-URL’er, sidemetadata (kategori, telefon, e-mail, antal følgere), feltdata fra Marketplace samt metadata for grupper eller events.

I 2026 handler det reelle kompromis ikke om sprogpræference. Det handler om, hvilken slags fejl du kan leve med.

Freshness-audit 2026: Hvilke Facebook Scraper GitHub-repos virker faktisk?

Jeg har gennemgået de repos til Facebook-scraping på GitHub, der har flest stjerner og er mest anbefalede, op mod reelle data fra 2026 — ikke README-påstande, men faktiske commit-datoer, issue-køer og rapporter fra fællesskabet. Det er det vigtigste afsnit.

Den fulde freshness-audit-tabel

Et par ting springer i øjnene:

• Selv den "aktive fork" (moda20) er ikke blevet opdateret siden juni 2024.
• Issue-køerne fortæller historien hurtigere end README-filerne.
• Både kevinzg og moda20 angiver stadig Python ^3.6 i deres -filer — et tegn på, at afhængighedsgrundlaget ikke er blevet moderniseret.

kevinzg/facebook-scraper

Den bedst kendte Python-Facebook-scraper på GitHub. Dens beskriver scraping af sider, grupper, login via legitimationsoplysninger eller cookies samt felter på post-niveau som comments, image, images, likes, post_id, post_text, text og time.

Det operative signal er dog svagt:

• Sidste push: 22. juni 2024
• Åbne issues: — blandt andet titler som "Example Scrape does not return any posts"
• Vedligeholderen har ikke svaret på nyere issues

Konklusion: Delvist i stykker. Har stadig værdi til små eksperimenter med offentlige sider og som reference for feltnavne, men er ikke pålidelig til produktion.

moda20/facebook-scraper (community fork)

Den mest synlige fork af kevinzg, med ekstra muligheder og Marketplace-fokuserede hjælpefunktioner som extract_listing (beskrevet i dens ).

gør brudhistorien meget tydelig:

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

Når den forenklede mbasic-front-end ændres eller forsvinder, bryder en hel klasse af scrapers sammen på én gang.

Konklusion: Den mest bemærkelsesværdige fork, men også forældet og skrøbelig i 2026. Værd at prøve først, hvis du absolut vil bruge en GitHub-baseret løsning, men forvent ikke stabilitet.

minimaxir/facebook-page-post-scraper

Engang et meget praktisk Graph API-værktøj til at hente opslag, reaktioner, kommentarer og metadata fra offentlige sider og åbne grupper til CSV-filer. Dens forklarer stadig, hvordan man bruger et Facebook-apps App ID og App Secret.

I 2026 er det et historisk levn:

• Sidste push: 23. maj 2019
• Åbne issues: 53 — blandt andet "HTTP 400 Error Bad Request" og "No data retrieved!!"

Konklusion: Forladt. Tæt koblet til en API-tilladelsesmodel, som Meta siden har strammet kraftigt.

Andre bemærkelsesværdige repos

• passivebot/facebook-marketplace-scraper: Nyttig til Marketplace-scenarier, men dens indeholder "login to view the content", "CSS selectors outdated" og "Getting blocked". Et case-eksempel i én linje på, hvad der går i stykker ved Marketplace-scraping.
• apurvmishra99/facebook-scraper-selenium: Har et issue, der bogstaveligt talt spørger fra september 2020. Det siger næsten alt.
• Mhmd-Hisham/selenium_facebook_scraper og anabastos/faceteer: Ingen af dem har nok aktuel aktivitet til, at man bør have tillid til dem.

Facebooks anti-scraping-forsvar: Hvad alle GitHub scrapers kæmper imod

De fleste artikler om emnet giver vage "tjek ToS"-forbehold. Det er ikke nyttigt.

Facebook har et af de mest aggressive anti-scraping-systemer blandt alle større platforme. At forstå de konkrete forsvarslag er forskellen mellem en scraper, der virker, og en eftermiddag med tomt output.

Metas egen beskriver et "Anti Scraping team", der bruger statisk analyse på tværs af kodebasen til at identificere scraping-vektorer, sender cease-and-desist-breve, deaktiverer konti og er afhængig af rate-limiting-systemer. Det er ikke hypotetisk — det er en organisatorisk prioritet.

Tilfældige DOM- og CSS-klassenavne

Facebook randomiserer bevidst HTML-element-id’er, klassenavne og sidestruktur. Som en formulerede det: "Ingen normal scraper kan virke på Facebook. HTML’en muterer mellem refreshes."

Hvad bryder sammen: XPath- og CSS-selectors, der virkede i sidste uge, returnerer intet i dag.

Modforanstaltning: Brug tekstbaserede eller attributbaserede selectors, når det er muligt. AI-baseret parsing, som læser sideindholdet i stedet for at stole på hårde selectors, håndterer det bedre. Forvent selector-vedligeholdelse som en tilbagevendende omkostning.

Login-vægge og sessionsstyring

Mange Facebook-flader — profiler, grupper, visse Marketplace-lister — kræver login for at blive set. Headless browsere bliver omdirigeret eller får serveret nedstrippet HTML. passivebots Marketplace-scraper har i "login to view the content" som en af de største klager.

Hvad bryder sammen: Anonyme requests mangler indhold eller bliver helt omdirigeret.

Modforanstaltning: Brug session-cookies fra en rigtig browsersession, eller browserbaserede scraping-værktøjer, der arbejder inden for din login-session. Rotering af konti er muligt, men risikabelt.

Digital fingerprinting

Metas ingeniørpost siger, at uautoriserede scrapers — hvilket i praksis er en erkendelse af, at browserkvalitet og adfærdskvalitet er centrale for detektion. Diskussioner i og anbefaler fortsat anti-detect-browsere og konsistente fingerprints.

Hvad bryder sammen: Standard Selenium- eller Puppeteer-opsætninger kan let identificeres.

Modforanstaltning: Brug værktøjer som undetected-chromedriver eller anti-detect browser-profiler. Realistiske sessions og konsistente fingerprints betyder mere end simpel user-agent spoofing.

IP-baseret rate limiting og blokering

Metas ingeniørpost diskuterer eksplicit rate limiting som en del af forsvarsstrategien, inklusive loft over antal følgere for at tvinge flere requests, som så . I praksis rapporterer brugere, at de bliver rate-limited efter at have postet i .

Hvad bryder sammen: Masseanmodninger fra samme IP bliver droslet ned eller blokeret inden for få minutter. Datacenter-proxy-IP’er er ofte allerede blokeret.

Modforanstaltning: Rotation af residential proxies, ikke datacenter-proxies, med fornuftig request-hastighed.

GraphQL-skemaændringer

Nogle scrapers bruger Facebooks interne GraphQL-endpoints, fordi de returnerer mere strukturerede data end rå HTML. Men Meta giver ingen stabilitetsgaranti for interne GraphQL-kald, så disse forespørgsler bryder lydløst — de returnerer tomme data i stedet for fejl.

Hvad bryder sammen: Struktureret udtræk returnerer lydløst ingenting.

Modforanstaltning: Tilføj valideringstjek, overvåg skema-endpoints, og lås dig til kendte fungerende forespørgsler. Forvent vedligeholdelse.

Opsummering af anti-scraping-forsvar

Når GitHub-repos fejler: No-code-udvejen

En stor del af dem, der lander på "facebook scraper github", er ikke udviklere. Det er sælgere, der leder efter e-mails fra virksomhedsider, ecommerce-operatører, der følger Marketplace-priser, eller marketingfolk, der laver konkurrentresearch. De vil ikke håndtere et Python-miljø, debugge ødelagte selectors eller rotere proxies.

Hvis det lyder som dig, er beslutningstræet kort:

Scraping af kontaktoplysninger fra Facebook-sider (e-mails, telefonnumre)

Hvis opgaven er at hente e-mails og telefonnumre fra sektionerne "Om" på sider, er et GitHub-repo overkill. 's gratis og scanner en webside og eksporterer resultaterne til Sheets, Excel, Airtable eller Notion. AI’en læser siden fra bunden hver gang, så ændringer i Facebooks DOM ødelægger ikke løsningen.

Scraping af strukturerede data fra Marketplace eller virksomhedsider

Til udtræk af produktlister, priser, lokationer eller virksomhedsoplysninger giver Thunderbits AI Web Scraper dig mulighed for at klikke på "AI Suggest Fields" — AI’en læser siden og foreslår kolonner som pris, titel og placering — og derefter klikke på "Scrape." Ingen vedligeholdelse af XPath, ingen installation af kode. Eksportér direkte til .

Planlagt overvågning (prisalarmer på Marketplace, konkurrentsporing)

Til løbende overvågning — "giv mig besked, når en Marketplace-liste matcher mit prisinterval" — lader Thunderbits dig beskrive intervallet i almindeligt sprog (f.eks. ) og angive URL’er. Den kører automatisk, uden behov for cron-job.

Hvornår GitHub-repos stadig er det rigtige valg

Hvis du har brug for dyb programmatisk kontrol, storskala udtræk eller brugerdefinerede datapipelines, er GitHub-repos (eller til struktureret udtræk) det rigtige værktøj. Beslutningen er enkel: forretningsbrugere med simple udtræksbehov → no-code først; udviklere, der bygger datapipelines → GitHub-repos eller API.

Rigtige output-eksempler: Hvad du faktisk får

Alle konkurrentartikler viser kodeeksempler, men aldrig det faktiske output. Her er, hvad du realistisk kan forvente fra hver tilgang.

Eksempeloutput: kevinzg/facebook-scraper (eller aktiv fork)

Fra giver et scrape af et offentligt opslag 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": "Don't let this diminutive version...",
9  "text": "Don't let this diminutive version...",
10  "time": "2019-04-30T05:00:01"
11}

Læg mærke til de nullable felter som comments_full. I 2026 skal du forvente, at flere felter kommer tilbage tomme eller mangler — det er som regel et tegn på blokering, ikke en harmløs fejl. Outputtet er rå JSON og kræver efterbehandling.

Eksempeloutput: Facebook Graph API

Metas nuværende dokumenterer forespørgsler om sideoplysninger som GET /<PAGE_ID>?fields=id,name,about,fan_count. indeholder felter som followers_count, fan_count, category, emails, phone og andre offentlige metadata — men kun med de rette tilladelser som .

Det er en langt snævrere datamodel, end de fleste brugere af GitHub-scrapers forventer. Den er sideorienteret, tilladelsesstyret og ikke en erstatning for vilkårlig scraping af offentlige opslag eller grupper.

Eksempeloutput: Thunderbit AI Web Scraper

Thunderbits AI-forslåede kolonner for en Facebook-virksomhedsside giver en ren, struktureret tabel:

For opslag og kommentarer ser output sådan ud:

Strukturerede kolonner, formaterede telefonnumre, data klar til brug — intet efterbehandlingstrin. Kontrasten til rå JSON fra GitHub-værktøjer er svær at overse.

Facebook-data-type × bedste værktøj-matrix

Intet enkelt værktøj håndterer alt godt på Facebook i 2026.

Denne matrix lader dig gå direkte til dit brugsscenarie i stedet for at læse hele artiklen i håb om at finde det rigtige svar.

Hvilken tilgang passer til dit team?

• Salgsteams, der udtrækker leads: Start med Thunderbits Email/Phone Extractor eller AI Scraper. Ingen opsætning, resultater med det samme.
• Ecommerce-teams, der overvåger Marketplace: Thunderbits Scheduled Scraper eller en skræddersyet Scrapy + residential proxies-opsætning (hvis du har ingeniørressourcerne).
• Udviklere, der bygger datapipelines: GitHub-repos (aktive forks) + residential proxies + et vedligeholdelsesbudget. Forvent løbende arbejde.
• Forskere, der arkiverer gruppeindhold: Kun browserbaseret workflow (Thunderbit eller Selenium med login) med compliance-gennemgang.

Den ærlige vurdering — og den, som — er, at der ikke findes én pålidelig løsning. Match dit konkrete databehov med det rigtige værktøj.

Trin for trin: Sådan sætter du en Facebook scraper op fra GitHub (når det giver mening)

Hvis du har læst freshness-auditten og stadig vil gå GitHub-vejen, så fair nok. Her er den praktiske fremgangsmåde — med ærlige noter om, hvor tingene går i stykker.

Trin 1: Vælg det rigtige repo (brug freshness-auditten)

Gå tilbage til audit-tabellen. Vælg det mindst forældede repo, der matcher din målflade. Før du installerer noget som helst, så tjek Issues-fanen — nyere issue-titler fortæller dig mere om den aktuelle funktionalitet end README’en gør.

Trin 2: Sæt dit Python-miljø op

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

Et klassisk problem: versionskonflikter med afhængigheder, især Selenium-/Playwright-versioner. Både kevinzg og moda20 angiver Python ^3.6 i deres — et ældre udgangspunkt, som kan kollidere med nyere biblioteker. passivebots Marketplace-scraper låser , hvilket er fint til eksperimenter, men ikke et bevis på holdbarhed.

Trin 3: Konfigurér proxies og anti-detection

Hvis du laver noget mere end en hurtig test:

• Sæt rotation af residential proxies op (se efter udbydere med Facebook-specifikke IP-pools)
• Hvis du bruger browser-automation, så installér undetected-chromedriver eller konfigurér anti-fingerprinting
• Spring ikke dette trin over — standard Selenium eller Puppeteer bliver hurtigt opdaget

Trin 4: Kør et lille test-scrape og valider outputtet

Start med én offentlig side, ikke en stor batch. Tjek outputtet grundigt:

• Tomme felter eller manglende data betyder som regel, at Facebooks forsvar blokerer dig
• Sammenlign output med det, du faktisk ser på siden i din browser
• En vellykket test på én side er vigtigere end en flot README

Trin 5: Håndter fejl, rate limits og vedligeholdelse

• Byg retry-logik og fejlhåndtering ind
• Forvent jævnligt at skulle opdatere selectors eller konfigurationer — det her er løbende vedligeholdelse, ikke "sæt op og glem"
• Hvis du bruger mere tid på at vedligeholde scraperen end på at bruge dataene, er det et signal om at genoverveje no-code-vejen

Juridiske og etiske overvejelser ved Facebook-scraping

Dette afsnit er kort og faktuelt. Det er ikke artiklens hovedfokus, men det ville være uansvarligt at ignorere det.

Facebooks siger, at brugere "may not access or collect data from our Products using automated means (without our prior permission)." Metas , opdateret 3. februar 2026, gør det klart, at håndhævelse kan omfatte suspension, fjernelse af API-adgang og handling på kontoniveau.

Det her er ikke teoretisk. Metas beskriver aktiv efterforskning af uautoriseret scraping, cease-and-desist-breve og deaktivering af konti. Meta har også mod scraping-virksomheder (fx Voyager Labs-sagen).

Den sikreste ramme er:

• Metas vilkår er eksplicit anti-scraping
• Tilladt API-brug er sikrere end uautoriseret scraping
• Offentlig tilgængelighed fjerner ikke forpligtelser efter privatlivslovgivning (GDPR, CCPA osv.)
• Hvis du arbejder i stor skala, så rådfør dig med en jurist
• Thunderbit er designet til at scrape offentligt tilgængelige data og omgår ikke login-krav ved cloud scraping

Vigtigste pointer: Hvad der faktisk virker til Facebook-scraping i 2026

De fleste Facebook scraper GitHub-repos er i stykker eller upålidelige i 2026. Det er ikke skræmmesnak — det er, hvad commit-datoer, issue-køer og rapporter fra fællesskabet konsekvent viser.

De få aktive forks virker stadig til begrænsede offentlige side-data, men de kræver løbende vedligeholdelse, anti-detection-opsætning og en realistisk forventning om, at tingene går i stykker igen. Graph API er nyttig, men snæver — den dækker metadata på sideniveau med korrekte tilladelser, ikke den brede scraping af offentlige opslag eller grupper, som de fleste ønsker.

For forretningsbrugere, der har brug for Facebook-data uden udvikler-overhead, giver no-code-værktøjer som en mere pålidelig og mindre vedligeholdelsestung vej. AI’en læser siden fra bunden hver gang, så DOM-ændringer bryder ikke dit workflow. Du kan prøve gratis og eksportere til Sheets, Excel, Airtable eller Notion.

Den praktiske anbefaling: start med freshness-audit-tabellen. Hvis du ikke er udvikler, så prøv no-code-muligheden først. Hvis du er udvikler, så investér kun i en GitHub-opsætning, hvis du har de tekniske ressourcer — og tålmodigheden — til at vedligeholde den. Og uanset hvilken vej du vælger, så match dit specifikke databehov med det rigtige værktøj i stedet for at håbe på én løsning, der kan det hele.

Hvis du vil gå dybere ind i scraping af data fra sociale medier og relaterede værktøjer, har vi guides om , og . Du kan også se gennemgange på .

FAQ

Findes der en fungerende Facebook scraper på GitHub i 2026?

Ja, men mulighederne er begrænsede. Den mest bemærkelsesværdige er forken af kevinzgs originale repo — se freshness-audit-tabellen ovenfor for den aktuelle status. Den kan delvist scrape offentlige opslag på sider og nogle metadata, men issue-køen viser centrale brud omkring mbasic og tomt output. De fleste andre repos er forladte eller helt i stykker.

Kan jeg scrape Facebook uden at kode?

Ja. Værktøjer som og gratis Email/Phone Extractors lader dig udtrække Facebook-data direkte fra din browser med få klik, uden at du behøver Python eller GitHub-opsætning. AI’en læser siden hver gang, så du ikke behøver at vedligeholde selectors, når Facebook ændrer layout.

Er det lovligt at scrape Facebook?

Facebooks forbyder automatiseret dataindsamling uden tilladelse. Meta håndhæver aktivt dette gennem kontoblokeringer, cease-and-desist-breve og . Lovligheden varierer efter jurisdiktion og brugsscenarie. Hold dig til offentligt tilgængelige virksomhedsdata, undgå personprofiler, og søg juridisk rådgivning, hvis du arbejder i stor skala.

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

I 2026 er kraftigt begrænset. Du kan få adgang til begrænsede data på sideniveau — felter som id, name, about, fan_count, emails, phone — med de rette tilladelser som . De fleste data om offentlige opslag, gruppedata ( ) og brugerdata er ikke længere tilgængelige via API.

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

Ofte. Facebook ændrer løbende sin DOM-struktur, sine anti-bot-foranstaltninger og sine interne API’er — der er ingen offentlig rytme, men rapporter fra fællesskabet viser brud hver få uger for aktive scrapers. moda20-forkens issue-kø omkring forsvinden af mbasic er et nyere eksempel. Hvis du er afhængig af et GitHub-repo, så budgettér med løbende vedligeholdelse og validering af output.

Læs mere