איך עושים Web Scraping בלי להיחסם: מדריך מעשי ל-2026

כמעט כל שבוע מגיעה אלי גרסה כלשהי של אותה שאלה: איך עושים web scraping בלי להיחסם? אחרי שנים של בניית scrapers בפרודקשן ללקוחות בארה"ב ובאירופה, התשובה הכנה שלי היא שאין טריק קסם אחד. להישאר לא חסום זה סכום של הרבה החלטות קטנות: באיזה קצב שולחים בקשות, איך הטראפיק נראה על החוט, מה ה-fingerprint של הדפדפן, והאם שמים לב לרגע שבו אתר מתחיל בשקט להזין זבל. המדריך הזה עובר על מה שבאמת חשוב ב-2026.

למה אתרים חוסמים מלכתחילה

מערכות anti-bot מקבצות את האותות שלהן לשלוש קטגוריות, וצריך לנצח את כולן. הראשונה היא קצב (rate): יותר מדי בקשות מ-IP אחד בחלון זמן קצר מדי. השנייה היא fingerprint: מוניטין ה-IP, לחיצת היד של TLS, סדר ה-HTTP headers ותכונות הדפדפן - שמצטרפים יחד לציון. השלישית היא התנהגות (behavior): האם הגלישה נראית אנושית, או שמישהו פוגע בעשרה דפי מוצר בשנייה בלי תזוזת עכבר ובלי referrer?

רוב המתחילים מתקנים רק את הקצב. מוסיפים proxy, מאטים, ועדיין נחסמים - כי ה-fingerprint צועק "סקריפט פייתון" כבר בבקשה הראשונה. כדאי לטפל בשלושת המרכיבים כמערכת אחת.

כבוד ל-robots.txt, ל-ToS ולחוק

לפני כל טכניקה, כדאי להחליט אם בכלל מותר וראוי לעשות scraping. קוראים את robots.txt ואת תנאי השימוש. מידע ציבורי ולא אישי הוא בדרך כלל בסיכון נמוך; מידע מאחורי login או מידע אישי נושא משקל משפטי אמיתי תחת GDPR ורגולציות דומות. הכלל שאני עובד לפיו פשוט: גורדים מידע ציבורי בנימוס, לא מכבידים על תשתית שאינה שלנו, ולא אוספים מידע אישי שאין לו הצדקה. להיות אזרח טוב ב-web גם שומר על חוסר חסימה לאורך זמן.

סיבוב כתובות IP: residential מול datacenter proxies

ה-IP הוא האות הרועש ביותר. כתובת datacenter בודדת ששולחת אלפי בקשות - הכי קל בעולם לחסום אותה. proxies מתחלפים מפזרים את הטראפיק על פני כתובות רבות כך שאף אחת לא נראית פוגענית. סוג ה-proxy הוא tradeoff בין עלות לחמקנות.

מתחילים עם datacenter proxies ומסלימים ל-residential או mobile רק כשמודדים חסימות בפועל. לשלם על mobile proxies באתר שלעולם לא בודק מוניטין IP - זה פשוט לשרוף כסף.

הגבלת קצב ומקביליות

גם עם proxies מושלמים, קצב בקשות לא טבעי חושף אותך. אני מגביל מקביליות לכל דומיין, מוסיף השהיות אקראיות, ומשתמש ב-exponential backoff על שגיאות. המטרה היא להיראות כמו קומץ בני אדם סקרנים, לא כמו עדר.

import asyncio, random
import httpx

SEM = asyncio.Semaphore(5)  # מקסימום 5 בו-זמנית לכל דומיין

async def fetch(client, url):
    async with SEM:
        await asyncio.sleep(random.uniform(1.0, 3.0))
        for attempt in range(4):
            r = await client.get(url, timeout=20)
            if r.status_code == 429:
                await asyncio.sleep(2 ** attempt)
                continue
            return r
        return None

שימו לב לטיפול המפורש ב-429 Too Many Requests. כשאתר מבקש להאט - מאטים. התעלמות מ-429 היא הדרך המהירה ביותר לחסימה קבועה.

Headers ריאליסטיים ו-TLS/JA3 fingerprints

קריאת requests או httpx רגילה שולחת headers בסדר ובערכים שאף דפדפן אמיתי לא משתמש בהם, ולחיצת היד של ה-TLS שלה מייצרת JA3 fingerprint שלא תואם ל-Chrome או ל-Firefox. כלי anti-bot מודרניים קוראים את זה כבר בחבילה הראשונה, עוד לפני ששום header בשליטתנו נשלח.

