כתבו כמה מילים על הבקשה.
``` בקוד האפליקציה, הסירו את מצב השגיאה אחרי תיקון והחזירו מיקוד לפי הצורך. הדוגמה מציגה את מצב השגיאה בלבד. **מה עדיין צריך לבדוק:** האם המשתמש מבין איך לתקן את הטקסט, והאם הטופס שומר את הפרטים שכבר מילא. הזינו קלט שגוי ובדקו שאפשר לתקן אותו ולהמשיך. ### 2. CLS: לשמור שהפעולה תישאר במקום CLS מודד תזוזות בלתי צפויות בפריסה. תמונה ללא מקום שמור או באנר שנטען באיחור יכולים להזיז את הכפתור בזמן הפעולה. הגדירו מידות לתמונות או `aspect-ratio`, ושמרו מקום לרכיבים שנטענים מאוחר. אלה [תיקונים מקובלים ל־CLS](https://web.dev/articles/optimize-cls). **מה עדיין צריך לבדוק:** האם הכפתורים והשדות נשארים במקומם גם אחרי בחירת מסלול, טעינת מחיר או הופעת שגיאה. הפעילו את המצבים האלה בנפרד. ### 3. llms.txt: להבחין בין חסר, שגוי ולא רלוונטי הקובץ אופציונלי. [תיעוד Chrome](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) מסביר ש־404 מסומן N/A, בעוד כשל שרת מסומן כבעיה. בקוד [גרסה 13.4.1](https://github.com/GoogleChrome/lighthouse/blob/v13.4.1/core/audits/agentic/llms-txt.js), קובץ שהוחזר נבדק גם לכותרת H1, קישור Markdown ואורך של לפחות 50 תווים. דוגמת מבנה בסיסי, אם בחרתם לתחזק קובץ כזה ``` # Example company Product documentation and support for customers. ## Documentation - [Getting started](https://example.com/docs): Setup instructions. ``` אם החלטתם לספק את הקובץ, בדקו את תגובת השרת ואת תוכנו. אל תיצרו אותו רק כדי להפוך N/A לסימון ירוק. **מה עדיין צריך לבדוק:** האם הסוכן שבו אתם משתמשים קרא את הקובץ, נעזר בו והצליח לבצע את הפעולה. קובץ תקין לבדו לא עונה על השאלות האלה. ### 4. WebMCP: רישום כלים, כיסוי טפסים ותקינות סכמה WebMCP מאפשר לחשוף פעולה מובנית לסוכן תומך. זו אפשרות שימושית כשפעולה כמו חיפוש זמינות יכולה לקבל קלט מוגדר ולהחזיר תוצאה ברורה. | בדיקה | מה לבדוק ולתקן | מה עדיין דורש הרצה | | --- | --- | --- | | רישום כלים | שהכלי נרשם בזמן ושמו ותיאורו מסבירים את הפעולה | שהצרכן התומך מזהה ובוחר את הכלי הנכון | | כיסוי טפסים | שהטופס המיועד חשוף נכון במימוש ההצהרתי | שהקלט ממופה לשדות העסקיים הנכונים | | תקינות סכמה | שסוגי הקלט והשדות הנדרשים תואמים את חוזה הפעולה | שקלט שגוי מקבל הסבר ותוצאה תקינה אכן נשמרת | בתיעוד הנוכחי רישום ב־JavaScript נעשה דרך `document.modelContext.registerTool`. בדקו תמיכה לפני השימוש, ופעלו לפי [הממשק העדכני](https://developer.chrome.com/docs/ai/webmcp/imperative-api). למימוש דרך HTML, ראו את [הממשק ההצהרתי](https://developer.chrome.com/docs/ai/webmcp/declarative-api). אל תוסיפו שמות כלים לטפסים בלי להגדיר מה הפעולה עושה. בדיקות WebMCP דורשות את תנאי הניסוי המתאימים. בגרסה שנבדקה כאן הן בעלות משקל אפס ביחס; במופע המקומי הן סומנו N/A. **מה עדיין צריך לבדוק:** האם הפעולה מותרת למשתמש, האם התוצאה התקבלה במערכת היעד והאם ניסיון חוזר יוצר כפילות. ## Agent Readiness מול Agentic Browsing מול בדיקת משימה כדי לבחור את הבדיקה הבאה, הייתי מתחיל במה שעדיין לא ידוע: האם האתר נגיש לסוכן, האם הוא מפרסם יכולת שהסוכן צריך, או האם המשימה הושלמה בפועל. לכל שאלה מתאימה בדיקה אחרת. | החלטה או בדיקה | Lighthouse Agentic Browsing | Cloudflare Agent Readiness | בדיקת משימה | | --- | --- | --- | --- | | יחידת הבדיקה | דף במצב ההרצה | כתובת ומשאבי גילוי באתר | מסלול ותוצאה שהוגדרו מראש | | מה מחפשים | תקינות מבנה, יציבות ושילוב WebMCP | תמיכה במנגנוני גילוי ופרוטוקולים | האם המשתמש השיג את מטרתו | | עץ נגישות ו־CLS | בדיקות ישירות בדוח | אינם המדדים שמופיעים בסיכום הסריקה | בוחנים השפעה בזמן ביצוע הפעולה | | robots.txt ומפת אתר | אינם בדיקות של קטגוריית Agentic | בדיקות גילוי | בודקים רק אם הם קשורים למשימה | | Markdown | בדיקת llms.txt אינה בודקת אם השרת מחזיר Markdown לפי בקשה | בודק תגובה ל־Accept: text/markdown | בודקים תוכן ופלט שהמשימה צריכה | | WebMCP | בדיקות רישום, כיסוי וסכמה בתנאים המתאימים | בדיקת גילוי יכולת | מפעילים את הכלי באמצעות סוכן שתומך בו ובודקים את התוצאה | | שגיאה וניסיון חוזר | סריקת טעינה אינה מריצה את מסלול הטופס | סריקת התקנים אינה משלימה פנייה | מתקנים קלט ובודקים קבלה וכפילויות | | תוצאת הבדיקה מ-10.9.2026 | 2/2 בדף הבית החי | 20/100 בסריקה החיה | תקלה מקומית תוקנה; פנייה אחת התקבלה | | תנאי סגירה | הממצא הטכני נפתר | היכולת הרצויה זמינה וניתנת לגילוי | הרשומה או הפלט נכונים במערכת היעד | אפשר לעבור את בדיקות Lighthouse ובמקביל לקבל ציון נמוך ב-Cloudflare, משום שהם בודקים יכולות שונות. כדי לדעת אם המשתמש הצליח להשלים פעולה, עדיין צריך לבצע אותה ולבדוק את התוצאה. ## איך מריצים בדיקה שאפשר לחזור אליה? פתחו את העמוד המדויק ב־Chrome, היכנסו ל־DevTools ובחרו Lighthouse. סמנו Agentic Browsing, הריצו ושמרו את הדוח. אם הקטגוריה אינה מופיעה, בדקו את גרסת Chrome ואת גרסת Lighthouse. אפשר להשתמש גם ב־CLI, כפי שנעשה כאן. הפקת דוח JSON ו־HTML — החליפו את הכתובת בעמוד שלכם ``` 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](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) מציינת שאין צורך בקבצים מיוחדים עבור תכונות ה־AI שלה, ושהיא מתעלמת מ־llms.txt. מעבר audit אינו הבטחה לאזכור או לדירוג. הסדר שאני ממליץ עליו פשוט: בחרו פעולה חשובה, תקנו את החסמים בה, ורק אז החליטו אם WebMCP מוסיף ערך למסלול. קחו את [תבנית הבדיקה](https://nirlevi.com/blog/agentic-browsing/task-checklist.md) וסיימו עם ממצא שאפשר להעביר לפיתוח: קלט, תקלה, תיקון ותנאי קבלה. למדידת תשובות עצמן, השתמשו ב[מדריך לנראות ב־AI](https://nirlevi.com/blog/measure-ai-visibility/). ## שאלות נפוצות ### איך בודקים שהסוכן באמת סיים משימה? בודקים את התוצאה במערכת היעד: הזמנת הבדיקה, הפנייה או הקובץ, כולל התוכן והכמות. אחר כך מוודאים שהסוכן קיבל אישור שמתאים למה שנוצר. צילום של לחיצה או הודעת הצלחה אינו תחליף לרשומה. ### איך אותו אתר מקבל 2/2 וגם 20/100? הכלים בודקים דברים שונים. ב־Nirlevi.com, Lighthouse העביר את עץ הנגישות ואת יציבות הפריסה. Cloudflare בדק גם גילוי משאבים, פורמט תוכן ופרוטוקולים שלא הוטמעו. אין המרה תקפה בין שני המספרים. ### האם סוכן חייב WebMCP כדי להשתמש באתר? לא. סוכן שיכול להפעיל דפדפן יכול להשתמש גם בשדות, בכפתורים ובקישורים רגילים. WebMCP מוסיף דרך להפעיל פעולות מוגדרות עבור סוכנים שתומכים בו. הייתי שוקל אותו כשיש פעולה ברורה שאפשר לבדוק אם הממשק הזה מקל על ביצועה. ### האם גם אתר תוכן צריך בדיקת משימה? כן, אם הקורא צריך לבצע פעולה: למצוא מסמך, להוריד קובץ או לאתר מידע מסוים. באתר קריאה בלבד, הגדירו משימת איתור והבנה. אין צורך להמציא תהליך רכישה או API כדי להצדיק ציון. ### איך בודקים מסלול שדורש התחברות או תשלום? משתמשים בחשבון בדיקה ובהרשאות שהוגדרו מראש, ובתשלום בסביבת בדיקות. מתעדים איפה נדרשת מעורבות אדם. CAPTCHA או שלב אישור אינם תקלה רק משום שהסוכן צריך לעצור ולהעביר שליטה. ### האם צריך לתקן כל כישלון ב־Agent Readiness? לא. התחילו בדרישה של המשתמש וביכולות שהאתר באמת מציע. קטלוג API מיותר באתר שאין לו API ציבורי. מדיניות שימוש בתוכן היא החלטת בעל האתר, ולא טקסט שמעתיקים רק כדי לקבל ציון. ### מתי צריך להריץ את הבדיקה מחדש? אחרי שינוי בטופס, בתפריט, באימות נתונים, בבאנר הסכמה או ברכיב שמשנה את הפריסה. הריצו את אותו תרחיש עם אותם תנאי קבלה. עדכוני דפדפן וסוכן מצדיקים בדיקה נוספת של מסלולים חשובים. ### מי אחראי לטפל בממצאים? המוצר או בעל האתר מגדירים תוצאה תקינה; הפיתוח מתקן התנהגות ואימות; ה־QA בודק הצלחה והתאוששות. צוות SEO עוזר לבחור מסלולים שמתחברים לביקוש. לכל ממצא צריך להיות אחראי ותנאי סגירה ברור. ## מקורות והמשך קריאה - [Chrome: Agentic Browsing scoring](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) - [Chrome: llms.txt audit](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) - [Google Search: AI optimisation guidance](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) - [Chrome: WebMCP imperative API](https://developer.chrome.com/docs/ai/webmcp/imperative-api) - [Chrome: WebMCP declarative API](https://developer.chrome.com/docs/ai/webmcp/declarative-api) - [Cloudflare: Agent Readiness](https://blog.cloudflare.com/agent-readiness/) - [Chrome: Run Lighthouse and export reports](https://developer.chrome.com/docs/lighthouse/overview) - [web.dev: Optimise Cumulative Layout Shift](https://web.dev/articles/optimize-cls) - [MDN: HTML label element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/label) - [Lighthouse 13.4.1: accessibility tree implementation](https://github.com/GoogleChrome/lighthouse/blob/v13.4.1/core/audits/agentic/agent-accessibility-tree.js) - [Lighthouse 13.4.1: llms.txt implementation](https://github.com/GoogleChrome/lighthouse/blob/v13.4.1/core/audits/agentic/llms-txt.js) - [MDN: minlength constraint](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/minlength) - [Cloudflare: Nirlevi.com scan (10 September capture in article)](https://isitagentready.com/nirlevi.com) [לתכנון בדיקת משימה באתר שלכם](https://nirlevi.com/services/technical-seo/#agent-task-audit)