ארכיטקטורת האתר: למה Requests לא יספיק כאן
נתחיל מהכישלון הראשון שכולנו חווינו. אתה מריץ requests.get() על כתובת של קטגוריית מוצרים בפלאפון ומקבל HTML ריק מתוכן. זה קורה כי התוכן לא שם. הוא נטען אסינכרונית. הגישה הזו, של שליפת HTML סטטי, מתה לפני שנים עבור רוב האתרים הרלוונטיים. האתר של פלאפון הוא דוגמה קלאסית לארכיטקטורת frontend מודרנית. הדף הראשוני הוא רק מעטפת, וספריית JavaScript (כמו React או Angular) אחראית על שליחת קריאות XHR/Fetch ל-endpoints של API פנימי כדי לאכלס את הדף במוצרים.
אז מה עושים? יש שתי דרכים. הראשונה, והמסורבלת יותר, היא לבצע reverse engineering לקריאות ה-API האלה. זה אפשרי, אבל שביר. כל שינוי קטן ב-endpoint, ב-headers הנדרשים או ב-payload, ישבור לכם את ה-scraper. זה דורש תחזוקה גבוהה וניטור צמוד. הדרך השנייה, והמועדפת עליי בפרויקטים כאלה, היא להשתמש ב-headless browser. כלים כמו Playwright או Puppeteer מריצים דפדפן אמיתי (כמו Chromium) ברקע. הם טוענים את ה-JavaScript, מבצעים את קריאות ה-API, ומרנדרים את ה-HTML הסופי, בדיוק כמו שמשתמש רואה. זה אולי איטי יותר פר בקשה, אבל חסין הרבה יותר לשינויים ב-backend. בשביל איסוף קטלוג פלאפון מלא, זו הגישה היחידה שמבטיחה שתקבלו את כל הדאטה, כולל מוצרים שנוספו לאחרונה.
ה-Stack הנכון: Playwright, Proxies וניהול Sessions
תפסיקו להשתמש ב-Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית — מהירות, יציבות, ו-API נקי יותר. עבור אתר כמו פלאפון, היכולת לחכות לאלמנטים ספציפיים או לתגובות רשת היא קריטית. עם Playwright, אפשר לכתוב לוגיקה שמחכה ל-endpoint של המוצרים שיחזיר תשובה לפני שמנסים לחלץ את הדאטה, מה שמוריד את כמות ה-race conditions לאפס.
השלב הבא הוא פרוקסיז. גם אם פלאפון לא אגרסיבי כמו אמזון, כל scraper שמבצע מאות בקשות בדקה מ-IP בודד יקבל חסימה. שכחו מפרוקסיז של דאטה סנטר; הם מזוהים בקלות. אתם צריכים רשת של residential proxies. זה מאפשר לכם לפזר את הבקשות על פני מאות כתובות IP שונות, מה שנראה כמו תנועה לגיטימית של משתמשים רבים. קצב של 20-30 בקשות לדקה פר IP הוא נקודת פתיחה טובה. אתם יכולים לקרוא עוד על איך לבחור פרוקסי residential במדריך המלא שלנו.
לבסוף, ניהול session. אל תתייחסו לכל בקשה כחדשה. שמרו קוקיז, local storage, ו-headers בין בקשות. זה לא רק עוזר לעקוף מנגנוני הגנה בסיסיים, אלא גם מבטיח שתקבלו תוכן מותאם אישית אם האתר מציע כזה (למשל, מבצעים לפי היסטוריית גלישה). ב-Playwright, זה קורה אוטומטית בתוך אותו BrowserContext, מה שמפשט את התהליך משמעותית.
איך לגשת ל-Use Cases המרכזיים
עם ה-stack הנכון, אפשר להתחיל לעבוד על המטרות העסקיות. כל use case דורש גישה מעט שונה.
-
ניטור מחירים פלאפון: זהו התרחיש הנפוץ ביותר. המטרה היא לא רק המחיר הנוכחי, אלא גם מבצעים, הנחות, ושינויים לאורך זמן. ה-scraper צריך לרוץ בתדירות גבוהה (למשל, כל 4-6 שעות) על רשימת מוצרים ספציפית, לחלץ את שדה ה-
מחיריםולשמור אותו עם חותמת זמן. חשוב לחלץ גם את 'מחיר לפני הנחה' אם קיים, כדי להבין את עומק המבצע. -
מעקב מלאי/זמינות פלאפון: קריטי לקמעונאים ומתחרים. כאן, המיקוד הוא על אלמנטים כמו "אזל מהמלאי", "זמין בסניפים" או כפתור "הוסף לסל" (אם הוא מושבת). חילוץ שדה ה-
זמינותהוא המפתח. לפעמים, המידע הזה לא מופיע ישירות ב-HTML אלא כ-state בתוך אובייקט JavaScript. תצטרכו להשתמש ב-page.evaluate()של Playwright כדי לגשת אליו. -
מודיעין מתחרים: זהו איסוף רחב יותר. לא רק מחיר ומלאי, אלא גם מפרטים טכניים, תיאורי מוצר, תמונות, ומוצרים חדשים שנוספו לקטלוג. זה דורש סריקה מלאה של כל הקטגוריות, תהליך שיכול לקחת כמה שעות ודורש טיפול נכון ב-pagination.
-
API / קובץ נתונים: השלב הסופי הוא הנגשת המידע. אחרי שכל הנתונים נאספו, צריך לבצע נרמול וניקוי, ואז לייצא אותם בפורמט שמיש. לרוב זה יהיה ייצוא CSV יומי או שבועי, או חשיפת המידע דרך API פנימי לשימוש מערכות אחרות.
תרחיש הכישלון הנפוץ: שינויים שקטים ב-API
הנה תרחיש שקרה לי יותר מפעם אחת עם אתרים דומים לפלאפון. הכל עובד חלק במשך חודשים. אחוז ההצלחה עומד על 99%. יום אחד, הדאטה מתחיל להגיע ריק או חלקי. אין שגיאות 5xx, אין חסימות 403, ה-scraper מדווח שהכל תקין. הבעיה? צוות ה-frontend של האתר שינה את מבנה ה-JSON שחוזר מה-API הפנימי שלהם. שדה שנקרא productPrice הפך ל-price.final, או שמזהה המוצר עבר מפורמט מספרי למחרוזת.
ה-scraper, שמחפש סלקטורים או מבני נתונים ספציפיים, פשוט לא מוצא אותם יותר ומחזיר null. זהו כישלון שקט ומסוכן, כי הוא יכול לזהם את בסיס הנתונים שלכם במידע שגוי במשך ימים עד שמישהו ישים לב. הפתרון הוא לא רק לנטר את קוד התגובה (HTTP status), אלא ליישם data validation על הפלט. השתמשו בספריות כמו Pydantic (בפייתון) או Zod (ב-Node.js) כדי להגדיר סכמה של הנתונים שאתם מצפים לקבל. אם פתאום 90% מהמוצרים לא עוברים את ה-validation כי שדה חובה חסר, המערכת צריכה להרים דגל אדום ולעצור את התהליך. ניטור כזה הוא ההבדל בין פרויקט חובבני למערכת דאטה אמינה. זה לא nice-to-have, זו דרישת חובה.
מתי לא להשתמש בגישה הזו (ולמה זה נדיר)
למרות שאני חסיד גדול של headless browsers לפרויקטים מורכבים, ישנם מצבים שבהם זה overkill. אם כל מה שאתם צריכים מפלאפון זה רק לוודא שרשימה של 10-15 דפים קיימת ומחזירה סטטוס 200, שימוש ב-Playwright הוא בזבוז משאבים. בקשות HTTP פשוטות עם ספריה כמו httpx יהיו מהירות פי 100 ופשוטות יותר לתחזוקה. אבל בואו נהיה מציאותיים – זה כמעט אף פעם לא המצב. רוב דרישות ה-scraping העסקיות כוללות חילוץ תוכן ספציפי, מה שמחייב רינדור JavaScript.
תרחיש נוסף הוא כשהאתר מציע API ציבורי ומתועד. במקרה כזה, כמובן שצריך להשתמש בו. זה תמיד יהיה יציב ומהיר יותר. אבל פלאפון, כמו 99% מאתרי הקמעונאות, לא מציע API כזה. ה-API שלהם הוא פנימי ונועד לשימוש ה-frontend בלבד. לכן, כמעט בכל תרחיש של איסוף קטלוג פלאפון או ניטור מחירים, אין מנוס משימוש בטכניקות שתיארתי. הגישה של reverse engineering ל-API הפנימי היא אופציה, אבל היא דורשת מומחיות גבוהה יותר ותחזוקה אינטנסיבית יותר. לרוב הצוותים, הזמן והמאמץ הנדרשים כדי לתחזק פתרון כזה לא מצדיקים את היתרון הקטן בביצועים על פני headless browser מנוהל היטב. לכן, למרות שקיימות אלטרנטיבות, הן רלוונטיות רק במקרים מאוד ספציפיים.