בדקתי אם סוכני AI יכולים לקרוא אתרים שנבנו ב-Lovable, Base44, Bolt ו-v0. הנה מה שמצאתי

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

בדקתי את זה על ידי בניית אותו עמוד בדיוק ב-Lovable, Base44, Bolt, v0 ובקובץ HTML סטטי כביקורת. אחר כך שאלתי את ChatGPT ואת Claude שלוש שאלות זהות על כל עמוד.

התוצאה הייתה חד-משמעית.

• כל המימושים חשפו מספיק מידע ב-title ובתיאור המטא לצורך זיהוי נושא
• שליפה אמינה של תוכן הגוף תלויה בשאלה אם העמוד מחזיר HTML משמעותי בתגובה הראשונית
• חלק מהפלטפורמות הצליחו לייצר פלט ידידותי לשליפה, חלקן לא
• אחת שיפרה את הנגישות דרך hack שעבד לעמוד הבדיקה אבל לא מתרחב בצורה נקייה
• זו בדיקת שליפה מבוקרת על פלט שפורסם, לא מחקר דירוגים או טענה הנדסית לגבי המנגנון הפנימי של ChatGPT או Claude

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

תקציר מנהלים

• בניתי את אותו עמוד ב-Lovable, Base44, Bolt, v0 ובקובץ HTML סטטי כביקורת
• העמוד הכיל עובדות בדויות שלא קיימות באף מקום אחר באינטרנט
• בדקתי אם ChatGPT ו-Claude מצליחים לשלוף:
  • את נושא העמוד (מה-title ותיאור המטא)
  • מספר מתוך טבלה בגוף העמוד
  • נתון סטטיסטי ספציפי שקבור בתוך פסקה
• כל המימושים חשפו מספיק ב-title ובתיאור המטא לצורך זיהוי נושא
• שליפה אמינה של תוכן הגוף הלכה יד ביד עם HTML משמעותי בתגובה הראשונית
• ההבדל המשמעותי ביותר לא היה רק מי עבר בפעם הראשונה, אלא מי יכול לייצר פלט ידידותי לשליפה כשמבקשים ממנו

מה הבדיקה הזו בודקת

הבדיקה עונה על כמה שאלות מעשיות שבעלי אתרים באמת שואלים:

• האם סוכני AI עדיין מבינים על מה העמוד שלי, גם אם הוא מסתמך בכבדות על client-side rendering?
• האם סיכום נכון אומר שהסוכן באמת יכול לקרוא את תוכן הגוף?
• אילו פלטפורמות מסוגלות לייצר פלט ידידותי לשליפה כשמבקשים מהן?
• אילו פלטפורמות משאירות אותך תלוי בפתרונות עוקפים?
• אם אני תקוע על פלטפורמה עם שליפת גוף חלשה, האם ה-title ותיאור המטא עדיין עוזרים?

עיצוב הבדיקה

יצרתי את אותו עמוד בחמישה מימושים: קובץ HTML סטטי כביקורת, ועוד גרסאות שנבנו ב-Lovable, Base44, Bolt ו-v0.

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

שאלתי את ChatGPT ואת Claude שלוש שאלות זהות בצ’אטים חדשים.

השאלות ששימשו לבדיקה

1. על מה העמוד הזה? תשובה צפויה: מדריך שדה בדוי על ה-Veloran Crested Ibex

2. לפי טבלת סקר האוכלוסין בעמוד הזה, מה היה הספירה המאושרת ב-2023? תשובה צפויה: 288

3. בעמוד הזה, איזה מתאם מצאה Torvik בין גובה מגדלי האבנים להצלחת ההזדווגות? אנא כללו את המספרים המדויקים. תשובה צפויה: r=0.72, n=84

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

היקף

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

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

מה כל פלטפורמה ייצרה

Title ותיאור מטא היו קריאים בכל מקום. תוכן הגוף לא.

למה ההבדל הזה חשוב

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

מה הסוכנים הצליחו לשלוף

1. Title ותיאור מטא (זיהוי נושא)

