רצינו למדוד אם מנועי AI מצטטים אותנו. במקום זה מצאנו בעיה שקודמת לשאלה הזו לגמרי: האתר החזיר "הכל תקין" לכל כתובת שלא קיימת.
התחלנו מהדבר שנראה הכי פשוט — לבדוק אם יש לנו
robots.txt. הבדיקה חזרה
200. גם sitemap.xml.
גם llms.txt. שלושה מתוך שלושה קיימים.
כמעט רשמנו את זה ועברנו הלאה.
מה שהציל את הבדיקה
לפני שרשמנו, ביקשנו כתובת שהיינו בטוחים שלא קיימת —
/definitely-not-a-real-file.txt.
גם היא חזרה 200. כלומר: אף אחד משלושת הקבצים לא היה קיים.
השרת פשוט הגיש את דף הבית לכל דבר שביקשנו.
200 הוא לא הוכחת קיום. כל בדיקת נוכחות חייבת לכלול כתובת אחת שאמורה להיכשל.
הכלל שנוסף למפרט אחרי הממצא הזה
זה נקרא soft-404, והמשמעות שלו חמורה יותר מקובץ חסר: לאתר היו אינסוף כתובות תקפות, כולן עם אותו תוכן. גוגל מגדירה ייצור המוני של דפים חסרי ערך כהפרת מדיניות מפורשת [1] — וזה בדיוק הדפוס שנוצר כאן בלי שאיש התכוון.
מה שכן עבד
לא הכל היה שבור, וזה שווה אמירה: שתי הכתבות שבאוויר נבנו נכון —
canonical ייחודי,
hreflang הדדי בין עברית לאנגלית,
וסכימת BlogPosting מלאה.
המבנה הדו־לשוני עבד. התשתית סביבו לא.
למה זה קדם לכל השאר
אין לנו לקוחות. המשמעות היא שהנראות שלנו במנועי תשובות היא ההוכחה היחידה שנוכל להציג — ולכן המדידה שלה היא לא מדד, היא המוצר. אבל אין טעם לשאול אם ChatGPT מצטט אותנו כשהאתר לא ניתן לסריקה תקינה. קודם מתקנים, אחר כך מודדים.
חמישה תיקונים באותו יום: דף 404 אמיתי, robots.txt שמזמין במפורש את זחלני ה־AI, sitemap שנוצר מהמאגר עצמו ולכן לא יכול להיסחף, llms.txt, וסכימת ארגון בדף הבית. אימתנו מול אותה כתובת בקרה שחשפה את התקלה — 404.
ומה שקרה אחר כך
תיקנו את המוצר, כתבנו את הכתבה הזו — ואז גילינו שאתר אחר שבנינו, זה שמציג את שלבי הבנייה, סבל מאותו באג בדיוק. תיקנו את המוצר ולא את הכלי שבנינו כדי לדווח על המוצר. גם זה מתועד, ביומן החזרות, עם השם שלנו עליו.