איך בודקים אתר לסוכני AI: מעבר לציון של Is Agentic

סוכן AI לא חווה אתר כמו בן אדם.

הוא עשוי לעולם לא לצייר את העמוד. הוא לא בהכרח מריץ JavaScript. הוא יכול לבקש Markdown, לעקוב אחרי sitemap, לבדוק structured data, או להחליט שנתיב קיים רק לפי קוד ה-HTTP שחזר.

אתר יכול להיראות מצוין ב-Chrome, ובאותו זמן להיות עמום, יקר או ממש מטעה עבור agent.

מכאן נולדת בעיית איכות חדשה:

איך בודקים שאתר ציבורי באמת שמיש עבור סוכני AI?

לא “האם ChatGPT מכיר את המותג?”. לא “האם scanner החזיר ציון גבוה?”. ולא “האם הוספנו קובץ llms.txt?”.

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

זו הדיסציפלינה ש-TestShift בונה: Agent-Readiness Quality Engineering. העבודה התחילה מ-audit ציבורי והסתיימה בארכיטקטורת בדיקות דטרמיניסטית — לא באוסף קישוטי SEO.

המימוש הראשון העלה את TestShift מ-76 ל-91. בדיקת Is Agentic האחרונה מדווחת על 97/100. חשוב יותר מהציון: העבודה חשפה באגים בפרוטוקול שבדיקה ויזואלית לעולם לא הייתה מוצאת.

מה באמת אומר Agent-Ready

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

עבור TestShift, החוזה הזה מורכב משש שכבות:

Agent readiness אינו תחליף לנגישות, אבטחה, SEO או איכות API. הוא נוגע בכולם, אבל יש לו failure modes משלו.

בדיקת קורא מסך לא בהכרח תמצא Content-Type שגוי. Visual regression לא יספר שנתיב שלא קיים נראה אמיתי ל-crawler. וכלי SEO עלול לתגמל schema שחושף מידע שהעסק צריך לשמור פרטי.

לכן צריך כאן ארכיטקטורת איכות, לא checklist שהועתק ל-production.

האות החדש: Is Agentic של Vercel על בסיס Ora

Is Agentic הוא scanner ציבורי של Vercel, המבוסס על מנוע ה-audit של Ora. ה-methodology מפריד בין בדיקות Essential ו-Recommended, מוסיף bonus מוגבל, ומגדיר כל report כצילום מצב — לא כהסמכה.

ההבחנה הזו קריטית.

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

הסריקה הראשונה של TestShift קיבלה 76/100. תיקוני production המשכיים העלו את הסריקה מ-26 באוגוסט 2026 ל-97/100. נשארו שני ממצאים:

1. Content without JavaScript — חלקי.
2. Brand-name discoverability — חלקי.

כל ממצא דרש תגובת QA אחרת.

• הראיה על 404 חשפה defect אמיתי והצדיקה שינוי קוד; היא עוברת כעת.
• הראיה על JavaScript דרשה חקירה ושיפור סמנטי ממוקד, לא השחתת markup.
• דירוג המותג תלוי בחלקו באינדוקס חיצוני, ולכן דורש עבודה אמינה לטווח ארוך — לא המצאת מידע עסקי.

זה הלב של הנדסת איכות בכירה:

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

הארכיטקטורה: עמוד אחד, שני ייצוגים סטטיים

TestShift בנוי ב-Astro. כל עמוד נוצר סטטית.

ארכיטקטורת ה-agent readiness שומרת על התכונה הזאת. היא לא מוסיפה runtime rendering לעמודים ולא מבקשת מ-LLM להמיר תוכן בזמן בקשה.

סדר ה-build הוא:

Astro static generation
  -> HTML-to-Markdown sibling generation
  -> Pagefind indexing
  -> Pagefind asset sync
  -> built SEO audit
  -> built agent-readiness audit

עבור כל page route נוצרים שני ייצוגים:

/services/quality-gates/index.html
/services/quality-gates/index.md

הכתובת הקנונית נשארת /services/quality-gates/. דפדפן מקבל HTML. לקוח ששולח במפורש Accept: text/markdown מקבל את קובץ ה-Markdown שנבנה מראש.

ה-Markdown מכיל את ה-canonical URL ואת התוכן המשמעותי מתוך main#main-content. ניווט עיצובי, scripts, styles, buttons, תוכן מוסתר ו-table of contents שמיועד לתצוגה בלבד מוסרים. כותרות, פסקאות, קישורים, תמונות, רשימות, blockquotes, קוד וטבלאות נשמרים.

