דוח סטטוס AMP

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

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

פתיחת דוח AMP

 

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

 

אילו נתונים מופיעים בדוח

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

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

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

מה צריך לחפש

בדוח, עליכם להתמקד בנתונים הבאים:

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

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

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

בעיות ב-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. אם זה לא מה שרציתם, עליכם לבדוק את הקובץ 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 של דף אחר.
בוצעה הצהרה (declare) על סקריפט של מודול ללא חלופה של nonmodule (או להפך).	נעשה שימוש בתג מסוג <script type="module"‎> ללא תג <script nomodule async> תואם, או להפך. צריך להשתמש בתגים האלה בזוגות תואמים כדי לאפשר עיבוד תקין על ידי דפדפנים שתומכים בסקריפטים של מודולים או דפדפנים שלא תומכים בסקריפטים כאלה.
חסרה כתובת URL בתג HTML	תג ה-HTML שצוין צריך להכיל מאפיין עם כתובת URL תקינה שאורכה אינו אפס, אבל כתובת ה-URL היא מחרוזת ריקה. צריך לספק כתובת URL תקינה למאפיין המודגש.
המאפיין חסר או שגוי, אבל הוא נדרש על ידי המאפיין 'on'	המאפיין שצוין נדרש אבל שגוי או חסר. המאפיין הזה נדרש כי ציינת את המאפיין "on" באותו התג.
תג צאצא מסוג <svg> נמצא מחוץ לבלוק<svg>.	צוין תג מחוץ לבלוק <svg> שחייב להיות בתוך בלוק <svg>.
הדף טוען מספר גרסאות של אותו סקריפט של תוסף	הדף טוען מספר גרסאות של אותו תוסף 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 משתמש בפרוטוקול החלפה חתומה, עלולות להתרחש הבעיות הבאות.

• ההחלפה החתומה לא חוקית
• יש שגיאת ניתוח במטען הייעודי (payload) של ההחלפה החתומה
• בכותרת 'header_name' של המטען הייעודי (payload) של ההחלפה החתומה יש ערך לא חוקי
• חסרה כותרת החובה 'header_name' של המטען הייעודי (payload) של ההחלפה החתומה
• לא ניתן לנתח את כותרת החתימה של ההחלפה החתומה
• הפרמטר 'parameter_name' בכותרת החתימה של ההחלפה החתומה אינו חוקי
• התאריכים של ההחלפה החתומה לא חוקיים
• לא ניתן לנתח את שרשרת האישורים שההחלפה החתומה 'cert-url' מפנה אליה
• שרשרת האישורים בהפניה 'cert-url' אינה חוקית להחלפה החתומה
• לא ניתן לנתח את ההחלפה החתומה
• כתובת ה-URL של המטען הייעודי (payload) הפנימי לא תואמת לכתובת ה-URL של ההחלפה החתומה
• לכותרת 'header_name' של תגובת ה-HTTP של ההחלפה החתומה יש ערך לא חוקי

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

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

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

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

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

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

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

• הדף מכיל כותרת שאינה מורשית במפרט ההחלפות החתומות או במטמון ה-AMP של Google.
• המקור של validity-url אינו זהה למקור של fallbackUrl, לפי הדרישה של מפרט ההחלפות החתומות.
• הכותרות של התגובות החתומות של הדף אינן מקודדות באופן קנוני.

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

אם משתמשים ב-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. קיימות שתי סיבות נפוצות לשינוי:
  • הקוד עבר סריאליזציה באמצעות מדפסת ששונה מזו שבחבילה שקובצה על ידי AMP Packager. אם משתמשים במחולל אחר להחלפה חתומה, יש לוודא שהוא משתמש בספריית הטרנספורמרים של AMP Packager.
  • ה-HTML גורם לשגיאה בניתוח, המטופלת על ידי שינוי עץ הניתוח. בדרך כלל, השגיאות האלו נובעות מהשמטת תגי סיום או עקב מיקום שגוי של תגי סיום. דוגמאות לכך כוללות את אלגוריתם סוכנות האימוץ וטיפול בתג הסיום form. קשה לאבחן את השגיאות האלו. כלי תיקוף לתגי עיצוב של HTML עשוי לעזור באיתור הסיבה.
  • אם שללתם את כל האפשרויות המפורטות למעלה:
    • אם משתמשים בספק שירות של החלפה חתומה, יש להתייעץ איתו לקבלת סיוע.
    • אם משתמשים ב-AMP Packager:
      • מוודאים שרצה הגרסה האחרונה של AMP Packager.
      • אם כן, ייתכן שקיים באג ב-AMP Packager, ויש לדווח על באג.

בכותרת '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, ייתכן שזה יקרה מכמה סיבות:

• יש לוודא ששרת ה-reverse-proxy של ממשק הקצה משכתב כתובות URL כראוי. כשיש תווים עם קידוד של אחוזים או תווים מוזמנים, סביר להניח שיהיו בעיות. למשל, לשרת nginx יש בעיות עם הוראות השכתוב שלו ועם העיצוב חסר הנתיב של ההוראה proxy_pass שלו. כדי לבדוק זאת, שולחים מספר בקשות בדיקה לממשק הקצה, ומשווים ביניהן לבין כתובות ה-URL ש-AMP Packager רושם ב-stdout שלו.
• מוודאים שרצה הגרסה האחרונה של AMP Packager.
• אם שללתם את כל האפשרויות המפורטות למעלה, ייתכן שקיים באג ב-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. תיקון השגיאות: לוחצים על שורה בטבלה כדי להציג את דף הפרטים של השגיאה:
   1. דף הפרטים כולל דוגמאות של כתובות URL שהושפעו. הרשימה מוגבלת ל-1,000 שורות. יכול להיות שהיא לא תכלול מופעים של השגיאה הזו שהתגלו רק לאחרונה או דפים שלא נסרקו מחדש מאז שהשגיאה הופיעה.
   2. לתיעוד רשמי על השגיאה, לוחצים על מידע נוסף לצד הבעיה.
   3. בטבלה של כתובות ה-URL לדוגמה, לוחצים על כתובת URL כדי לראות את הבעיה מודגשת בקוד הדף.
   4. לוחצים על סמל הבדיקה כדי להריץ בדיקה מפורטת על דף ספציפי. הבדיקה הזו תצביע על כל השגיאות (לא רק על השגיאה הנוכחית) ותציע קוד שיאתר את השגיאות, ידגיש אותן ויספק מידע נוסף עליהן. אם הדף לא נסרק מחדש לאחרונה, תוכלו לראות את הבעיה בדף שנוסף לאינדקס אבל לא בדף הפעיל. במקרה כזה, אפשר לבקש להוסיף את הדף הספציפי הזה לאינדקס.
   5. מתקנים את כל מופעי הבעיה באתר, בודקים את התיקון ומוודאים שהתיקונים מופיעים באינטרנט.
4. לאחר תיקון כל המופעים, חוזרים לדף הפרטים של הבעיה ולוחצים על הלחצן אימות התיקון כדי להתחיל את תהליך האימות. התהליך אינו מיידי. מומלץ לעיין בקטע מידע על אימות כדי להבין את תהליך האימות.
5. ממשיכים בתיקון השגיאות.
6. אם המספר הכולל של דפים תקינים ולא תקינים נמוך באופן משמעותי ממספר דפי ה-AMP באתר, כדאי לעיין בקטע פתרון בעיות של דפי AMP חסרים.
7. לאחר תיקון כל השגיאות הקריטיות, כדאי לתקן את הבעיות שאינן קריטיות. חלק מהבעיות שאינן קריטיות (למשל, שימוש בתכונות שהוצאו משימוש) עשויות להפוך לקריטיות בהמשך.

שיתוף הדוח

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

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

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

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

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

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

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

למה כדאי לאמת

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

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

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

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

טיפ למתקדמים: אימות התיקונים באמצעות sitemap

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

איך להתחיל את האימות

כדי להודיע ל-Search Console שפתרתם בעיה:

1. מתקנים את כל המופעים של הבעיה באתר שלכם. אם מופע כלשהו לא תוקן, האימות יופסק כאשר Google תמצא מופע יחיד של הבעיה שנותר.
2. פותחים את דף הפרטים של הבעיה שתיקנתם. לוחצים על הבעיה ברשימת הבעיות בדוח.
   • ⚠️ אם אתם מבצעים סינון ל-sitemap מסוים בדוח, האימות יחול רק על פריטים שנכללים ב-sitemap בזמן בקשת האימות. יכול להיות שזה מה שאתם רוצים ויכול להיות שלא. חשוב להיות מודעים לזה.
3. לוחצים על אימות התיקון. אל תלחצו שוב על 'אימות התיקון' עד שהאימות יסתיים בהצלחה או ייכשל. בקישור הבא מוסבר איך Google בודקת את התיקונים.
4. אתם יכולים לעקוב אחר ההתקדמות של תהליך האימות. בדרך כלל, תהליך האימות נמשך עד כשבועיים, אבל במקרים מסוימים הוא יכול להימשך זמן רב יותר ולכן צריך להתאזר בסבלנות. אתם תקבלו הודעה כשהאימות יסתיים בהצלחה או ייכשל.
5. אם האימות נכשל, לוחצים על לפרטים בדף פרטי הבעיה כדי לראות איזו כתובת URL גרמה לכישלון האימות. מתקנים את הדף הזה, מאשרים את התיקון בכל כתובות ה-URL שבמצב בהמתנה ומתחילים מחדש את האימות.

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

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

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

משך החיים של בעיה

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

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

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

תהליך האימות

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

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

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

אימות מחדש

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

כדי להתחיל מחדש אימות שנכשל:

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

הצגת ההתקדמות בתהליך האימות

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

1. פותחים את דף הפרטים של הבעיה. לוחצים על שורת הבעיה בדף הראשי של הדוח כדי לפתוח את דף הפרטים של הבעיה.
   • הסטטוס של בקשת האימות מוצג גם בדף הפרטים של הבעיה וגם בשורה אימות שבטבלה 'פרטים'.
2. לוחצים על לפרטים כדי לפתוח את דף פרטי האימות של הבקשה הזאת.
   • סטטוס המופע של כל כתובת URL שכלולה בבקשה מוצג בטבלה.
   • סטטוס המופע חל על הבעיה הספציפית שבודקים. יכול להיות מצב שבו בעיה אחת מסומנת בסטטוס עבר בדף, ובעיות אחרות מסומנות בסטטוסים נכשל, בהמתנה או אחר באותו דף.
   • בדוח AMP ובדוח ההוספה של דפים לאינדקס, הרשומות בדף של היסטוריית האימות מקובצות לפי כתובת URL.
   • בדוח 'תוצאות חיפוש מתקדמות', הפריטים מקובצים לפי השילוב של כתובת URL ופריט נתונים מובְנים (כפי שנקבע על ידי ערך השם של הפריט).

סטטוס של בקשת אימות

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

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

סטטוס של אימות מופע

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

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

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

 

בעיות ידועות

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

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