גרידת אתר מתחרה: שאלות חוקיות וטכניות לפני שאוספים אפילו שורה אחת
חזרה לבלוג
scraping·6 בספטמבר 2026·4 דק' קריאה·מאת יהונתן סעדיה

גרידת אתר מתחרה: שאלות חוקיות וטכניות לפני שאוספים אפילו שורה אחת

רשימת השאלות שיש לענות עליהן לפני איסוף נתונים מאתר של מתחרה, ומה תקן robots אומר בפועל: זיהוי עצמי, קצב בקשות, 429, מטמון ותיעוד של מה נלקח ומתי.

עיקרי הדברים

  • החלק המשפטי של הרשימה נשאר בצורת שאלות. תנאי שימוש, הנחיות robots, זכויות יוצרים ודיני הגנת הפרטיות קיימים וחלים; מה מהם חל על האתר שלכם הוא שאלה למי שמוסמך לענות עליה.
  • החלק הטכני קונקרטי: לזהות את עצמכם, לכבד קצב, להעדיף הזנה או ממשק רשמי, לשמור מטמון כדי לא לבקש שוב, ולתעד מה נלקח ומתי.
  • תקן RFC 9309 מגדיר שאסימון הזיהוי של הסורק צריך להופיע כמחרוזת משנה בכותרת `User-Agent`, ושמותר להחזיק את קובץ ה-robots במטמון, אך לא יותר מ-24 שעות.
  • אותו תקן קובע הבחנה שרבים מפספסים: תשובת 4xx על קובץ robots פירושה שאין כללים, ואילו תשובת 5xx פירושה שהסורק חייב להניח איסור מלא.
  • כשהתשובה הכנה היא "יש להם הזנה רשמית" או "אפשר פשוט לבקש מהם", זו התשובה. מאמר הזה אינו מתאר דרך לעקוף חסימה, התחברות או תשלום.

זו רשימת שאלות, לא רשימת תשובות. לפני בקשה ראשונה לאתר של מתחרה יש לענות על ארבע שאלות: מה בדיוק נאסף, מה תנאי השימוש של האתר אומרים, אילו הנחיות robots מפורסמות שם, והאם יש בנתונים פרטים על אנשים. התשובה לאתר מסוים היא עניין עבורכם ועורך הדין שלכם.

השאלות שצריך לענות עליהן לפני הבקשה הראשונה

כתבו את התשובות במסמך אחד. אם אחת מהן ריקה, הפרויקט עדיין לא מוגדר:

  • מה בדיוק נאסף? רשימת שדות מפורשת, לא "כל מה שיש בעמוד".
  • לשם מה נעשה בו שימוש? ניתוח פנימי, החלטת תמחור, מוצר שנמכר, או פרסום מחדש. אלה מקרים שונים לחלוטין.
  • מה כתוב בתנאי השימוש של האתר לגבי גישה אוטומטית, והאם נדרשה הסכמה מפורשת כדי להגיע לתוכן.
  • אילו הנחיות מפורסמות בקובץ ה-robots של האתר, ומה הן אומרות לגבי הנתיבים שמעניינים אתכם.
  • האם התוכן שנאסף כולל יצירה מוגנת, ולא רק עובדות כמו מחיר או זמינות.
  • האם יש בנתונים פרטים שמזהים אדם, גם אם הם מוצגים בגלוי.
  • כמה זמן הנתונים נשמרים אצלכם, ומי מוחק אותם.
  • מי אצלכם מאשר שהתשובות לעיל התקבלו, ומתי הן ייבדקו שוב.

השאלות האלה אינן מכשול בירוקרטי. הן מה שמאפשר לכם לענות בשקט אם מישהו ישאל, והן גם מקצרות את הפרויקט, כי רוב הפרויקטים מתכווצים משמעותית ברגע שכותבים רשימת שדות מפורשת.

מה קובץ ה-robots באמת מגדיר?

