Facebook Scraper ב-GitHub: מה עדיין עובד ומה כבר לא

חיפוש ב-GitHub אחר "facebook scraper" מחזיר 475 מאגרים. רק 62 מהם עודכנו בששת החודשים האחרונים.

הפער הזה בין "קיים" לבין "באמת עובד" הוא כל הסיפור של scraping ל-Facebook ב-GitHub בשנת 2026.

השקעתי לא מעט זמן בבדיקת לשוניות issues במאגרים, תלונות ב-Reddit ותוצרים אמיתיים מהכלים האלה. התמונה חוזרת על עצמה: רוב הפרויקטים עם הכי הרבה כוכבים שבורים בשקט, המתחזקים כבר לא שם, ו-Facebook רק מחזקת עוד ועוד את ההגנות שלה נגד scraping. מפתחים ומשתמשים עסקיים ממשיכים להגיע לאותן תוצאות חיפוש, להתקין את אותם מאגרים, ולהיתקל באותו פלט ריק. המאמר הזה הוא בדיקת מציאות ל-2026 — סקירה כנה של אילו מאגרים עדיין שווים את הזמן שלכם, איך Facebook שוברת אותם, ומתי עדיף לדלג על GitHub לגמרי.

למה אנשים מחפשים Facebook Scraper ב-GitHub

המקרים לשימוש מאחורי החיפוש הזה הם אותם מקרים שמלווים אותנו כבר שנים — גם אם הכלים עצמם מתפרקים שוב ושוב:

• יצירת לידים: חילוץ פרטי קשר מעמודי עסקים (אימיילים, מספרי טלפון, כתובות) לצורכי פנייה
• ניטור Marketplace: מעקב אחרי מוצרים, מחירים ופרטי מוכרים לצורכי ecommerce או arbitrage
• מחקר קבוצות: ארכוב פוסטים ותגובות למחקר שוק, OSINT או ניהול קהילה
• ארכוב תוכן ופוסטים: שמירה של פוסטים ציבוריים, תגובות, תמונות וחותמות זמן
• איסוף אירועים: משיכת כותרות אירועים, תאריכים, מיקומים ומארגנים

היתרון של GitHub ברור: קוד גלוי, ללא עלות, תחזוקה קהילתית — לפחות בתיאוריה — ושליטה מלאה בשדות ובצינורות העיבוד.

הבעיה היא שכוכבים ו-forks לא באמת אומרים "עובד עכשיו". מבין 10 המאגרים הבולטים לפי כוכבים לחיפוש המדויק הזה, כל 10 היו מיושנים ביותר מ-12 חודשים נכון לאפריל 2026. זה לא מקרה חריג — זה פשוט המצב.

משתמש ב-Reddit כתב בשרשור מנובמבר 2025 בפשטות, אחרי חצי שנה של ניסיונות: זה היה "בלתי אפשרי בלי לשלם על אפליקציית scraping חיצונית" או להשתמש ב-Python יחד עם rendering של JS ועם כוח חישוב משמעותי. משתמש אחר, בדיון מאפריל 2026, ניסח זאת כך: "Facebook היא אחת הקשות ביותר ל-scraping כי היא חוסמת אוטומציה באגרסיביות", ו-automation בדפדפן היא "שברירית כי Facebook משנה את ה-DOM כל הזמן."

המקרים לשימוש אמיתיים. הביקוש אמיתי. והתסכול — עוד יותר אמיתי. שאר המאמר הזה נועד לעזור לנו לנווט בתוך הפער הזה.

מה זה בעצם Facebook Scraper ב-GitHub?

"Facebook scraper" ב-GitHub הוא סקריפט בקוד פתוח — בדרך כלל ב-Python — שמחלץ בצורה תכנותית מידע ציבורי מ-Facebook: עמודים, פוסטים, קבוצות, Marketplace או פרופילים. לא כולם עובדים באותה שיטה. שלוש ארכיטקטורות שולטות בתחום:

Scrapers מבוססי Browser Automation מול Wrappers ל-API מול Scrapers ישירים ב-HTTP

Approach	Typical stack	Strength	Weakness
Browser automation	Selenium, Playwright, Puppeteer	Can handle login walls, mimics real user behavior	Slow, resource-heavy, easy to fingerprint if not configured carefully
Official API wrapper	Meta Graph API / Pages API	Stable, documented, compliant when approved	Severely restricted — most public post/group data is no longer available
Direct HTTP scraper	requests, HTML parsing, undocumented endpoints	Fast and lightweight when it works	Breaks whenever Facebook changes page structure or anti-bot measures

