למה ה-Scraper הראשון שלך לעזריאלי קום ייכשל
בואו נדבר גלויות. אם הגישה הראשונה שלכם היא requests ו-BeautifulSoup, אתם יכולים לעצור כאן. זה פשוט לא יעבוד. דפי המוצר והקטגוריות ב-azrieli.com לא מגיעים כ-HTML מלא מהשרת. מה שתקבלו בחזרה זה שלד HTML עם המון קוד JavaScript שאחראי לרנדור התוכן האמיתי. שדות קריטיים כמו מחירים, מבצעים ונתוני זמינות נטענים באופן אסינכרוני, לעיתים קרובות דרך קריאות API פנימיות לאחר טעינת הדף הראשונית.
הכישלון הנפוץ ביותר הוא לקבל דף ריק, או דף עם אנימציית טעינה נצחית, ולחשוב שהסלקטור שגוי. הסלקטור כנראה בסדר, האלמנט פשוט לא קיים ב-DOM בזמן שהסקריפט שלכם מסתכל. זו הסיבה שחייבים לעבור לכלים שמריצים דפדפן אמיתי. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית – מהירות, יציבות, וה-API שלו פשוט נקי יותר. שימוש ב-Playwright עם stealth plugin בסיסי הוא נקודת הפתיחה המינימלית, לא אופציה. כל דבר אחר הוא בזבוז זמן יקר בדיבאגינג של בעיות שכבר נפתרו.
ארכיטקטורת ה-Scraping הנכונה לקטלוג של 200,000+ מוצרים
איסוף קטלוג מלא מעזריאלי קום הוא לא משימה של סקריפט בודד שרץ על הלפטופ. אנחנו מדברים על קטלוג עם מאות אלפי מוצרים, וזה דורש ארכיטקטורה מבוזרת. המטרה היא להפריד בין שלב גילוי הקישורים (Crawling) לשלב חילוץ המידע (Scraping). תהליך ה-Crawl יכול לרוץ פעם ביום, לסרוק את עצי הקטגוריות והפגינציה, ולמלא תור משימות (עם RabbitMQ או Redis) בקישורי מוצר. תהליך ה-Scrape, שמורכב ממספר workers, שולף משימות מהתור ומבצע את העבודה הכבדה של הרצת Playwright.
הגישה הזו נותנת גמישות אדירה. אם worker אחד נופל, המשימה חוזרת לתור. אם צריך להגביר קצב, פשוט מרימים עוד workers. קצב סביר להתחיל איתו הוא סביב 200-300 דפים בדקה, מה שמצריך סדר גודל של 10-15 workers במקביל, תלוי במשאבים. זה מאפשר סריקה מלאה של הקטלוג תוך מספר שעות, לא ימים. חשוב מאוד לנהל את ה-state. כל worker צריך פרוקסי משלו, ורצוי מאוד להשתמש בפתרון של איך לבחור פרוקסי residential כדי להימנע מחסימות IP שיהרגו את כל ה-batch. ללא הפרדה כזו, כל תקלה קטנה עוצרת את כל התהליך.
מעקב מלאי ומודיעין מתחרים: המיקוד ב-API הפנימי
אחרי שהרצתם את ה-scraper כמה פעמים, תשימו לב לתבנית. רוב המידע הדינמי – מלאי, מחירים, זמינות בסניפים – לא מגיע מה-HTML הראשוני. הוא נטען דרך קריאות XHR/Fetch שהדפדפן מבצע ברקע. כאן נמצא מכרה הזהב. במקום לרנדר דף שלם עם Playwright רק כדי לבדוק אם המחיר השתנה, אפשר לנטר את תעבורת הרשת של הדף ולזהות את ה-endpoints של ה-API הפנימי.
לרוב, מדובר ב-endpoint שמקבל מזהה מוצר (SKU) ומחזיר JSON עם כל המידע הרלוונטי. ברגע שמזהים את הקריאה הזו, אפשר לבצע מעקב מלאי/זמינות עזריאלי קום בעזרת בקשות ישירות ל-API הזה. זה מהיר פי 100 וצורך 1% מהמשאבים. המורכבות עוברת מניהול דפדפנים כבדים לניהול cookies, headers, ו-tokens שנדרשים לאימות הבקשה. זה מושלם למשימות של מודיעין מתחרים עזריאלי קום שדורשות בדיקות תכופות של מוצרים ספציפיים. הצלחה של 99.5% בגישה זו היא ריאלית, לעומת כ-97% בגישה מבוססת דפדפן מלא, בגלל פחות נקודות כשל. כדאי לבנות מערכת שיודעת לטפל בשגיאות 429 בצורה חכמה, כי גם בקשות API יכולות להיתקל ב-rate limiting.
תרחיש הכשל הנפוץ: מלכודת הפגינציה האינסופית
הנה תרחיש שראיתי קורה יותר מדי פעמים באתרים כמו עזריאלי קום. ה-crawler שלך מתחיל לעבור על קטגוריה, לוחץ על "הבא" בסוף כל עמוד, ואוסף קישורים. הכל נראה תקין. אבל אז, אחרי עמוד 25, האתר מתחיל להחזיר את אותם מוצרים שכבר ראית, בסדר שונה, או עם פרמטר URL קצת אחר. לפעמים הוא פשוט חוזר על עמוד 25 לנצח. זו לא טעות באתר, זה פיצ'ר הגנה.
אתרים גדולים מגבילים את עומק הפגינציה כדי למנוע סריקות עומק אוטומטיות. ה-crawler שלך, אם הוא לא בנוי להתמודד עם זה, ייכנס ללולאה אינסופית, יבזבז משאבים, יזהם את בסיס הנתונים במוצרים כפולים, ואולי אפילו יגרום לחסימת IP בגלל פעילות חריגה. הפתרון הוא לא לסמוך על כפתור "הבא". צריך לבנות לוגיקה שמזהה תוכן כפול. לפני שמוסיפים קישורי מוצרים לתור, בודקים אם המזהים שלהם כבר נראו בסריקה הנוכחית. אם אחוז החפיפה בין עמוד נוכחי לעמוד קודם עובר סף מסוים (נניח 70%), עוצרים את הסריקה באותה קטגוריה ומסמנים אותה לבדיקה. זו הגנה פשוטה שיכולה לחסוך שעות של דיבאגינג ודאטה לא נקי.
מאיסוף נתונים למוצר: בניית API וייצוא קבצים
איסוף הנתונים הוא רק חצי מהעבודה. הדאטה הגולמי, גם אם הוא נקי, לא שווה הרבה אם הוא יושב סתם בבסיס נתונים. השלב הבא הוא הפיכת המידע הזה למוצר שמיש עבור הלקוחות או הצוותים הפנימיים. הדרישה הנפוצה ביותר היא API / קובץ נתונים עזריאלי קום. זה יכול להיות endpoint פשוט שמחזיר מידע על מוצר לפי SKU, או תהליך יומי/שבועי שמייצא את כל הקטלוג לקובץ CSV או JSON ומעלה אותו ל-S3.
כשבונים API על גבי דאטה מ-scraping, חשוב לכלול מטא-דאטה. מתי המוצר נסרק לאחרונה? מה היה ה-HTTP status code? מהי היסטוריית המחירים שלו? המידע הזה קריטי לאמינות. עבור ייצוא קבצים, חשוב לתכנן את הסכמה היטב. שינוי עמודה בקובץ CSV ענק יכול לשבור תהליכים שלמים אצל הלקוח. לכן, גרסאות של סכמת הייצוא הן חובה. אחת הטכניקות היעילות ביותר היא שימוש ב-מדריך Playwright stealth לאיסוף הראשוני, ואז עיבוד אסינכרוני שמנרמל את הנתונים, מעשיר אותם, ורק אז חושף אותם דרך ה-API או קובץ הייצוא. זה מבטיח שהמוצר הסופי הוא יציב וצפוי.