התיקון כולל שני דברים. שולחים סט מלא ועקבי של headers (User-Agent, Accept, Accept-Language, Sec-CH-UA, Referer) שכולם מתארים את אותו דפדפן. ומשתמשים ב-client שמחקה TLS של דפדפן אמיתי, כמו curl_cffi עם impersonate="chrome". שכבות לא תואמות הן סימן מובהק: User-Agent של Chrome שרוכב על fingerprint TLS פייתוני לא מרמה אף מערכת.

זיהוי headless browser ו-Playwright stealth

כשאתר עמוס JavaScript או מוגן בצורה אגרסיבית, פונים לדפדפן אמיתי דרך Playwright. אבל headless Chrome רגיל מדליף: navigator.webdriver הוא true, ה-GPU מרונדר בתוכנה, התוספים ריקים, והתזמון נקי מדי. תיקוני stealth סוגרים את הפערים האלה.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True, args=[
        "--disable-blink-features=AutomationControlled",
    ])
    ctx = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/130.0 Safari/537.36",
        locale="en-US", timezone_id="America/New_York",
    )
    page = ctx.new_page()
    page.goto("https://example.com", wait_until="networkidle")

עדיף להשתמש בפלאגין stealth מתוחזק במקום לתקן הכל ביד, ולוודא שאזור הזמן, ה-locale והגיאולוקציה של ה-proxy תואמים זה לזה. IP residential בטקסס יחד עם דפדפן שמוגדר לשעון תל אביב - זו סתירה שמפילה את כל המאמץ.

Cloudflare, DataDome ו-hCaptcha

אלה משקלי הכבד, ואין מעקף כן בשורה אחת. ברמה גבוהה: Cloudflare ו-DataDome מנקדים כל בקשה לפי מוניטין IP, fingerprint של TLS והתנהגות, ומגישים אתגר מנוהל כשמשהו נראה חשוד. hCaptcha ו-Turnstile מוסיפים חידה אינטראקטיבית. האפשרויות הריאליות הן דפדפן stealth איכותי על residential או mobile proxies, שירות unblocking מסחרי או ספק פתרון CAPTCHA, או פשוט להאט מספיק כדי להישאר מתחת לסף החשד. האם שווה לבנות מעקף עצמאי זו בדיוק השאלה שאני מכסה בלבנות מול לקנות scraper, כי עבור יעדים מוגנים שירות מנוהל לרוב זול יותר מזמן הפיתוח.

ניהול sessions ו-cookies

אתרים רבים מגדירים cookie של clearance אחרי הטעינה המוצלחת הראשונה. לזרוק אותו ולפתור מחדש את האתגר בכל בקשה - זה מבזבז רוחב פס של proxy ונראה רובוטי. שומרים cookies לכל session, מקבעים כל session ל-IP אחד, ונותנים לו להזדקן באופן טבעי. session שמתחבר, גולש ושומר את ה-cookies שלו למשך שעה נראה הרבה יותר אנושי מאלף ביקורים ראשונים קרים.

מתי עדיף API

הדרך הנקייה ביותר לעשות web scraping בלי להיחסם היא לעיתים קרובות בכלל לא לעשות scraping. כדאי לבדוק אם קיים API רשמי, endpoint של אפליקציית מובייל, פיד RSS או dataset ציבורי לפני שכותבים selector אחד. API מהיר יותר, יציב יותר, ומורשה במפורש. חוזרים ל-scraping של דפדפן רק כשאין שום מקור מובנה.

ניטור חסימות שקטות

הכשל המסוכן הוא לא ה-403. הוא החסימה השקטה: האתר מחזיר 200 OK עם תוצאות ריקות, מחירים מיושנים או מידע מורעל בעדינות - כדי לבזבז זמן. בלי ניטור לא שמים לב לזה במשך ימים. אני בודק שדות וכמויות צפויים, מתריע כשקצב החילוץ צונח, מתעד status codes וגדלי תגובות, ומשווה מדי פעם מול baseline ידוע-תקין. לתפוס חסימה שקטה מוקדם - זה מה שמבדיל pipeline אמין מאחד שבור בשקט, ולכן אני מתייחס לאימות כחלק מרכזי מכל pipeline למידע שנגרד.

לסיכום

אין דגל קסם שמעלים חסימות. נשארים לא חסומים על ידי שכבוב של הרגלים הנכונים: מסובבים IP בהתאם, מגבילים קצב בנימוס, מתאימים headers ו-TLS, מקשיחים את הדפדפן, מנהלים sessions, מעדיפים APIs, ומנטרים ללא הרף כשלים שקטים. עושים את זה נכון - ורוב האתרים לעולם לא ישימו לב.

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