כשהתוכן קיים רק אחרי הרצת קוד

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

למה זה קורה בכלל?

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

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

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

הבדיקה שלוקחת דקה

שלוש בדיקות בסדר עולה של מאמץ, ורובכם תסיימו אחרי הראשונה.

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

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

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

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

מה כל סורק באמת עושה, ומה לא ידוע?

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

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

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

איך זה נראה מבחוץ, כשלא יודעים לחפש?

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

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

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

הפתרון: להעביר את ההרכבה לשרת

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

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

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

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

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

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

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

המקרים שחוזרים באתרים ישראליים

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

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

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

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

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

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

מה לא לעשות?

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

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

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

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

מה עדיין לא ידוע

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

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