ב-gate של המהדורה המקורית, ה-build אימת 145 עמודי HTML ו-145 קובצי Markdown תואמים.

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

באג הניתוב שנראה נכון

המימוש הראשון השתמש ב-conditional rewrites וב-headers בתוך vercel.json.

על הנייר הוא נראה הגיוני:

Accept: text/markdown
  -> rewrite /page/ to /page/index.md
  -> set Content-Type: text/markdown

ב-production, Vercel פתר את קובץ ה-HTML הסטטי הקיים לפני שלב ה-rewrite. גוף התגובה היה HTML, אבל ה-header הצהיר Markdown.

זה גרוע יותר מהיעדר תמיכה ב-Markdown. זו הבטחת פרוטוקול שקרית.

התיקון העביר את ה-negotiation ל-Vercel Routing Middleware בשורש הפרויקט, שרץ לפני בדיקת ה-static filesystem. ה-middleware צר בכוונה:

• רק GET ו-HEAD;
• רק root או page routes שמסתיימים ב-/;
• רק media range פעיל של text/markdown;
• לעולם לא RSS, sitemap XML, תמונות OG, assets או file-like routes;
• q=0 פירושו ש-Markdown אינו מקובל;
• בקשות דפדפן ממשיכות כרגיל.

תגובה תקינה כוללת:

Content-Type: text/markdown; charset=utf-8
Vary: Accept, Accept-Encoding

קובצי index.md ישירים מקבלים גם X-Robots-Tag: noindex, כדי שכתובת ה-HTML הקנונית תישאר הכתובת לאינדוקס.

המסקנה פשוטה:

לעולם אל תאמתו content negotiation רק לפי headers. בדקו יחד status, media type וגוף תגובה.

באג ה-404 שהסתתר מאחורי הציון הקודם 91

ה-report של 91/100 אמר שהאתר מחזיר 404 אמיתי, אך חסר גוף Markdown קצר להתאוששות.

עמוד ה-HTML כבר הכיל קישורים מקומיים ל-homepage, לתובנות, ל-llms.txt ול-sitemap. אז למה ה-scanner עדיין ראה תמיכה חלקית?

ה-probe ב-production חשף באג עמוק יותר.

בקשה כמו:

curl -i -H "Accept: text/markdown" \
  https://www.test-shift.com/agent-readiness-does-not-exist/

עברה rewrite אל Markdown sibling שלא קיים. Vercel חזר בצדק ל-HTML 404 ושמר על status 404, אבל header שהוגדר על ה-route הקנוני סימן את גוף ה-HTML כ-text/markdown.

Status אמיתי. Representation שגוי.

התיקון המשלים עושה שלושה דברים:

1. ה-middleware בודק שקובץ ה-Markdown שנבנה מראש קיים לפני rewrite.
2. אם הוא חסר, מוחזר artifact בשם 404.md עם status 404.
3. התגובה מקבלת Content-Type, Vary ו-X-Robots-Tag נכונים, וה-content-type override המסוכן הוסר.

ה-Markdown 404 שנוצר ב-build נותן ל-agent צעדי המשך קצרים:

• homepage;
• אינדקס התובנות;
• מדריך הסוכנים llms.txt;
• XML sitemap.

גם הוא נגזר ממקור ה-404 הגלוי למשתמש, ולא נשמר כעותק שני ומנותק.

כך נראית שגיאה ידידותית לסוכן: כישלון אמיתי ונתיב ברור להתאוששות.

תוכן ללא JavaScript: בודקים את הראיות, לא את התווית

ה-scanner האחרון דיווח על 3,348 תווים ועל H1, אבל עדיין תיאר את מבנה הכותרות של דף הבית כ-flat.

האמירות האלה לא מתיישבות לגמרי.

ה-HTML הגולמי ב-production כבר נבנה סטטית. ה-audit הדטרמיניסטי מצא תוכן משמעותי, H1 יחיד, מספר כותרות H2 ו-H3, וללא דילוג בין רמות. תקציר ה-hero הוא כעת H2 גלוי עם שם המותג; הטיפוגרפיה נשמרת, אך extractors שטחיים מקבלים קשר מיידי של H1 ל-H2. Playwright מאמת גם את ה-H1 ואת H2 ה-hero המקומיים במסמכי האנגלית והעברית הגולמיים.

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

תגובת ה-QA הנכונה היא:

1. לשחזר מול raw HTML, לא מול DOM לאחר hydration;
2. לספור תווים בתוך אזור ה-main הקנוני;
3. לדרוש H1 אחד;
4. לדרוש כותרות משנה שימושיות;
5. לדחות דילוג כמו H1 ישירות ל-H3;
6. לבצע את התיקון הסמנטי הקטן ביותר כשהראיות הגולמיות מצביעות על פער חד-משמעי;
7. לבדוק שוב אחרי deployment ופקיעת cache.

לכן TestShift מתייחס ל-scanners חיצוניים כאל test oracles עם מגבלות ידועות. הם יכולים למצוא סיכונים. הם יכולים גם להיות מיושנים, אטומים או שגויים.

אל תעשו gaming ל-scanner. בנו ראיות חזקות יותר ממנו.

Brand Discoverability אינו תחרות בהמצאת Schema

הממצא האחרון ברמת Recommended הציב את test-shift.com במקום השישי מתוך תשע תוצאות בחיפוש המותג “TestShift”.

חלק מהעבודה שייך ל-repository:

• זהות קנונית אחת: https://www.test-shift.com;
• שמות עקביים: TestShift ו-TestShift by Nir Tal;
• התאמה בין Organization, WebSite, founder ופרופילים ציבוריים;
• canonical ו-alternate URLs מודעי-locale;
• בלי redirect chains שמסתירים את ה-domain הקנוני;
• מאמרים ממקור ראשון שמחברים את TestShift ל-Agent-Readiness Quality Engineering.

חלק מהעבודה אינו שייך לקוד:

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

ה-audit המליץ על NAP חזק יותר. TestShift הוסיף במכוון רק כתובת אמת ברמת המדינה: ישראל. לא הומצאו רחוב, עיר, מיקוד או מספר טלפון בשביל נקודות.

פרטיות ואמת חשובות יותר משלמות של scanner.

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

ארכיטקטורת הבדיקות מאחורי השינוי

הפלט החשוב לא היה llms.txt. הוא היה מערכת ה-regression סביב כל החוזה.

באימות האחרון, ה-suite הדטרמיניסטי דיווח על 23 קובצי Vitest, 140 בדיקות שעברו ו-2 TODOs מפורשים. המספרים יתפתחו. השכבות הן העיקר.

1. Unit Tests להמרת HTML ל-Markdown

בדיקות ה-converter מוכיחות שהייצוג הקריא למכונה שומר:

• canonical URLs;
• כותרות ופסקאות;
• קישורים, רשימות ותמונות;
• blockquotes;
• inline code ו-fenced code;
• טבלאות;
• טקסט באנגלית ובעברית.

הן גם מוכיחות ש-scripts, styles, תוכן מוסתר, presentation chrome ו-table of contents שולחני אינם דולפים ל-artifact.

תיקון ה-404 הוסיף כלל חשוב: recovery navigation יכול לבחור להיכלל בתוכן לסוכנים, בזמן ש-navigation רגיל נשאר בחוץ.

2. בדיקות יצירת Artifacts

ה-generator עובר על פלט ה-build ויוצר Markdown sibling עבור כל index.html וגם עבור 404.html המיוחד.

הבדיקות מוכיחות שהוא:

• יוצר כל sibling צפוי;
• כולל את artifact ה-404;
• מתעלם מקובצי HTML שאינם עמודים;
• נכשל בקול רם ומציג את שם המקור השבור כאשר main#main-content חסר.

Build חלקי ושקט מסוכן יותר מ-build שנכשל. לכן חוסר שלמות הוא כשל.

3. Unit Tests ל-Routing Middleware

ה-suite של ה-middleware מכסה את טבלת החלטות הפרוטוקול:

הבדיקה מאמתת את הגוף ואת קישורי ההתאוששות, לא רק את header ה-rewrite.

4. בדיקות חוזה על פלט ה-Build

pnpm check:agent בודק את הפלט הסטטי הסופי אחרי ה-build.

הוא דוחה:

• עמוד ללא Markdown sibling;
• sibling ריק או כזה שאיבד את הכותרת הראשית;
• נתיבים מייצגים שחסרים באנגלית או בעברית;
• תוכן homepage חלש או סדר כותרות לא תקין;
• recovery לא מלא ב-HTML או ב-Markdown 404;
• הנחיות חיוביות או שליליות חסרות ב-llms.txt;
• שדות Organization פרטיים ומסוכנים;
• זהות לא עקבית בין Organization ל-WebSite;
• rewrites ל-Markdown ברמה הגבוהה של vercel.json;
• content-type overrides שעלולים לסמן HTML 404 כ-Markdown;
• headers חסרים ל-artifacts או Routing Middleware לא מלא.

כך agent readiness הופך ל-release invariant.

5. בדיקות Playwright בדפדפן אמיתי

