דברו איתנו
לכל המאמריםמרכז מידע

למה האתר שלכם לא קיים בשביל AI — וזה בגלל JavaScript

· צוות LEADZ · 6 דקות קריאה · עודכן:

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

הסורקים של ה-AI לא מריצים JavaScript

ניתוח של Vercel על תעבורת סורקים אמיתית הראה שהסורקים של OpenAI, של Anthropic ושל Perplexity אינם מריצים JavaScript בזמן הסריקה. הם מושכים את ה-HTML הגולמי וקוראים מה שיש בו. אם ה-HTML הזה מכיל רק שלד ריק שממתין לקוד שירוץ בדפדפן, זה מה שהם רואים: עמוד ריק. סייג אחד שחשוב לנו לומר: הניתוח הזה פורסם בדצמבר 2024, התנהגות סורקים משתנה, ולכן זה נכון למועד הפרסום — לא הבטחה לנצח. נכון להיום אף אחד מהם לא הודיע על שינוי, אבל שווה לבדוק מחדש מדי כמה חודשים.

גוגל היא יוצאת דופן — לפי התיעוד של Google Search Central היא מעבדת עמודים לחוויות ה-AI שלה באותו מנגנון של החיפוש הרגיל, שבו JavaScript אכן מורץ בשלב שני של העיבוד, ולכן אתרים כאלה בדרך כלל מופיעים בחיפוש הרגיל. זה בדיוק מה שמטעה: האתר נראה בסדר גמור בגוגל, ובמקביל לא קיים בכלל עבור ChatGPT, Claude או Perplexity. שתי המציאויות האלה יכולות להתקיים יחד באותו רגע.

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

ומה עם הסכמה שהטמענו

שאלה טובה, כי הרבה אתרים מזריקים את ה-JSON-LD שלהם באמצעות JavaScript. בדיקה של searchVIU מצאה שמידע שקיים רק בתוך סימון הסכמה, ולא בטקסט הגלוי, לא נקלט כשמנוע ניגש לעמוד בזמן אמת. בדיקה של Otterly הצביעה לאותו כיוון, אבל היא נעשתה על אתר אחד והתוצאה שלה מעורבת, ו-Otterly גם מוכרת כלי מדידה לתחום הזה — כלומר זו תמיכה חלשה ולא אישוש שני. המסקנה המעשית פשוטה: אם עובדה חשובה לעסק שלכם — שעות פעילות, אזור שירות, מה בדיוק אתם עושים — היא חייבת להיות כתובה בטקסט שאדם יכול לקרוא, ולא רק בקוד.

מה עושים, לפי סוג האתר

אתר React / Vue / Angular

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

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

וורדפרס

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

וויקס ו-Squarespace

כאן המצב טוב יותר ממה שכתבנו בגרסה הקודמת של המאמר, ששמה את שתיהן באותו סל עם אתרי JavaScript. וויקס כותבת בתיעוד שלה שהעמודים מרונדרים בשרת, ומסבירה בעצמה שרוב סורקי ה-AI לא מריצים JavaScript. בבדיקה שלנו, ב-7 אתרי וויקס וב-4 אתרי Squarespace בישראל (מדגם קטן, ספטמבר 2026), הטקסט של העמוד הגיע מהשרת. הבעיה בפלטפורמות האלה היא כמעט אף פעם לא JavaScript. היא רכיבים מסוימים ותוכן חסר. אתר וויקס ו-AI: מה ChatGPT וגוגל באמת רואים

בניתם ב-Lovable או ב-Base44?

כאן התמונה מבלבלת, כי כל כלי פותר את בעיית ה-JavaScript אחרת. ב-Lovable, אפליקציות שנוצרו מ-13 במאי 2026 בנויות על TanStack Start ומרונדרות בשרת, כך שהטקסט נמצא ב-HTML לכל מי שמבקש. אפליקציות ישנות יותר נבנות בדפדפן, ו-Lovable מגישה עותק מוכן שלהן ״רק לסורקי חיפוש ו-AI מאומתים״. כל השאר, כולל כלי בדיקה חיצוניים, מקבלים את השלד הריק. אפשר לשדרג אפליקציה ישנה במקום. לפי Lovable, רוב השדרוגים צורכים 10 עד 35 קרדיטים, ואחריהם צריך לבדוק את העמודים, כי ספריות שעובדות רק בדפדפן עלולות לשבור את הרינדור בשרת.

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