kevinzg/facebook-scraper הוא הדוגמה הקלאסית ל-HTTP ישיר: הוא סורק עמודים ציבוריים "ללא API key" באמצעות בקשות ישירות ו-parsing. apurvmishra99/facebook-scraper-selenium הוא דוגמה ל-browser automation. minimaxir/facebook-page-post-scraper מייצג את העידן הישן של Graph API, שבו סקריפטים יכלו לשלוף פוסטים מעמודים/קבוצות דרך endpoints רשמיים שכבר אינם זמינים בהיקף רחב.

המידע הטיפוסי שמושכים מהמאגרים האלה כולל טקסט של פוסטים, חותמות זמן, מספרי תגובות/תגובות רגשיות, כתובות URL של תמונות, מטא-דאטה של עמודים (קטגוריה, טלפון, אימייל, מספר עוקבים), שדות של רישומי Marketplace, ומטא-דאטה של קבוצות או אירועים.

ב-2026, הפשרה האמיתית היא לא העדפת שפה. היא באיזו סוג תקלה אתם מוכנים לחיות.

בדיקת טריות 2026 ל-Facebook Scraper ב-GitHub: אילו מאגרים באמת עובדים?

ביצעתי audit למאגרים הכי מפורסמים והכי מומלצים בתחום Facebook scraper ב-GitHub מול נתוני 2026 אמיתיים — לא מול הבטחות ב-README, אלא מול תאריכי commit, תורי issues ודיווחים קהילתיים. זה החלק החשוב ביותר.

טבלת בדיקת הטריות המלאה

Repo	Stars	Last Push	Open Issues	Language / Runtime	What It Still Scrapes	Status
kevinzg/facebook-scraper	3,157	2024-06-22	438	Python ^3.6	Limited public page posts, some comments/images, page metadata	⚠️ Partially broken / stale
moda20/facebook-scraper	110	2024-06-14	29	Python ^3.6	Same as kevinzg + Marketplace helper methods	⚠️ Partially broken / stale fork
minimaxir/facebook-page-post-scraper	2,128	2019-05-23	53	Python 2/3 era, Graph API dependent	Historical reference only	❌ Abandoned
apurvmishra99/facebook-scraper-selenium	232	2020-06-28	7	Python + Selenium	Browser automation for page scraping	❌ Abandoned
passivebot/facebook-marketplace-scraper	375	2024-04-29	3	Python 3.x + Playwright 1.40	Marketplace listings via browser automation	⚠️ Fragile / niche
Mhmd-Hisham/selenium_facebook_scraper	37	2022-11-29	1	Python + Selenium	General Selenium scraping	❌ Abandoned
anabastos/faceteer	20	2023-07-11	5	JavaScript	Automation-oriented	❌ Risky / low proof

כמה דברים בולטים מיד:

• אפילו ה-fork ה"פעיל" ביותר (moda20) לא עודכן מאז יוני 2024.
• תורי issues מספרים את הסיפור האמיתי מהר יותר מ-README.
• גם kevinzg וגם moda20 עדיין מצהירים על Python ^3.6 בקבצי pyproject.toml שלהם — סימן לכך שבסיס התלויות לא עבר מודרניזציה.

kevinzg/facebook-scraper

זהו ה-Facebook scraper הידוע ביותר ב-GitHub ב-Python. ה-README שלו מתאר scraping לעמודים, scraping לקבוצות, התחברות דרך credentials או cookies, ושדות ברמת פוסט כמו comments, image, images, likes, post_id, post_text, text, ו-time.

אבל האות התפעולי חלש:

• עדכון אחרון: 22 ביוני 2024
• issues פתוחים: 438 — כולל כותרות כמו "Example Scrape does not return any posts"
• המתחזק לא הגיב לבעיות האחרונות

מסקנה: שבור חלקית. עדיין יש לו ערך לניסויים בהיקף קטן על פוסטים ציבוריים ולשמש כמקור לשמות שדות, אבל הוא לא אמין לשימוש בפרודקשן.

moda20/facebook-scraper (Fork קהילתי)

זהו ה-fork הבולט ביותר של kevinzg, עם אפשרויות נוספות ועזרים שמכוונים ל-Marketplace כמו extract_listing (מתועד ב-README שלו).