כל מימוש חשף title tag ותיאור מטא שהסוכנים יכלו לקרוא. זה החלק הקל. גם אפליקציות CSR מזריקות את אלה לתוך שלד ה-HTML הסטטי לפני שה-JavaScript רץ.

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

2. שליפת טבלה מגוף העמוד

השאלה השנייה כוונה לתוכן מובנה בגוף העמוד. התשובה הנכונה הייתה 288.

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

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

אותה שאלה על גרסת ה-Astro של Bolt. חמש שניות:

3. שליפת עובדה ברמת פסקה

השאלה השלישית כוונה לנתון סטטיסטי ספציפי שקבור בתוך פסקה. התשובה הנכונה הייתה r=0.72, n=84.

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

שוב, לפני הפתרון העוקף של Lovable. ChatGPT חיפש בעמוד של Lovable את “Torvik”, “tower”, “mating” ו-”stone”. אפס תוצאות:

על עמוד ה-Astro של Bolt, הוא ציטט את השורה המדויקת:

מה קרה כשביקשתי מהפלטפורמות לתקן

יש אקוסיסטם שלם של פתרונות prerendering ו-static generation. זה לא מה שהבדיקה הזו בודקת. הנקודה כאן צרה יותר: מה הפלטפורמות עצמן הצליחו לייצר כשביקשתי מהן להנגיש את התוכן בלי להסתמך על JavaScript? שם הופיעו ההבדלים הגדולים ביותר.

Bolt: עבר (נבנה מחדש ב-Astro)

• כתובת בדיקה: csr-test.bolt.host
• Stack: React + Vite (התחלתי), אחר כך Astro
• פלט ברירת מחדל: שלד CSR. שליפת גוף נכשלה.
• כשביקשתי SSR: בנה מחדש את כל הפרויקט ב-Astro. הפלט השתנה מ-SPA מבוסס JavaScript לאתר סטטי עם כל התוכן אפוי ב-HTML. שני הסוכנים עברו את כל שלוש השאלות אחרי הבנייה מחדש. זה שינוי ארכיטקטורי אמיתי. גילוי נאות: Astro SSG על Cloudflare Pages זה אותו stack שאני משתמש בו לאתר הזה.

Lovable: עבר (פתרון עוקף)

• כתובת בדיקה: csr-test.lovable.app
• Stack: React + Vite
• פלט ברירת מחדל: שלד CSR. שליפת גוף נכשלה.
• כשביקשתי SSR: הזריקה HTML סטטי לתוך שלד ה-<div id="root"> עם class בשם noscript-header. ChatGPT מצא את המידע אחרי השינוי, אבל עדיין זיהה את העמוד כ-”loading as a client-rendered app” ולקח לו יותר מ-60 שניות לחלץ את התשובה, לעומת 5 שניות בגרסת ה-Astro של Bolt. זה פתרון עוקף מקודד ידנית, לא שינוי ארכיטקטורת רינדור. זה לא מתרחב לנתיבים דינמיים, תוכן מבוסס API, או אתרים עם יותר מקומץ עמודים סטטיים.

Base44: נכשל (SSR לא נתמך)

• כתובת בדיקה: csr-test.base44.app
• Stack: React 18 + Vite
• פלט ברירת מחדל: שלד CSR. שליפת גוף נכשלה.
• כשביקשתי SSR: אמר לי ישירות שזה לא אפשרי. “Base44 apps are React SPAs. The platform doesn’t support SSR. There’s no way to add server-side rendering without switching to a different framework, which isn’t supported here.”

v0: עבר (SSR כברירת מחדל)

• כתובת בדיקה: v0-csr-test.vercel.app
• Stack: Next.js 16 + React 19
• פלט ברירת מחדל: SSR. תוכן נוכח בתגובת ה-HTML הראשונית.
• לא נדרש תיקון. שני הסוכנים עברו את כל שלוש השאלות מהניסיון הראשון.

איך נראה ההבדל ב-HTML

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

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

<body>
  <div id="root"></div>
</body>

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

