Agentic Browsing: האתר עבר את הבדיקה. הטופס עדיין הכשיל את המשימה.

מה זה Agentic Browsing, ולמי כדאי לבדוק אותו?

Agentic Browsing הוא שימוש בסוכן AI שמפעיל דפדפן כדי לבצע משימה: לקבוע הדגמה, למלא טופס או להשלים הזמנה.

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

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

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

האתר החי: 2/2 ב־Lighthouse, ו־20/100 ב־Agent Readiness

כדי לבדוק את האתר כפי שהוא מוגש לציבור, נסרק גם https://nirlevi.com/. תוצאת Agentic Browsing הייתה 2/2, עם CLS של 0.

עץ הנגישות עבר. בדיקות WebMCP ו־llms.txt סומנו N/A. הדוח המלא וקובץ המקור זמינים לבדיקה.

באותה הרצה התקבלו Performance 75, Accessibility 97, Best Practices 100 ו־SEO 100. אלה ציוני מעבדה של דף הבית, לא של המאמר.

בסריקה של Cloudflare Agent Readiness, אותה כתובת קיבלה 20/100, ברמה Basic Web Presence.

אני לא הייתי הופך את 12 ההמלצות של הכלי לרשימת פיתוח אוטומטית. קודם צריך לדעת אילו יכולות האתר אמור לספק.

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

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

המקרה: הטופס דחה את הקלט, אבל הסתיר את הסיבה

בטופס הפנייה כאן באתר נמצא פער קטן בין הדפדפן לשרת. מספיק היה להזין SEO — שלוש אותיות ורווח בכל קצה.

בדפדפן הוגדר minlength="5". הקלט אכן מכיל חמישה תווים. השרת הסיר את הרווחים שבקצוות, ספר שלושה ודחה את הבקשה.

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

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

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

במקביל, דוח Lighthouse על אותו קוד הציג 2/2: עץ הנגישות עבר, ו־CLS היה 0. ארבע בדיקות נוספות סומנו N/A.

אפשר לפתוח את דוח הבסיס המלא ואת קובץ ה־JSON. שאר קטגוריות הדוח מוצגות כפי שנמדדו בסביבה המקומית.

התיקון: להסביר את השגיאה ולאפשר להשלים את הפנייה

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

• הדפדפן והשרת משתמשים באותה פונקציית אימות של הטקסט.
• השדה מקבל aria-invalid והסבר המקושר אליו באמצעות aria-describedby.
• המיקוד חוזר לשדה הבעייתי, והפרטים שכבר מולאו נשמרים.
• הודעת הצלחה מופיעה רק אחרי שהשרת מחזיר אישור.

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

הראיה לסיום היא רשומת הקבלה, לצד תיעוד הבקשה. הודעת ההצלחה לבדה לא מספיקה.

הדוח החוזר נשאר 2/2. מה שהשתנה הוא היכולת לתקן ולהמשיך בטופס.

אני הייתי מוסיף את המקרה הזה לבדיקות הקבועות של הטופס. הוא בודק משהו שהסריקה הראשונית של הדף לא הפעילה.

רשימת הבדיקות: מה לתקן, ומה לבדוק אחרי המעבר

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

לפי תיעוד Chrome, הקטגוריה ניסיונית ודורשת Chrome 150 ומעלה. היחס מציג בדיקות שעברו; הוא אינו ציון משוקלל של 0–100.

<label for="request">מה תרצו לבדוק באתר?</label>
<textarea id="request" name="goal"
  aria-invalid="true" aria-describedby="request-error"></textarea>
<p id="request-error">כתבו כמה מילים על הבקשה.</p>

# Example company

Product documentation and support for customers.

## Documentation
- [Getting started](https://example.com/docs): Setup instructions.

Agent Readiness מול Agentic Browsing מול בדיקת משימה

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

הממצאים משלימים זה את זה. הציון הנמוך ב־Cloudflare אינו מבטל את מעבר בדיקות Lighthouse; שניהם משאירים את תוצאת המשתמש לבדיקה נפרדת.

איך מריצים בדיקה שאפשר לחזור אליה?

פתחו את העמוד המדויק ב־Chrome, היכנסו ל־DevTools ובחרו Lighthouse. סמנו Agentic Browsing, הריצו ושמרו את הדוח.

אם הקטגוריה אינה מופיעה, בדקו את גרסת Chrome ואת גרסת Lighthouse. אפשר להשתמש גם ב־CLI, כפי שנעשה כאן.

npx lighthouse@13.4.1 https://example.com/ \
  --only-categories=agentic-browsing \
  --output=json --output=html --output-path=./audit

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

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

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

איך יודעים אם הבעיה באתר או בכלי הבדיקה?

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

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

מה הקשר ל־GEO, ומה כדאי לעשות קודם?

Agentic Browsing עוסק בביצוע פעולה. GEO עוסק בנראות בתשובות AI. אלה מטרות שונות, גם כשהן נשענות על אותו אתר.

Google Search מציינת שאין צורך בקבצים מיוחדים עבור תכונות ה־AI שלה, ושהיא מתעלמת מ־llms.txt. מעבר audit אינו הבטחה לאזכור או לדירוג.

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

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

שאלות נפוצות