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

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

מתחילים מהמטרה של הבדיקה

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

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

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

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

דורשים להפריד בין תצפית למסקנה

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

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

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

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

בודקים מה המספר באמת סופר

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

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

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

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

ציון של כלי אינו ציון של Google

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

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

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

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

מתעדפים לפי השלכה, ביטחון ומאמץ

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

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

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

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

מבקשים מהספק להסביר מה יכול להמתין

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

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

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

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

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

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

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

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

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