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

איך מזהים שזו תעבורת בוטים ולא מבקרים

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

  • מאות או אלפי בקשות לדקה מאותה כתובת IP או מטווח כתובות צר.
  • User-Agent חוזר וזהה בכל הבקשות, לעיתים עם שם שקוף כמו meta-externalagent, GPTBot, ClaudeBot, bytespider או AhrefsBot.
  • סריקה שיטתית של כתובות לפי תבנית: כל דף מוצר, כל קומבינציה של פילטרים, כל פרמטר ב-URL, בלי היגיון אנושי.
  • התעלמות מ-robots.txt או מקצב סביר. crawler מנומס מאט מעצמו, בוט תוקפני לא.
  • זינוק בעומס CPU או בזיכרון בשרת בלי עלייה מקבילה במכירות, בלידים או בתנועה ב-Analytics. זה הסימן הקלאסי: השרת עמוס, אבל אנליטיקס שקט, כי בוטים לרוב לא מריצים JavaScript ולא נספרים שם.

הכלי המרכזי לאבחון הוא ה-access log של השרת. שורה אחת לכל בקשה, עם הזמן, ה-IP, ה-User-Agent וכתובת היעד. דקה של עיון בלוג, או פקודה שמסכמת אילו User-Agents וכתובות IP מובילים בכמות הבקשות, מספיקה לרוב כדי לזהות את האשם.

Case: Meta externalagent שמציף את השרת

המקרה הזה קרה אצלנו בפועל. שרת שאירח כמה אתרים התחיל להיחנק לסירוגין, בלי שינוי בקוד ובלי עלייה אמיתית בתנועה. בלוגים התגלה דפוס ברור: צי כתובות IP של Meta, כולן עם ה-User-Agent ‏meta-externalagent, סורקות את אחד האתרים בקצב גבוה, כולל נתיבים כבדים שמייצרים עמוד מחדש בכל בקשה ועוקפים cache. זה לא היה ניסיון פריצה, אלא crawler לגיטימי מבחינת המקור, שפשוט התנהג בצורה אגרסיבית מדי לשרת.

הפתרון לא היה לחסום את Meta לגמרי, אלא להחיל הגבלת קצב (rate-limit) פר-דומיין בשכבת ה-nginx: מעבר לסף בקשות לשנייה, השרת מחזיר תשובת 429 Too Many Requests במקום לרנדר עמוד מלא. זה הוריד את העומס מיידית, השאיר את האתר זמין למבקרים אמיתיים, ולא פגע בסריקה הלגיטימית במינון סביר. העיקרון חשוב: המטרה היא לווסת, לא תמיד לחסום.

שיטות החסימה, מהקלה לתקיפה

הסדר תלוי בשאלה אם הבוט לגיטימי שמתנהג גרוע, או זדוני ממש.

  1. Rate-limiting בשכבת השרת. ההגנה הטובה ביותר ברוב המקרים. הגדרת סף בקשות לשנייה פר-IP או פר-דומיין ב-nginx או ב-Apache, עם תשובת 429 מעל הסף. עובד גם נגד בוט שמחליף User-Agent, כי הוא מתבסס על קצב, לא על זהות.
  2. חסימה לפי User-Agent. מתאימה לבוטים שמזהים את עצמם בכנות ושאתם לא צריכים, למשל סורקי SEO מסחריים שצורכים משאבים בלי תועלת. כלל פשוט בשרת שמחזיר 403 ל-User-Agent מסוים. חולשתה: בוט זדוני פשוט משקר על הזהות.
  3. חסימה לפי IP או טווח. יעילה נגד מקור בודד וברור, פחות נגד צי כתובות מתחלף. לטווחים גדולים עדיף לעבוד ברמת ה-firewall ולא בקובץ הגדרות של האתר.
  4. שכבת CDN או WAF. שירות כמו Cloudflare מסנן את רוב תעבורת הבוטים עוד לפני שהיא מגיעה לשרת, כולל זיהוי בוטים מתוחכמים והגבלת קצב מנוהלת. זו ההגנה היציבה ביותר לאתר שסובל מהצפות חוזרות.
  5. robots.txt כקו ראשון, לא כהגנה. אפשר לבקש מ-crawler להאט או לא לסרוק נתיבים מסוימים, אבל זו בקשה בלבד. בוט מנומס מציית, בוט תוקפני מתעלם. לעולם לא להסתמך על זה כחסימה.

חשוב להבחין: הצפת crawler היא בדרך כלל בעיית ביצועים ויציבות, לא פריצה. אבל אותו דפוס של תעבורה חריגה יכול להיות גם התקפת brute force על דף ההתחברות, שהיא כן ניסיון חדירה. אם הבקשות מתרכזות ב-wp-login.php או ב-xmlrpc.php, זה כבר נושא אחר, שמטופל במאמר על חסימת ניסיונות התחברות.

למה זה מתפספס כל כך הרבה

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

איך OCW מטפלים בזה

אנחנו מאבחנים את מקור ההצפה בלוגים, מזהים אם מדובר ב-crawler לגיטימי, בסורק מסחרי מיותר או בתעבורה זדונית, ומחילים את החסימה המתאימה: rate-limit פר-דומיין בשכבת nginx, כללי User-Agent, או הגנת CDN מלאה כשצריך. המטרה היא להוריד את העומס בלי לחסום מבקרים אמיתיים או סריקה לגיטימית.

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

שאלות נפוצות

איך אני יודע אם העומס מבוטים ולא ממבקרים אמיתיים?

ההבדל הקלאסי: השרת עמוס וצורך CPU, אבל ב-Google Analytics התנועה רגועה. רוב הבוטים לא מריצים JavaScript ולא נספרים שם. עיון ב-access log של השרת, שמראה איזה User-Agent ואיזו כתובת IP מובילים בכמות הבקשות, מאשר את זה תוך דקות.

האם לחסום בוטים כמו GPTBot ו-meta-externalagent זה חוקי?

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

robots.txt לא אמור לעצור את זה?

‏robots.txt הוא בקשה, לא חסימה. בוט מנומס מציית לו, בוט תוקפני מתעלם. כדי לעצור באמת צריך rate-limit או חסימה בשכבת השרת או ה-CDN, לא הסתמכות על קובץ שהבוט בוחר אם לכבד.

חסמתי IP אחד והעומס חזר. למה?

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