En GitHub-sökning på "facebook scraper" ger 475 repositories. Bara 62 av dem har fått commits under de senaste sex månaderna.
Klyftan mellan "finns tillgängligt" och "fungerar faktiskt" är hela berättelsen om Facebook-scraping på GitHub år 2026.
Jag har lagt mycket tid på att gå igenom issue-flikar i repos, klagomål på Reddit och faktiskt resultat från de här verktygen. Mönstret är tydligt: de flesta populära projekten är i praktiken trasiga, underhållare har gått vidare och Facebooks skydd mot scraping blir allt vassare. Utvecklare och affärsanvändare hamnar gång på gång i samma sökresultat, installerar samma repos och möts av samma tomma output. Den här artikeln är en verklighetscheck för 2026 — en ärlig genomgång av vilka repos som fortfarande är värda din tid, vad Facebook gör för att stoppa dem och när du bör hoppa över GitHub helt.
Varför folk söker efter en Facebook Scraper på GitHub
Anledningarna bakom sökningen är desamma som för flera år sedan — även om verktygen ständigt går sönder:
- Leadgenerering: Extrahera kontaktuppgifter från företagssidor, som e-post, telefonnummer och adresser
- Bevakning av Marketplace: Följa produktannonser, priser och säljarinformation för e-handel eller arbitrage
- Gruppanalys: Arkivera inlägg och kommentarer för marknadsundersökning, OSINT eller community management
- Arkivering av innehåll och inlägg: Spara offentliga inlägg, reaktioner, bilder och tidsstämplar
- Aggregering av event: Hämta evenemangstitlar, datum, platser och arrangörer
GitHubs attraktionskraft är lätt att förstå: synlig kod, ingen kostnad, community-underhåll i teorin och full kontroll över fält och datakanaler.
Problemet är att stjärnor och forks inte säger något om huruvida något fungerar just nu. Av de 10 mest stjärnade reposen som matchar exakt frasen var alla 10 mer än 12 månader gamla i april 2026. Det är ingen slump — det är normen.
En Reddit-användare i en tråd från november 2025 skrev efter sex månaders försök att det var "omöjligt utan att antingen betala för en extern data scraping-applikation" eller använda Python plus JS-rendering plus rejäl beräkningskraft. En annan i en diskussion från april 2026 sammanfattade det så här: "Facebook är ett av de svårare systemen att scrapa eftersom de aggressivt blockerar automation" och browser automation är "skört eftersom Facebook ändrar sin DOM hela tiden."
Behovet finns. Efterfrågan finns. Frustrationen är mycket verklig. Resten av artikeln handlar om hur man navigerar i den klyftan.
Vad är egentligen ett Facebook Scraper-repo på GitHub?
En "Facebook scraper" på GitHub är ett open source-script — oftast i Python — som programmässigt hämtar offentliga data från Facebook-sidor, inlägg, grupper, Marketplace eller profiler. Alla fungerar inte på samma sätt. Tre arkitekturer dominerar:
Browser automation-scrapers vs. API-wrappers vs. direkta HTTP-scrapers
| Angreppssätt | Typisk stack | Styrka | Svaghet |
|---|---|---|---|
| Browser automation | Selenium, Playwright, Puppeteer | Kan hantera inloggningsväggar och efterliknar verkligt användarbeteende | Långsamt, resurskrävande, lätt att identifiera om det inte konfigureras noggrant |
| Officiell API-wrapper | Meta Graph API / Pages API | Stabil, dokumenterad, följsam när den är godkänd | Kraftigt begränsad — det mesta av offentliga inläggs- och gruppdata är inte längre tillgängligt |
| Direkt HTTP-scraper | requests, HTML-parsning, odokumenterade endpoints | Snabb och lättviktig när den fungerar | Går sönder så fort Facebook ändrar sidstruktur eller anti-bot-skydd |
kevinzg/facebook-scraper är det klassiska exemplet på direkt HTTP: det hämtar offentliga sidor "utan API-nyckel" via direkta requests och parsning. apurvmishra99/facebook-scraper-selenium är ett exempel på browser automation. minimaxir/facebook-page-post-scraper representerar Graph API-eran, då scripts kunde hämta sid- och gruppinlägg via officiella endpoints som inte längre är brett tillgängliga.
Typiska datatyper i de här reposen är inläggstext, tidsstämplar, antal reaktioner/kommentarer, bild-URL:er, sidmetadata (kategori, telefon, e-post, följare), fält för Marketplace-annonser samt metadata för grupper och event.
År 2026 handlar den verkliga avvägningen inte om språkpreferens. Det handlar om vilken typ av fel du kan leva med.
2026 års färskhetsgranskning av Facebook Scraper-repos på GitHub: Vilka fungerar faktiskt?
Jag granskade de mest stjärnade och mest rekommenderade Facebook scraper-reposen på GitHub mot verkliga data från 2026 — inte README-anspråk, utan faktiska commit-datum, issue-köer och rapporter från communityn. Det här är den viktigaste delen.
Den fullständiga färskhetsgransknings-tabellen
| Repo | Stars | Senaste push | Öppna issues | Språk / runtime | Vad det fortfarande kan hämta | Status |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | Begränsade offentliga sidinlägg, vissa kommentarer/bilder, sidmetadata | ⚠️ Delvis trasig / gammal |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | Samma som kevinzg + hjälpfunktioner för Marketplace | ⚠️ Delvis trasig / gammal fork |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Python 2/3-era, beroende av Graph API | Endast historisk referens | ❌ Övergivet |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Browser automation för sid-scraping | ❌ Övergivet |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Marketplace-annonser via browser automation | ⚠️ Skört / nischat |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Allmän Selenium-scraping | ❌ Övergivet |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Automation-orienterat | ❌ Riskabelt / svagt bevisat |
Några saker sticker ut:
- Även den "aktiva forken" (moda20) har inte fått en push sedan juni 2024.
- Issue-köerna berättar sanningen snabbare än README-filerna.
- Både kevinzg och moda20 anger fortfarande Python ^3.6 i sina pyproject.toml-filer — ett tecken på att beroendebaslinjen inte har moderniserats.
kevinzg/facebook-scraper
Den mest kända Python Facebook scrapern på GitHub. Dess README beskriver scraping av sidor och grupper, inloggning med credentials eller cookies, samt fältnivådata som comments, image, images, likes, post_id, post_text, text och time.
Operativt är signalen däremot svag:
- Senaste push: 22 juni 2024
- Öppna issues: 438 — inklusive titlar som "Example Scrape does not return any posts"
- Underhållaren har inte svarat på de senaste frågorna
Bedömning: Delvis trasig. Har fortfarande värde som referens för fältnamn och för små experiment med offentliga sidor, men är inte tillförlitlig för produktion.
moda20/facebook-scraper (community fork)
Den mest synliga forken av kevinzg, med extra alternativ och hjälpfunktioner för Marketplace, som extract_listing (dokumenterat i dess README).
Issue-kön visar tydligt vad som gått sönder:
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
När den förenklade mbasic-frontenden ändras eller försvinner försämras en hel klass av scrapers på en gång.
Bedömning: Den mest relevanta forken, men också gammal och skör år 2026. Värt att testa först om du absolut vill använda en GitHub-baserad lösning, men räkna inte med stabilitet.
minimaxir/facebook-page-post-scraper
En gång i tiden ett mycket praktiskt Graph API-verktyg för att samla in inlägg, reaktioner, kommentarer och metadata från offentliga sidor och öppna grupper till CSV-filer. Dess README förklarar fortfarande hur man använder ett Facebook-apps App ID och App Secret.
År 2026 är det ett historiskt artefakt:
- Senaste push: 23 maj 2019
- Öppna issues: 53 — inklusive "HTTP 400 Error Bad Request" och "No data retrieved!!"
Bedömning: Övergivet. Tätt kopplat till en API-behörighetsmodell som Meta sedan dess har begränsat kraftigt.
Andra noterbara repos
- passivebot/facebook-marketplace-scraper: Användbar för Marketplace-scenarier, men dess issue-kö innehåller "login to view the content", "CSS selectors outdated" och "Getting blocked." En kort fallstudie i vad som brukar gå sönder vid Marketplace-scraping.
- apurvmishra99/facebook-scraper-selenium: Har ett issue som bokstavligen frågar "Does it work with new Facebook layout?" från september 2020. Det säger nästan allt.
- Mhmd-Hisham/selenium_facebook_scraper och anabastos/faceteer: Ingen av dem har tillräckligt med aktuell aktivitet för att inge förtroende.
Facebooks anti-scraping-försvar: vad varje GitHub-scraper måste möta
De flesta artiklar om det här ämnet nöjer sig med vaga "kolla ToS"-varningar. Det är inte särskilt hjälpsamt.
Facebook har ett av de mest aggressiva anti-scraping-systemen bland stora plattformar. Att förstå de specifika skyddslagren är skillnaden mellan en fungerande scraper och en eftermiddag med tom output.
Metas egen engineering-post från februari 2025 beskriver ett "Anti Scraping team" som använder statisk analys i hela kodbasen för att identifiera scraping-vägar, skickar cease-and-desist-brev, inaktiverar konton och förlitar sig på rate limiting-system. Det här är inte teori — det är ett organisatoriskt åtagande.
Slumpmässig DOM och CSS-klassnamn
Facebook slumpmässiggör medvetet HTML-elementens ID:n, klassnamn och sidstruktur. Som en kommenterare på r/webscraping uttryckte det: "No normal scraper can work on Facebook. The HTML mutates between refreshes."
Vad som går sönder: XPath- och CSS-selektorer som fungerade förra veckan returnerar inget idag.
Motåtgärd: Använd textbaserade eller attributbaserade selektorer när det går. AI-baserad parsning som läser sidinnehållet istället för att förlita sig på hårda selektorer fungerar bättre här. Räkna med selector-underhåll som en återkommande kostnad.
Inloggningsväggar och sessionshantering
Många Facebook-ytor — profiler, grupper, vissa Marketplace-annonser — kräver inloggning för att kunna visas. Headless browsers omdirigeras eller får nedskalad HTML. Marketplace-scrapern från passivebot har issue-fliken med "login to view the content" som ett av de vanligaste klagomålen.
Vad som går sönder: Anonyma requests missar innehåll eller omdirigeras helt.
Motåtgärd: Använd sessionscookies från en riktig webbläsarsession, eller browserbaserade scrapingverktyg som körs i din inloggade session. Att rotera konton är möjligt, men riskabelt.
Digital fingerprinting
Metas engineering-inlägg säger att otillåtna scrapers "commonly hide themselves by mimicking the ways users would normally use a product" — vilket i praktiken betyder att kvaliteten på webbläsaren och beteendet är centrala för upptäckt. Diskussioner i mars och april 2026 fortsätter att rekommendera anti-detect browsers och konsekventa fingerprints.
Vad som går sönder: Vanliga Selenium- eller Puppeteer-upplägg identifieras lätt.
Motåtgärd: Använd verktyg som undetected-chromedriver eller anti-detect browser-profiler. Realistiska sessioner och konsekventa fingerprints är viktigare än enkel user-agent spoofing.
IP-baserad rate limiting och blockering
Metas engineering-post diskuterar uttryckligen rate limiting som en del av försvarsstrategin, inklusive att begränsa antal följare för att tvinga fram fler requests som sedan utlöser rate controls. I praktiken rapporterar användare att de blir rate-limlade efter att ha postat till 10 grupper med 10 sekunders intervall.
Vad som går sönder: Bulk-anrop från samma IP stryps eller blockeras inom minuter. Datacenter-proxy-IP:er är ofta redan blockerade.
Motåtgärd: Rotation med residential proxies, inte datacenter-proxies, och rimlig takt på requests.
Förändringar i GraphQL-schema
Vissa scrapers förlitar sig på Facebooks interna GraphQL-endpoints eftersom de ger renare strukturerad data än rå HTML. Men Meta ger ingen stabilitetsgaranti för interna GraphQL-anrop, så dessa querys går sönder tyst — de returnerar tom data istället för felmeddelanden.
Vad som går sönder: Strukturerad extrahering returnerar helt enkelt inget.
Motåtgärd: Lägg in valideringskontroller, bevaka schema-endpoints och lås till querys som du vet fungerar. Räkna med underhåll.
Sammanfattning av anti-scraping-försvar
| Försvarslager | Hur det bryter din scraper | Praktisk motåtgärd |
|---|---|---|
| Layout-ändringar / instabila selektorer | XPath- och CSS-selektorer returnerar inget eller bara delar av fälten | Föredra robusta ankare, validera mot synligt sidinnehåll, räkna med underhåll |
| Inloggningsväggar | Utloggade requests missar innehåll eller omdirigeras | Använd giltiga sessionscookies eller verktyg som körs i browser-session |
| Fingerprinting | Standardautomation ser syntetisk ut | Använd riktiga webbläsare, konsekvent sessionskvalitet, anti-detect-metoder |
| Rate limiting | Tom output, blockeringar, throttling | Långsammare takt, mindre batcher, rotation med residential proxies |
| Ändringar i interna querys | Strukturerad extrahering returnerar tom data utan fel | Lägg in validering och räkna med query-underhåll |
När GitHub-repos inte räcker: välj ett tillåtet alternativ
Ett trasigt repo är inte en anledning att försöka kringgå en plattforms skydd. Först bör du klargöra affärsfrågan: behöver du sidnivåanalys, annonsinsyn, en offentlig kontaktkatalog eller en produktkatalog? Många av dessa behov kan lösas med en officiell Meta-produkt, ett behörighetsstyrt API eller en offentlig källa utanför Meta.
Använd till exempel Graph API endast när appen och användningsfallet har rätt behörigheter, använd Metas forskningsprogram endast om du är berättigad, och använd Meta Ad Library för den annonseringsinformation som faktiskt görs tillgänglig. För lead research, prissättning och lokal företagsupptäckt är det ofta bättre att använda oberoende offentliga webbplatser vars villkor och integritetskrav du kan bedöma direkt.
Verkliga output-exempel: vad du faktiskt får
Alla konkurrentartiklar visar kodsnuttar men aldrig själva resultatet. Nedan ser du vad du realistiskt kan förvänta dig av varje metod.
Exempeloutput: kevinzg/facebook-scraper (eller aktiv fork)
Från README-exemplet returnerar ett scrapat offentligt inlägg JSON som:
{
"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"
}
Notera nullable-fälten som comments_full. År 2026 bör du räkna med att fler fält kommer tillbaka tomma eller saknas — det är oftast ett tecken på blockering, inte ett harmlöst fel. Utdata är rå JSON och kräver efterbearbetning.
Exempeloutput: Facebook Graph API
Metas nuvarande Pages API dokumenterar sidinfo-anrop som GET /<PAGE_ID>?fields=id,name,about,fan_count. Page reference innehåller fält som followers_count, fan_count, category, emails, phone och annan offentlig metadata — men bara med rätt behörigheter, som Page Public Content Access eller Page Public Metadata Access.
Det är en mycket snävare datamodell än vad de flesta användare av GitHub-scrapers förväntar sig. Den är sidcentrerad, behörighetsstyrd och inte en ersättning för allmän scraping av offentliga inlägg eller grupper.
Matris för Facebook-datatyper × åtkomstvägar
| Facebook-datatyp | Bästa startpunkt | Viktig begränsning |
|---|---|---|
| Resurser som din organisation administrerar | Officiella Meta-verktyg för administration och godkända API:er | Behörigheter och tillgängliga fält varierar |
| Annonsobservationer | Meta Ad Library | Använd endast de fält och filter som faktiskt exponeras |
| Offentliga företagsuppgifter för lead research | En tillåten katalog eller publicistwebbplats utanför Meta | Kontrollera källans villkor och integritetskrav |
| Privat, stängd grupp, inloggningslåst eller kontospecifikt material | Automatisera inte insamlingen | Välj istället en auktoriserad väg |
Steg för steg: Så sätter du upp en Facebook scraper från GitHub när det faktiskt är rimligt
Om du har läst färskhetsgranskningen och ändå vill gå GitHub-vägen, fair enough. Här är den praktiska vägen — med ärliga noteringar om var det brukar falla isär.
Steg 1: Välj rätt repo (använd färskhetsgranskningen)
Gå tillbaka till tabellen ovan. Välj det minst föråldrade repot som matchar din mål-yta. Innan du installerar något, kontrollera Issues-fliken — de senaste issue-titlarna berättar mer om aktuell funktionalitet än README:n gör.
Steg 2: Sätt upp din Python-miljö
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Vanlig fallgrop: versionskonflikter i beroenden, särskilt med Selenium/Playwright-versioner. Både kevinzg och moda20 anger Python ^3.6 i sina pyproject.toml, vilket är en äldre baslinje som kan krocka med nyare bibliotek. passivebots Marketplace-scraper låser playwright==1.40.0, vilket duger för experiment men inte bevisar hållbarhet.
Steg 3: Konfigurera proxies och anti-detection
Om du gör något mer än ett snabbt test:
- Sätt upp rotation med residential proxies (leta efter leverantörer med Facebook-specifika IP-pooler)
- Om du använder browser automation, installera undetected-chromedriver eller konfigurera anti-fingerprinting
- Skippa inte det här steget — vanlig Selenium eller Puppeteer flaggas snabbt
Steg 4: Kör en liten test-scraping och validera resultatet
Börja med en enda offentlig sida, inte en stor batch. Kontrollera resultatet noggrant:
- Tomma fält eller saknad data betyder oftast att Facebooks försvar blockerar dig
- Jämför resultatet med det du faktiskt ser på sidan i din webbläsare
- Ett lyckat test på en sida är viktigare än en snygg README
Steg 5: Hantera fel, rate limits och underhåll
- Bygg in retry-logik och felhantering
- Räkna med att uppdatera selektorer eller konfigurationer regelbundet — det här är löpande underhåll, inte något man ställer in en gång
- Om du märker att du lägger mer tid på att underhålla scrapern än att använda datan, är det ett tecken på att du bör överväga en no-code-väg
Juridiska och etiska överväganden vid Facebook scraping
Plattformsvillkor, integritetsregler, avtalsförpliktelser och dataskyddslagar kan alla vara tillämpliga. Att något är offentligt synligt är inte en generell tillåtelse för automatiserad insamling. Minimera datamängden, dokumentera syftet och den rättsliga grunden, och ta juridisk rådgivning för kommersiella eller storskaliga program.
Behandla inte en webbläsartilläggslösning, en inloggad session eller en "offentlig" etikett som tillstånd att automatisera insamling från Meta-produkter.
Viktiga slutsatser: Vad som faktiskt fungerar för Facebook scraping år 2026
Aktivitet i repot, issue-köer och aktuella plattformsregler spelar större roll än ett stjärnbetyg eller en gammal README. När affärsfrågan gäller en resurs du själv administrerar, börja med officiella Meta-verktyg och godkända API:er. För marknadsresearch, lead research och prisfrågor är en tillåten källa utanför Meta ofta enklare att dokumentera och styra.
Vanliga frågor
Finns det en fungerande Facebook scraper på GitHub år 2026?
Ja, men alternativen är begränsade. Den mest relevanta är moda20/facebook-scraper, en fork av kevinzgs ursprungliga repo — se färskhetsgranskningstabellen ovan för aktuell status. Den kan delvis scrapa offentliga sidinlägg och viss metadata, men issue-kön visar grundläggande problem med mbasic och tom output. De flesta andra repos är övergivna eller helt trasiga.
Kan jag scrapa Facebook utan att koda?
Använd Facebooks egna sök- och adminverktyg för manuell research. För återkommande eller programmatisk användning bör du utvärdera det officiella API:t och dess behörigheter, eller bygga om arbetsflödet kring en tillåten källa utanför Meta. No-code-bekvämlighet tar inte bort plattforms-, integritets- eller avtalskrav.
Är det lagligt att scrapa Facebook?
Facebooks Terms of Service förbjuder automatiserad datainsamling utan tillstånd. Meta upprätthåller detta aktivt genom kontoblockeringar, cease-and-desist-brev och rättsprocesser. Lagligheten varierar beroende på jurisdiktion och användningsfall. Håll dig till offentligt tillgänglig företagsdata, undvik personprofiler och rådgör med jurist om du arbetar i stor skala.
Vilken data kan jag fortfarande få via Facebook Graph API?
År 2026 är Graph API starkt begränsat. Du kan få tillgång till begränsad sidnivådata — fält som id, name, about, fan_count, emails, phone — med rätt behörigheter, till exempel Page Public Metadata Access. Det mesta av data för offentliga inlägg, gruppdata (där Groups API är utfasat) och användarnivådata är inte längre tillgängligt via API.
Hur ofta går GitHub-repos för Facebook scraper sönder?
Ofta. Facebook ändrar sin DOM-struktur, sina anti-bot-skydd och interna API:er löpande — det finns ingen publicerad cykel, men communityrapporter visar att aktiva scrapers går sönder med några veckors mellanrum. moda20-forkens issue-kö kring att mbasic försvann är ett färskt exempel. Om du litar på ett GitHub-repo bör du budgetera för löpande underhåll och validering av output.
Läs mer
