במשך שנים דירג PageSpeed Insights ארבעה תחומים: ביצועים, נגישות, שיטות מומלצות ו-SEO. ב-2026 הצטרף בשקט פריט חמישי לאותה שורה: Agentic Browsing. הוא עונה על שאלה שארבע הקטגוריות האחרות מתעלמות ממנה — האם סוכן בינה מלאכותית באמת יכול לעבוד עם הדף הזה?
המדריך הזה עוסק בהפעלה מעשית של הבדיקה באתר שלכם: להריץ אותה, להבין מה כל בדיקה באמת אומרת, ולצאת עם רשימת תיקונים.
מה יהיה לך בסוף
למי זה מיועד: לאנשי SEO, למפתחים ולבעלי אתרים שרוצים לדעת איך הדפים שלהם מתנהגים כשסוכן גולש בהם ולא אדם.
מה יהיה בידיך בסוף: תוצאת Agentic Browsing אמיתית לאתר שלך, קריאה בדיקה-בדיקה של מה עובר, נכשל או לא רלוונטי, ורשימת תיקונים בסדר עדיפויות.
דרישות מקדימות: כתובת נגישה לציבור, כעשר דקות להרצה הראשונה, וגישה לקוד אם אתם מתכננים לתקן באותו יום.
תנאי סיום: אתם יכולים להסביר את הציון השברי בדיקה אחר בדיקה, ולזהות אילו כשלים באמת מונעים מסוכן להשלים משימה בדף שלכם.
מאיפה הגיעה הבדיקה ולמה עכשיו
קטגוריית Agentic Browsing לא הייתה קיימת לפני שנה. ההשקה התקדמה בשלושה שלבים, וכולם מתועדים על ידי Google:
- 7 במאי 2026: Lighthouse 13.3 מוסיף את הקטגוריה לתצורה המוגדרת כברירת מחדל, והיא הופכת לחלק מהרצה סטנדרטית.
- 22 ביוני 2026: הבלוג של Chrome for Developers מכריז עליה במאמר על ערכת כלים להכנת האתר לסוכנים, לצד DevTools לסוכנים והנחיות WebMCP.
- 20 ביולי 2026: Lighthouse 13.4.1 מפעיל את הקטגוריה בנתיב ה-API של PageSpeed Insights ומודיע שהגרסה אמורה להגיע ל-PageSpeed Insights בתוך שבועיים. כלומר ההשקה הציבורית נפלה בתחילת אוגוסט 2026.
כשהרצתי את הבדיקה ב-11 בספטמבר 2026, בתחתית הדוח הופיעה הרצה מדומה עם Lighthouse 13.4.1, ו-Agentic Browsing ישב ממש לצד SEO. כלומר התכונה פעילה, לא רק בערוץ ניסיוני. ובמקביל היא מוצהרת כלא גמורה: תיאור הקטגוריה בדוח אומר זאת במפורש — הקטגוריה עדיין בפיתוח ועשויה להשתנות.
הערה מעשית לפני שמתחילים: PSI מריץ את הקטגוריה עבורכם בצד של Google. אין צורך בגרסת Chrome מסוימת או בניסוי מקור (origin trial) לבדיקות ברמת הדף. דרישות גרסה חלות רק על הרצה מקומית בתוך Chrome DevTools.
הריצו את הבדיקה באתר שלכם
- פתחו את pagespeed.web.dev והדביקו את הכתובת. הריצו קודם לנייד ואחר כך שוב למחשב, כי שתי ההרצות במעבדה מדורגות בנפרד.
- המתינו לסיום נתוני המעבדה. נתוני השדה שלמעלה מגיעים מ-Chrome UX Report ונעלים מהר. הרצת Lighthouse שמתחת אורכת יותר, ושם נמצאות הקטגוריות.
- מצאו את שורת הציונים. תראו ביצועים, נגישות, שיטות מומלצות, SEO, ואחריהם Agentic Browsing כשבר במקום ציון מ-0 עד 100.
- פתחו את הקטגוריה. רשימת הבדיקות מתחלקת לקבוצות Agent Accessibility, WebMCP, ולצברי העובר והלא רלוונטי הרגילים.
- פתחו כל בדיקה שנכשלה. כל שורה נפתחת ומציגה את הכלל, האלמנט או הקובץ שמאחורי הכשל, וזה בדיוק מה שצריך כדי לפתוח כרטיס תיקון.
הקטגוריה החמישית יושבת באותה שורה עם הציונים שצוותי SEO בודקים מדי יום. צולם ב-PageSpeed Insights ב-11 בספטמבר 2026.
בדיקת איכות: ודאו את גרסת Lighthouse בפרטי ההרצה לפני שאתם משווים תוצאות עם עמית. PSI מעדכן את Lighthouse לפי לוח זמנים משלו, והקטגוריה ממשיכה להשתנות בין גרסאות.
אם ההרצה נכשלת: לעיתים PSI מחזיר פסק זמן RPC בדפים כבדים. זה קרה לי באתר גדול באמצע המחקר. נסו שוב, או בדקו את הדף ב-Lighthouse מקומי.
קראו נכון את הציון השברי
ל-Agentic Browsing אין ציון משוקלל מ-0 עד 100, וזה מכוון. התיעוד של Lighthouse מסביר שתקני האינטרנט הסוכני עדיין מתגבשים, ולכן הדגש הוא על אותות מעשיים ולא על דירוג.
החשבון שבאמת חשוב הוא זה:
התצוגה | המשמעות |
|---|---|
3/3 | כל הבדיקות הנמדדות עברו. בדיקות לא רלוונטיות אינן נכללות. |
1/3 | אחת עברה ושתיים נכשלו. המכנה כולל רק בדיקות שעברו או נכשלו. |
0/3 | אף בדיקה נמדדת עוד לא עברה. נפוץ בהרצה ראשונה על דף כבד עם פרסומות. |
בלי שבר | כל הבדיקות לא רלוונטיות או שהקטגוריה לא רצה. בדקו את פרטי ההרצה. |
המלכודת היא לקרוא 1/3 כ״33 אחוז מוכנות לסוכנים״. זה לא אחוז של שום דבר. זה מונה: מתוך שלוש בדיקות שאפשר היה למדוד בדף הזה, אחת עברה, והבדיקות שלא היו רלוונטיות יצאו מהחשבון לגמרי. בדוח שבדקתי רצו שש בדיקות, שלוש לא היו רלוונטיות, והשלוש הנותרות יצרו את 1/3.
הציון גם זז בין הרצות באותו דף. Lighthouse מציין שלוש סיבות: רישום כלים דינמי (כלי WebMCP שנרשמו מ-JavaScript עשויים להיתפס או להיפספס בהתאם לתזמון), שינויי DOM שמעצבים מחדש את עץ הנגישות, ותזוזות פריסה מפרסומות, מתמונות בלי מידות או מתוכן מוזרק. אם המספר שלכם מתנדנד, זו כנראה הסיבה.
עברו על שש הבדיקות
הגרסה הנוכחית של PSI מריצה שש בדיקות. בדיקה נוספת בדרך: בענף הפיתוח של Lighthouse כבר נוספה בדיקת ai-catalog.json (Agent Resource Discovery) תחת קבוצה חדשה בשם Agent Discoverability, כך שכדאי להתייחס לרשימה הזו ככזו שתלויה בגרסה.
הבדיקה | מה היא בודקת | מה המשמעות של ״לא רלוונטי״ |
|---|---|---|
עץ הנגישות אינו תקין | תת-קבוצה של כללי נגישות במיקוד סוכנים: שמות ותוויות פרוגרמטיים, מבנה ARIA תקין, ואלמנטים שנשארים אינטראקטיביים גם כשהם מוסתרים מהעץ | אף פעם; זו נמדדת תמיד |
llms.txt אינו עומד בהמלצות | שהקובץ | הקובץ החזיר 404. היעדר llms.txt נחשב רשות, לא כשל |
תזוזת פריסה מצטברת | יציבות חזותית, כדי שסוכנים שפועלים לפי מיקום אלמנטים לא ילחצו על הדבר הלא נכון באמצע תזוזה | אף פעם; זו נמדדת תמיד |
כלי WebMCP רשומים | האם הדף רושם כלי WebMCP דרך ה-API ההצהרתי או הציוויי | לא זוהו כלי WebMCP |
כיסוי טפסי WebMCP | טפסים הצהרתיים שחסרים בהם סימוני כלים | כמו למעלה |
תוקף סכימות WebMCP | האם הכלים הרשומים מפרסמים סכימות קלט ופליטה תקינות | כמו למעלה |
תצוגה פרושה של הקטגוריה: שני כשלים, מעבר אחד ושלוש בדיקות לא רלוונטיות. רשימת הכשלים היא רשימת המשימות הקצרה ביותר.
הצגת שלוש בדיקות WebMCP כ״לא רלוונטי״ היא מצב רגיל ב-2026. WebMCP הוא תקן מוצע בשלב ניסוי מקור ותצוגה מוקדמת, עם שני ממשקים: האחד הצהרתי שמסמן טפסי HTML רגילים, והשני ציוויי שרושם כלים מ-JavaScript. רוב האתרים עדיין לא מיישמים אף אחד מהם, ולכן רוב הדוחות מציגים שם שלושה עיגולים אפורים. אפור אינו אדום. אל תתייחסו לזה ככשל.
תקנו את מה שהבדיקה מסמנת
ארבעה נושאי תיקון מכסים את שש הבדיקות. שלוש שורות WebMCP דורשות תשומת לב רק אם אתם באמת מספקים כלים לסוכנים.
הפכו את עץ הנגישות לקריא לסוכנים
סוכנים נשענים על עץ הנגישות כמפה הראשית של הדף. הוא מפרט תפקידים, שמות ומצבים. כפתור בלי שם נגיש הוא מבוי סתום עבורם, וגם עבור משתמשי קוראי מסך.
מה לעשות: עברו על הכללים שנכשלו בבדיקה הפרושה. החשודים הרגילים: כפתורים עם אייקון בלבד, שדות טופס בלי תווית, קישורים שהטקסט שלהם הוא רק ״לחצו כאן״, שילובי תפקידי ARIA לא תקינים, ומזהים כפולים ש-ARIA מפנה אליהם. העדיפו HTML סמנטי, הוסיפו מאפיין for לתוויות, ותנו לווידג׳טים מותאמים תפקיד מפורש ו-tabindex כשאביזר מקורי אינו אפשרי.
התוצאה הצפויה: הבדיקה הופכת לעוברת, ולרוב גם ציון הנגישות הרגיל משתפר במקביל, מפני שהגרסה של Agentic Browsing היא תת-קבוצה ממוקדת של אותן בדיקות.
אם נתקעתם: כשהרשימה מגיעה למאות אלמנטים, אל תרדפו אחריהם אחד-אחד. תקנו את הרכיב המשותף, כמו כפתור האייקון בכותרת, והריצו שוב. רכיב אחד לעיתים קרובות מנקה עשרות שורות.
פרסמו llms.txt שעובר את בדיקת התבנית
כאן יש מלכודת שתופסת דווקא את הקפדנים. הבדיקה לא מסתפקת בכך ש-/llms.txt קיים. היא בודקת את תוכן הקובץ, וקובץ שמפרט כתובות חשופות נכשל, כי הבדיקה מחפשת קישורים בפורמט Markdown.
מה לעשות: צרו /llms.txt בשורש הדומיין, עם כותרת H1 וקישורי Markdown אמיתיים:
# שם החברה
תיאור קצר של מה האתר מכסה ואיך כדאי להשתמש בו.
## עמודים עיקריים
- [סקירת המוצר](https://example.com/product)
- [מחירים](https://example.com/pricing)
- [תיעוד](https://example.com/docs)התוצאה הצפויה: הבדיקה הופכת לירוקה. לעומת זאת 404 מוצג כלא רלוונטי, וזה מקובל היום. תגובה מסדרת 500 או כשל בשליפה הם כשל אמיתי שדורש תיקון בשרת.
בדיקת איכות: שלופו את /llms.txt שלכם בטרמינל וספרו את הקישורים. אם הם נראים כמו https://example.com/pricing בלי סוגריים מרובעים, הבדיקה תיכשל גם אם הקובץ פורסם ובני אדם יכולים לקרוא אותו.
הסתייגות כנה אחת: חיפוש Google לא משתמש ב-llms.txt. המדריך של Google לאופטימיזציה ל-AI אומר במפורש שהקובץ ״לא יזיק ולא יועיל לנראות או לדירוג של האתר שלך בחיפוש Google, כי חיפוש Google מתעלם מהם״. כתבו אותו עבור כלים סוכניים שקוראים את המוסכמה הזו, לא בשביל דירוג.
ייצבו את הפריסה כדי שסוכנים יוכלו לכוון
תזוזת פריסה חשובה יותר מבעבר. סוכן שמאתר כפתור ואז לוחץ על הקואורדינטות שלו יפספס אם פרסומת, באנר או תמונה שנטענת באיחור דוחפים את הכפתור 200 פיקסלים למטה בין שני הרגעים האלה.
מה לעשות: הגדירו רוחב וגובה מפורשים (או יחס גובה-רוחב) לתמונות ולתוכן מוטמע, הקצו מקום קבוע לחריצי פרסום ולבאנרים של הסכמה, הימנעו מהוספת תוכן מעל תוכן קיים אחרי הטעינה, והניעו באנימציות עם transform במקום מאפיינים שמפעילים חישוב מחדש של הפריסה.
התוצאה הצפויה: תזוזת פריסה מצטברת נמוכה מ-0.1 בהרצת המעבדה, אותו סף שמשמש את Core Web Vitals.
בדיקת איכות: התובנה על גורמי תזוזת הפריסה באזור הביצועים של הדוח מציינת את האלמנטים המדויקים. התחילו משם במקום לנחש.
החליטו לגבי WebMCP מאוחר יותר
שלוש בדיקות WebMCP נמדדות רק אם האתר רושם כלים. אם יש לכם תהליך הזמנה, קופה, טופס תמיכה או כל משימה מובנית שסוכן יכול להשלים, WebMCP שווה אב-טיפוס: הוא אומר לסוכן בדיוק איזה כלי להפעיל במקום לגרום לו לנחש מתוך ה-DOM. Chrome מספק את התכונה מאחורי ניסוי מקור ודגל בדיקה מקומי, כך שזו אפשרות אמיתית ולא ניסוי מחשבתי.
אם אין לכם משימה ששווה אוטומציה, הניחו ל-WebMCP. אין שום בעיה בשלושה עיגולים אפורים. הדבר היחיד שאסור לעשות הוא לרשום כלי דקורטיבי רק כדי שהשבר ייראה טוב יותר. הקטגוריה היא אות מוכנות, וסימון מלאכותי מרוקן אותה ממשמעות.
אמתו את התיקון
הריצו שוב את אותה כתובת ב-PSI והשוו שלושה דברים ולא אחד: את השבר, את מצב הבדיקות הנקודתי ואת סוג המכשיר. תיקון יכול להזיז את השבר בלי לפתור את מה שעניין אתכם, ונייד ומחשב מפיקים תוצאות מעבדה נפרדות.
כדי לזרז איטרציות, הריצו Lighthouse מקומית במקום לחכות ל-PSI. הקטגוריה נכללת מ-Lighthouse 13.3 ואילך, כך שהתקנה מקומית תכלול אותה. אם אתם רוצים את גרסת לוח ה-DevTools, התיעוד של Google מציין שבדיקת הקטגוריה דורשת Chrome 150 ואילך, ובדיקות WebMCP דורשות גם רישום לניסוי המקור.
נהלו תיעוד קצר של לפני ואחרי. שורה עם תאריך כמו ״2026-09-11: נייד 1/3, עץ הנגישות ו-llms.txt נכשלו״ מספיקה. היא תגיד לכם אם נסיגה מאוחרת היא אמיתית או רק תנודה בין הרצות.
מה הבדיקה הזו אינה
שלושה דברים שהיא לא עושה, כי הבלבול סביבם נפוץ:
- היא לא גורם דירוג. ההכרזה של Chrome מתארת את הקטגוריה כאינפורמטיבית וככזו שלא נכללת במדידה תחרותית. הדירוג בחיפוש Google אינו מושפע מהשבר שלכם ב-Agentic Browsing.
- היא לא ציון נראות ב-AI. היא מודדת אם סוכן יכול להפעיל את הדף שלכם, ואינה אומרת דבר על כך ש-ChatGPT או Perplexity מצטטים אתכם בתשובה.
- היא לא פסק דין עובר/נכשל על האתר. שבר נמוך בדף שיווקי פשוט אומר בדרך כלל שהיה מעט מה למדוד, ולא שסוכנים חסומים.
העדשה שכדאי לאמץ: הקטגוריה בודקת אם האתר מחזיק מעמד כשהמבקר אינו אדם. כל מה שהיא מתגמלת עליו שווה עשייה בכל מקרה: HTML סמנטי, פריסה יציבה, פקדים מתויגים. גם המדריך של Google לאתרים ידידותיים לסוכנים נחתם באותה נקודה — מה שהופך אתר למוכן לסוכנים הופך אותו לטוב יותר גם לבני אדם.
שלבו אותה בשגרת הבדיקה
מוכנות לסוכנים היא מתחום התחומים שבהם הפלטפורמה זזה מהר מהצ׳קליסט. שתי הרגלים ישמרו אתכם מעודכנים בלי להפוך את זה לפרויקט:
- הריצו את הבדיקה מחדש אחרי כל שינוי בתבנית, בניווט, בטופס או בתהליך התשלום. אלה השינויים שמזיזים את עץ הנגישות ואת יציבות הפריסה.
- עקבו אחרי השבר לפי תבנית, לא לפי כתובת. עשרה עמודי מוצר עם אותה תוצאה הם בעיית תבנית, ותיקון אחד פותר את כולם.
הבדיקה של PSI צרה במכוון: שש בדיקות, דף אחד בכל פעם. אם אתם רוצים את התמונה הרחבה יותר, כולל כללי robots, כרטיסי שרת MCP, גילוי OAuth ואותות מסחר סוכני, Auspia מפעילה בדיקת Agent Readiness חינמית שסורקת כתובת מול תקני הפרוטוקול האלה ומציגה טבלת השוואה.
שאלות נפוצות
האם ציון Agentic Browsing משפיע על הדירוג ב-Google? לא. Google מתארת את הקטגוריה כאינפורמטיבית, והיא אינה חלק ממערכות הדירוג של החיפוש. התייחסו אליה כבדיקת מוכנות לסוכנים, לא כציון SEO.
למה השבר שלי השתנה בין שתי הרצות באותו דף? רישום כלים דינמי, שינויי DOM שמשנים את עץ הנגישות ותזוזות פריסה מאוחרות יוצרים שונות בין הרצות. בדקו שוב והשוו את רשימת הבדיקות, לא רק את השבר.
למה כל שלוש בדיקות WebMCP מוצגות כלא רלוונטיות? כי הדף שלכם לא רושם כלי WebMCP. זה המצב הצפוי ברוב האתרים ב-2026 וזה לא כשל.
האם היעדר llms.txt הוא בעיה? לצורך הבדיקה הזו, לא. תגובת 404 נחשבת ללא רלוונטית. אבל קובץ שקיים אך פגום נכשל, ואם כבר מפרסמים — פרסמו נכון.
אפשר להריץ את זה ב-CI? כן, ברגע שהקטגוריה נמצאת בגרסת ה-Lighthouse שלכם. הבדיקות דטרמיניסטיות בתכנון, וזה מה שהופך אותן למתאימות לבדיקות בצינור. קחו בחשבון שחלקי WebMCP תלויים בתמיכת הדפדפן ובהרשמה לניסוי המקור, ולכן בסביבות CI רבות הן יוצגו כלא רלוונטיות.
האם אני צריך Chrome 150 כדי להשתמש בזה בכלל? לא. PageSpeed Insights מריץ את זה בצד השרת. דרישת Chrome 150 חלה על הרצת הקטגוריה מקומית ב-DevTools.
הכותבת: Alice Monroe, אנליטיקאית כלים ל-SEO עם AI ב-Auspia, מכסה יותר מ-150 כלים. כותבת על SEO וכלי חיפוש מבוססי AI, על אילו בדיקות שוות את הזמן שלכם ואיך לשלב אותן בשגרת העבודה.
