דוח סטטוס AMP

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

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

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

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

פתיחת דוח AMP

 

דוח סטטוס AMP ב-Search Console – הדרכה בנושא Google Search Console

מה צריך לחפש

במצב אידאלי, זה מה שיופיע בדוח:

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

רשימה של בעיות AMP

נוסף לשגיאות AMP רגילות, הדוח יכול לחשוף את סוגי הבעיות הבאות (שגיאות או אזהרות).

בעיות AMP ספציפיות ל-Google
הבעיה תיאור
אי התאמה בתוכן: חסר סרטון מוטמע דף האינטרנט הקנוני מכיל סרטון מוטמע שחסר בגרסת ה-AMP. בדרך כלל, מומלץ לכלול בגרסת ה-AMP את אותם משאבי תוכן חשובים שנמצאים בדף האינטרנט הקנוני. לתשומת ליבכם: הסרטון מזוהה לפי כתובת אתר. אם יש לכם שתי כתובות URL שונות שמפנות לאותו סרטון, תוצג האזהרה הזו.
התמונה קטנה מהגודל המומלץ הנתונים המוּבְנִים בגרסת ה-AMP מתייחסים לתמונה שקטנה יותר מהגודל המומלץ שלנו. עובדה זו עלולה למנוע את הצגת הדף לצד כל התכונות הקשורות ל-AMP בחיפוש Google. ייתכן גם שכרטיסי Discover לא יופיעו עם תמונות גדולות (הדבר יוביל לצמצום של התנועה באתר ושל מעורבות משתמשים). כדי לתקן זאת, יש להשתמש בתמונה גדולה יותר בהתאם להנחיות שלנו.
אי-התאמה בין דומיינים של דפי AMP דף ה-AMP מתארח בדומיין שונה מדומיין הגרסה הקנונית שלו. זה עלול לבלבל משתמשים המבצעים חיפוש בנייד ונתקלים בכתובת אתר דומיין אחת בתוצאות החיפוש ובכתובת אחרת כשפותחים את הדף בקורא של דפי AMP. (הדבר אינו משפיע על יצירת האינדקס של דפים או על הדירוג שלו).
כתובת האתר לא נמצאה (404) לא הייתה אפשרות למצוא את כתובת הדף המבוקשת של AMP. מידע על תיקון דפי 404.
שגיאת שרת (5xx) שגיאת שרת 5XX לא מוגדרת בעת בקשה של דף ה-AMP. למידע נוסף על שגיאות שרת.
נחסמה על ידי robots.txt כתובת הדף המבוקשת של AMP נחסמה על ידי כלל robots.txt.
בעיית סריקה שגיאת סריקה לא מזוהה לדף ה-AMP. אפשר להשתמש בכלי לבדיקת כתובות URL על כתובת של דף ה-AMP כדי לפתור את הבעיה. 
כתובת דף ה-AMP המצוינת אינה AMP דף קנוני מפנה אל AMP שלמעשה אינו דף AMP. כיצד דף שאינו AMP צריך להפנות לדף AMP.
כתובת דף ה-AMP המצוינת היא AMP קנוני עצמי הדף הקנוני מפנה אל דף AMP עצמאי. לא ניתן להפנות ל-AMP עצמאי כגרסת ה-AMP של דף כלשהו. כך מפנים אל AMP מדף שאינו AMP.
כתובת הדף מסומנת כ-noindex דף AMP נחסם על ידי הוראת noindex‏. Google לא יכולה להוסיף לאינדקס דף שנחסם על ידי noindex. צריך להסיר את ההוראה noindex, או להסיר את ההפניה אל הדף החסום.
עבר התאריך של 'unavailable_after' לדף זה לדף ה-AMP יש מטא תג או הוראה של תאריך unavailable_after שכבר חלף, מה שמציין שאין להציגו יותר. יש לעדכן את התג לתאריך עתידי או להסיר את התג.
הדף הקנוני מוביל לכתובת URL לא תקינה דף קנוני מפנה לגרסת AMP באמצעות כתובת URL בפורמט לא חוקי. כאן מפורטת הדרך הנכונה להפנות לגרסת AMP.
שגיאה קנונית של סטורי ב-AMP

