למה PharmStore שובר סקריפטים פשוטים תוך דקות
הסיבה הראשונה שסקריפטים נכשלים ב-PharmStore היא שהם לא רואים את התוכן האמיתי. כשאתה שולח בקשת GET פשוטה ל-URL של מוצר, מה שחוזר זה מעטפת HTML וצרור של קבצי JavaScript. המחיר, הזמינות, המפרט — כל המידע שאתה באמת צריך — נטען דינמית דרך קריאות API אסינכרוניות שהדפדפן מריץ. סקריפט פייתון בסיסי לא מריץ JS, ולכן הוא עיוור למידע הזה.
האתר מנהל קטלוג של כ-50,000 מוצרים, והמידע הזה מתעדכן בתדירות גבוהה. אם המטרה שלך היא מעקב מלאי/זמינות PharmStore, אתה חייב לתפוס את קריאות ה-API הספציפיות שמחזירות את נתוני המלאי. גישה זו מהירה יותר מרינדור דף מלא, אבל היא שבירה. כל שינוי קטן ב-endpoint של ה-API או במבנה התשובה ישבור לך את ה-scraper. לרוב הפרויקטים, הפתרון היציב יותר, גם אם איטי יותר, הוא להשתמש בדפדפן אמיתי (headless) שיבצע את כל העבודה הזו בשבילך. בנוסף, האתר משתמש במנגנוני הגנה בסיסיים שמזהים בקלות user-agents גנריים של ספריות HTTP. אם אתה לא מחקה התנהגות דפדפן, אתה תיחסם עוד לפני שהגעת לנתונים.
הסטאק הנכון לאיסוף קטלוג מלא מ-PharmStore
תשכחו מ-Selenium לפרויקטים חדשים. ב-2025, Playwright הוא הבחירה הנכונה. הוא מהיר יותר, ה-API שלו נקי יותר, והכי חשוב — קהילת ה-stealth סביבו חזקה. כדי לבצע איסוף קטלוג PharmStore בצורה מלאה, תצטרך דפדפן שיכול לרנדר את הדפים במלואם. המטרה היא לאסוף שדות כמו שמות מוצרים ו-קטגוריות מכל עמודי המוצרים. התהליך מתחיל בדרך כלל מעמוד הקטגוריה, איסוף כל הקישורים למוצרים, ואז מעבר סדרתי עליהם.
התקנה של Playwright עם פלאגין stealth היא קו ההגנה הראשון. זה דואג להסתיר את העובדה שאתה מריץ דפדפן אוטומטי, על ידי תיקון מאפיינים ש-bot detection scripts מחפשים (כמו navigator.webdriver). בלי זה, הסיכוי שלך לעבור את ההגנות הראשוניות נמוך. המערכת צריכה להיות בנויה לעבודה אסינכרונית. אם אתה מנסה לסרוק 50,000 דפים באופן סנכרוני, אתה מבזבז 90% מהזמן על המתנה ל-network I/O. שימוש ב-asyncio עם Playwright מאפשר לך לנהל מאות דפים במקביל, מה שמוריד את זמן הסריקה המלאה מימים לשעות. למי שרוצה להעמיק, הנה מדריך Playwright stealth שמכסה את הנקודות הטכניות.
הקרב האמיתי: ניהול סשנים ורוטציית פרוקסי חכמה
כאן רוב המערכות נופלות, גם אלו עם סטאק טכנולוגי נכון. PharmStore, כמו כל אתר e-commerce רציני, לא רק בודק IP בודד; הוא מנתח התנהגות לאורך סשן. אם תשתמש ברוטציית פרוקסי פשוטה שמחליפה IP בכל בקשה, אתה צועק "אני בוט!". התנהגות אנושית היא עקבית: משתמש נשאר עם אותו IP לאורך זמן מסוים. לכן, אתה צריך פרוקסי עם תמיכה ב-sticky sessions. זה מאפשר לך לשלוח, נגיד, 30-50 בקשות מאותו IP לפני שאתה עושה רוטציה.
תרחיש הכישלון הקלאסי שאני רואה הוא מה שאני קורא "זיהום IP". אתה מתחיל עם מאגר פרוקסי נקי, אבל אחרי כמה שעות של סריקה אגרסיבית, האתר מתחיל לסמן את ה-IPs שלך. התוצאה היא לא חסימה מוחלטת (שגיאת 403), אלא soft ban: אתה מתחיל לקבל CAPTCHAs, זמני טעינה ארוכים בכוונה, או אפילו נתונים שגויים. פתאום, המחירים שאתה מקבל הם לא המחירים האמיתיים. הדרך להתמודד עם זה היא להשתמש ב-פרוקסי residential איכותיים, לנהל קצב בקשות סביר (לא יותר מ-20 לדקה פר IP), ולבנות לוגיקה שיודעת להוציא IP "שרוף" מהמאגר באופן אוטומטי.
מתי הגישה הזו היא Overkill (ואפילו מזיקה)
למרות כל מה שאמרתי, שימוש ב-Playwright ורשת פרוקסי מורכבת הוא לא תמיד התשובה. זו גישה שדורשת משאבי מערכת משמעותיים. אם כל מה שאתה צריך זה לבדוק מחיר של 10 מוצרים פעם ביום, הקמת תשתית כזו היא בזבוז זמן ומורכבות. במקרים כאלה, עדיף לחקור את קריאות ה-API של האתר. פתח את כלי המפתחים בדפדפן, נווט באתר, ובדוק את לשונית ה-Network. סביר שתמצא קריאת XHR/Fetch שמחזירה JSON עם כל המידע שאתה צריך.
הנדסה הפוכה של ה-API היא גישה הרבה יותר יעילה מבחינת משאבים, אבל היא שבירה יותר. היא דורשת הבנה עמוקה יותר של איך האתר עובד, ולפעמים צריך להתמודד עם טוקנים ו-headers מורכבים. אבל אם הפרויקט שלך קטן וממוקד, המאמץ הראשוני הזה יכול לחסוך לך את התחזוקה השוטפת של scraper מבוסס דפדפן. הגישה הזו לא מתאימה למי שצריך API / קובץ נתונים PharmStore מלא ומקיף, כי קשה למפות את כל ה-API. אבל לניטור ממוקד, זו יכולה להיות הדרך הנכונה. היא גם נכשלת באופן ברור יותר: או שהיא עובדת או שהיא נשברת. אין מצב ביניים של קבלת דאטה חלקי או שגוי כמו שיכול לקרות עם דפדפן.
מניטור מחירים ועד מודיעין מתחרים בזמן אמת
ברגע שיש לך תשתית יציבה לאיסוף נתונים מ-PharmStore, האפשרויות נפתחות. המקרה הברור הוא ניטור מחירים PharmStore, שמאפשר לעקוב אחרי שינויים, לזהות מבצעים, ולהשוות מול המתחרים. אבל הדאטה הזה יכול להניב תובנות עמוקות יותר. לדוגמה, על ידי מעקב אחר השדה זמינות לאורך זמן, אפשר להעריך קצב מכירות של מוצרים מסוימים ולהבין מגמות ביקוש. זה הופך את הדאטה לכלי מודיעין מתחרים PharmStore.
אחד הפרויקטים המעניינים שעבדתי עליהם היה בניית מערכת שמזהה שינויים במוצרים. לא רק במחיר, אלא בתיאור, בתמונות, או במפרט. שינוי כזה יכול לאותת על השקת גרסה חדשה של מוצר או שינוי אסטרטגיה שיווקית. בנינו מערכת שמחשבת hash לתוכן של כל עמוד מוצר, וכך זיהינו שינויים בלי צורך לנתח את כל ה-HTML בכל פעם. הצלחנו להגיע לזמן תגובה של פחות מ-15 דקות לשינוי באתר, מה שסיפק יתרון משמעותי. במערכות כאלה, חשוב מאוד לדעת איך לטפל בשגיאות 429 ו-rate limiting בצורה חכמה, כדי שהמערכת תמשיך לרוץ גם כשהאתר מנסה להאט אותך.