שגיאות סריקה (Crawl Errors): גוגל מספרת לך בדיוק מאילו חלקים באתר היא מתעלמת

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

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

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

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

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

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

Crawl Errors הוא מונח ותיק. הדוח הישן כבר לא קיים

מקדם אתרים פרילנסר ואנשי SEO אחרים עדיין מדברים על Crawl Errors, אף שדוח שגיאות הסריקה הישן של Search Console הוסר בסוף מרץ 2019. היום אין מסך אחד שמרכז את כל התשובות. המידע מפוזר בין Page Indexing, כלי URL Inspection, דוח Crawl Stats, דוח robots.txt, דוח Sitemaps ונתוני השרת של האתר.

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

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

גם הדוחות הנוכחיים אינם מספרים את כל הסיפור. Page Indexing מציג ספירות רחבות, אך רשימות הדוגמאות מוגבלות לעד 1,000 כתובות בכל קבוצה. Crawl Stats מספק דוגמאות מייצגות בלבד. כשאני צריך לדעת מתי Googlebot ביקש כתובת מסוימת ומה השרת החזיר באותו רגע, אני עובר ללוגים. Search Console מראה איפה לחפש; הלוגים עוזרים להוכיח מה התרחש.

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

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

1. גילוי: גוגל לומדת שהכתובת קיימת, למשל מקישור פנימי, מקישור חיצוני או ממפת אתר.
2. המתנה לסריקה: הכתובת מוכרת, אך עדיין לא נשלחה אליה בקשה.
3. סריקה ואחזור: Googlebot פונה לשרת ומקבל תגובת HTTP, או נתקל בכשל DNS, רשת או שרת.
4. רינדור: במידת הצורך, גוגל מריצה JavaScript ובונה את הגרסה המרונדרת של העמוד.
5. עיבוד ואינדוקס: המערכות מנתחות את התוכן ומחליטות אם לצרף אותו לאינדקס.
6. קנוניקליזציה: כאשר יש כתובות דומות, גוגל מאגדת אותן ובוחרת כתובת מייצגת.
7. הצגה בתוצאות: גם לעמוד מאונדקס לא מובטח שיופיע בכל חיפוש או יקבל חשיפה משמעותית.

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

אותו דיוק נדרש בסטטוס Crawled – currently not indexed. גוגל כבר סרקה את הכתובת. לכן, בתור מקדם בגוגל, לא הייתי מעביר את המקרה לאיש השרת תחת הכותרת ״גוגל לא מצליחה להגיע״. קודם צריך לבחון מה התקבל בפועל, עד כמה העמוד ייחודי ואילו אותות האתר שולח לגבי החשיבות שלו.

מבחינתי, האבחון אינו הקדמה לעבודה. הוא החלק שמונע את העבודה הלא נכונה.

אני מתחיל ברוחב — ואז מצמצם לכתובת ולבקשה

אין כלי אחד שעונה על כל השאלות, ולכן סדר הבדיקה חשוב. אם נעלם עמוד עסקי יחיד, אני מתחיל ב־URL Inspection. אם קבוצה שלמה נפגעה או שהשינוי התרחש סביב פריסה, מעבר שרת או עדכון תבנית, אני מתחיל מהמגמה ב־Page Indexing וב־Crawl Stats.

Page Indexing: לזהות איזו משפחת עמודים השתנתה

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

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

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

URL Inspection: לבדוק מה קרה לכתובת החשובה

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

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

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

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

Crawl Stats: כשהבעיה מרגישה גדולה מכתובת אחת

Crawl Stats מציג נתונים מ־90 הימים האחרונים, ובהם מספר בקשות הסריקה, נפח ההורדות, זמן תגובה ממוצע, קודי תגובה, סוגי קבצים, מטרת הסריקה וסוג Googlebot. הוא כולל גם מידע על DNS, קישוריות וזמינות robots.txt.

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

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

robots.txt ומפת האתר: שתי כוונות שונות

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

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

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

כשהשרת נכשל, אין לתוכן הזדמנות להתחרות

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

שגיאות 5xx: קודם בודקים היקף ושעה

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

המקור יכול להיות תהליך PHP שקרס, תוסף בעייתי, שאילתת מסד נתונים כבדה, מחסור בזיכרון, timeout ב־CDN או ב־reverse proxy, שגיאת upstream, פריסה שנכשלה או מערכת אבטחה שחסמה את הבקשה.

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

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

בזמן תחזוקה קצרה ומתוכננת, 503 Service Unavailable הוא בדרך כלל הקוד המתאים. 500 מתאר כשל לא צפוי, ו־429 מתאים לעומס או להגבלת קצב אמיתית. אפשר לצרף ל־503 את הכותרת Retry-After, אך אין התחייבות שגוגל תחזור בדיוק במועד שנקבע.

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

DNS, רשת ו־TLS: לפעמים הבקשה לא מגיעה לאתר

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

בודקים את רשומות A,‏ AAAA ו־CNAME, מוודאים שכל שרתי השמות מחזירים תשובה עקבית ובוחנים אם IPv6 מוגדר אך מוביל למסלול שבור. צריך לבדוק גם את תעודת האבטחה, את יצירת חיבור ה־TLS, חסימות בחומת האש, אובדן חבילות וניתוקים לפני תגובת HTTP.

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

401,‏ 403 ו־429: כשההגנה חוסמת גם את הדלת הנכונה

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