תור ה-issues מציג במפורש את סיפור השבירה:

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

כאשר ה-frontend הפשוט mbasic משתנה או נעלם, כל מחלקה של scrapers מתדרדרת בבת אחת.

מסקנה: ה-fork הכי ראוי לציון, אבל גם מיושן ושברירי ב-2026. כדאי לנסות אותו קודם אם אתם מתעקשים על פתרון מבוסס GitHub, אבל לא לצפות ליציבות.

minimaxir/facebook-page-post-scraper

פעם זה היה כלי מאוד שימושי ל-Graph API, שאיפשר לאסוף פוסטים, תגובות, תגובות רגשיות ומטא-דאטה מעמודים ציבוריים וקבוצות פתוחות ל-CSV. ה-README שלו עדיין מסביר איך להשתמש ב-App ID וב-App Secret של אפליקציית Facebook.

ב-2026 זהו בעיקר ממצא היסטורי:

• עדכון אחרון: 23 במאי 2019
• issues פתוחים: 53 — כולל "HTTP 400 Error Bad Request" ו-"No data retrieved!!"

מסקנה: נטוש. קשור חזק מדי למודל הרשאות API ש-Meta צמצמה מאז משמעותית.

מאגרים בולטים נוספים

• passivebot/facebook-marketplace-scraper: שימושי לתרחישי Marketplace, אבל בתור ה-issues יש "login to view the content", "CSS selectors outdated" ו-"Getting blocked". מקרה בוחן במשפט אחד של מה נשבר ב-scraping ל-Marketplace.
• apurvmishra99/facebook-scraper-selenium: יש בו issue אחד שממש שואל "Does it work with new Facebook layout?" מספטמבר 2020. זה אומר כמעט הכול.
• Mhmd-Hisham/selenium_facebook_scraper ו-anabastos/faceteer: אין להם פעילות עדכנית מספקת כדי להצדיק אמון.

מנגנוני ההגנה של Facebook נגד scraping: מול מה כל scraper מ-GitHub מתמודד

רוב המאמרים בנושא הזה מסתפקים באזהרות כלליות של "תבדקו את ה-ToS". זה לא באמת מועיל.

ל-Facebook יש אחת ממערכות ההגנה נגד scraping האגרסיביות ביותר מבין הפלטפורמות הגדולות. הבנת שכבות ההגנה הספציפיות היא ההבדל בין scraper שעובד לבין אחר צהריים של פלט ריק.

פוסט ההנדסה של Meta מפברואר 2025 מתאר צוות "Anti Scraping" שמשתמש בניתוח סטטי לאורך בסיס הקוד כדי לזהות וקטורי scraping, שולח מכתבי cease-and-desist, משבית חשבונות, ונשען על מנגנוני rate limiting. זו לא השערה — זו מדיניות ארגונית.

DOM ושמות מחלקות CSS שמשתנים אקראית

Facebook משבשת בכוונה את ה-IDs, את שמות המחלקות ואת מבנה הדף ב-HTML. כפי שאמר אחד המגיבים ב-r/webscraping: "No normal scraper can work on Facebook. The HTML mutates between refreshes."

מה נשבר: XPath ו-CSS selectors שעבדו בשבוע שעבר מחזירים היום כלום.

מה עושים: להשתמש במזהים מבוססי טקסט או מאפיינים, כשאפשר. parsing מבוסס AI שקורא את תוכן הדף במקום להסתמך על selectors קשיחים מתמודד עם זה טוב יותר. צריך לצפות לתחזוקת selectors כחלק קבוע מהעלות.

קירות התחברות וניהול סשן

הרבה משטחי Facebook — פרופילים, קבוצות וחלק מרישומי Marketplace — דורשים התחברות כדי לראות את התוכן. דפדפנים headless מופנים מחדש או מקבלים HTML מקוצץ. לשונית ה-issues של הסקרייפר ל-Marketplace של passivebot כוללת את "login to view the content" בין התלונות המובילות.

מה נשבר: בקשות אנונימיות לא מקבלות תוכן או שמופנות מחדש לגמרי.

מה עושים: להשתמש ב-session cookies מסשן אמיתי בדפדפן, או בכלי scraping שמבוססים על דפדפן ופועלים בתוך הסשן המחובר שלכם. אפשר גם להחליף חשבונות, אבל זה מסוכן.

טביעת אצבע דיגיטלית

