אם לאתר שלכם יש כמה עשרות עמודים, כנראה שאתם לא חושבים הרבה על תקציב סריקה (crawl budget). Google תגיע בסוף לכל העמודים. אבל אם אתם מריצים חנות אונליין עם 50,000 עמודי מוצר, אתר מדיה שמפרסם תוכן כל יום, או מרקטפלייס עם מודעות שמשתמשים מעלים, תקציב הסריקה הופך לנושא שאתם צריכים לנהל בפועל. והנה החלק שרוב האנשים מפספסים: לאחסון האתר שלכם יש תפקיד גדול יותר בעניין הזה מלמפת האתר (sitemap).
מה זה בעצם תקציב סריקה
תקציב סריקה הוא מספר העמודים שמנוע חיפוש מוכן ומסוגל לסרוק באתר שלכם בפרק זמן מסוים. ל-Google אין משאבים אינסופיים לסרוק כל אתר באינטרנט, אז היא מקצה תקציב משוער לכל דומיין בהתאם לשני גורמים: ביקוש לסריקה (כמה Google רוצה לסרוק את התוכן שלכם) וקיבולת סריקה (כמה השרת שלכם מסוגל לספוג בלי להתמוטט).
באתרים קטנים זה כמעט ולא משנה. Google יכולה לסרוק 200 עמודים בשעה קלה בלי מאמץ. אבל כשמדובר בעשרות אלפי כתובות URL, עמודים שלא נסרקים או שנסרקים לאט הופכים לבעיה כלכלית ממשית. עמוד מוצר שלא נסרק לא מדורג. עמוד שלא מדורג לא מקבל תנועה. זה כל הסיפור.
קיבולת סריקה היא בעיה של אחסון
זה החלק שמפתיע בעלי אתרים רבים. ביקוש לסריקה נוגע לתוכן וקישורים. קיבולת סריקה שייכת כמעט לגמרי לתחום האחסון. Googlebot עוקב באופן פעיל אחרי איך השרת שלכם מגיב בזמן הסריקה. אם השרת מתחיל להגיב לאט, מחזיר שגיאות, או נתקע תחת עומס הסריקה, Google מאיטה את הקצב. היא מקטינה את קצב הסריקה כדי לא להעמיס עליכם יותר מדי.
המשמעות היא ששרת איטי, עמוס, או מוגדר בצורה לא טובה, לא רק מפגיע בחוויית המשתמשים שלכם, הוא ממש אומר ל-Google לסרוק את האתר שלכם בתדירות נמוכה יותר. בבלוג עם 200 עמודים זה אי נוחות קלה. בקטלוג ecommerce גדול, זה יכול להוביל לאלפי עמודים שלא מאונדקסים במשך חודשים.
סימנים לכך שהאחסון שלכם מגביל את תקציב הסריקה
- זמני תגובת שרת שמזנקים מעל 1-2 שניות בשעות עומס
- שגיאות 5xx שמופיעות בדו"ח נתוני הסריקה של Google Search Console
- מספר בקשות הסריקה שנופל בצורה בולטת לאחר עלייה בתנועה
- עמודים חדשים שלוקח להם שבועות להופיע בתוצאות החיפוש, אף שהם מקושרים פנימית
- שאילתות מסד נתונים שמתחילות להיאט ככל שהקטלוג או ספריית התוכן גדלים
דו"ח Crawl Stats בכלי Search Console הוא הכלי החינמי הטוב ביותר לזיהוי הבעיה הזו. הסתכלו על גרף זמן התגובה הממוצע. אם הוא מתאם עם ירידה במספר בקשות הסריקה, קיבולת השרת היא הבעיה, לא אסטרטגיית התוכן שלכם.
למה זמן תגובת שרת ו-SEO ואחסון אתרים כרוכים זה בזה
הרבה בעלי אתרים מתייחסים ל-SEO ולאחסון כשני תחומים נפרדים. צוות אחד כותב תוכן ובונה קישורים, צוות אחר רק שומר על השרת פעיל. אבל כשמנהלים SEO ואחסון אתרים לאתר גדול, זה בעצם אותה עבודה עם שני כובעים. כל מילישנייה שהשרת שלכם לוקח כדי להגיב, גורעת מתקציב הסריקה שגוגל מקצה לכם, וכל קיצוץ בתקציב הסריקה משמעו אינדוקס איטי יותר לתוכן חדש או מעודכן.
כתבנו על הקשר הזה בפירוט רב יותר במאמר איך SEO ואחסון אתרים קשורים יותר ממה שחשבתם, וכדאי לחזור אליו אם רק עכשיו אתם מבינים שמפרטי השרת שלכם הם למעשה נדבך ב-SEO.
עומס על מסד הנתונים הוא החשוד המיידי
באתרים גדולים, הבעיה לרוב אינה שרת האינטרנט עצמו. זה מסד הנתונים. כל עמוד מוצר, פילטר קטגוריה, או רשימה דינמית כרוך בדרך כלל בשאילתת מסד נתונים, ובקטלוג גדול, השאילתות האלה מתרבות מהר. עמוד שנטען ב-200 מילישניות בתנועה נמוכה, יכול לתפוח ל-3 שניות כשגם Googlebot וגם מבקרים אמיתיים פוגעים בשרת באותו זמן.
הרחבנו על הסיבות לכך במאמר למה שאילתות מסד נתונים איטיות הן הבעיה הנסתרת ברוב האפליקציות. אם האתר שלכם מריץ קטלוג מוצרים גדול, שווה לבדוק את השאילתות האיטיות ביותר בזמן סימולציה של עומס סריקה, לא רק בתנועה רגילה.
דרכים מעשיות להגן על תקציב הסריקה באתרים גדולים
1. תקנו את זמן התגובה לפני שנוגעים במפת האתר
בעלי אתרים נוטים לפנות ראשית לשינויים במפת האתר (XML sitemap). אלה עוזרים ל-Google למצוא עמודים, אבל לא עוזרים ל-Google בפועל לטעון אותם מהר יותר. אם זמן התגובה הממוצע שלכם עולה על שנייה, זה התיקון בעל העדיפות הגבוהה יותר.
2. הפעילו caching אגרסיבי בצד השרת
caching בצד השרת מונע מ-Googlebot להפעיל שאילתת מסד נתונים מלאה בכל סריקה. שכבת cache מוגדרת היטב יכולה לקצר זמני תגובה משניות למילישניות, מה שמגדיל באופן ישיר את מספר העמודים ש-Google יכולה לסרוק בכל סשן. caching של אובייקטים באמצעות Redis יעיל במיוחד לאתרים דינמיים עם עומס גבוה על מסד הנתונים.
3. גזרו כתובות URL בעלות ערך נמוך
ניווט מבוסס פילטרים, מזהי סשן (session IDs), ופרמטרי URL לסינון יכולים להכפיל את מספר כתובות ה-URL הנסרקות פי 10 ואף יותר, בלי להוסיף תוכן אמיתי. זה מדלל את תקציב הסריקה על פני עמודים שלא ממש חשובים. השתמשו ב-robots.txt ותגי canonical כדי לשמור על Googlebot ממוקד בעמודים שאתם באמת רוצים באינדקס.
4. עקבו אחרי תקינות השרת באופן רציף, לא מדי פעם
בעיות סריקה מופיעות לרוב כקוצים קצרים, נעילת מסד נתונים בזמן גיבוי, זינוק בתנועה מקמפיין שיווקי, עדכון תוסף שהשתבש. אם אתם בודקים את תקינות השרת רק פעם בשבוע, תפספסו את התבנית. מעקב רציף אחרי זמן פעילות (uptime) וזמן תגובה תופס את הצניחות האלה בזמן אמת, כך שתוכלו לתקן אותן לפני שהן מצטברות לבעיה של תקציב סריקה. זו בדיוק הסיבה שאנחנו עוקבים באופן רציף אחרי זמני תגובה ושגיאות בשרתים שאנחנו מנהלים, במקום לחכות לדו"ח חודשי.
5. תנו לשרת שלכם מרווח נשימה
אם השרת שלכם רץ ב-90% קיבולת בתנועה רגילה, לא נשאר מקום לקוץ סריקה או לזינוק תנועה. אתרים גדולים צריכים תשתית שיכולה לספוג גם מבקרים אמיתיים וגם תנועת בוטים בלי להאט בגלל אף אחד מהם. זה אחד התחומים שבהם תוכנית VPS בגודל מתאים יוצרת הבדל מדיד לעומת אחסון משותף, שבו אתם מתחרים על משאבים עם אתרים אחרים באותו שרת.
לסיכום
תקציב סריקה אינו מושג טכני מעורפל השייך רק לאתרים ענקיים. הוא תוצאה ישירה של המהירות והאמינות שבה השרת שלכם מגיב לבקשות, כולל אלה שמגיעות מבוטים של מנועי חיפוש. אם אתם מריצים קטלוג גדול, מפרסמים תוכן בתדירות גבוהה, או מנהלים אלפי כתובות URL, מערך האחסון שלכם עוזר ל-Google למצוא ולדרג את התוכן שלכם במהירות, או בשקט מאט את התהליך הזה.
התחילו מדו"ח הסריקה ב-Search Console. אם זמני התגובה עולים, זה הסיגנל לבדוק קיבולת שרת ו-caching לפני שנוגעים בכל דבר אחר. כך תבטיחו ש-SEO ואחסון אתרים יעבדו יחד ולא אחד נגד השני.