<body>
  <h1>The Veloran Crested Ibex</h1>
  <p>...</p>
  <table>
    <tr><td>2023</td><td>288</td></tr>
  </table>
</body>

ההבדל הזה הוא המרכז המכני של כל המאמר.

מה הבדיקה הזו מראה

הבדיקה תומכת בארבע מסקנות מעשיות.

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

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

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

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

אני מבין למה הפלטפורמות האלה עוד לא טיפלו בזה. הן חברות בצמיחה שמתמקדות בשילוח פיצ’רים ורכישת משתמשים. SSR זו השקעת בגרות, לא מנוף צמיחה. הפשרה הזו הגיונית בשלב שלהן. אבל בשלב מסוים הן יצטרכו לטפל בזה, אחרת המשתמשים שלהן ימשיכו להיתקל בחומה הזו. התמודדתי עם זה מכלי ראשון ב-Wix, שם השקענו אלפי שעות הנדסה בבנייה ותחזוקה של תשתית SSR למיליוני אתרים. זה יקר. זה מוסיף latency. זה נשבר בדרכים שלא מצפים להן. אבל אין קיצורי דרך: אם התוכן לא ב-HTML, הזחלנים לא רואים אותו.

עם זאת, האחריות כאן משותפת. פלטפורמות הבנייה צריכות לייצר פלט שניתן לשליפה, אבל גם חברות ה-AI צריכות להשקיע בקריאת הרשת כפי שהיא באמת קיימת. גוגל הבינו את זה. הם לא בנו את ה-Web Rendering Service שלהם מתוך נדיבות. הם בנו אותו כי הבינו שכדי להיות הספרייה של האינטרנט, צריך להיות מסוגלים לקרוא אתרים שמרונדרים ב-JavaScript. לקח להם שנים והשקעת תשתית עצומה, אבל הם עשו את זה כי האלטרנטיבה הייתה אינדקס לא שלם. אם OpenAI ו-Anthropic רוצים שהסוכנים שלהם ייתנו למשתמשים את הידע הטוב ביותר הזמין, הם עומדים בפני אותה בחירה. כרגע בוטי השליפה שלהם מתנהגים כמו שולפי HTML גולמי. זה פשרה הנדסית לגיטימית בשלב הזה, אבל זה אומר שחלק משמעותי מהרשת קשה יותר עבורם לגשת אליו. לשני הצדדים יש עבודה לעשות.

מה הבדיקה הזו לא מראה

המאמר הזה לא טוען שכל עמוד client-rendered תמיד נכשל, או ש-ChatGPT ו-Claude אף פעם לא מריצים JavaScript בשום נסיבה. הוא לא מעריך כלים חיצוניים של prerendering או שירותי static generation, והוא לא מודד דירוג, תדירות ציטוט, או תנועת הפניה. הנקודה צרה יותר: בסטאפ המבוקר הזה, שליפת גוף התיישרה עם HTML משמעותי ראשוני, והפלטפורמות נבדלו בשאלה האם הן יכלו לייצר את הפלט הזה בעצמן.

המלצות מעשיות

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

• השתמשו ב-title ברור
• כתבו תיאור מטא חזק
• השתמשו ב-URL תיאורי

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

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

שתי דרכים לבדוק את האתר שלכם:

1. כבו JavaScript בדפדפן (Chrome DevTools, Settings, Disable JavaScript), ואז טענו מחדש את העמוד. אם התוכן נעלם, ככה סוכני AI רואים אותו.

2. שאלו סוכן AI ישירות. פתחו שיחה חדשה עם ChatGPT או Claude, תנו לו את ה-URL שלכם, ושאלו שאלה ספציפית שאפשר לענות עליה רק על ידי קריאת גוף העמוד. לא “על מה העמוד הזה” (זה מגיע מתגיות מטא). שאלו על מספר, שם, פרט מאמצע פסקה. אם הוא לא מצליח לענות, התוכן לא נגיש.

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

למי זה הכי חשוב

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

לכלים פנימיים, דשבורדים ותהליכי עבודה פרטיים, כלום מזה לא רלוונטי.

שורה תחתונה

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