פוסט ההנדסה של Meta אומר ש-scrapers לא מורשים "commonly hide themselves by mimicking the ways users would normally use a product" — כלומר, איכות הדפדפן ואיכות ההתנהגות הן ליבת הזיהוי. דיונים קהילתיים במרץ ובאפריל 2026 ממשיכים להמליץ על anti-detect browsers ועל fingerprints עקביים.

מה נשבר: הגדרות Selenium או Puppeteer סטנדרטיות מזוהות בקלות.

מה עושים: להשתמש בכלים כמו undetected-chromedriver או בפרופילי anti-detect browser. סשנים מציאותיים וטביעות אצבע עקביות חשובים יותר מ-user-agent spoofing פשוט.

rate limiting וחסימות מבוססות IP

פוסט ההנדסה של Meta דן מפורשות ב-rate limiting כחלק מאסטרטגיית ההגנה, כולל הגבלת ספירות של רשימות עוקבים כדי לאלץ עוד בקשות שמפעילות מנגנוני rate control. בפועל, משתמשים מדווחים על rate limit אחרי פרסום ל-10 קבוצות בהפרשים של 10 שניות.

מה נשבר: בקשות מרובות מאותו IP נבלמות או נחסמות בתוך דקות. IPs של datacenter proxies נחסמים לעיתים מראש.

מה עושים: שימוש ברוטציה של residential proxies, לא proxies של datacenter, ובקצב בקשות סביר.

שינויים בסכמת GraphQL

חלק מה-scrapers נשענים על endpoints פנימיים של GraphQL ב-Facebook כי הם מחזירים נתונים מובנים ונקיים יותר מ-HTML גולמי. אבל Meta לא מפרסמת הבטחת יציבות ל-GraphQL פנימי, ולכן queries כאלה נשברים בשקט — ומחזירים נתונים ריקים במקום שגיאות.

מה נשבר: חילוץ מובנה מחזיר שקט כלום.

מה עושים: להוסיף בדיקות ולידציה, לעקוב אחרי endpoints של הסכימה, ולעגן ל-queries ידועות שעובדות. צריך לצפות לתחזוקה שוטפת.

סיכום שכבות ההגנה נגד scraping

Defense Layer	How It Breaks Your Scraper	Practical Countermeasure
Layout churn / unstable selectors	XPath and CSS selectors return nothing or partial fields	Prefer resilient anchors, validate against visible page output, expect maintenance
Login walls	Logged-out requests miss content or redirect	Use valid session cookies or browser-session tools
Fingerprinting	Standard automation looks synthetic	Use real browsers, consistent session quality, anti-detect measures
Rate limiting	Empty output, blocks, throttling	Slow pacing, lower batch sizes, residential proxy rotation
Internal query changes	Structured extraction silently returns empty data	Add validation checks, expect query maintenance

כשמאגרי GitHub נכשלים: בוחרים חלופה מותרת

מאגר שבור הוא לא סיבה לחפש דרך לעקוף את בקרות הפלטפורמה. קודם כל צריך לחדד את שאלת העסק: האם אתם צריכים analytics ברמת עמוד, שקיפות פרסומית, מדריך קשרים ציבורי או קטלוג מוצרים? להרבה מהצרכים האלה יש מענה דרך מוצר רשמי של Meta, API מורשה, או מקור ציבורי שאינו של Meta.

לדוגמה, השתמשו ב-Graph API רק כשהאפליקציה והמקרה שלכם זכאים להרשאות הנדרשות; השתמשו בתוכניות המחקר של Meta רק אם אתם עומדים בתנאי הזכאות; והשתמשו ב-Meta Ad Library בשביל מידע פרסומי שהוא אכן חושף. לצורכי חיפוש לידים, תמחור וגילוי עסקים מקומיים, עדיף לעיתים להסתמך על אתרים ציבוריים עצמאיים שהתנאים והחובות שלהם ברורים לכם ישירות.

דוגמאות לפלט אמיתי: מה באמת מקבלים

כל מאמר מתחרה מציג snippets של קוד אבל כמעט אף פעם לא את הפלט בפועל. הנה מה שאפשר לצפות לו באופן ריאלי מכל גישה.

דוגמת פלט: kevinzg/facebook-scraper (או fork פעיל)

מתוך דוגמת ה-README, פוסט ציבורי שנלכד מחזיר JSON כזה:

{
  "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"
}

