rate-limit של פייסבוק ב־2026: ההנדסה האמיתית מאחורי הזיהוי

מי שמפעיל בוטים לפרסום בפייסבוק יותר מכמה שבועות יודע את האמת הלא־נוחה: מנגנון ההגבלה של פייסבוק (rate-limit) ב־2026 הוא לא קיר אחד אלא רשת של שלושה גבולות מצטברים — לכל חשבון, לכל שעה, ולכל קבוצה. הבעיה היא שאף אחד מהגבולות האלה לא מתועד פומבית; פייסבוק לא יפרסם API שאומר "אתה הגעת ל־121 פוסטים, חכה". במקום זה, היא משתמשת בדיאלוג חזותי עמום שמופיע במסך כשאתה חוצה את הסף.

במאמר הזה אני הולך לפרק את המנגנון הזה כפי שהוא נראה ב־2026, להראות איך הדיאלוג עצמו בנוי ב־DOM, ולמה זיהוי מבני (structural) יציב פי 50 מזיהוי טקסטואלי. אם אתה כותב בעצמך כלי אוטומציה לפייסבוק, או שאתה לקוח של BuzzPost וסקרן איך הצד הטכני עובד — זה המאמר.

כמה פוסטים באמת אפשר להעלות ביום?

הנה המספרים שאנחנו רואים אחרי שלוש שנים של מדידה רציפה על מאות חשבונות במגזר נדל"ן בישראל:

שני דברים חשובים על הטבלה: ראשית, המספרים הם תלויי־חשבון. חשבון בן 8 שנים עם פעילות אורגנית עשירה (חברים אמיתיים, לייקים, תגובות, שיתופים) יישא 150 פוסטים ביום ללא בעיה. חשבון חדש בן שבועיים — 40 הם כבר תקרה. שנית, פייסבוק לא מודדת רק את הקצב — היא מודדת את קצב + דמיון תוכן + דמיון תזמון ביחד.

זה לא רק טיפול בטקסט — אלא טיפול ב־vector רב־ממדי. למשל, אם פוסט #1 פורסם בשעה 03:14 ומכיל את המילים "דירה להשכרה קריית מוצקין", ופוסט #2 פורסם בשעה 03:14:08 ומכיל "דירה להשכרה קריית מוצקין 3 חדרים", פייסבוק תזהה שאלה תאומים סמנטיים. אפילו אם החלפת מילה אחת. הדרך היחידה לעקוף זה היא רנדומיזציה אמיתית של מבנה משפט, סדר פיסקאות, סינונים שגויים מכוונים — אבל גם זה לא מספיק אם הקצב לא משתנה.

למה שעות הלילה (00:00-07:00) הן זהב

הניתוח שלנו על דאטה של מעל מיליון פוסטים מראה ש־בין 00:00 ל־07:00 שעון ישראל, אחוז ההצלחה לפרסום הוא ~94%, לעומת ~71% בשעות 09:00-22:00. הסיבה: בשעות האלו עומס הבדיקה האוטומטית של פייסבוק נמוך יותר, מספר הדיווחים האנושיים על קבוצות נמוך יותר, והאלגוריתם של איתור ספאם מסתמך יותר על signals התנהגותיים גסים ופחות על אנליזה דקה של כל פוסט.

בנוסף, רוב הקבוצות בנדל"ן ישראלי "מתעוררות" סביב 06:00 — אנשים שמתחילים את היום בודקים את הפיד. פוסט שעלה ב־04:30 עדיין נמצא בראש הפיד ב־07:00 וזוכה לכל הוויזיביליות הטבעית, בעוד פוסט שעלה ב־08:00 נדחק במהירות.

מה בדיוק קורה בלילה במגדל השליטה של פייסבוק?

פייסבוק מפעילה כמה רבדים של זיהוי: (1) מודל ML real-time שמסתכל על vector של פעולות, (2) מודל batch שמתעדכן כל שעה ומחזיק היסטוריה ארוכה יותר, (3) דיווחי משתמשים שמטפלים בהם reviewers אנושיים בעיקר בשעות העבודה. בלילה האירופי/אמריקאי הצוותים האנושיים מצומצמים יותר, ומודלי ה־real-time פועלים על threshold מעט סלחני יותר כי כל דקה של בלימה מטעות עולה הרבה ביצוע מנועי המלצה. זה לא תיעוד רשמי — זו הסקה מהתנהגות שנמדדה.

שעה אחת ספציפית שכדאי להזכיר: 04:00-05:00. זה החלון שבו רוב מאגרי הדאטה של פייסבוק רצים tasks תחזוקה ו־data warehousing. כתוצאה, גם המודלים שמטפלים בזיהוי ספאם בזמן אמת רצים על caches מעט יותר ישנים, ולכן הם פחות זריזים לסמן חשבון חדש. אם אתה חייב לבחור שעה אחת מתוך הלילה — תבחר ב־04:30.

מבנה הדיאלוג של rate-limit ב־DOM

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

גישה 1 (גרועה): התאמת טקסט