דף מפנה בצורה שגויה אל דף סטורי ב-AMP כגרסת ה-AMP שלו. פעולה זו אסורה כי דף סטורי ב-AMP מוגדר כדף קנוני עצמי: הוא חייב להפנות אל עצמו באמצעות תג <rel="canonical"> ולא יכול לשמש כגרסת AMP של דף אחר.

בעיות בהחלפה חתומה

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

כדי להציג פרטים על החלפה חתומה לגבי בעיה

ניתן למצוא מידע על החלפה חתומה שמשויכת ל-AMP במספר מקומות:

  • בכלי לבדיקת כתובות URL, לוחצים על הבעיה שבקטע פרטי גרסת AMP.
  • בדוח סטטוס AMP, לוחצים על כתובת URL בטבלה של פרטי הבעיות.

כדי לבדוק אם דף ה-AMP משתמש בהחלפה חתומה

כדי לבדוק אם Google זיהתה כותרות או מטענים ייעודיים (payload) של החלפה חתומה ל-AMP:

  1. בודקים את כתובת ה-URL של ה-AMP (משתמשים בכלי לבדיקת כתובות URL כדי לבדוק כתובת URL ספציפית, או בדוח סטטוס AMP, לוחצים על סמל הבדיקה לצד כתובת ה-URL בטבלה של פרטי הבעיות).
  2. לוחצים על להצגת הדף שנסרק בדף התוצאות כדי לפתוח חלונית צדדית עם מידע נוסף.
  3. לוחצים על הכרטיסייה מידע נוסף.
  4. מתחת לתווית החלפה חתומה יוצג סטטוס שמציין אם Google זיהתה רכיבים כלשהם של החלפה חתומה לאותו AMP.

רשימת בעיות בהחלפה חתומה

אם דף ה-AMP משתמש בפרוטוקול החלפה חתומה, עלולות להתרחש הבעיות הבאות.

ההחלפה החתומה לא חוקית

תגובת ה-HTTP הייתה החלפה חתומה שלא עמדה בדרישות של מטמון AMP של Google. כתוצאה מכך, הדף יוצג למשתמשים ללא מידע מהחתימה.

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

יש שגיאת ניתוח במטען הייעודי (payload) של ההחלפה החתומה

תגובת ה-HTTP הייתה החלפה חתומה ש"המטען הייעודי" (payload, הגוף) שלה לא עמד בדרישות של מטמון AMP של Google. כתוצאה מכך, הדף יוצג למשתמשים ללא מידע מהחתימה.

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

השגיאה עשויה להתרחש עקב כמה סיבות:

  • יש לוודא שה-HTML לא מכיל קידוד UTF-8 לא חוקי. בשביל $URL עם שגיאות, יש להריץ curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null, ולחפש הודעות שגיאה כמו “רצף קלט לא חוקי”. אם יש, עליכם לוודא שקידוד ה-UTF-8 של המסמך תקין. שני מקורות נפוצים לתווים עם מספר בייטים הם טקסטים שאינם באנגלית ורווחים.
  • יש לוודא שה-HTML לא מכיל תו Unicode או U+0000 NULL שגורמים לשגיאה בניתוח HTML.
  • יש לוודא שה-HTML לא משתנה לאחר ההפעלה של transform -config NONE. קיימות שתי סיבות נפוצות לשינוי:

בכותרת 'header_name' של המטען הייעודי (payload) של ההחלפה החתומה יש ערך לא חוקי

תגובת ה-HTTP הייתה החלפה חתומה שהכילה כותרת תגובה חתומה שלא עמדה בדרישות של מטמון AMP של Google. כתוצאה מכך, הדף יוצג למשתמשים ללא מידע מהחתימה.

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

חסרה כותרת החובה 'header_name' של המטען הייעודי (payload) של ההחלפה החתומה

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

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

לא ניתן לנתח את כותרת החתימה של ההחלפה החתומה

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

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

הפרמטר 'parameter_name' בכותרת החתימה של ההחלפה החתומה אינו חוקי

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

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

התאריכים של ההחלפה החתומה לא חוקיים

