למה סופר-פארם הוא לא עוד אתר e-commerce פשוט
נתחיל מהבסיס. האתר של סופר-פארם הוא Single Page Application (SPA). המשמעות היא שה-HTML הראשוני שאתה מקבל כמעט ריק מתוכן. הנתונים האמיתיים — שמות מוצרים, מחירים, מבצעים, זמינות — נטענים דינמית דרך קריאות AJAX/Fetch ל-API פנימי. כל ניסיון לפרסר את ה-HTML הראשוני יחזיר דף ריק. זה ה-failure mode הראשון והנפוץ ביותר.
הגישה הנכונה מתחילה בהבנה שאתה צריך לדמות דפדפן אמיתי. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים וב-API הנקי שלו. המטרה הראשונית היא לא לחלץ נתונים מה-HTML, אלא להשתמש בכלי כמו Playwright כדי לרגל אחרי תעבורת הרשת (network traffic) של הדפדפן. פתחו את ה-DevTools, עברו לטאב Network, ותראו את הזהב האמיתי: קריאות ה-API שמחזירות JSON נקי ומסודר. קריאות אלה הן היעד האמיתי של ה-scraper שלכם, לא תגיות ה-HTML.
האתר מנהל קטלוג של עשרות אלפי מוצרים, הפרוס על פני מאות קטגוריות ותתי-קטגוריות. ניווט ידני דרך ה-UI כדי למפות את כל נקודות הקצה האלה הוא לא סקיילבילי. השלב הראשון והקריטי הוא לכתוב scraper ראשוני שמטרתו היחידה היא למפות את היררכיית הקטגוריות ולהפיק רשימה של כל כתובות ה-URL של הקטגוריות. זו תהיה רשימת המשימות (task queue) שלכם להמשך.
ארכיטקטורת ה-Scraper: מ-Headless Browser ל-API ישיר
אחרי שמיפינו את האתר, האסטרטגיה משתנה. שימוש ב-Playwright לכל בקשה הוא בזבוז משאבים עצום. דפדפן headless צורך הרבה יותר זיכרון ו-CPU מאשר קריאת HTTP פשוטה. הגישה ההיברידית היא מה שעובד כאן הכי טוב. השתמשו ב-Playwright רק פעם אחת, בסביבת פיתוח, כדי להבין את מבנה קריאות ה-API. תעדו את ה-Headers, ה-Cookies, וה-Payloads שכל קריאה שולחת.
ברגע שיש לכם את תבנית הקריאה, 95% מהעבודה יכולה לעבור לספריית HTTP מהירה כמו httpx בפייתון, שתומכת ב-async. עכשיו אתם יכולים לשלוח מאות בקשות במקביל ישירות ל-API של סופר-פארם, במקום לדמות משתמש שלוחץ על כפתורים. זה ההבדל בין חילוץ של 1,000 מוצרים בשעה לחילוץ של 50,000. המטרה היא לחלץ שדות קריטיים כמו מחירים ומבצעים בצורה יעילה. אם תבנו את זה נכון, תוכלו להשיג latency ממוצע של 300-500ms לבקשה, במקום 5-10 שניות לדף מלא ב-Playwright.
המפתח הוא לטפל נכון באימות (Authentication). סביר להניח שה-API דורש טוקנים מסוימים (למשל, CSRF tokens או Bearer tokens) שנוצרים בצד הלקוח. פה Playwright נכנס שוב לתמונה, בתפקיד קטן יותר: טעינת דף הבית פעם בכמה שעות כדי לרענן את הטוקנים הנדרשים, שאותם תזריקו לבקשות ה-HTTP המהירות שלכם. למידע נוסף על גישה זו, קראו את ה-מדריך Playwright stealth שלנו.
ניהול Proxies וחסימות: המשחק האמיתי מתחיל כאן
בואו נדבר על מה ששובר את רוב הפרויקטים: חסימות. אם תנסו להריץ את ה-scraper שלכם מ-IP יחיד של שרת בענן (כמו AWS או GCP), תחסמו תוך פחות מ-200 בקשות. מערכות הגנה מודרניות מזהות בקלות טווחים של ספקי ענן. אתם חייבים להשתמש ב-Proxy rotation.
השאלה היא איזה סוג. פרוקסי של דאטה סנטר הם מהירים אבל קלים לזיהוי. עבור אתר כמו סופר-פארם, שסביר שמשתמש ב-WAF (Web Application Firewall) כלשהו, אתם צריכים proxies איכותיים יותר. פרוקסי Residential או Mobile הם הבחירה הנכונה כאן, כי הם נראים כמו תעבורה של משתמשים אמיתיים. אל תשלחו יותר מ-15-20 בקשות בדקה מאותו IP. תכננו את ה-scraper שלכם עם מנגנון backoff אקספוננציאלי ו-retry אוטומטי. ניסיון שנכשל עם שגיאת 429 או 503 לא צריך להרוג את התהליך כולו. הוא צריך להיכנס לתור ניסיונות חוזרים עם פרוקסי אחר. למידע מעמיק על הנושא, קראו את המדריך על איך לבחור פרוקסי residential.
תרחיש כשל נפוץ ספציפי לאתרי פארם וקמעונאות הוא 'soft block'. לא תקבלו שגיאה ברורה. במקום זה, ה-API יתחיל להחזיר תוצאות ריקות או נתונים חלקיים. הדף נטען, קוד הסטטוס הוא 200, אבל המידע חסר. זו הסיבה שחייבים לבנות מנגנוני ולידציה לכל תגובה. תמיד תבדקו אם השדות שאתם מצפים לקבל אכן קיימים לפני שאתם שומרים את הנתונים.
מעקב מלאי ומודיעין מתחרים: מעבר למחיר
איסוף נתונים מסופר-פארם פותח אפשרויות מעבר לניטור מחירים בסיסי. אחד ה-use cases המורכבים והמעניינים ביותר הוא מעקב מלאי/זמינות סופר-פארם ברמת הסניף. האתר מאפשר לבדוק זמינות של מוצר בסניפים שונים. המשמעות היא שכל מוצר דורש סדרה של קריאות API נוספות, אחת לכל אזור או סניף רלוונטי. זה מכפיל את כמות הבקשות הנדרשת פי עשרות או מאות, ומכניס את ניהול ה-proxies למבחן אמיתי. אם לא תנהלו את קצב הבקשות שלכם נכון, תגיעו מהר מאוד למגבלות ותתחילו לקבל שגיאות 429.
שימוש נוסף הוא מודיעין מתחרים סופר-פארם. זה לא רק להשוות מחירים. זה לזהות מתי מוצרים חדשים מתווספים לקטגוריה מסוימת, מתי מוצרים יורדים מהמדף, או אילו מבצעים מופעלים לפני כולם. זה דורש שמירה של סנאפשוטים יומיים של הקטלוג והשוואה ביניהם. דאטהסט כזה יכול להגיע בקלות למאות מגה-בייטים ביום בפורמט JSON, ודורש תכנון של מסד נתונים או Data Lake שיודע להתמודד עם נפחים כאלה. הטיפול בשגיאות קצב הוא קריטי כאן, ומומלץ לקרוא את המדריך שלנו על טיפול בשגיאות 429.
לבסוף, ניתן לאגד את כל המידע הזה ולייצר API / קובץ נתונים סופר-פארם לשימוש פנימי. דמיינו קובץ CSV או נקודת קצה של API פנימית שחושפת את כל קטלוג המוצרים, כולל מחירים, מבצעים וזמינות בסניפים, מעודכן כל 24 שעות. זה נכס אדיר.
מתי Scraping ישיר הוא הגישה הלא נכונה
אחרי כל מה שאמרתי, חשוב להיות כנים. בניית ותחזוקת מערכת scraping כזו היא מאמץ הנדסי לא קטן. יש מצבים שבהם זו פשוט הגישה הלא נכונה. אם כל מה שאתם צריכים זה לעקוב אחרי מחיר של עשרה מוצרים פעם בשבוע, בניית ארכיטקטורה מורכבת עם Playwright, proxies ו-data pipeline היא ירי בנמלה עם תותח. במקרה כזה, סקריפט פשוט שמבקר ישירות בכמה דפים יכול להספיק, גם אם הוא שביר יותר.
בנוסף, תמיד כדאי לבדוק אם קיים API רשמי. עבור סופר-פארם, הסיכוי נמוך, אבל בעבודה מול פלטפורמות אחרות, לפעמים יש תוכניות שותפים או API ציבורי שמאפשר גישה לנתונים בצורה מוסדרת. גישה כזו תמיד תהיה יציבה ואמינה יותר מ-scraping. הבעיה היא שלרוב היא מוגבלת במידע שהיא מספקת, ולא תיתן לכם את כל הפרטים ש-scraping יכול.
נקודה נוספת היא התחזוקה. אתרי e-commerce משנים את המבנה שלהם כל הזמן. סלקטור שהיה נכון אתמול יכול להישבר מחר. קריאת API יכולה לשנות את הפרמטרים שלה. מערכת scraping דורשת ניטור והתאמות מתמידות. אם אין לכם את הזמן או המשאבים להשקיע בתחזוקה שוטפת, הפרויקט ייכשל תוך כמה חודשים. לפעמים, הפתרון הפשוט והידני הוא הנכון, גם אם הוא פחות 'מרשים' טכנולוגית.