הגישה האינטואיטיבית היא לחפש את הטקסט: if "you can't post right now" in page_text:. הבעיה? פייסבוק מחליפה את הניסוח כל 2-4 חודשים. בשנת 2024 ראינו 14 וריאציות שונות באנגלית, 8 בעברית. רק בעברית התנסחנו:

• "לא ניתן לפרסם כרגע, נסה שוב מאוחר יותר"
• "אינך יכול לפרסם בקבוצה הזאת כעת"
• "מסיבות אבטחה, נחסמת מפרסום זמני"
• "זוהתה פעילות חריגה בחשבונך"
• "חרגת ממגבלת הפרסומים היומית"
• "הפעולה לא זמינה כרגע"
• "לא אפשרי לפרסם תוכן זה במיקום זה"
• "מערכת ההגנה זיהתה דפוס יוצא דופן"

הזיהוי הטקסטואלי שובר בכל פעם שפייסבוק מעדכנת ניסוח. אם הבוט שלך הסתמך על "לא ניתן לפרסם כרגע" — ביום אחד הוא פשוט יתחיל לחשוב שכל פוסט הצליח, ויעלה 200 פוסטים שלמעשה נחסמו, וגורם ל־cascade שלילי בחשבון.

חמור יותר: התרגום של פייסבוק לעברית עובר רוטציה ב־A/B testing. שני משתמשים שונים, באותה רגע, באותה גרסת אפליקציה — יכולים לקבל ניסוחים שונים. בוט שמתבסס על התאמת טקסט יחזיק רק עבור החתך הספציפי שבדקת בו.

גישה 2 (טובה): זיהוי מבני

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

הקוד המבני נראה בערך כך (בלי לחשוף את כל ה־selectors שלנו, אבל הרעיון ברור):

def detect_post_outcome(driver, timeout=20):
    # Structural detector - agnostic to wording changes
    end = time.time() + timeout
    while time.time() < end:
        dialogs = driver.find_elements(By.CSS_SELECTOR, '[role="dialog"]')
        if not dialogs:
            return "success"
        for d in dialogs:
            buttons = d.find_elements(By.CSS_SELECTOR, '[role="button"]')
            if len(buttons) == 1:
                # Only a dismiss button -> group restriction
                return "group_restricted"
            send_btn = find_primary_button(buttons)
            if send_btn and send_btn.get_attribute("aria-disabled") == "true":
                if not has_spinner(d):
                    return "rate_limit"
        time.sleep(0.5)
    return "timeout"

שים לב: הקוד לא קורא אף מילה של טקסט. הוא בודק רק role="dialog", role="button", ו־aria-disabled. אלה אלמנטים סטרוקטורליים של מערכת הנגישות של פייסבוק (Accessibility) — והם פי 100 יציבים יותר מאשר טקסטים. פייסבוק לא תוותר על נגישות ARIA, כי זה דרישה חוקית באירופה ובארה"ב.

למה ARIA יציבה כל כך?

בארה"ב פייסבוק כפופה ל־Americans with Disabilities Act (ADA) ולתביעות class action על נגישות אתרים לעיוורים. ב־EU יש את ה־European Accessibility Act שנכנס לתוקף ביוני 2025. תוצאה: פייסבוק חייבת לתחזק role="dialog", aria-label, aria-disabled, aria-busy בכל אינטראקציה. שינוי ב־ARIA = הפרת החוק. שינוי בטקסט = שום דבר. לכן בוט שמסתמך על ARIA רץ שנים בלי תחזוקה, ובוט שמסתמך על טקסט שובר כל רבעון.

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

שלוש קטגוריות של חסימה — וטיפול שונה לכל אחת

1. Soft rate-limit (חסימה זמנית של החשבון)

הכי נפוץ. החשבון "מצטנן" ל־30 דקות עד 24 שעות. הטיפול הנכון: עצירה מיידית, לא לנסות בכלל. כל ניסיון נוסף בפרק הזמן הזה מוסיף "נקודות שחורות" לחשבון. הבוט צריך להיכנס למצב cooldown ולחזור אחרי 3-6 שעות לפחות. אצלנו ב־BuzzPost זה אוטומטי לחלוטין: מרגע שזוהה rate-limit מבני, המערכת מציגה התראה בפאנל ועוצרת את הענף הספציפי הזה עד שהמשתמש שואל לחזור.

טעות נפוצה: לחשוב ש"אם הניסיון הבא נכשל, אנסה רק עוד פעם". פייסבוק רואה את הקצב הזה ומסמנת את החשבון כ"bot suspected". 5-10 ניסיונות חוזרים תוך 10 דקות שווים ל־escalation מ־soft ל־hard ban.

2. Group restriction (קבוצה ספציפית שמסרבת)