תקן RFC 9309 מתאר את פרוטוקול ה-robots, והוא טכני ולא משפטי. כמה נקודות שמשנות את המימוש:

  • הסורק בוחר לעצמו אסימון זיהוי, והתקן קובע שהוא צריך להיות מורכב מאותיות, קו תחתון ומקף בלבד, ושהוא אמור להופיע כמחרוזת משנה במחרוזת הזיהוי שנשלחת, כלומר בכותרת User-Agent.
  • ההתאמה בין האסימון לקבוצות בקובץ מתבצעת ללא תלות ברישיות, וכשכמה קבוצות מתאימות הן ממוזגות לקבוצה אחת.
  • אם אין קבוצה שמתאימה, יש לציית לקבוצה של * אם קיימת. אם גם היא אינה קיימת, אין כללים.
  • תשובת שרת בטווח 400 עד 499 על קובץ ה-robots פירושה שהקובץ אינו זמין, ואז מותר לסורק לגשת למשאבים.
  • תשובת שרת בטווח 500 עד 599 פירושה שהקובץ אינו מוגדר, ואז הסורק חייב להניח איסור מלא. זו ההבחנה שנופלים בה: תקלה בצד השרת אינה היתר.
  • מותר להחזיק את הקובץ במטמון, אך לא מעבר ל-24 שעות אלא אם הוא אינו נגיש.
  • על מנתח הקובץ לתמוך בלפחות 500 קיבי-בייט, ועל הסורק לעקוב אחרי לפחות חמש הפניות רצופות.

הנחיות robots אינן קובעות מה מותר לכם לעשות בנתונים אחרי שנאספו. הן מגדירות אילו נתיבים מבקשים מסורקים לא לגשת אליהם. שתי השאלות נפרדות, וערבוב ביניהן הוא הבלבול הנפוץ בתחום.

איך מבקשים בלי להזיק לשרת שאינו שלכם?

זו השאלה הטכנית המרכזית, ויש לה תשובות מדידות:

  1. שלחו כותרת User-Agent שמזהה את מי שאתם, עם דרך ליצור קשר. מי שרואה תעבורה לא מזוהה מניח את הגרוע ביותר, ובצדק.
  2. העדיפו הזנה רשמית או ממשק מתועד על פני קריאת עמוד. זה גם יציב יותר וגם זול יותר לשני הצדדים.
  3. הגבילו קצב, והתייחסו לתשובת 429 כפי שהיא מוגדרת ב-RFC 6585: היא מציינת שנשלחו יותר מדי בקשות בפרק זמן נתון, והיא עשויה לכלול כותרת Retry-After שאומרת כמה להמתין. יש להמתין את הזמן הזה, לא לנסות שוב מיד.
  4. השתמשו בבקשות מותנות ובמטמון לפי RFC 9111 כדי לא למשוך שוב תוכן שכבר יש לכם. פחות בקשות זה גם פחות עומס וגם פחות סיכוי להיחסם.
  5. הריצו בשעות שבהן העומס נמוך, ובקצב שאתם מוכנים להגן עליו בשיחה.
  6. עצרו כשנחסמתם, ובדקו מה קרה. חסימה היא תשובה, לא תקלה שצריך לעקוף.

הצעד הראשון ברשימה הזו הוא גם הזול ביותר: לבדוק אם בכלל קיים ממשק רשמי. הסדר המלא בין ממשק לבין קריאת עמוד מתואר בגרידה מול API, ואופן ההגדרה של היקף הפרויקט באיך מגדירים פרויקט גרידה.

מי עונה על כל שאלה, ומה נשמר

השאלהמי עונהמה נשמר בתיעוד
מה נאסף בפועלמי שמגדיר את הפרויקטרשימת שדות ומטרה בשורה אחת
מה תנאי השימוש אומריםיועץ משפטי מטעמכםתאריך הבדיקה ומי ביצע אותה
מה הנחיות ה-robots אומרותהמפתחהעתק הקובץ כפי שנקרא, עם תאריך
האם יש נתונים אישייםמי שמגדיר יחד עם יועץ משפטיסימון בשדות הרלוונטיים
באיזה קצב לפנותהמפתחהקצב שנקבע והנימוק לו
מתי נבדוק שובבעל התהליךמועד הבדיקה הבאה

