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

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

· צוות LEADZ · 5 דקות קריאה

יש תקלה אחת שיכולה להפוך אתר מצוין לבלתי נראה עבור מנועי 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 ובוני אתרים סגורים

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

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

לפעמים הבעיה היא לא הקוד אלא החסימה. שירותי הגנה מפני בוטים וחומות אש נוטים לחסום כל סורק שאינו מוכר להם. התיעוד של 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 — נראה להם כעמוד ריק. וורדפרס מייצר HTML מלא בשרת ולכן שם המצב טוב ברוב המקרים, ובוני אתרים סגורים כמו Wix נמצאים איפשהו באמצע ודורשים בדיקה. הבדיקה עצמה פשוטה: לוחצים על הצגת מקור העמוד בדפדפן ומחפשים משפט מתוך העמוד. אם הוא לא שם, הוא לא שם גם בשביל ה-AI — וזה נכון גם לטקסט שנטען רק אחרי לחיצה או גלילה.

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

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

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

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

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