תגובת ה-HTTP הייתה החלפה חתומה שכותרת החתימה שלה הכילה ערך שגוי בפרמטר date או expires, לפי מפרט ההחלפות החתומות או הדרישות של מטמון AMP של Google (שימו לב שהחתימה חייבת להיות תקפה בזמן האחזור שלה, ולפחות לעוד 4 ימים לאחר מכן). כתוצאה מכך, הדף יוצג למשתמשים ללא מידע מהחתימה

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager, ייתכן שזה יקרה מכמה סיבות:

  • יש לוודא ששרת ה-reverse-proxy של ממשק הקצה לא שומר במטמון תגובות של החלפה חתומה לזמן ממושך מדי. מבצעים מספר בקשות לדף באמצעות curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' ומחפשים אחר "date=‎" בכל תגובה. יש לוודא שהמספר העוקב שונה בכל פעם.
  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם שללתם את כל האפשרויות המפורטות למעלה, ייתכן שקיים באג ב-AMP Packager, ויש לדווח על באג.

לא ניתן לנתח את שרשרת האישורים שההחלפה החתומה 'cert-url' מפנה אליה

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

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager:

  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם כן, יש לדווח על באג.

שרשרת האישורים בהפניה 'cert-url' אינה חוקית להחלפה החתומה

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

כך האתר שלכם יושפע:

הדף יוצג במציג ה-AMP עם כתובת URL של Google, במקום כתובת ה-URL המקורית שלו.

השלבים הבאים:

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

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager, השגיאה הזו עשוי להתרחש מכמה סיבות. כדאי לבדוק את הדברים הבאים:

  • יש לוודא כי CertFile לא מכיל רשימה מלאה של אישורי קצה וביניים.
  • יש לוודא כי AMP Packager לא הופעל עם הסימון ‎-development או ‎-invalidcert. במצב הייצור, AMP Packager יאמת מספר אספקטים של האישור.
  • יש לוודא ששרת ה-reverse-proxy של ממשק הקצה לא שומר במטמון כתובות URL של /amppkg/cert/ לזמן ממושך יותר מזה שהוגדר בתור הגיל המקסימלי שלהן.
  • יש לוודא ששרת ה-reverse-proxy של ממשק הקצה לא משנה כותרות מטמון. זה עלול לגרום לשרת upstream proxy לשמור במטמון את שרשראות האישורים לזמן ממושך מדי. כדי לבדוק זאת, קובעים מהי כתובת ה-URL התואמת של /amppkg/cert/ בדומיין ה-packager הפנימי, מאחזרים אותה יחד עם כותרות התגובות (למשל, באמצעות curl -i), ומשווים את כותרות התגובות לאלו שהוחזרו משרת ממשק הקצה.
  • יש לוודא שהאישור מכיל SCT. למשל, באמצעות הכלי openssl x509. אם לא, יש להתייעץ עם רשות האישורים.
  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם שללתם את כל האפשרויות המפורטות למעלה, ייתכן שקיים באג ב-AMP Packager, ויש לדווח על באג.

לא ניתן לנתח את ההחלפה החתומה

תגובת ה-HTTP הכילה סוג תוכן application/signed-exchange;v=b3, אבל לא ניתן היה לשלוף את גוף התגובה. ייתכן שהסיבה לכך היא שהתגובה לא עמדה בדרישות הגבוהות של הסוג הזה, או שהמטען הייעודי (payload) שלה הכיל קידוד Merkle שגוי.

כך האתר שלכם יושפע:

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

השלבים הבאים:

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager, ייתכן שזה יקרה מכמה סיבות:

  • יש לוודא ששרת ה-reverse-proxy של ממשק הקצה לא משנה את התגובות מה-packager. לכתובת ה-URL עם השגיאות, קובעים את כתובת ה-URL התואמת /priv/doc בדומיין ה-packager הפנימי, ובודקים אותה באמצעות dump-signedexchange. אם תגובת ה-packager הפנימית היא החלפה חתומה חוקית אבל התגובה החיצונית של ממשק הקצה לא חוקית, כנראה שיש שגיאת הגדרה בממשק הקצה.
  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם שללתם את כל האפשרויות המפורטות למעלה, ייתכן שקיים באג ב-AMP Packager, ויש לדווח על באג.

