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

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

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

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

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

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

השרת לא קרס בשום שלב: אין 503, אין ספייקים של שגיאות לאורך כל התקופה. וקשה לתלות את זה בצד של הביקוש^? מה זה ביקוש סריקה? ✕ ביקוש סריקה (crawl demand) הוא כמה גוגל רוצה לסרוק אתר, בנפרד מהשאלה כמה גוגל יכולה לסרוק אותו. להגדרה המלאה של ביקוש סריקה ← , כי ביקוש לא קופץ פי שבעה בין לילה ולא נופל בחזרה בדיוק כשהשרת מאט. כשהסריקה משקפת את זמן התגובה כמו מראה, בשני הכיוונים, ברור מי מזיז את מי: זמן התגובה מוביל, והסריקה הולכת אחריו.

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

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

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

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

תקציב סריקה^? מה זה תקציב סריקה? ✕ תקציב סריקה (crawl budget) הוא קבוצת הכתובות שגוגל גם יכולה וגם רוצה לסרוק באתר, ונקבע לפי קיבולת הסריקה וביקוש הסריקה. להגדרה המלאה של תקציב סריקה ← , כמות הסריקה שגוגל מקצה לאתר שלכם, הוא בעצם כמות של זמן Googlebot. וזמן התגובה שלכם הוא שער ההמרה שהופך את הזמן הזה ל-URLs שנסרקים.

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

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

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

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

התיעוד הרשמי של תקציב הסריקה אומר את זה ישירות: אם האתר מגיב באופן עקבי וזמני התגובה שלו, “כולל latency ו-Time-to-First Byte”, נשארים יציבים או משתפרים, “המגבלה עולה ואפשר להשתמש ביותר חיבורים לסריקה”. וההפך: כשהוא מאט, או מחזיר שגיאות שרת (5xx) או סיגנלים של הגבלת קצב כמו HTTP 429, “המגבלה יורדת וגוגל סורקת פחות”.

בעדכון של יולי 2026 גוגל גם הגדירה מה בדיוק היא סופרת. קיבולת הסריקה^? מה זה קיבולת סריקה? ✕ קיבולת סריקה (crawl capacity) היא התקרה שגוגל שמה על הזמן הכולל שהשרת מחזיק חיבורים פתוחים בשבילה. להגדרה המלאה של קיבולת סריקה ← , או בשמה השני hostload, היא תקרה על “סך הזמן שהשרת שלכם מחזיק חיבורים פתוחים עבור גוגל, לפי מספר החיבורים המקבילים ומשך כל אחד מהם”.

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

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

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

התקרה שזמן התגובה קונה משותפת לשאר הסורקים של גוגל

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

בפועל זה אומר ש-Googlebot לא לבד על השרת שלכם. AdsBot, StoreBot ושאר הסורקים של גוגל נגרעים מאותה תקרה. לפי התיעוד, הביקוש של AdsBot עולה כשלאתר יש הרבה יעדים של Dynamic Search Ads, והוא חוזר אליהם בערך כל שבועיים.

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

ביקוש הסריקה: מתי גוגל בוחרת לסרוק פחות

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

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

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

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

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

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

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

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

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

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

מה עושים

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

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

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

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

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

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

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

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

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

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

יש גם את המקרה ההפוך: עמודים נסרקים שוב למרות שהתוכן בהם לא השתנה. תשובת 304 (Not Modified) אומרת ל-Googlebot להשתמש בעותק שכבר יש לו, בלי להוריד שוב את כל ה-HTML. באתר גדול זה מחזיר זמן 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