למה סקריפט Requests פשוט יקרוס אחרי 200 בקשות
נתחיל מהטעות הנפוצה ביותר. אתה כותב סקריפט Python עם requests ו-BeautifulSoup, מריץ אותו על קטגוריה אחת ב-Wellcom, והכל נראה מצוין. 50 המוצרים הראשונים יורדים חלק. אבל כשאתה מנסה להרחיב את זה לכל 15,000+ המוצרים בקטלוג, המערכת קורסת. אחרי 200-300 בקשות, ה-scraper מתחיל לקבל דפי 403, רידיירקטים לדף הבית, או גרוע מכל – דפים ריקים מתוכן המוצר. זו לא בעיה ב-IP שלכם, עדיין לא. זו בעיית סשן ו-fingerprinting.
אתרי e-commerce כמו Wellcom בונים פרופיל של כל משתמש על בסיס עוגיות, headers, ורצף הפעולות. סקריפט פשוט שולח תמיד את אותו user-agent ובדרך כלל מתעלם מעוגיות סשן שמתעדכנות. המערכת מזהה את זה מהר מאוד כפעילות בוט. התוצאה היא לא חסימה מיידית, אלא מה שאני קורא לו 'חסימה רכה': ה-IP עדיין מורשה גישה, אבל הסשן שלו מסומן כלא אמין, והשרת מפסיק להגיש לו את התוכן הדינמי. פתאום, ה-div שמכיל את נתוני הזמינות או ה-span של המחיר פשוט לא מופיעים ב-HTML. ראיתי את התרחיש הזה עשרות פעמים, והוא גורם לאיסוף דאטה שקט ופגום. אחוזי ההצלחה צונחים מ-100% ל-20% תוך פחות מ-10 דקות ריצה, והדיבאגינג הופך לסיוט.
ה-Stack המנצח ל-Scraping של אתרי E-commerce מודרניים
תפסיקו להשתמש ב-Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים ובאמינות. עבור אתר כמו Wellcom, שבו חלק מהמידע על מבצעים או מלאי נטען דינמית עם JavaScript, שימוש בדפדפן אמיתי הוא לא מותרות, אלא חובה.
ה-stack שאני ממליץ עליו מורכב משלושה חלקים: Playwright כ엔진 הדפדפן, תוסף stealth שעוזר להסוות את האוטומציה, וניהול פרוקסי חכם. למה זה עובד? כי Playwright מנהל באופן אוטומטי את כל מה ש-requests מפספס: הוא מעבד JavaScript, מנהל עוגיות סשן מורכבות, ומבצע את בקשות ה-XHR/Fetch ברקע בדיוק כמו דפדפן אנושי. תוסף ה-stealth מטפל בטביעת האצבע הדיגיטלית – הוא משנה מאפיינים שספריות אוטומציה חושפות, כמו navigator.webdriver. זה הופך את ה-scraper להרבה יותר קשה לזיהוי. כשאנחנו מריצים סריקה מלאה על Wellcom עם הסטאפ הזה, אנחנו רואים אחוזי הצלחה יציבים של 98-99%, גם בסריקות שלוקחות מעל שעה. ה-overhead של הרצת דפדפן מלא מתגמד לעומת הזמן שתחסכו על דיבאגינג של חסימות.
איסוף קטלוג ומעקב מלאי: מעבר לנתונים הבסיסיים
שני מקרי השימוש המרכזיים ב-scraping של Wellcom הם איסוף קטלוג Wellcom ומעקב מלאי/זמינות Wellcom. איסוף קטלוג נשמע פשוט – לעבור על כל עמודי הקטגוריות ולאסוף קישורים למוצרים. האתגר הוא לעשות את זה ביעילות. במקום לסרוק את כל האתר כל יום, גישה טובה יותר היא לסרוק את עמודי הקטגוריות הראשיים פעם ביום כדי לזהות מוצרים חדשים, ולסרוק את עמודי המוצרים הקיימים בתדירות נמוכה יותר, אולי פעם בשבוע, רק כדי לעדכן מפרטים.
מעקב מלאי הוא סיפור אחר לגמרי ודורש גישה כירורגית. המידע על זמינות בסניפים יכול להשתנות כל כמה דקות. כאן, אין טעם להריץ את Playwright על כל הדף כל פעם. גישה היברידית עובדת הכי טוב: השתמשו ב-Playwright כדי לקבל את עוגיות הסשן הראשוניות ולנתח את בקשות הרשת של הדף. ב-90% מהמקרים, תגלו שהמידע על המלאי מגיע מבקשת API נפרדת (XHR). אחרי שזיהיתם את ה-endpoint וה-headers הנדרשים, תוכלו לפגוע ישירות ב-API הזה עם requests או httpx ולמשוך רק את פיסת המידע שאתם צריכים. זה מקטין את ה-latency מ-3-5 שניות לטעינת דף מלא לפחות מ-300 מילישניות לבקשת API. כך אפשר לבנות מערכת API / קובץ נתונים Wellcom כמעט בזמן אמת, בלי להעמיס על התשתיות שלכם או על האתר.
מודיעין מתחרים וניטור מחירים: ארכיטקטורת הנתונים
כשהמטרה היא מודיעין מתחרים Wellcom או ניטור מחירים Wellcom, ה-scraping הוא רק 20% מהעבודה. 80% הנותרים הם ארכיטקטורת הנתונים שאוגרת ומנתחת את המידע. אתם לא יכולים פשוט לזרוק את הנתונים לקובץ CSV. אתם צריכים מסד נתונים שיודע לשמור היסטוריה.
לכל מוצר, שמרו רשומה נפרדת לכל סריקה עם חותמת זמן. המינימום שצריך לשמור הוא: product_id, timestamp, price, availability_status. זה מאפשר לכם לענות על שאלות מורכבות כמו: 'מה היה המחיר של מוצר X לפני שבוע?', 'מתי מוצר Y חזר למלאי?', או 'אילו מוצרים שינו מחיר יותר מ-3 פעמים בחודש האחרון?'. זה הבסיס לכל ניתוח מתחרים רציני. בנוסף, חשוב לנרמל את הנתונים. שמות קטגוריות יכולים להשתנות, אז השתמשו במזהה פנימי קבוע. שמות מוצרים יכולים להכיל שגיאות כתיב או וריאציות קלות; השתמשו באלגוריתמים של fuzzy matching כדי לקבץ אותם יחד. בלי בסיס נתונים מובנה היטב, הדאטה שנאסף בעמל רב הופך במהירות לרעש חסר תועלת. אם אתם רציניים לגבי זה, תכננו את סכמת הדאטה לפני שאתם כותבים שורת קוד אחת של scraper.
מתי הגישה הזו לא עובדת (או שהיא Overkill)
למרות שאני מאמין גדול בגישת הדפדפן המלא, יש מצבים שבהם היא פשוט מיותרת. אם כל מה שאתם צריכים זה לבדוק פעם ביום אם עמוד מסוים קיים (מחזיר סטטוס 200), שימוש ב-Playwright הוא בזבוז משאבים. סקריפט curl פשוט יעשה את העבודה. באופן דומה, אם אתר היעד שלכם הוא old-school לחלוטין, עם HTML סטטי שנוצר בצד השרת וללא שום JavaScript בצד הלקוח, requests עם ניהול sessions ו-headers נכון יכול להספיק. הבעיה היא שקשה לדעת זאת מראש, והרבה אתרים שנראים פשוטים מסתירים לוגיקה מורכבת.
הנקודה הקריטית היא ב-Trade-off בין זמן פיתוח ראשוני לזמן תחזוקה. גישת requests מהירה יותר לפיתוח ראשוני, אבל שבירה יותר ודורשת יותר דיבאגינג ותחזוקה כשהאתר משתנה. גישת Playwright דורשת יותר מאמץ בהתחלה (setup של סביבה, ניהול דפדפנים), אבל היא הרבה יותר עמידה לשינויים קטנים ב-frontend. הכלל שלי: אם הפרויקט צריך לרוץ יותר מחודש ואמינות הנתונים קריטית, התחילו עם Playwright. אם זה סקריפט חד-פעמי לאיסוף 500 פריטים, httpx אסינכרוני עם רוטציית פרוקסי חכמה יספיק בהחלט.