שימו לב לשדות שיכולים להיות ריקים כמו comments_full. ב-2026, צפוי שחלק גדול יותר מהשדות יחזרו ריקים או חסרים — זה בדרך כלל סימן לחסימה, לא תקלה תמימה. הפלט הוא JSON גולמי ודורש עיבוד נוסף.

דוגמת פלט: Facebook Graph API

ה-Pages API הנוכחי של Meta מתעד בקשות למידע על עמודים כמו GET /<PAGE_ID>?fields=id,name,about,fan_count. ה-reference של Page כולל שדות כמו followers_count, fan_count, category, emails, phone ומטא-דאטה ציבורי נוסף — אבל רק עם ההרשאות הנכונות כמו Page Public Content Access או Page Public Metadata Access.

זהו מבנה נתונים מצומצם בהרבה ממה שרוב משתמשי ה-GitHub scrapers מצפים לו. הוא ממוקד בעמודים, תלוי בהרשאות, ולא מהווה תחליף ל-scraping כללי של פוסטים ציבוריים או קבוצות.

מטריצת סוגי נתוני Facebook מול מסלול הגישה

סוג נתוני Facebook	נקודת פתיחה מומלצת	מגבלה מרכזית
נכסים שהארגון שלכם מנהל	כלי הניהול הרשמיים של Meta ו-APIs מאושרים	ההרשאות והשדות הזמינים משתנים
תצפיות פרסום	Meta Ad Library	יש להשתמש רק בשדות ובפילטרים שהיא חושפת
פרטי עסקים ציבוריים שנדרשים למחקר לידים	ספריה ציבורית שאינה של Meta או אתר מפרסם שמותר להשתמש בו	יש לאמת את תנאי השימוש וחובות הפרטיות של המקור
חומרים פרטיים, קבוצות סגורות, תכנים מאחורי התחברות או חומרים שמוגבלים לחשבון	לא לבצע איסוף אוטומטי	לחפש מסלול מורשה במקום

שלב אחר שלב: איך להקים Facebook Scraper מ-GitHub (כשזה באמת הגיוני)

אם קראתם את בדיקת הטריות ועדיין בא לכם ללכת על GitHub — סביר. הנה המסלול המעשי, עם הערות כנות על המקומות שבהם דברים נשברים.

שלב 1: לבחור את המאגר הנכון (להשתמש בבדיקת הטריות)

חזרו לטבלת הבדיקה. בחרו את המאגר הכי פחות מיושן שמתאים למשטח היעד שלכם. לפני שמתקינים משהו, בדקו את לשונית Issues — כותרות של issues עדכניות מספרות יותר על הפונקציונליות הנוכחית מאשר ה-README.

שלב 2: להקים סביבת Python

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

תקלת נפילה נפוצה: התנגשויות גרסאות בתלויות, במיוחד ב-Selenium/Playwright. גם kevinzg וגם moda20 מצהירים על Python ^3.6 ב-pyproject.toml שלהם — בסיס ישן שעלול להתנגש עם ספריות חדשות. הסקרייפר ל-Marketplace של passivebot נועל את playwright==1.40.0, וזה בסדר לניסויים אבל לא מהווה הוכחה לעמידות.

שלב 3: להגדיר proxies ואמצעי הסתרה

אם אתם עושים יותר מבדיקה מהירה:

• הגדירו רוטציה של residential proxies (חפשו ספקים עם מאגרי IP שמתאימים ל-Facebook)
• אם אתם משתמשים ב-browser automation, התקינו undetected-chromedriver או הגדירו anti-fingerprinting
• אל תדלגו על השלב הזה — Selenium או Puppeteer רגילים מסומנים מהר מאוד

שלב 4: להריץ בדיקה קטנה ולאמת את הפלט

התחילו עם עמוד ציבורי אחד, לא עם batch גדול. בדקו את הפלט בקפידה:

• שדות ריקים או נתונים חסרים בדרך כלל אומרים שמנגנוני ההגנה של Facebook חוסמים אתכם
• השוו את הפלט למה שאתם באמת רואים בדף בדפדפן
• בדיקת דף אחת שעובדת חשובה יותר מ-README יפה

שלב 5: לטפל בשגיאות, rate limits ותחזוקה

• בנו לוגיקת retry וטיפול בשגיאות
• צפו לעדכן selectors או קונפיגורציות באופן קבוע — זו תחזוקה מתמשכת, לא משהו שמגדירים ושוכחים
• אם אתם מוצאים את עצמכם משקיעים יותר זמן בתחזוקת ה-scraper מאשר בשימוש בנתונים, זה סימן לשקול מחדש את הנתיב ללא קוד

