מהירות ויציבות מול סורקי AI

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

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

שני סורקים, שתי רמות סבלנות

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

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

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

מה קורה כשהשרת עונה רע?

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

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

איטיות שקטה מסוכנת יותר משגיאה רועשת

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

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

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

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

המקרה הישראלי: הגנה, הגבלת קצב וחסימה שנראית כמו איטיות

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

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

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

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

איך זה נראה בלוגים?

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

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

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

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

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

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

מה לתקן ומה לא, לפי סדר?

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

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

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

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

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

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

מתי איטיות היא לא הבעיה שלכם?

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

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

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

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

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

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