כתובת ה-URL של המטען הייעודי (payload) הפנימי לא תואמת לכתובת ה-URL של ההחלפה החתומה

תגובת ה-HTTP הייתה החלפה חתומה עם fallbackUrl שלא תואמת לכתובת ה-URL שבבקשה. הן חייבות להיות זהות בכל בייט. כתוצאה מכך, התגובה שמייצגת את כתובת ה-URL שבבקשה תיחשב כלא אמינה בחיפוש Google.

כך האתר שלכם יושפע:

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

השלבים הבאים:

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

אם משתמשים ב-AMP Packager, ייתכן שזה יקרה מכמה סיבות:

לכותרת 'header_name' של תגובת ה-HTTP של ההחלפה החתומה יש ערך לא חוקי

תגובת ה-HTTP הכילה סוג תוכן application/signed-exchange, אבל כותרות התגובות לא היו חוקיות באופן אחר. למשל, ייתכן שחסר הפרמטר v=b3 בסוג התוכן. כתוצאה מכך, הפורמט לא ידוע ל-Google ולכן לא ניתן לשלוף את גוף התגובה.

כך האתר שלכם יושפע:

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

השלבים הבאים:

אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.

אם משתמשים ב-AMP Packager, ייתכן שזה יקרה מכמה סיבות:

  • יש לוודא ששרת ה-reverse-proxy של ממשק הקצה לא משנה את הכותרות של סוג התוכן. לכתובת ה-URL עם השגיאות, קובעים את כתובת ה-URL התואמת /priv/doc בדומיין ה-packager הפנימי, ומאחזרים אותה יחד עם כותרות התגובות (למשל, באמצעות curl -i). אם הכותרות של תגובת ה-packager הפנימית והתגובה החיצונית של ממשק הקצה שונות, ייתכן שזהו מקור השגיאה. אם השוני הוא בכותרת שאינה content-type, יש לדווח על באג במסמך העזרה הזה כדי לעדכן את רשימת הדרישות.
  • מוודאים שרצה הגרסה האחרונה של AMP Packager.
  • אם שללתם את כל האפשרויות המפורטות למעלה, ייתכן שקיים באג ב-AMP Packager, ויש לדווח על באג.

תעדוף בעיות ותיקונן

  1. בדף המסכם את דפי ה-AMP, מסננים את דפי האזהרה ומתמקדים תחילה בשגיאות. כברירת מחדל, השגיאות מסודרות לפי שקלול מידת החומרה, מצב האימות ומספר הדפים שהושפעו מהשגיאה. מומלץ לטפל בשגיאות לפי סדר ברירת המחדל הזה. תחילה מתקנים את השגיאות הנגרמות מסיבה שכיחה (לדוגמה, שימוש בתבנית שגויה), ואחר כך מתקנים שגיאות ייחודיות לכל דף.
  2. כדאי לבדוק אם עלייה במספר הכולל של השגיאות נגרמת בעיקר בגלל שגיאה אחת: אפשר לחפש בטבלה עלייה תואמת ביחס לאותה שגיאה.
  3. מומלץ לעיין במידע שבהמשך על ניפוי באגים בשגיאות שהביאו לעליות חדות בנתוני הטבלה ועל דפי AMP חסרים.
  4. כדי לצפות בדף פרטי השגיאה, לוחצים על שורה בטבלה:
    1. דף הפרטים כולל דוגמאות של כתובות URL שהושפעו מהשגיאה. הרשימה לא תמיד מלאה, כיוון שהיא מוגבלת ל-1,000 שורות וייתכן שלא תכלול מופעים של השגיאה שהתגלו רק לאחרונה.
    2. אם מדובר בשגיאת תחביר, לוחצים על מידע נוסף לקבלת תיעוד רשמי על התחביר התקין.
    3. לוחצים על סמל הבדיקה כדי להריץ בדיקת תוקף על דף רלוונטי. בדיקה זו תצביע על כל השגיאות (לא רק על הנוכחית) ותציע קוד שיאתר את השגיאות, ידגיש אותן ויספק מידע נוסף עליהן. ייתכן ששגיאה כבר תוקנה בדף הפעיל אך עדיין מופיעה ברשימת השגיאות, כיוון שטרם נסרקה מחדש. במקרה זה יש לבקש אימות לאחר תיקון כל המופעים של הבעיה.
  5. מתקנים את כל מופעי הבעיה באתר, בודקים את התיקון ומוודאים שהתיקונים מופיעים באינטרנט.
  6. חוזרים לדף פרטי הבעיה ולוחצים על הלחצן אימות התיקון כדי להתחיל את תהליך האימות. התהליך אינו מיידי. מומלץ לעיין בקטע מידע על אימות כדי להבין את תהליך האימות.
  7. ממשיכים בתיקון השגיאות.
  8. לאחר תיקון כל השגיאות, מבטלים את סינון דפי האזהרה ושוקלים אם לתקן גם את האזהרות. אזהרות מסוימות מתייחסות להיעדר תגי עיצוב אופציונליים של נתונים מובְנים, המאפשרים הפעלה של תכונות חיפוש חדשות לדפים עם תוכן רלוונטי.

