Agentic Browsing: למה הטופס נכשל למרות בדיקת Lighthouse תקינה?

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

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

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

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

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

מה הראו שתי הסריקות של האתר ב-10.9.2026?

ב-10.9.2026 נסרק גם דף הבית החי, 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", ולכן קיבל את הטקסט עם הרווחים. השרת הסיר את הרווחים שבקצוות, נשאר עם שלוש אותיות ודחה את הבקשה.

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

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

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

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

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

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

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

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

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

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

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

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

מה Lighthouse בודק, ואיך ממשיכים מהממצא לתיקון?

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 מול בדיקת משימה

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

אפשר לעבור את בדיקות Lighthouse ובמקביל לקבל ציון נמוך ב-Cloudflare, משום שהם בודקים יכולות שונות. כדי לדעת אם המשתמש הצליח להשלים פעולה, עדיין צריך לבצע אותה ולבדוק את התוצאה.

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

פתחו את העמוד המדויק ב־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.

שאלות נפוצות