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

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

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

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

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

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

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

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

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

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

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

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

בודקים גישה לפני איכות

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

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

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

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

מפרידים בין הוראה מכוונת לטעות בתבנית

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

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

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

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

בודקים לאן ההפניה או ה-canonical מובילים

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

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

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

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

סטטוס אינו אבחון מלא של התוכן

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

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

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

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

מעבירים לפיתוח חבילת ראיות

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

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

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

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