למה Mango Israel אינו עוד אתר WordPress פשוט
הטעות הראשונה היא לחשוב על Mango Israel כעל אתר סטטי. פתחו את ה-DevTools ותראו את האמת: זו אפליקציית עמוד יחיד (SPA) שכנראה רצה על React או Vue. התוכן, ובמיוחד פרטי המוצרים, לא מגיע ב-HTML הראשוני. הוא נטען דינמית דרך קריאות API פנימיות שמחזירות JSON. לנסות לגרד את ה-HTML ישירות ייתן לכם רק שלד ריק.
האתר מציג קטלוג של אלפי פריטים, שמתעדכן באופן תדיר. הערכה גסה מדברת על מעל 15,000 דפי מוצר ייחודיים, לא כולל וריאציות של צבע ומידה. המשמעות היא שכל פרויקט רציני של איסוף קטלוג Mango Israel ידרוש סריקה של עשרות אלפי נקודות קצה. הניווט בין קטגוריות מתבצע client-side, מה שמוסיף עוד שכבת מורכבות. ניתוח תעבורת הרשת (Network Tab) הוא חובה. שם תגלו את ה-endpoints האמיתיים שמספקים את המידע על מוצרים, מחירים וזמינות. לעיתים קרובות, גישה ישירה ל-API הפנימי הזה יכולה להיות יעילה פי 10 מאשר רינדור דפים מלא, אבל היא גם שבירה יותר ודורשת תחזוקה צמודה יותר כשה-API משתנה.
תשכחו מ-Requests; כאן צריך Headless Browser אמיתי
בגלל שהאתר הוא SPA, אין מנוס משימוש ב-Headless Browser. ותהיו רציניים, תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית: מהירות, יציבות, וה-API שלו פשוט נקי יותר. היכולת של Playwright ליירט ולשנות בקשות רשת היא קריטית כאן. למשל, אפשר לחסום טעינה של סקריפטים של מעקב, פונטים ותמונות לא רלוונטיות כדי להאיץ את תהליך איסוף הנתונים ב-30-40%.
האתר של Mango Israel משתמש במנגנוני הגנה מבוססי JavaScript כדי לזהות בוטים. הם בודקים מאפיינים של הדפדפן, תנועות עכבר מדומות, ופרמטרים נוספים שספרייה כמו requests לעולם לא תוכל לספק. שימוש ב-Playwright, במיוחד עם תוספים כמו ספריית ה-stealth, מאפשר לעקוף את רוב ההגנות הבסיסיות האלה. זה מאפשר לכם להתמקד באיסוף נתונים במקום בקרב אינסופי מול מנגנוני הזיהוי. אם אתם רוצים לבנות מערכת אמינה, המדריך לעקיפת Cloudflare יכול לתת לכם כמה רעיונות מתקדמים, גם אם האתר לא משתמש ספציפית ב-Cloudflare, העקרונות דומים.
איך לאסוף קטלוג שלם בלי להפעיל את כל האזעקות
אז יש לכם Playwright עובד. יופי. עכשיו נסו להריץ אותו על 5,000 מוצרים במקביל ותראו איך ה-IP שלכם נחסם תוך דקות. הבעיה היא לא הכלי, אלא האסטרטגיה. מעקב מלאי/זמינות Mango Israel דורש קצב בקשות גבוה, אבל שליחת 200 בקשות בשנייה מאותו IP היא הזמנה לחסימה. כאן נכנס לתמונה ניהול פרוקסי חכם. אני לא מדבר על רשימה חינמית שמצאתם ברשת. אתם צריכים מאגר גדול של Residential Proxies איכותיים, עם רוטציה חכמה ביניהם. לכל session של דפדפן, הקצו IP אחר. אם נתקלתם ב-CAPTCHA או שגיאת 429, אל תנסו שוב מאותו IP. זרקו את ה-session, קחו IP חדש, ונסו שוב. מערכת טובה תשיג 98% הצלחה בבקשות הראשונות, כשה-2% הנותרים יצליחו בניסיון שני או שלישי עם IP אחר. חשוב גם לנהל קצב בקשות סביר פר IP. אל תעברו את ה-15-20 בקשות לדקה מכתובת אחת. זה אולי נשמע איטי, אבל כשאתם מריצים 500 sessions במקביל, אתם מגיעים לקצב כולל מרשים. בניית מערכת כזו היא מורכבת, אבל היא ההבדל בין פרויקט שעובד שבוע ונופל לבין מערכת שמספקת נתונים יציבים לאורך חודשים. המדריך שלנו על איך לבחור פרוקסי residential מכסה את הנושא לעומק.
תרחיש הכשל: כשמבנה ה-JSON משתנה לך מתחת לרגליים
הנה תרחיש שקרה לי יותר מפעם אחת עם אתרי אופנה: ה-scraper רץ חלק במשך חודשיים, אוסף מבצעים ומלאי לפי מוצר בצורה מושלמת. פתאום, בוקר אחד, כל הנתונים ריקים. אין שגיאות, אין חסימות, פשוט null בכל השדות. מה קרה? צוות הפיתוח של Mango Israel שינה את מבנה ה-JSON שחוזר מה-API הפנימי שלהם. שדה שהיה פעם product.price.final הפך ל-product.pricing.current.value. שינוי קטן ושקט שלא שובר את האתר למשתמשים, אבל מוחק לכם את כל הדאטה.
זו החולשה הגדולה של גישה המבוססת על API פנימי. היא מהירה ויעילה, אבל שבירה מאוד. הפתרון הוא לא לוותר עליה, אלא לבנות מערכת ניטור והתראה. ה-scraper שלכם חייב לכלול בדיקות תקינות (sanity checks) אחרי כל ריצה. האם 90% משמות המוצרים ריקים? שלח התראה. האם המחירים נראים חריגים? תעצור ותתריע. אי אפשר לצפות שהמבנה יישאר קבוע לנצח. צריך לתכנן מראש למצב שהוא ישתנה, עם מערכת שיודעת לזהות את הכשל באופן מיידי ולא אחרי שבוע של איסוף נתונים פגומים. ניהול שגיאות הוא לא רק לטפל ב-HTTP 503, אלא גם בנתונים שנראים לא הגיוניים.
מאיסוף נתונים גולמי למוצר מודיעין תחרותי
איסוף הנתונים הוא רק חצי מהסיפור. כדי להפוך את המידע הגולמי לבעל ערך, למשל עבור מודיעין מתחרים Mango Israel, צריך תהליך עיבוד (post-processing) חזק. הנתונים שמגיעים מהאתר אינם נקיים. שמות מוצרים יכולים להכיל תווים מיותרים, מחירים יכולים להופיע בפורמטים שונים, וקטגוריות דורשות נרמול. לדוגמה, 'שמלות ערב' ו-'שמלות לאירועים' צריכות להיות ממופות לאותה קטגוריה במערכת שלכם.
בסופו של דבר, המטרה של רוב הפרויקטים האלה היא לספק API / קובץ נתונים Mango Israel למערכות אחרות. זה אומר שהפלט שלכם חייב להיות עקבי, מתועד היטב, ואמין. תהליך ה-ETL (Extract, Transform, Load) צריך לכלול שלבי ולידציה, ניקוי והעשרה. למשל, אפשר להוסיף שדה שמציין מתי מוצר נראה לראשונה, או לעקוב אחר היסטוריית שינויי המחיר שלו. בניית ה-pipeline הזה דורשת לא פחות מאמץ מאשר בניית ה-scraper עצמו, אבל זה מה שהופך אוסף של HTML גולמי למוצר נתונים שבאמת אפשר לקבל עליו החלטות עסקיות. קל לזלזל בשלב הזה, אבל פה נמצא הערך האמיתי.
הצד השני של המטבע: מתי לא כדאי לבנות Scraper בעצמכם
אחרי כל מה שאמרתי, חשוב להיות כנים. לא תמיד בניית scraper מורכב ל-Mango Israel מאפס היא ההחלטה הנכונה. אם הצורך שלכם הוא חד-פעמי, או שאתם צריכים נתונים רק מכמה עשרות מוצרים, המאמץ הנדרש להקמת תשתית של פרוקסי, דפדפנים, וטיפול בחסימות פשוט לא מצדיק את עצמו. המורכבות של פרויקט כזה גדלה באופן אקספוננציאלי עם קנה המידה. לאסוף 100 מוצרים זה קל. לאסוף 10,000 מוצרים כל שעה, 24/7, זו בעיה הנדסית אחרת לגמרי.
התחזוקה היא גורם נוסף. אתרי מסחר אלקטרוני משנים את המבנה שלהם כל הזמן. מה שעובד היום עלול להישבר מחר בעקבות עדכון קטן. אם אין לכם צוות שיכול להקדיש זמן לתחזוקה שוטפת, לדיבוג כשהדברים נשברים, ולעדכון הסלקטורים והלוגיקה, הפרויקט יהפוך מהר מאוד לנטל. לפעמים, הפתרון היעיל ביותר הוא לא לכתוב קוד, אלא להשתמש בפתרון קיים או בשירות שמספק את הנתונים. צריך להעריך בכנות את המשאבים והזמן הפנוי לפני שצוללים לפרויקט כזה. מדריך טוב בנושא טיפול בשגיאות 429 יכול לתת לכם מושג על היקף הבעיות שתתמודדו איתן.