Playwright בודק את הצד הגלוי לאדם של אותו חוזה:

• עמודי אנגלית ועברית מקבלים locale ו-direction נכונים;
• תוכן homepage גולמי קיים לפני שהתנהגות client-side משנה משהו;
• 404 נשאר HTTP 404 אמיתי;
• קישורי recovery באנגלית ובעברית נכונים;
• 404.md הישיר מכיל את נתיבי ההתאוששות לסוכן;
• מאמרים מייצגים מציגים HTML ו-Markdown תואמים;
• skip link עדיין מכוון ל-main#main-content;
• התנהגות routes ונגישות נשמרת.

Astro Preview אינו מריץ Vercel Routing Middleware או deployment headers. הגבול הזה מפורש. Playwright בודק את האתר הבנוי; probes חיים בודקים את התנהגות הפלטפורמה.

6. בדיקות חוזה ב-Production

ה-gate האחרון בודק endpoints פרוסים באמצעות curl:

# Browser representation
curl -I -H "Accept: text/html" https://www.test-shift.com/

# Negotiated representation
curl -I -H "Accept: text/markdown" https://www.test-shift.com/

# Direct artifact
curl -I https://www.test-shift.com/index.md

# Agent-friendly missing route
curl -i -H "Accept: text/markdown" \
  https://www.test-shift.com/this-route-must-not-exist/

# File-like route must stay XML
curl -I -H "Accept: text/markdown" https://www.test-shift.com/rss.xml

בכל תגובה בודקים status, Content-Type, Vary, מדיניות אינדוקס וסמן בגוף. בדיקת header עם 200 בלבד אינה מספיקה.

Quality Gate מעשי ל-Agent Readiness

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

Gate 1: HTTP אמיתי

• נתיבים חסרים מחזירים 404 או 410;
• HTML מסומן כ-HTML;
• Markdown מסומן כ-Markdown;
• routes עם negotiation משתנים לפי Accept;
• file-like endpoints נשארים ללא negotiation.

Gate 2: תוכן דטרמיניסטי

• תוכן שימושי קיים ב-raw HTML;
• H1 אחד ברור והיררכיית headings תקינה;
• לכל canonical page יש ייצוג שנוצר למכונה;
• ההמרה מודעת לאובדן ונכשלת בצורה סגורה.

Gate 3: Recovery ו-Discovery

• sitemap ו-llms.txt נגישים;
• תגובות 404 נותנות צעדי המשך קצרים;
• הנחיות לסוכן מסבירות מתי הארגון רלוונטי ומתי לא.

Gate 4: זהות בלי בדיה

• canonical domain, Organization, WebSite, founder והתוכן הגלוי מסכימים;
• חלופות locale נשארות מיושרות;
• לא מפרסמים שדות פרטיים או מומצאים עבור ציון.

Gate 5: מציאות הפלטפורמה

• Unit Tests בודקים decision logic;
• built audits בודקים artifacts;
• Playwright בודק דפדפן ו-locale;
• Preview בודק hosting semantics;
• production probes בודקים את החוזה הציבורי;
• scanners חיצוניים מספקים אות בלתי תלוי, לעולם לא סמכות סופית.

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

השינוי האסטרטגי: Agents הם צרכן חדש של הפלטפורמה

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

זה קטן מדי.

Agents הופכים לסוג חדש של צרכן פלטפורמה. יש להם העדפות transport, מגבלות context, צרכי recovery, שאלות זהות ו-failure modes. הממשק יכול להיות HTML, Markdown, API או WebMCP, אבל בעיית האיכות נשארת זהה: האם המערכת חושפת חוזה אמיתי ומבוקר?

TestShift מביאה למרחב הזה את השיטות של ארכיטקטורת בדיקות מודרנית:

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

הציון שימושי. הציון אינו המוצר.

המוצר הוא אמון.

וזה המרחב ש-TestShift מתכוונת להוביל: בדיקה וממשל של הדרך שבה מערכות תוכנה הופכות לשמישות עבור agents — בלי להפוך לפחות אמיתיות עבור בני אדם.

אם צוות הפלטפורמה שלכם מכין אתר ציבורי, developer portal, פלטפורמת בדיקות או מאגר ידע פנימי עבור AI agents, Quality Gates של TestShift יכולים להפוך את היעד לחוזה release שניתן להרצה. צרו קשר עם TestShift כדי לתכנן את ה-audit, בדיקות הפרוטוקול, כיסוי Playwright ואימות ה-production סביב הארכיטקטורה שלכם.

Architecture > Magic. Evidence > Score.