למה ישראל היום הוא לא עוד אתר וורדפרס פשוט
נתחיל מהבסיס: ישראל היום הוא לא אתר קטן. אנחנו מדברים על ארכיון שיכול להגיע בקלות ל-1.5 מיליון כתבות ויותר, עם מאות כתבות חדשות שמתווספות מדי יום. הגישה הקלאסית של שליחת בקשת GET וניתוח ה-HTML פשוט לא תחתוך את זה. חלק ניכר מהתוכן, במיוחד בעמוד הבית ובעמודי קטגוריה, נטען דינמית באמצעות JavaScript לאחר טעינת הדף הראשונית. אם תסתכלו על ה-source, תראו placeholder ריק שמתמלא רק אחרי שה-JS רץ.
זו הסיבה שתפסיקו להשתמש ב-Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים וב-API. עבור ישראל היום, שימוש ב-headless browser הוא חובה, לא אופציה. אנחנו צריכים לרנדר את הדף במלואו, כולל הרצת סקריפטים של צד-שלישי שאחראים על פרסומות או ווידג'טים, כדי לקבל תמונה מלאה של ה-DOM. זה גם אומר שה-scraper שלנו צריך להיות חכם מספיק כדי לחכות לאלמנטים ספציפיים שיופיעו (waitForSelector) ולא להסתמך על אירוע load גנרי, שבאתרים מודרניים כבר לא אומר כלום. המורכבות הזו דורשת מאמץ פיתוח גדול יותר בהתחלה, אבל היא היחידה שמבטיחה דאטה איכותי ומלא.
איסוף קטלוג מלא: ארכיטקטורת ה-Crawl הנכונה
אז איך ניגשים לאיסוף קטלוג מלא מאתר בסדר גודל כזה? הנטייה הראשונה היא לחפש sitemap.xml. זה מקום טוב להתחיל בו, אבל זו טעות להסתמך עליו בלבד. מניסיוני, sitemaps באתרים גדולים הם כמעט תמיד לא מעודכנים או חלקיים. הגישה הנכונה היא היברידית: השתמשו ב-sitemap כדי 'לזרוע' את ה-crawler, אבל המנגנון המרכזי חייב להיות זחילה רקורסיבית מעמודי הקטגוריות והארכיונים.
זה אומר לבנות מערכת עם תור (Queue) מבוזר, כמו RabbitMQ או אפילו Redis. כל כתובת URL שמתגלה בעמוד קטגוריה נכנסת לתור, ו-workers שונים שולפים משימות מהתור ומעבדים אותן. חובה לנהל סט של כתובות שכבר ביקרנו בהן (seen URLs) כדי למנוע לולאות אינסופיות. בקנה מידה של מיליוני דפים, להחזיק את הסט הזה בזיכרון של תהליך בודד זה מתכון לאסון. השתמשו במבנה נתונים יעיל כמו Bloom Filter או פשוט בטבלה ייעודית בבסיס הנתונים שלכם. המטרה היא להגיע לכיסוי של 99.9% מהכתבות, וזה יקרה רק אם תשלבו בין גילוי אקטיבי לבין המקורות הסטטיים כמו ה-sitemap.
מודיעין מתחרים וניטור תוכן ממומן
אחד ה-use cases המעניינים באתרי חדשות הוא לא רק איסוף הכתבות עצמן, אלא ניתוח התמונה הרחבה יותר. למשל, ניטור תוכן ממומן (שנראה לעיתים קרובות כמו כתבה רגילה) או מעקב אחר מודעות ספציפיות. זהו אתגר שונה לחלוטין מ-scraping של תוכן מערכתי. המודעות האלו נטענות מאסיבית דרך JavaScript, לעיתים קרובות משרתים של צד שלישי, והן יכולות להשתנות בין טעינה לטעינה או לפי פרמטרים של המשתמש (מיקום, עוגיות וכו').
כאן, צריך לעבוד עם פרוטוקול כמו Chrome DevTools Protocol (CDP) ש-Playwright חושף. הוא מאפשר ליירט ולנתח את כל בקשות הרשת שהדפדפן מבצע. אפשר לבנות לוגיקה שמזהה בקשות לדומיינים של רשתות פרסום (כמו Google AdSense, Taboola) ולחלץ את המידע ישירות מה-payload של הבקשה. כך אפשר לענות על שאלות כמו: 'אילו מותגים מפרסמים הכי הרבה בקטגוריית כלכלה?' או 'האם מתחרה שלי מריץ קמפיין תוכן חדש?'. זהו מודיעין מתחרים בזמן אמת. פרויקט כזה דורש הבנה עמוקה יותר של רשת ושל האופן שבו דפדפנים עובדים, הרבה מעבר לניתוח HTML פשוט. אפשר גם לייצא את הנתונים האלה ל-ייצוא CSV/API יומי או שבועי כדי לאפשר ניתוח במערכות BI.
תרחיש הכשל: כש-Lazy Loading שובר לך את הלילה
בואו נדבר על תרחיש כשל קלאסי שראיתי קורה ספציפית באתרים כמו ישראל היום. אתה בונה scraper, מריץ אותו על 100 כתבות, הכל עובד. אתה מריץ על 10,000, ופתאום 30% מהרשומות חוזרות עם תוכן חלקי. הכותרת קיימת, אבל גוף הכתבה ריק. מה קרה? נכנסת למלכודת lazy loading.
בכתבות ארוכות מאוד או כאלו עם גלריות תמונות רבות, האתר לא טוען את כל התוכן מיד. הוא טוען רק את מה שנמצא ב-viewport, ואת השאר טוען רק כשהמשתמש גולל למטה. ה-scraper שלך, לעומת זאת, לא גולל. הוא טוען את הדף, לוקח 'צילום מסך' של ה-DOM ויוצא. כל מה שהיה 'מתחת לקפל' (below the fold) פשוט לא קיים ב-HTML בזמן החילוץ.
הפתרון דורש סימולציה של התנהגות אנושית. לפני שאתה מנסה לחלץ את התוכן, אתה חייב לכתוב סקריפט ב-Playwright שמגלגל את הדף למטה באופן הדרגתי. לא לקפוץ ישר לסוף. גלילה איטית, אולי עם השהיות קטנות של 200ms בין גלילה לגלילה, כדי לתת לסקריפטים של האתר זמן לטעון את התוכן החדש. רק אחרי שהגעת לתחתית הדף (או זיהית אלמנט פוטר), אתה יכול בבטחה לחלץ את כל גוף הכתבה. זו דוגמה קלאסית למה שדורש התמודדות עם הגנות אנטי-בוט מתוחכמות, גם אם הן לא מכוונות לחסום אותך אלא רק לשפר חווית משתמש.
מתי לא כדאי לעשות Scraping לישראל היום
למרות כל מה שאמרנו, יש מצבים שבהם בניית scraper ייעודי לישראל היום היא פשוט בזבוז זמן ומאמץ. אם כל מה שאתה צריך זה את 10 הכתבות האחרונות מהעמוד הראשי פעם ביום, אתה לא צריך ארכיטקטורה מבוזרת עם Playwright ו-RabbitMQ. במקרה כזה, ייתכן שפיד ה-RSS של האתר יספיק לך לחלוטין. הוא יספק לך את הכותרות, התקצירים והקישורים בצורה מובנית ופשוטה.
תרחיש נוסף הוא כשאין לך את המשאבים לתחזוקה. Scraper לאתר גדול הוא לא פרויקט של 'שגר ושכח'. מבנה ה-HTML ישתנה. סלקטורים יישברו. לוגיקת ה-lazy loading תתעדכן. אם אין לך צוות או לפחות מהנדס שיכול להקדיש כמה שעות בחודש לתחזוקה, דיב깅 ותיקונים, המערכת תקרוס תוך כמה חודשים. לפעמים, פתרון ידני או חצי-אוטומטי הוא עדיף על פתרון אוטומטי לא יציב. חשוב להעריך את המורכבות מול התועלת. אם הערך העסקי מהנתונים לא מצדיק את מאמץ התחזוקה המתמשך, אולי כדאי לחפש דרך אחרת להשיג אותם.
ניהול Proxy וטביעות אצבע: איך להישאר מתחת לרדאר
גם אם ה-scraper שלך מושלם טכנית, הוא חסר ערך אם הוא נחסם אחרי 1,000 בקשות. אתר בסדר גודל של ישראל היום משתמש ככל הנראה במערכות הגנה כמו Cloudflare או דומותיה. שליחת 50,000 בקשות ב-10 דקות מכתובת IP בודדת של שרת דאטה סנטר היא הדרך המהירה ביותר להיחסם. לכן, ניהול פרוקסי חכם הוא קריטי.
הבחירה היא בין residential ל-datacenter proxies. לרוב המשימות, מאגר גדול של datacenter proxies עם רוטציה אגרסיבית יספיק. אבל אם אתם נתקלים בחסימות תכופות, מעבר ל-residential proxies הוא הצעד הבא. הם יקרים יותר במשאבים, אבל הסיכוי שלהם להיחסם נמוך משמעותית. בנוסף ל-IP, צריך לנהל את טביעת האצבע של הדפדפן. זה כולל זיוף של user-agent, שליחת headers נכונים, ושימוש בטכניקות מתקדמות יותר כמו אלו שמוצעות ב-מדריך Playwright stealth. המטרה היא לא להיראות כמו בוט, אלא להיראות כמו אוסף של אלפי משתמשים שונים, כל אחד גולש באופן לגיטימי. קצב הבקשות הוא גם פקטור: שמרו על קצב סביר פר IP, אולי לא יותר מ-10-15 בקשות בדקה, כדי לא לעורר חשד.