שיתוף הדוח

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

ייצוא של נתוני הדוח

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

עלייה חדה במספר השגיאות

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

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

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

פתרון הבעיה של דפי AMP חסרים

אם הספירה של דפי ה-AMP (חוקיים + אזהרות + שגיאות) בדוח קטנה מהספירה של דפי ה-AMP באתר שלכם, ייתכן שזה נובע מאחת הסיבות הבאות:

  • מוודאים שהדפים הקנוניים שאינם דפי AMP מקושרים באופן תקין לדף ה-AMP.
  • מוודאים שדפי ה-AMP או הדפים הקנוניים אינם חסומים על ידי קובץ robots.txt או בלתי ניתנים להוספה לאינדקס, או מוגנים על ידי מנגנוני אימות או דרישות כניסה.
  • מחפשים ב-Google את כתובת האתר של הדף הקנוני, וכך בודקים אם דפי ה-AMP והדפים הקנוניים נמצאים באינדקס. אם הדפים לא עולים ברשימת החיפוש, הם לא כלולים באינדקס.
  • האם דפי ה-AMP והדפים הקנוניים מקושרים על ידי דפים אחרים? האם הם רשומים ב-sitemap? כדי לבקש הוספה של כמות קטנה של דפי AMP לאינדקס, מומלץ להשתמש בכלי לבדיקת כתובות URL. אם מדובר בכמות גדולה של דפים, כדאי להשתמש בקובצי sitemap (ב-sitemap מציינים רק את הדפים הקנוניים). כששולחים sitemap, מומלץ לשקול שימוש בדוח קובצי Sitemap.
  • ייתכן שיחלוף זמן מה עד שהדפים החסרים יימצאו וייסרקו על ידי Google, בהתאם לאופן שבו אתם מעדכנים את Google לגבי הדפים החדשים.
  • ייתכן שחלק מדפי ה-AMP התקינים לא ייכללו בדוח זה, למרות שהם רשומים בדוח הדפים הנכללים באינדקס. זאת מכיוון שדוח הדפים הנכללים באינדקס חייב להיות מקיף יותר כדי שאפשר יהיה להיעזר בו בניפוי באגים בבעיות הוספה לאינדקס. לעומת זאת, דוח סטטוס ה-AMP עשוי לכלול פחות דפים, שיהיו יותר רלוונטיים, באופן יותר מפורט, כדי שתוכלו להיעזר בו לניפוי באגים בבעיות ספציפיות שקשורות ל-AMP באתר. כדי לבדוק אם דף AMP נוסף לאינדקס, משתמשים בכלי לבדיקת כתובות URL, בו תופיע התשובה הסופית.

הסבר על אזהרות

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

מידע על אימות