שיקולים משפטיים ואתיים ב-scraping ל-Facebook

תנאי הפלטפורמה, כללי פרטיות, התחייבויות חוזיות וחוקי הגנת מידע עשויים לחול כולם. העובדה שמשהו נראה ציבורי לא מעניקה אישור גורף לאיסוף אוטומטי. שמרו על מינימום נתונים, תעדו את המטרה ואת הבסיס החוקי, וקבלו ייעוץ משפטי לתוכניות מסחריות או בהיקף גדול.

אל תתייחסו ל-extension בדפדפן, לסשן מחובר או לתווית “public” כאל רשות לאיסוף אוטומטי ממוצרי Meta.

נקודות המפתח: מה באמת עובד ל-Facebook scraping ב-2026

פעילות המאגר, תורי ה-issues והחוקים הנוכחיים של הפלטפורמה חשובים יותר ממספר הכוכבים או מ-README ישן. כששאלת העסק נוגעת לנכס שאתם מנהלים, התחילו בכלים הרשמיים של Meta וב-APIs מאושרים. לצורכי מחקר שוק, מחקר לידים ושאלות מחירים, מקור מורשה שאינו של Meta הוא לעיתים הרבה יותר קל לתיעוד ולניהול.

שאלות נפוצות

האם יש Facebook scraper שעובד ב-GitHub ב-2026?

כן, אבל האפשרויות מוגבלות. הבולט ביותר הוא ה-fork moda20/facebook-scraper של המאגר המקורי של kevinzg — בדקו את טבלת בדיקת הטריות למעלה למצב הנוכחי. הוא יכול לבצע scraping חלקי לפוסטים ציבוריים ולחלק מהמטא-דאטה, אבל תור ה-issues שלו מציג שבירה מרכזית סביב mbasic ופלט ריק. רוב המאגרים האחרים נטושים או שבורים לגמרי.

אפשר לעשות scraping ל-Facebook בלי קוד?

אפשר להשתמש בכלי החיפוש והניהול של Facebook עצמו למחקר ידני. עבור עבודה חוזרת או תכנותית, בדקו את ה-API הרשמי וההרשאות שלו, או עצבו מחדש את התהליך סביב מקור ציבורי מותר שאינו של Meta. נוחות של no-code לא מבטלת חובות של פלטפורמה, פרטיות או חוזה.

האם חוקי לעשות scraping ל-Facebook?

ה-Terms of Service של Facebook אוסרים איסוף נתונים אוטומטי ללא אישור. Meta אוכפת את זה באופן פעיל באמצעות חסימות חשבון, מכתבי cease-and-desist ו-תביעות משפטיות. החוקיות משתנה לפי תחום שיפוט ומקרה שימוש. היצמדו לנתונים עסקיים ציבוריים, הימנעו מפרופילים אישיים, והתייעצו עם עורך דין אם אתם פועלים בהיקף גדול.

איזה נתונים עדיין אפשר לקבל מ-Facebook Graph API?

ב-2026, ה-Graph API מוגבל מאוד. אפשר לקבל רק נתונים מצומצמים ברמת עמוד — שדות כמו id, name, about, fan_count, emails, phone — עם הרשאות מתאימות כמו Page Public Metadata Access. רוב נתוני הפוסטים הציבוריים, נתוני הקבוצות (ה-Groups API הוצא משימוש), ונתונים ברמת משתמש כבר אינם זמינים דרך ה-API.

באיזו תדירות מאגרי Facebook scraper ב-GitHub נשברים?

לעיתים קרובות. Facebook משנה באופן שוטף את מבנה ה-DOM, את מנגנוני ה-anti-bot שלה ואת ה-APIs הפנימיים שלה — אין קצב רשמי, אבל דיווחי הקהילה מראים שבירה כל כמה שבועות עבור scrapers פעילים. תור ה-issues של ה-fork moda20 סביב היעלמות mbasic הוא דוגמה עדכנית. אם אתם נשענים על מאגר ב-GitHub, תכננו מראש תחזוקה שוטפת ואימות של הפלט.

לקריאה נוספת

• Playwright Vs Puppeteer
• Top Financial Data Delivery Solutions
• Web Scraping For Price Comparison
• Scraper Api Review
• How To Create Site Rips