הטבלה הזו היא גם קו ההסלמה. שורה שהתשובה עליה אינה בסמכות מי שמריץ את הפרויקט עוברת בשורה אחת למי שכן מוסמך, עם התאריך שבו נדרשת תשובה.

מה מתעדים על כל שורה שנאספה

מקור נתונים בלי מקור אינו נתון, הוא שמועה. לכל רשומה שנשמרת:

  • כתובת המקור המדויקת שממנה נקראה, ולא שם האתר.
  • מועד השליפה, בשעון אחיד.
  • קוד התשובה שהתקבל בפועל.
  • מזהה הריצה שאספה אותה.
  • העתק גולמי שמור, או מזהה שלו, לצורך בירור עתידי.
  • הכלל או השדה שממנו חולץ הערך, כדי שאפשר יהיה לבדוק מה השתנה כשמבנה העמוד ישתנה.

המטא-נתונים האלה הם מה שמאפשר לענות על השאלה "מאיפה הגיע הערך הזה" בלי לחזור ולבקש מהאתר. הם גם מה שהופך תלונה על נתון שגוי לבדיקה של דקה במקום לוויכוח.

מקורות

#web scraping#competitors#robots.txt#RFC 9309#ethics#איסוף נתונים

שאלות נפוצות

האם מותר לגרוד אתר של מתחרה?

זו שאלה שהתשובה עליה תלויה באתר, בנתונים ובשימוש, והיא שאלה עבורכם ועורך הדין שלכם. מה שאפשר לומר: תנאי שימוש, הנחיות robots, זכויות יוצרים ודיני הגנת הפרטיות קיימים וחלים על איסוף. המאמר הזה נועד לוודא שהשאלות נשאלות לפני הבקשה הראשונה ולא אחריה.

מה עושים כשקובץ ה-robots אינו נגיש?

מבחינים בין שני מצבים. לפי RFC 9309, תשובה בטווח 400 עד 499 פירושה שהקובץ אינו זמין ומותר לגשת למשאבים, בעוד תשובה בטווח 500 עד 599 פירושה שהקובץ אינו מוגדר וחובה להניח איסור מלא. אחרי פרק זמן ארוך של חוסר נגישות מותר להתייחס למצב כאל הראשון.

האם הזדהות בכותרת חושפת אותנו לחסימה?

היא מאפשרת לצד השני להחליט. זו בדיוק המטרה: מפעיל אתר שיודע מי פונה אליו ובאיזה קצב יכול לאשר, להגביל או לפנות אליכם. המאמר הזה אינו עוסק בהסתרת זהות, ואם התוכנית תלויה בכך שלא יזהו אתכם, זה סימן שהשאלות בפרק הראשון עדיין לא נענו.

מתי עדיף פשוט לבקש מהמתחרה או מהספק?

לעיתים קרובות יותר משנדמה. ספקים רבים מפרסמים הזנה, קטלוג או ממשק ללקוחות, והרבה נתונים שנראה שצריך לגרוד ניתנים לקבלה בבקשה פשוטה. זה מהיר יותר, יציב יותר, נשאר בתוקף גם כשמבנה האתר משתנה, וחוסך את רוב רשימת השאלות שבפרק הראשון של המאמר.

להמשך קריאה

שירות רלוונטי

Web Scraping וחילוץ נתונים

סקרייפינג וצינורות נתונים אמינים שמספקים נתונים נקיים.

מידע נוסף →←

על הכותב

יהונתן סעדיה

מפתח פרילנסר לאוטומציה, אתרים ו-MVP

אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.

בוא נעבוד יחד

יש לך פרויקט דומה?

ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.