לאחר תיקון כל המופעים של בעיה ספציפית באתר, אפשר לבקש מ-Google לאמת את השינויים. אם כל המופעים הידועים ייעלמו, הבעיה תסומן כ"תוקנה" בטבלת הסטטוסים ותרד לתחתית הטבלה. Search Console עוקב אחר מצב האימות של הבעיה בכללותה, ואחר המצב של כל מופע של הבעיה. כשכל המופעים של הבעיה נעלמים, הבעיה נחשבת כ"תוקנה" (למידע על מצבים שנרשמו בפועל, אפשר להיכנס לקישורים: מצב אימות הבעיה ומצב אימות המופע).

מידע נוסף על משך החיים של בעיה...

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

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

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

תהליך האימות הבסיסי

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

  1. כשלוחצים על אימות התיקון, מיד נבדקים כמה דפים ב-Search Console.
    • אם המופע הנוכחי קיים באחד מהדפים האלה, תהליך האימות מסתיים ומצב האימות נשאר ללא שינוי.
    • אם הדפים שנדגמו לא כוללים את השגיאה הנוכחית, תהליך האימות ממשיך ועובר למצב התחיל. אם בתהליך האימות מתגלות בעיות אחרות שאינן קשורות, בעיות אלה נספרות לטובת אותו סוג בעיה והאימות ממשיך.
  2. תהליך האימות של Search Console מסתמך על רשימה של כתובות אתרים הידועות ככאלה שהושפעו מבעיה זו. רק כתובות אתרים הכוללות מופעים ידועים של בעיה זו ממתינות בתור לסריקה מחדש, ולא האתר כולו. Search Console מתעד את כל כתובות האתרים שנבדקו בהיסטוריית האימות. ניתן לעבור לקטע זה מדף הפרטים של הבעיה.
  3. כשכתובת אתר נבדקת:
    1. אם הבעיה לא מתגלה, מצב האימות של המופע משתנה לעבר. אם זהו המופע הראשון שנבדק לאחר תחילת האימות, מצב האימות של הבעיה משתנה לנראה טוב.
    2. אם לא ניתן להיכנס יותר לכתובת האתר, מצב האימות של המופע משתנה לאחר (זהו לא מצב שגיאה).
    3. אם המופע עדיין קיים, מצב הבעיה משתנה לנכשל ותהליך האימות מסתיים. אם מדובר בדף חדש שהתגלה במהלך סריקה רגילה, הוא ייחשב כמופע נוסף של הבעיה הקיימת.
  4. כשכל כתובות האתרים הכוללות שגיאות ואזהרות נבדקות ומספר הבעיות עומד על 0, מצב הבעיה משתנה לעבר. חשוב: גם אם מספר הדפים שהושפעו ירד ל-0 ומצב הבעיה השתנה לעבר, תווית החומרה המקורית עדיין תוצג (שגיאה או אזהרה).

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

