למה Scraping GOV.IL הוא לא פרויקט ל-Junior
הטעות הראשונה היא לחשוב על gov.il כעל דומיין יחיד. במציאות, זהו פורטל-על שמפנה לעשרות, אם לא מאות, תתי-מערכות שונות. תמצאו שם הכל: מאתרי מידע מבוססי React/Vue עם API פנימי, דרך מערכות מכרזים שמבוססות על ASP.NET WebForms ישנים, ועד לדפי HTML סטטיים לחלוטין. כל תת-מערכת היא אתגר בפני עצמו, עם מבנה DOM שונה, לוגיקת ניווט ייחודית, ולפעמים גם הגנות שונות.
השלב הראשון והקריטי הוא מיפוי. לפני שכותבים שורת קוד אחת, צריך להבין את הארכיטקטורה. לדוגמה, כשניגשים למשימת איסוף קטלוג GOV.IL של כלל השירותים, מגלים מהר מאוד שאין נקודת כניסה אחת. חלק מהשירותים מתועדים במערכת מרכזית, בעוד שאחרים קיימים רק באתר של המשרד הספציפי. זה דורש זחלן שמסוגל לטפל במספר סוגי מבנים במקביל. הפרויקט הופך מעבודת scraping פשוטה לעבודת אינטגרציה בין מקורות מידע הטרוגניים. זה המקום שבו פרויקטים נכשלים: הם בונים פתרון שמותאם למערכת אחת, ומגלים שהוא לא רלוונטי ל-80% מהיעדים האחרים בתוך הדומיין.
הסטאק הטכני הנכון: למה Playwright מנצח כאן
תפסיקו לנסות עם requests ו-BeautifulSoup על החלקים המודרניים של GOV.IL. אתם פשוט תבזבזו זמן על ניסיונות להנדס לאחור קריאות API פנימיות שמוגנות בטוקנים דינמיים. ב-2025, הגישה הנכונה היא Headless Browser, וספציפית Playwright. הוא מהיר יותר, יציב יותר וה-API שלו נקי משמעותית מזה של Selenium.
הסיבה המרכזית היא שחלקים נרחבים מהאתר, במיוחד פורטלי שירותים חדשים, מבצעים רינדור בצד הלקוח (Client-Side Rendering). התוכן שאתה צריך פשוט לא קיים ב-HTML הראשוני. Playwright מריץ מנוע דפדפן אמיתי (Chromium, Firefox, WebKit) ומטפל בזה בשבילך. עם תוספים נכונים, אפשר להפוך אותו כמעט בלתי ניתן לזיהוי. ראינו הצלחה גבוהה עם שילוב של Playwright עם פתרונות proxy מתקדמים כדי לדמות משתמשים אמיתיים מאזורים גיאוגרפיים שונים. בשיא, מערכת שבנינו הצליחה להריץ 50 מופעי דפדפן במקביל על שרת בודד, מה שאיפשר לנו לסרוק מעל 10,000 דפים מורכבים בשעה עם אחוזי הצלחה של 99.5%. זה סדר גודל שאי אפשר להגיע אליו עם כלים ישנים יותר.
תרחיש הכשל הקלאסי: כש-GOV.IL משנה מבנה בלי להודיע
ה-Failure mode המסוכן ביותר ב-scraping של GOV.IL הוא לא חסימה או CAPTCHA. אלו בעיות רועשות שקל לזהות. הבעיה האמיתית היא כשל שקט. דמיין שאתה מריץ scraper למשימת מעקב מלאי/זמינות GOV.IL עבור תורים למשרד הפנים. הסקרייפר שלך רץ כל יום, מחלץ את שדה ה-זמינות ומדווח "אין תורים פנויים". הכל נראה תקין, אין שגיאות בלוגים.
אלא שאתמול בלילה, משרד הפנים עדכן את הפורטל. הסלקטור של ה-CSS שמצא את אלמנט הזמינות כבר לא תופס כלום. הסקרייפר שלך, במקום לקרוס, פשוט מחזיר ערך null או מערך ריק, שהלוגיקה שלך מפרשת כ"אין זמינות". במשך שבועות, אתה מדווח נתונים שגויים לחלוטין בזמן שתורים כן היו זמינים. זו הסיבה שאימות נתונים (schema validation) ובדיקות תקינות הן לא nice-to-have, אלא חובה קריטית. צריך להגדיר חוקים ברורים: האם ייתכן ששדה מסוים יהיה ריק? האם הגיוני ש-100% מהסניפים מדווחים על חוסר זמינות במשך שבוע? בלי המנגנונים האלה, אתה אוסף זבל ומאמין שיש לך זהב.
בניית API פרטי על בסיס נתונים ציבוריים
אחד ה-use cases החזקים ביותר הוא יצירת API / קובץ נתונים GOV.IL פרטי על בסיס מידע שזמין ציבורית אבל לא נגיש. לדוגמה, ניטור מכרזים ממשלתיים. המידע קיים, אבל הוא מפוזר, קשה לחיפוש, ולרוב אין לו API נוח. כאן נכנס ה-scraper לתמונה. המטרה היא לאסוף את כל המכרזים החדשים, לנרמל את הנתונים למבנה אחיד (JSON או טבלה ב-DB), ולהעשיר אותם. אפשר לחלץ שמות מוצרים/מודעות (במקרה זה, כותרות המכרזים), קטגוריות, תאריכי יעד, ולסווג אותם אוטומטית.
התוצר הסופי הוא נקודת קצה (endpoint) פרטית שמספקת את המידע הזה בצורה נקייה ומהירה, או לחילופין, ייצוא CSV יומי שמתעדכן אוטומטית. זהו פתרון שמשרת מטרות של מודיעין מתחרים GOV.IL עבור חברות שעובדות עם הממשלה. בניית צינור נתונים כזה דורשת תשומת לב לפרטים: טיפול בעמודים מרובים (pagination), שמירת מצב כדי לא לעבד את אותם מכרזים שוב, וארכוב של מכרזים ישנים. זהו פרויקט שמדגים איך scraping הופך מאיסוף נתונים גרידא ליצירת מוצר מידע בעל ערך.
מתי לוותר על דפדפן מלא: אמנות מציאת ה-API הנסתר
למרות כל מה שאמרתי על Playwright, שימוש בדפדפן מלא הוא לא תמיד התשובה. זה בזבוז משאבים עצום אם אפשר להימנע ממנו. בחלקים מסוימים של GOV.IL, במיוחד במערכות מודרניות יותר, ממשק המשתמש הוא רק מעטפת דקה מעל API פנימי. כאן העבודה הופכת מעבודת DOM לעבודת בילוש ברשת.
פתח את כלי המפתחים בדפדפן (F12), עבור לטאב ה-Network, ותתחיל לנווט באתר. סנן לפי XHR/Fetch ובדוק את הבקשות שהדפדפן שולח. לעיתים קרובות, תגלה קריאות ל-endpoints שמחזירים JSON נקי. מצאת את מכרה הזהב שלך. עכשיו, המשימה היא להבין איך לשחזר את הבקשה הזו. זה יכול להיות פשוט כמו העתקת ה-URL, או מורכב יותר ולדרוש הוספת headers ספציפיים, cookies, או טוקן אימות (JWT) שצריך לחלץ מבקשה קודמת. אם אתה מצליח, אתה יכול להחליף scraper מבוסס Playwright שצורך 1GB RAM ו-CPU משמעותי, בסקריפט Python פשוט עם ספריית httpx שרץ כמעט בחינם. זה לא תמיד אפשרי, אבל תמיד שווה את הבדיקה של 30 הדקות הראשונות. אם אתה נתקל בקצב בקשות גבוה במיוחד, כמו בזמן טיפול בשגיאות 429, גישה ישירה ל-API תהיה תמיד עדיפה על פני דפדפן. למידע נוסף, קרא את המדריך שלנו לטיפול בשגיאות 429.