סורקי AI מנפחים את נתוני התנועה שלכם, והקיצור הרגיל — בדיקת כותרת ה-User-Agent — לא תופס אותם.
סריקה של לוגים לאורך שמונה ימים חשפה 468 שליפות אמיתיות של מאמרים, אך 991 בקשות שהתחזו לבוטים של AI בעוד שבפועל הן חיפשו קבצים כמו .env או .git. האשם? כל אחד יכול להכניס מחרוזת User-Agent שהוגדרה באופן עצמאי, כמו GPTBot או ChatGPT-User, לתוך בקשת HTTP.
למה המדד הזה חשוב
אתרים מתייחסים לזינוק ב"תנועת AI" כסימן לרלוונטיות. הם משתמשים במספרים כדי להצדיק תעריפי פרסום, להקצות משאבי שרת ולהתגאות בפני משקיעים. כשמחצית מהחשיפות המדווחות של AI הן בסך הכל רעש, תקציבים הולכים לאיבוד ולוחות הבקרה (dashboards) הופכים למטעים.
שני המסננים שמפרידים בין טענה למציאות
verifiedBotCategoryשל Cloudflare – Cloudflare ממלאת שדה זה רק לאחר שהיא פותרת את כתובת ה-IP של הבקשה חזרה לדומיין בוט מוכר באמצעות reverse DNS. אם הכותרת אומרת "GPTBot" אך ה-IP נכשל בחיפוש, הבקשה נופלת לקטגוריית ה-"unverified".- בדיקה מול ה-Sitemap – בוט קורא באמת את התוכן שלכם רק כאשר ה-URL המבוקש מופיע ב-XML sitemap שלכם. בקשות לנתיבים שאינם מופיעים ב-sitemap מחפשות ככל הנראה פגיעויות (vulnerabilities) ולא מאנדקסות מאמרים.
החלת שני המסננים הללו על אותו מדגם של שמונה ימים הניבה מספרים בולטים:
- ChatGPT-User – 39% מהבקשות עברו אימות.
- GPTBot – 13% מאומתים.
- PerplexityBot – 0% מאומתים.
- Google-Extended – 0% מאומתים; המחרוזת אינה תואמת לאף סורק רשמי של Google.
אפילו בין הקריאות המאומתות, בוטים רבים שלחו בקשות רק עבור robots.txt או עבור ה-sitemap עצמו, ולא עבור דפי המאמרים שחשובים לכם.
מה מפתחים יכולים לעשות כבר היום
- הפעילו את אימות הבוטים של Cloudflare בצינור הנתונים (pipeline) של האנליטיקה שלכם. השדה
verifiedBotCategoryמופיע בכותרות הבקשה וניתן לשמור אותו לצד הלוגים שלכם. - תחזקו sitemap מעודכן ואוטומטו בדיקה שכל נתיב של בקשה נכנס אכן קיים שם לפני שאתם סופרים אותו כצפייה בתוכן.
- סננו שיטות (methods) שאינן GET ובקשות שמטרתן קבצי פיתוח טיפוסיים (
.env,.git,.bak). אלו הן כמעט תמיד סריקות זדוניות.
נקודת המבט הנגדית
יש הטוענים שניתן לזייף (spoof) בדיקות reverse DNS, ושהמטרה הלגיטימית של בוט עשויה להיות גילוי כתובות URL חדשות שטרם נכללו ב-sitemap. החששות הללו תקפים: תוקף נחוש יכול לפרוץ לרשומה של DNS, ותוכן חדש לא יהיה מופיע באופן טבעי ב-sitemap הנוכחי עד למחזור היצירה הבא.
התגובה הפרגמטית היא להתייחס לאימות כאל "ציון ביטחון" (confidence score) ולא כשער מוחלט. שילוב של אימות DNS, נוכחות ב-sitemap ובדיקת שיטת הבקשה (request-method) יעלה את הרף למה שאתם סופרים כ"תנועת AI אמיתית". אם בקשה עוברת שניים משלושת הבדיקות, סמנו אותה לבדיקה ידנית במקום לפסול אותה מיד.
מה כדאי לעקוב אחריו בהמשך
- שינויים ב-API האימות של Cloudflare – כל שינוי בלוגיקה של ה-
verifiedBotCategoryעלול לשנות את שיעורי האימות. - הופעתם של בוטים חדשים המזדהים באופן עצמאי – עקבו אחר מחרוזות ה-User-Agent המופיעות בלוגים שלכם; עלייה פתאומית עשויה להעיד על סורק חדש המתחזה לסורק AI.
- תדירות יצירת ה-sitemap – מרווחים ארוכים יותר מגדילים את הסיכוי שסורקים לגיטימיים יסווגו בטעות.
השורה התחתונה היא פשוטה: הפסיקו להתייחס למחרוזת User-Agent כהוכחה. הוסיפו שכבות של אימות DNS ואימות sitemap, ותראו תמונה ברורה יותר של מי באמת קורא את התוכן שלכם.
Source: https://dev.to/aulvem/ai-crawler-user-agents-are-self-reported-468-real-fetches-991-fake-ones-bgo