מה זה זמן תגובה ממוצע של השרת ואיך הוא משפיע על הסריקה של גוגל

תסתכלו על הגרף הזה. אני חייב להודות שאני אוהב אותו.

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

שני הקווים זזים בכיוונים הפוכים, וזה כל הסיפור.

• כתום: זמן תגובה ממוצע, במילישניות.
• כחול: בקשות הסריקה היומיות של Googlebot.

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

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

מה זה זמן תגובה ממוצע של השרת?

המדד נקרא זמן תגובה ממוצע, והוא נמצא בדוח “נתונים סטטיסטיים של סריקה” ב-Search Console. זה הזמן הממוצע שלוקח ל-Googlebot לאחזר משאב מהאתר, נמדד מהצד של גוגל, על פני כל מה שהוא מבקש. זה לא כולל rendering.

החלק האחרון חשוב, כי קל להתבלבל בין זה לבין ה-TTFB (Time to First Byte) שמדווח לצד Core Web Vitals. אלה לא אותו מספר. ה-TTFB של נתוני השטח נמדד בדפדפנים של משתמשים אמיתיים, ברשתות שלהם, אז הוא סוחב גם רשת איטית, DNS וזמן התחברות. המספר של דוח הסריקה נמדד על ידי בוט שיושב ליד התשתית של גוגל, בלי דפדפן, בלי rendering וכמעט בלי רשת באמצע. שניהם מושפעים ממהירות השרת, אבל הם מודדים דברים שונים, ובשביל סריקה קובע רק המספר של דוח הסריקה.

תקציב הסריקה הוא בעצם תקציב זמן

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

ככה זה נראה במספרים: נניח שגוגל נותנת לאתר שלכם 60 דקות של זמן Googlebot ביום. ב-100ms ל-URL נכנסים לשעה הזאת בערך 36,000 כתובות. בחצי שנייה, בערך 7,200. בשלוש שניות, בערך 1,200. אותה שעה, וזמן התגובה לבדו מזיז את המספר פי שלושים בערך, בין קצה לקצה. ה-60 דקות הן רק כדי להמחיש. בפועל התקציב נקבע מהרבה גורמים, וזמן התגובה הוא החלק שבשליטתכם.

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

מה גוגל אומרת על זמן תגובה וסריקה

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

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

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

וב-2024 גוגל הסירה את הכלי הידני לשליטה בקצב הסריקה מ-Search Console, כי Googlebot ממילא מכוונן את קצב הסריקה אוטומטית לפי איך שהשרת מגיב. הכלי הידני היה איטי יותר ועשה עבודה פחות טובה.

מה עוד משפיע על הסריקה: ביקוש הסריקה

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

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

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

למה הייתי מסתכל על זה לפני Core Web Vitals

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

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

למה זה מחמיר ככל שהאתר גדל

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

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

מה עושים

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

גוגל לא מפרסמת יעד רשמי, אבל הנה שלי. אני רוצה לראות מתחת ל-300ms, ורצוי מתחת ל-200ms. כל דבר מעל 600ms הוא גרוע מבחינתי. קחו את זה ככלל אצבע של איש מקצוע, לא כחוק.

החשודים הרגילים באתר גדול, וכולם בצד של צוות הפיתוח:

• hit ratio נמוך של ה-cache, כך שדפים דינמיים פונים ל-origin בכל בקשה.
• שאילתות DB יקרות, במיוחד בעמודי סינון ופילטרים עם אינסוף שילובים.
• אין CDN, או שיש CDN שלא מטמין HTML.
• origin חלש מדי שמאט תחת עומס הסריקה.
• קריאות בק-אנד או צד-שלישי איטיות שחוסמות את התגובה.
• רינדור בצד שרת בלי שום שכבת cache לפניו.

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

איך מאתרים את מקור ההאטה

פרקו את הדוח לפי קוד תגובה ולפי סוג קובץ, ואם יש לכם server logs, תסתכלו על האחוזונים האיטיים של זמן התגובה, p75 ו-p95, לפי תבנית URL.

ותסתכלו מעבר לעמודים שהמבקרים רואים. זמן תגובה ממוצע מכסה כל מה ש-Googlebot מאחזר, לא רק את עמודי ה-HTML: JavaScript, CSS, תמונות, פונטים, וקריאות API או XHR שה-renderer עושה. endpoint איטי שאף בן אדם לא טוען ישירות עדיין יכול למשוך את המספר למטה, כי Googlebot מאחזר גם אותו.

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

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

שאלות נפוצות

מקורות

• Google Search Central, המדריך לניהול תקציב סריקה לאתרים גדולים
• Gary Illyes, What Crawl Budget Means for Googlebot (2017)
• Google Search Central, Inside Googlebot: demystifying crawling, fetching, and the bytes we process (2026)
• Google Search Central, Upcoming deprecation of the Crawl Rate Limiter tool (2023, בתוקף מ-2024)
• Search Off the Record, פרק 105, Google crawlers behind the scenes
• Search Off the Record, פרק 79, Crawling smarter, not harder