מה זה web-bot-auth?
נתי אלימלך·עודכן 27.07.2026 web-bot-auth הוא פרוטוקול מתגבש ב-IETF לאימות בוטים: הבוט חותם קריפטוגרפית על בקשות, והאתר מאמת מי שלח אותן.
הבעיה ש-web-bot-auth פותר מוכרת לכל מי שניהל אתר גדול: כל בקשה יכולה לטעון שהיא Googlebot או GPTBot, כי user-agent הוא טקסט חופשי שכל אחד יכול לזייף. עד היום האימות נשען על רשימות IP ובדיקות reverse DNS, תחזוקה ידנית שנשברת בשקט כשטווח מתחלף. web-bot-auth מחליף את השכבה הזאת בחתימה: מפתח פרטי אצל מפעיל הבוט, מפתח ציבורי שגלוי לכולם, וחתימה על הבקשות שהאתר מאמת מול המפתח הציבורי.
איך web-bot-auth עובד
הפרוטוקול נולד ב-Cloudflare, והטיוטות הנוכחיות נכתבות יחד עם גוגל, על בסיס RFC 9421, תקן IETF מאושר לחתימות על הודעות HTTP. מפעיל הבוט חותם על בקשות בשלוש כותרות: Signature-Agent, שמצביעה על ספריית המפתחות של המפעיל, Signature-Input, שמפרטת על מה נחתם ומתי החתימה פגה, ו-Signature עצמה.
Signature-Agent: "https://chatgpt.com"
Signature-Input: sig1=("@authority" "signature-agent");created=1753500000;expires=1753500300;keyid="...";tag="web-bot-auth"
Signature: sig1=:BASE64_SIGNATURE:האתר קורא את הכתובת מ-Signature-Agent, שולף ממנה את המפתח הציבורי בנתיב הקבוע /.well-known/http-message-signatures-directory, ומאמת את החתימה. אי אפשר יותר לזייף כותרת בהקלדה: התחזות דורשת את המפתח הפרטי של המפעיל.
web-bot-auth כבר עובד בשטח לפני שהוא תקן: קבוצת העבודה ב-IETF הוקמה באוקטובר 2025 ואף טיוטה עדיין לא אומצה רשמית, אבל ספריות המפתחות כבר באוויר. אפשר לבדוק לבד: בקשת GET ל-/.well-known/http-message-signatures-directory מחזירה היום JSON של מפתחות ציבוריים גם ב-chatgpt.com וגם ב-agent.bot.goog.
איך web-bot-auth קשור ל-SEO ול-GEO
ככל שאתרים חוסמים בוטים באגרסיביות רבה יותר, גובר הסיכון שחסימה גורפת תפגע גם בבוטים שמביאים ציטוטים, כולל ה-fetchers שמשתמש יזם. web-bot-auth מאפשר מדיניות מדויקת במקום בחירה בין הכול לכלום: להכניס בוטים חתומים, ולחסום מתחזים ששולחים את אותו user-agent בלי חתימה.
ההבדל בין web-bot-auth ל-robots.txt
robots.txt הוא בקשה מנומסת: RFC 9309, התקן שמגדיר אותו, מצהיר במפורש שהכללים בו אינם הרשאת גישה. web-bot-auth הוא הוכחת זהות קריפטוגרפית. robots.txt עונה על “מה מותר לך”. web-bot-auth עונה על “מי אתה בכלל”. robots.txt לא מזהה מתחזה, ו-web-bot-auth לא אומר לו לאן מותר להיכנס.
שאלות על web-bot-auth
האם כדאי לחסום בוטים שלא חותמים על הבקשות?▼
לחסום בוטים שלא חותמים לא כדאי היום, כי כמעט אף סורק לא חותם. Googlebot, Bingbot, GPTBot ו-OAI-SearchBot שולחים בקשות בלי חתימה, וכלל של חתימה-או-חסימה היה מוציא מהאתר את רוב הסריקה של מנועי החיפוש ומנועי ה-AI.
חתימה שימושית כדי לתת גישה, לא כדי לחסום: להעדיף בוט חתום, ולהמשיך לאמת את השאר מול רשימות ה-IP הרשמיות ובדיקת reverse DNS.
האם web-bot-auth כבר תקן רשמי?▼
web-bot-auth עדיין לא תקן: קבוצת העבודה ב-IETF הוקמה באוקטובר 2025, ונכון לאוגוסט 2026 אף טיוטה עדיין לא אומצה רשמית. מה שכן סופי הוא הבסיס, RFC 9421, תקן החתימות על הודעות HTTP שהפרוטוקול נשען עליו.
בינתיים האימוץ בשטח מקדים את התקינה: ה-CDN הגדולים כבר מאמתים חתימות בפרודקשן.
מי משתמש ב-web-bot-auth היום?▼
בצד החתימה: הדפדפן של ChatGPT במצב סוכן, שרץ בענן של OpenAI ומזדהה כ-chatgpt.com, Google-Agent, שגוגל חותמת על חלק מבקשותיו באופן ניסיוני, ו-Bedrock AgentCore של אמזון, בתצוגה מקדימה וכבוי כברירת מחדל. בצד האימות: Cloudflare, Akamai, Vercel, HUMAN ו-AWS WAF בהפצות CloudFront, בין השאר.
מה שעוד לא קורה: היום זה פרוטוקול של סוכנים, לא של סורקי חיפוש ואימון.
האם אפשר לזייף חתימת web-bot-auth?▼
לזייף חתימת web-bot-auth בלי המפתח הפרטי אי אפשר.
אבל הפרוטוקול לא חסין לגמרי: לפי הטיוטה, ההגנה מפני שימוש חוזר באותה בקשה חתומה (בדיקת ה-nonce) היא באחריות האתר שמקבל אותה, והוא רשאי לוותר עליה. Cloudflare, למשל, מוותרת, ונשענת על כך שהחתימה פגה מהר. ומפתח שדלף מחייב רוטציה, כמו כל מפתח.
האם צריך להטמיע web-bot-auth באתר שלי?▼
להטמיע web-bot-auth בעצמכם עדיין לא צריך ברוב המקרים: אם האתר מאחורי Cloudflare, Akamai או Vercel, האימות כבר קורה בתשתית בלי קוד מצדכם. שווה להכיר את הפרוטוקול ולעקוב אחרי האימוץ.