אני מחפש הגנת סיסמה שנשארה מסביבת הפיתוח, חסימת מדינה או ASN, כלל WAF רחב מדי ואתגר שמצריך CAPTCHA, עוגייה או JavaScript. צריך לבדוק במיוחד את Googlebot Smartphone; בדיקה רגילה מהמחשב שלכם עלולה לעבור בלי לחשוף חסימה שמופעלת רק על בקשות מובייל או על בוטים.

המעבר ל־mobile-first הושלם ביולי 2024, וגוגל סורקת ומאנדקסת אתרים לחיפוש באמצעות Googlebot Smartphone. עדיין אפשר לראות בלוגים פעילות של Googlebot Desktop למטרות מסוימות, אבל גרסת דסקטופ תקינה אינה מצילה תוכן שאינו נגיש כלל במובייל.

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

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

404 אינו אויב. Soft 404 כבר דורש חקירה

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

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

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

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

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

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

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

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

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

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

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

Discovered ו־Crawled דורשים החלטות שונות

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

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

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

Crawled – currently not indexed מספר סיפור אחר: הכתובת כבר נסרקה. עכשיו אני בוחן את התוצאה. האם התוכן המרכזי מלא וייחודי? האם הוא חופף לעמודים אחרים? האם הקישורים הפנימיים מציגים אותו כעמוד חשוב? האם הגרסה המרונדרת מכילה את מה שאתם רואים בדפדפן?

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

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

JavaScript ומובייל: מה שאתם רואים אינו בהכרח מה שנשלח לעיבוד

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

בדצמבר 2025 גוגל הבהירה שעמודים שמחזירים 200 נשלחים לרינדור, ואילו בדפים שמחזירים קוד שאינו 200 הרינדור עשוי להידלג. המשמעות המעשית ברורה: אי אפשר להחזיר מהשרת 404,‏ 403 או 500 ולסמוך על JavaScript שיתקן את הסטטוס בצד הלקוח. ייתכן שהקוד כלל לא יורץ.

בעמוד מבוסס JavaScript אני משווה בין קוד המקור ל־HTML המרונדר. אני רוצה למצוא בגרסה המרונדרת את הכותרת, התוכן המרכזי והקישורים, ולוודא שקובצי JS,‏ CSS וה־API זמינים ל־Googlebot Smartphone.

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

כך אני בודק אתר בלי לרדוף אחרי כל התרעה

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

1. מגדירים קבוצת יעד: עמודי שירות, קטגוריות, מוצרים, מאמרים או דפי מיקום שאמורים להביא תנועה ופעולות.
2. מאתרים את המגמה: בודקים איזו קבוצה השתנתה ב־Page Indexing, מתי השינוי החל ואילו תבניות חוזרות בדוגמאות.
3. בוחרים מדגם: כמה כתובות שנפגעו, עמוד תקין מאותה תבנית ועמוד עסקי חשוב. URL אחד עלול להיות מקרה חריג.
4. בודקים את הכתובות: משווים ב־URL Inspection בין המידע האחרון של גוגל לבין Live Test, כולל תגובה, חסימות, קנוניקל ורינדור.
5. עולים לשכבה הרוחבית: בוחנים Crawl Stats,‏ robots.txt, מפות אתר, זמני תגובה ושינויים בשרת, ב־CDN, ב־WAF או בתבנית.
6. מתקנים את המחולל: אם הדפוס חוזר, מטפלים ברכיב המשותף ולא בכל כתובת בנפרד.
7. מאמתים ומנטרים: בודקים שוב את הגרסה החיה ואת תגובת השרת ועוקבים אחר המגמה. גם תיקון נכון אינו מבטיח אינדוקס מיידי.

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

טעויות נפוצות שמחליפות תקלה אחת באחרת

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

SEO טכני טוב אינו תחרות בהעלמת התרעות מ־Search Console. אפשר לנקות דוח שלם ועדיין להשאיר בחוץ את העמודים שמכניסים כסף. אפשר גם ״לתקן״ החרגה מכוונת ולפתוח לגוגל אלפי מסננים חסרי ערך.

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

• האם הכתובת באמת אמורה להופיע בתוצאות, ומה הערך העסקי שלה?
• באיזה שלב נמצאת הבעיה: גילוי, אחזור, רינדור, אינדוקס או בחירת קנוניקל?
• האם הכשל נקודתי, או שהוא משותף לתבנית שלמה או לנתיב שלם?
• איזה קוד HTTP מקבלים משתמש רגיל ו־Googlebot Smartphone?
• האם robots.txt,‏ noindex, הקנוניקל, הקישורים הפנימיים ומפת האתר משדרים אותה כוונה?
• מה השתנה סמוך לתחילת המגמה — פריסה, תוסף, CDN,‏ WAF, מבנה כתובות או מערכת JavaScript?
• האם התוכן המרכזי נמצא בגרסה המרונדרת גם כאשר שירות חיצוני מגיב לאט?
• האם גוגל בחרה כתובת חלופית, והאם הבחירה הזאת רצויה מבחינת העסק?
• איך תימדד ההצלחה: פחות שגיאות שרת, סריקה יציבה יותר, אינדוקס של קבוצת היעד או התאוששות בחשיפה?

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

הטיפ האישי שלי: כשהקנוניקל הצביע למקום הלא נכון

במבט חוזר: השגיאה היא רמז, לא פסק דין

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

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

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

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