בדקנו אם האתר שלנו כשיר ל־AI. הוא לא היה.

למה בדיקת הנוכחות שלנו כמעט עברה?

יצאנו למדוד דבר מסוים: האם מנועי תשובות מצטטים אותנו. השלב הראשון היה אמור להיות טכני ומשעמם — לוודא ששלושת הקבצים שמנוע מחפש באמת מוגשים. ביקשנו robots.txt. חזר 200. ביקשנו sitemap.xml. 200. אחר כך llms.txt. שוב 200. שלושה מתוך שלושה. היינו הקלדה אחת מלרשום "כשירות סריקה: תקינה" בקו הבסיס ולעבור לחלק המעניין.

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

איך מוכיחים שקובץ באמת קיים?

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

200 הוא לא הוכחת קיום. כל בדיקת נוכחות חייבת לכלול כתובת אחת שאמורה להיכשל.

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

למה soft 404 גרוע יותר מקובץ חסר?

התיעוד של גוגל נותן למשפחה הזאת שם: כשכתובת מחזירה סטטוס 2xx בזמן שהתוכן שלה מסמן שגיאה, ה־Search Console מדווח soft 404. אצלנו זו הייתה הגרסה הרחבה יותר של אותה תקלה — דף הבית מאחורי כל כתובת, ולא דף שגיאה מאחורי 200 — וההנחיה של גוגל לתקציב סריקה מבקשת בדיוק את אותו תיקון: לחסל soft 404 ולהחזיר 404 או 410 לדפים שאינם קיימים. הסיבה מכנית. כשכל כתובת שגויה מגישה את דף הבית, לאתר יש מספר בלתי מוגבל של כתובות תקפות, כולן עם תוכן זהה. זחלן לא יכול לבנות מפה של מה שקיים, כי שום דבר אף פעם לא מדווח כחסר.

יש מחיר שני, והוא זה שהפך את זה אצלנו מדבר לא־מסודר לדבר דחוף. מדיניות הספאם של גוגל מגדירה ייצור תוכן בנפח (scaled content abuse) כהפקת דפים רבים ש"מטרתם העיקרית היא מניפולציה של דירוגי חיפוש ולא עזרה למשתמשים". ההגדרה הזאת נשענת על כוונה, ואצלנו זו הייתה תצורה חסרה ולא תרגיל — ולכן אנחנו לא טוענות שהפרנו את המדיניות. הנקודה הצרה יותר היא זו שהפכה את זה לדחוף: מה שזחלן באמת רואה, קבוצה בלתי מוגבלת של כתובות שכולן מגישות את אותו דף, הוא הצורה שעליה המדיניות נכתבה — ואנחנו מעדיפות לא להיות במצב שבו ההבדל הוא ויכוח על הכוונות שלנו.

שלושת הקבצים שנראו תקינים הם מסמכים מוגדרים, לא מוסכמות שניחשנו. חריגת זחלנים מתוקננת ב־RFC 9309, מפות אתר ב־פרוטוקול sitemaps.org, ו־llms.txt הוא הצעה שפורסמה בספטמבר 2024 — כפי ש־llmstxt.org עצמו כותב בדף שלו, ולכן אנחנו מיישמים אותו בלי לקרוא לזה אף פעם תאימות לתקן. שלושה מפרטים אמיתיים, שלושה קבצים שלא היו לנו, ושלוש בדיקות שאמרו לנו שכן.

מה כן היה תקין באתר?

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

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

למה כשירות סריקה קדמה למדידה?

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

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

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

מה בכל זאת פספסנו?

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

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

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