החשבון בסדר, אבל קבוצה X לא מאפשרת לך לפרסם בה. סיבות: אדמין של הקבוצה דיווח עליך, אלגוריתם פנימי של הקבוצה (chatbot של אדמין) חוסם, או שהקבוצה מצריכה אישור אדמין לכל פוסט. הטיפול: ספירת כשלים. אחרי 5 כשלים רצופים על אותה קבוצה — להוסיף ל־blacklist ולעבור הלאה. לא לנסות שוב במחזורים הקרובים.

הסיבה ל־5 ולא ל־1: לפעמים פוסט נכשל בגלל גלישת קונקטיביות זמנית או slow loading של פייסבוק עצמה. שגיאה בודדת לא מוכיחה שום דבר. 5 כשלים רצופים, אבל, הם signal חזק.

3. Hard ban (חסימת חשבון)

החשבון נדרש לאמת זהות (תעודה מזהה) או חסום ל־30 יום / לצמיתות. כאן הבוט לא יכול לעשות כלום — צריך התערבות אנושית. חשוב: כשהבוט מזהה hard ban, הוא חייב להפסיק לחלוטין, לתעד מסך + DOM, ולשלוח התראה. ניסיון להתחבר שוב בלי שטיפלת באימות רק יגרום לחסימה קבועה. ראה למה חשבונות נחסמים לפירוט נוסף.

4. Checkpoint challenge (אימות זהות "רך")

קטגוריה רביעית שלא נכנסת לטבלת הסיכומים אבל חייבת להיות מטופלת: פייסבוק לפעמים מציגה challenge — קוד SMS, אימייל, או אישור תמונה. הבוט לא יכול לעבור את זה אוטומטית (גם לא צריך — זה חוצה את גבול ה־ToS). הוא חייב לזהות שיש iframe captcha או דרישת SMS, לעצור, ולפנות לבעלים.

איך זה משתלב במערכת אמיתית

במערכת המבצעית של BuzzPost, גלאי ה־rate-limit המבני מוזן ל־pipeline בן 5 שלבים:

1. זיהוי: הגלאי מחזיר "rate_limit" אחרי פוסט.
2. שמירת ראיות: צילום מסך + DOM נשמרים תחת _rl_evidence/YYYYMMDD_HHMMSS.png ו־.txt. ראיות אלה משמשות מאוחר יותר לערעור אם החשבון נחסם.
3. התראה ב־Telegram: בוט מנהל שולח הודעה לבעלים: "VDS #3 — חשבון X נתפס ב־rate-limit, נכנס ל־cooldown".
4. POST לפאנל: שרת הניהול מקבל POST עם {"server_id": 3, "type": "rate_limit", "timestamp": ...} ושומר ב־DB.
5. UI: בפאנל הניהול מופיעה פלטה אדומה על השרת הספציפי, מתנקה אוטומטית כשהפוסט הבא מצליח.

זה הצינור שמאפשר ל־150+ חשבונות לרוץ ללא יד אנושית, וברגע שמשהו לא בסדר — אתה יודע בתוך 30 שניות. אם אתה רוצה לקנות את התשתית הזו ולא לבנות אותה, ראה תוכניות.

חוקי אצבע מעשיים

אם אתה בונה משלך, הנה רשימת בדיקה קצרה:

• קצב: לעולם לא לעבור 6 פוסטים בשעה לחשבון. בין פוסטים — סנדויץ' של 8-22 שניות עם רנדומיזציה.
• פיזור: לפזר את הפעילות על פני 4-5 חלונות זמן ב־24 שעות, לא לרכז ב־burst אחד.
• וריאציה: כל פוסט עם טקסט שונה במבנה (לא רק במילים), כל פוסט עם תמונה שונה, כל פוסט עם hashtags אחרים.
• חימום: חשבון חדש — 3 שבועות של גלישה ולייקים לפני פוסט אוטומטי ראשון.
• גלאי מבני: אל תסתמך על טקסט. רק על מבנה ARIA.
• קודוקת ויומן: כל פוסט שמור עם זמן, קבוצה, תוצאה. בלי זה אתה עיוור.
• ניתוק רשת בין חשבונות: כל חשבון על VDS משלו עם IP נפרד.

סיכום

rate-limit ב־2026 הוא לא מספר אחד אלא רשת תלת־ממדית של גבולות. הצלחה ארוכת־טווח דורשת: (א) פעולה בשעות הנכונות (לילה ישראל), (ב) זיהוי מבני יציב שלא נשבר עם כל עדכון UI, (ג) שלוש קטגוריות תגובה שונות לשלוש קטגוריות חסימה, (ד) cooldown אגרסיבי ופאסיבי, (ה) מעקב ראיות לערעור אם חשבון בכל זאת נחסם. BuzzPost מטפל בכל זה אוטומטית — כל לקוח מקבל VDS ייעודי, פרופיל Chrome נפרד, וניטור rate-limit מבני שהוכח על מיליון פוסטים. אם אתה רוצה להתחיל לפרסם נדל"ן בקבוצות פייסבוק ולא לאבד את החשבון אחרי שבוע — קנה את התוכנית הראשונה ב־249₪ לחודש, שרת אחד, כל הניטור והפיקוח בתוך.

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