תקציב הסריקה (Crawl Budget): למה גוגל לא סורקת את כל העמודים שלך — ואיך זה פוגע בדירוגים

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

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

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

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

מהו תקציב סריקה, ומה הוא לא

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

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

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

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

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

איך סריקה יכולה להשפיע בלי להיות גורם דירוג

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

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

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

לא כל אתר צריך פרויקט תקציב סריקה

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

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

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

גוגל רואה הרבה יותר ממה שמופיע בתפריט

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

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

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

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

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

ניווט מסונן: המקום שבו אתר סביר הופך לאינסופי

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

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

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

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

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

robots.txt, noindex וקנוניקל פותרים בעיות שונות

שלושת הכלים האלה מוזכרים לפעמים כאילו אפשר להחליף ביניהם, אבל כל אחד מהם פועל בשלב אחר:

• robots.txt: יכול למנוע מ־Googlebot לבקש נתיב. הוא עשוי לצמצם סריקה, אך אינו הוראת הסרה מהאינדקס. כתובת חסומה עדיין יכולה להופיע בתוצאות אם גוגל מכירה אותה ממקורות אחרים.
• noindex: מורה שלא לכלול את העמוד באינדקס, אבל גוגל צריכה לסרוק אותו כדי לקרוא את ההוראה. לכן הוא אינו כלי יעיל לחיסכון מיידי בסריקה של מרחב כתובות עצום.
• rel="canonical": מצביע על הגרסה המועדפת בין עמודים דומים. זהו רמז לאיחוד, לא איסור סריקה ולא הבטחה שהגרסה שסומנה תיבחר.

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

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

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

אני מתחיל ב־Search Console כדי לקבל תמונה ראשונית. בדוח Crawl Stats אני מחפש שינויים במספר הבקשות, בזמני התגובה, בקודי המצב ובסוגי הקבצים. בדוחות האינדוקס, בבדיקת הכתובת ובמפות האתר אני בודק אם הכתובות התגלו, אם נסרקו, איזו גרסה נבחרה כקנונית ומהי הסיבה המדווחת לאי־אינדוקס.

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

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

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

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

תרחיש היפותטי: מהודעת הוואטסאפ עד למדד ההצלחה

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

ב־Search Console מופיע מספר הולך וגדל של כתובות במצב “התגלה — כרגע לא נוסף לאינדקס”. דוח Crawl Stats אינו מצביע על קריסה כללית של הסריקה, וגם זמני התגובה נראים סבירים. בשלב הזה אפשר להתפתות לבקש אינדוקס ידני למוצרים נוספים, אבל זאת פעולה נקודתית שאינה מסבירה מדוע התופעה חוזרת.

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

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

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

כך אני קובע במה מטפלים קודם

כאשר השרת מחזיר שגיאות או מגיב לאט

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

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

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

כאשר עמודים חשובים מוכרים אך כמעט אינם נסרקים

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

כאשר העמודים נסרקים אך אינם נכנסים לאינדקס

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

לאחר התיקון מודדים חלוקה, לא רק כמות

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

טעויות נפוצות בטיפול בתקציב הסריקה

• לייחס כל אי־אינדוקס למחסור בתקציב: אם העמוד כבר נסרק, ייתכן שהבעיה היא כפילות, קנוניקל, תוכן דל או חוסר הצדקה לעמוד עצמאי.
• לחסום נתיבים בלי מיפוי: חסימת robots.txt עשויה לחסוך בקשות, אך אינה מבטיחה הסרה מהאינדקס ועלולה לפגוע בעמודים חשובים.
• להוסיף noindex למיליוני כתובות ולסיים את העבודה: גוגל עדיין צריכה להגיע לעמודים כדי לקרוא את ההוראה. צריך להבין מדוע הכתובות נוצרות ומקבלות קישורים.
• להשתמש בקנוניקל במקום לתקן את המערכת: קנוניקל מסייע באיחוד אותות, אך אינו מפצה על יצירה בלתי נשלטת של גרסאות.
• להכניס כל כתובת למפת האתר: כתובות חסומות, מופנות, לא קנוניות או כאלה שאינן מיועדות לאינדוקס יוצרות מסר לא עקבי.
• לבקש אינדוקס ידני שוב ושוב: הכלי מתאים לבדיקות נקודתיות, לא לטיפול שיטתי באלפי עמודים.
• לשדרג שרת ולצפות שכל האתר ייסרק: תשתית טובה יכולה להסיר מגבלת קיבולת, אבל אינה הופכת תוכן כפול או דל לתוכן שגוגל מעוניינת לסרוק.
• להסתמך רק על Search Console: בלי פילוח לפי תבניות ובלי קובצי לוג קשה לדעת אם הבקשות הגיעו לעמודים העסקיים או לאלפי כתובות טכניות.

שאלות שחשוב לשאול לפני שמאשרים שינוי

לפני שמפתח, חברת SEO או ספק תשתית חוסמים נתיבים ומשנים תגיות, אני מציע לבקש תשובות שאפשר לבדוק:

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

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

טיפ מקצועי: השוו בין שלוש רשימות לפני שמשנים את robots.txt

במבט חוזר: מה אני רוצה שתראו אחרי הודעת הוואטסאפ

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

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

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

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