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

מאיפה מתחילים לבדוק אם סוכן AI יכול לפעול באתר?

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

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

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

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

Lighthouse: 2/2 בספטמבר, 3/3 באוקטובר; Cloudflare 20/100

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

בדיקת Accessibility Tree עברה. בדיקות WebMCP ו-llms.txt סומנו N/A, כלומר לא נכללו בציון. אפשר לפתוח את הדוח המלא ואת קובץ המקור.

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

בדיקה חוזרת, 12.10.2026: לפי רישום הבדיקה החדשה, Lighthouse 13.4.1 החזיר 3/3 גם בדף הבית וגם במאמר הזה. בדיקת Accessibility Tree עברה ו-CLS נשאר 0. אחרי שפורסם /llms.txt, הבדיקה שלו הפכה מ-N/A לבדיקה שעברה. שלוש בדיקות WebMCP נותרו N/A. לא בוצע בבדיקה הזו ניסיון לשלוח פנייה בטופס.

המעבר מ-2/2 ל-3/3 הוא שינוי במכנה: בדיקה נוספת נעשתה רלוונטית אחרי פרסום הקובץ. שתי הבדיקות הראשונות נותרו תקינות. אין כאן ראיה שהטופס או יכולת של סוכן AI להשלים משימה השתפרו באוקטובר.

אפשר לפתוח את הדוחות שנשמרו מהבדיקה החוזרת ב-12.10.2026: דף הבית: HTML ו-JSON; המאמר: HTML ו-JSON. הבדיקות הורצו ב-Lighthouse 13.4.1 עם Chrome 154. אלה דוחות של העמודים הציבוריים, לא של ניסיון שליחה בטופס.

בסריקה של Cloudflare Agent Readiness, אותה כתובת קיבלה 20/100, ברמה Basic Web Presence. התוצאה הזאת נרשמה ב-10.9.2026 ולא נמדדה מחדש כחלק מבדיקת Lighthouse באוקטובר.

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

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

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

מה קרה כשהטקסט בטופס היה קצר מדי?

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

הדפדפן דרש לפחות חמישה תווים, לפי minlength="5". הוא ספר גם את הרווחים ואפשר לשלוח. השרת הסיר את הרווחים, נשאר עם שלוש אותיות ודחה את הפנייה.

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

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

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

בדיקת Lighthouse על אותו קוד הציגה 2/2: בדיקת Accessibility Tree עברה ו-CLS היה 0. ארבע בדיקות נוספות סומנו N/A.

אפשר לפתוח את הדוח לפני התיקון ואת קובץ ה-JSON. גם שאר הציונים בדוח נמדדו על העותק המקומי.

איך הטופס תוקן, ומה קרה בבדיקה החוזרת?

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

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

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

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

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

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

איך מודדים הצלחה: שיעור השלמה מאומת

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

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

מה Lighthouse בודק, ומה כדאי לתקן?

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

לפי תיעוד Chrome, הקטגוריה עדיין ניסיונית ודורשת Chrome 150 ומעלה. המספר בדוח מציג כמה בדיקות עברו. הוא לא ציון מתוך 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. הריצו את הבדיקה ושמרו את הדוח.

אם Agentic Browsing לא מופיע, בדקו את גרסאות Chrome ו-Lighthouse. אפשר להריץ את הבדיקה גם דרך שורת הפקודה, ב-CLI, כמו בדוגמה הבאה.

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

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

• מלאו פרטים תקינים ובדקו שהם התקבלו במערכת.
• מלאו פרט שגוי. בדקו אם ברור מה לתקן ואם שאר הפרטים נשארו.
• תקנו ושלחו שוב. בדקו שהתקבלה התוצאה שרציתם.
• נסו שוב אחרי עיכוב או ניתוק. ודאו שלא נוצרה פנייה או הזמנה כפולה.
• בדקו גם שדה בחירה ותאריך, תגובה איטית או ניתוק רשת, והאם ניסיון חוזר משאיר רק תוצאה אחת.
• במבחן שדורש CAPTCHA או אימות אנושי, סמנו את הניסיון BLOCKED ותעדו את החסימה; אל תציגו אותו כאילו הסוכן נכשל במשימה שאפשרה להשלים.
• אם בדקתם פעולה עם כלי WebMCP, בדקו רישום, קלט ותוצאה בעזרת Chrome DevTools for agents והגדירו eval חוזר.

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

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

איך יודעים אם הבעיה באתר או בסוכן?

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

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

ומה הקשר ל-GEO?

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

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

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

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

שאלות נפוצות