בדקנו אתרים כאלה בישראל בכלי שלנו (מדגם קטן, ספטמבר 2026). ב-Lovable, 3 מתוך 5 היו מרונדרים בשרת, ו-2 היו אפליקציות ישנות. ב-Base44, בכתובות החינמיות, 8 מתוך 9 אפליקציות החזירו רק תקציר של פחות מ-150 מילים. ובאפליקציות Lovable ראינו גם מלכודת: ברכיב שאלות נפוצות שה-AI בנה, תשובה מקופלת נשארת ריקה ב-HTML.

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

המקורות לחלק הזה

ותקלה אחת שקטה נוספת

לפעמים הבעיה היא לא הקוד אלא החסימה. שירותי הגנה מפני בוטים וחומות אש נוטים לחסום כל סורק שאינו מוכר להם. התיעוד של OpenAI אומר שחסימת OAI-SearchBot מוציאה את האתר מהחיפוש של ChatGPT, ושעדכון robots.txt נקלט תוך כ-24 שעות; גם בתיעוד של Perplexity מופיע סדר גודל דומה, אבל שם חשוב לדעת ש-PerplexityBot מציית ל-robots.txt ואילו Perplexity-User, שנשלח בזמן אמת בעקבות שאלה של משתמש, אינו מציית לו. בנוסף, החיפוש של Claude רץ על המנוע של Brave, והסורק של Brave מכבד את ההוראות שנכתבו עבור Googlebot — כך שחסימה גורפת עלולה להוציא אתכם משני מקומות בבת אחת.

סדר העדיפויות

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

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

בדיוק בשביל זה בנינו את הבדיקה החינמית: היא מושכת את האתר שלכם בלי להריץ JavaScript — כמו שסורק AI עושה — ומראה מה נשאר על המסך. בדקו מה ה-AI רואה באתר שלכם

בדיקה חינמית

רוצים לראות מה ה-AI רואה אצלכם?

הבדיקה החינמית שלנו מושכת את האתר שלכם בלי להריץ JavaScript — בדיוק כמו סורק AI — ומחזירה הערכה של המצב תוך שניות.

לבדיקה החינמיתדברו איתנו
שאלות על המאמר הזה

מה ששואלים אותנו אחרי שקוראים.

איך אני בודק בעצמי אם האתר שלי קריא?

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

לבדיקה החינמית — מה ה-AI רואה באתר שלכם
האתר שלי בנוי בוורדפרס / Wix / React — זה משנה?

הפלטפורמה משנה במובן אחד: האם הטקסט של העמוד מגיע ל-HTML בלי שצריך להריץ JavaScript. הסורקים של OpenAI, Anthropic ו-Perplexity לא מריצים JavaScript, ולכן אתר שכל התוכן שלו נבנה בצד הלקוח, מצב נפוץ באפליקציות React, Vue ו-Angular, נראה להם כעמוד ריק. וורדפרס, וויקס ו-Squarespace מגישים HTML מלא מהשרת, ולכן שם הבעיה היא בדרך כלל תוכן חסר או רכיב מסוים, ולא הפלטפורמה. ב-Lovable וב-Base44 התשובה תלויה בגיל האפליקציה ובדומיין. הבדיקה עצמה פשוטה: לוחצים על הצגת מקור העמוד בדפדפן ומחפשים משפט מתוך העמוד. אם הוא לא שם, הוא לא שם גם בשביל ה-AI.

המקורות לתשובה הזו:
מה זה prerender או SSR בפועל, ומה זה דורש ממני?

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

גוגל כן מריצה JavaScript — אז למה אכפת לי?

כי זה בדיוק מה שמסתיר את הבעיה. לפי התיעוד של Google Search Central גוגל מעבדת עמודים לחוויות ה-AI שלה באותו מנגנון של החיפוש הרגיל, שבו JavaScript אכן מורץ בשלב שני — ולכן אתר שכל התוכן שלו נבנה בדפדפן יכול להיראות תקין לחלוטין בגוגל. במקביל, ניתוח של Vercel על תעבורת סורקים אמיתית הראה שהסורקים של OpenAI, של Anthropic ושל Perplexity אינם מריצים JavaScript. הניתוח הזה פורסם בדצמבר 2024 והתנהגות סורקים משתנה, אז שווה לבדוק מדי כמה חודשים מחדש. שתי המציאויות האלה מתקיימות יחד באותו רגע: מצוין בגוגל, ולא קיים בשביל ChatGPT.

המקורות לתשובה הזו:
בניתי ב-Lovable. איך אני יודע אם האפליקציה שלי מרונדרת בשרת?

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

המקורות לתשובה הזו:
האתר שלי ב-Base44 על כתובת חינמית. מה ה-AI רואה?

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

המקורות לתשובה הזו:
דברו איתנו