מתי בעיה בכתובת אתר או בפריט נחשבת כ"תוקנה"?

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

  • כשכתובת האתר נסרקה והבעיה לא נמצאה עוד בדף. במקרה של שגיאה בתג AMP, ייתכן שהתג תוקן או הוסר (אם התג לא נדרש). במהלך ניסיון אימות, מצב הבעיה יהיה "עבר".
  • אם הדף אינו זמין לסריקה של Google מכל סיבה שהיא (הדף הוסר, סומן בתור noindex, דורש אימות וכו'), הבעיה בכתובת האתר הזו תיחשב כ"תוקנה". במהלך ניסיון אימות, מצב הבעיה יהיה "אחר".

אימות מחדש

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

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

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

היסטוריית האימות

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

רשומות בדף ההיסטוריה של האימות מקובצים לפי כתובת אתר בדוח AMP ובדוח 'סטטוס אינדקס'. בדוחות 'נוחות השימוש לניידים' ו'תוצאת חיפוש מתקדמת', פריטים מקובצים לפי השילוב של כתובת אתר יחד עם פריט נתונים מוּבְנִים (כפי שנקבע בערך השם של הפריט). מצב האימות חל על הבעיה המסוימת שנבדקת. אפשר שבעיה אחת בדף תסומן בתווית "עבר", אך בעיות אחרות יסומנו בתוויות "נכשל", "בהמתנה" או "אחר".

מצב אימות הבעיה

מצבי האימות הבאים חלים על בעיה נתונה:

  • לא התחיל: יש דף אחד לפחות הכולל מופע של בעיה זו, ומעולם לא התחלתם ניסיון אימות עבורו. השלבים הבאים:
    1. לוחצים על הבעיה כדי לעיין בפרטי השגיאה. בודקים כל דף בנפרד כדי לראות דוגמאות של השגיאה בדף פעיל באמצעות בדיקת ה-AMP. (אם בדיקת ה-AMP לא מציגה את השגיאה בדף, הסיבה לכך היא שתיקנתם את השגיאה בדף הפעיל לאחר ש-Google מצאה את השגיאה והפיקה את דוח הבעיה הזה).
    2. לוחצים על 'מידע נוסף' בדף הפרטים כדי להציג את הפרטים של הכלל שהופר.
    3. לוחצים על שורה של כתובת אתר לדוגמה בטבלה כדי לקבל פרטים לגבי השגיאה הספציפית הזו.
    4. מתקנים את הדפים ולאחר מכן לוחצים על אימות תיקון כדי לבקש מ-Google לסרוק אותם מחדש. Google תודיע לכם על ההתקדמות של תהליך האימות. תהליך האימות נמשך בין מספר ימים לשבועיים, לכן צריך להתאזר בסבלנות. 
  • התחיל: התחלתם ניסיון אימות ועדיין לא נמצאו מופעים של הבעיה שנותרו. השלב הבא: Google תשלח לכם הודעות לגבי ההתקדמות של תהליך האימות שיציינו מה עליכם לעשות, במידת הצורך.
  • נראה טוב: התחלתם ניסיון אימות וכל מופעי הבעיה שנבדקו עד כה תוקנו. השלב הבא: לא נדרשת פעולה מצידכם. עם זאת, Google תשלח לכם הודעות לגבי ההתקדמות של תהליך האימות שיציינו מה עליכם לעשות, במידת הצורך.
  • עבר: כל המופעים הידועים של הבעיה נעלמו (או שכתובת האתר שהושפעה לא זמינה יותר). קרוב לוודאי שלחצתם על "אימות תיקון" כדי להגיע למצב זה (אם המופעים היו נעלמים מבלי ששלחתם בקשה לאימות, המצב היה משתנה ל"לא רלוונטי"). השלב הבא: לא נדרשת כל פעולה נוספת מצידכם.
  • לא רלוונטי: Google גילתה שהבעיה תוקנה בכל כתובות האתרים, אף על פי שמעולם לא התחלתם ניסיון אימות. השלב הבא: לא נדרשת כל פעולה נוספת מצידכם.
  • נכשל: סף מסוים של דפים עדיין כוללים בעיה זו אחרי שלחצתם על "אימות". השלבים הבאים: עליכם לתקן את הבעיה ולבקש אימות מחדש.

מצב אימות המופע

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

  • אימות בהמתנה: המופע ממתין בתור לאימות. בפעם האחרונה ש-Google בדקה, מופע זה עדיין היה קיים.
  • עבר: [מצב זה לא זמין בכל הדוחות] Google בדקה ומצאה שמופע הבעיה לא קיים יותר. ניתן להגיע למצב זה רק אם לוחצים בצורה מפורשת על אימות של מופע זה.
  • נכשל: לאחר בדיקה, Google גילתה שמופע הבעיה עדיין קיים. ניתן להגיע למצב זה רק אם לוחצים בצורה מפורשת על אימות של מופע זה.
  • אחר: [מצב זה לא זמין בכל הדוחות] Google לא הצליחה להיכנס לכתובת ה-URL המארחת את המופע, או (בנתונים מוּבְנִים) לא הצליחה למצוא את הפריט בדף. המצב הזה זהה למצב עבר.

הערה: לאותה כתובת URL יכולים להיות מצבים שונים לבעיות שונות. לדוגמה, אם בדף אחד קיימות בעיה X וגם בעיה Y, בעיה X יכולה להיות במצב אימות עבר, ואילו בעיה Y באותו הדף יכולה להיות במצב אימות בהמתנה.

 

בעיות ידועות

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

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