«Discovered – currently not indexed» ו-«Crawled – currently not indexed» הן שתי השורות הנפוצות ביותר בדוח האינדוקס של העמודים ב-Search Console, וגם שתי השורות המובנות הכי פחות נכון. הן נראות כמו כשל טכני, אבל בדרך כלל מדובר בהחלטות עדיפות ואיכות ש-Google קיבל לגבי העמודים שלכם. שליחה חוזרת ונשנית לא תשנה את זה. תיקון הסיבה — כן.
המדריך הזה הוא הלולאה המלאה שאפשר למסור ל-Hermes Agent: שליפת רשימת כתובות ה-URL, בדיקת כל עמוד, טריאז' של הסיבה האמיתית, אישור תור תיקונים ושליחה רק של העמודים שראויים לאינדוקס דרך Google Indexing API. בסוף תקבלו pipeline שבועי שניתן לחזרה במקום מפגש חד-פעמי של לחיצות.
מה תשיגו בסוף
- מלאי מסווג: אילו כתובות URL תקועות ב-discovered, אילו ב-crawled-but-not-indexed, ואילו מעולם לא היו צריכות להישלח
- רשימת שליחה מאושרת שנשלחה ל-Indexing API, ועוד רשימת דילוג עם סיבות
- מעבר אימות שמראה אם השליחות שלכם באמת הזיזו את המחט
אתם צריכים: Hermes Agent מותקן ועובד (hermes chat פותח סשן; ראו את התיעוד הרשמי ב-hermes-agent.nousresearch.com/docs לשלבי ההתקנה העדכניים), הרשאת בעלים על נכס ב-Search Console, ושתי קבוצות של אישורי Google (אחת לקריאת GSC ואחת ל-Indexing API). תכננו 60–90 דקות להקמה בפעם הראשונה, ואחר כך כ-15 דקות לכל ריצה שבועית. «נגמר» אומר שכתובות ה-URL ששלחתם מראות תזוזה אמיתית בסטטוס ב-Inspection API תוך שבועיים, או שיש לכם הוכחה ברורה למה זה לא יקרה.
שתי הסטטוסות, בקריאה נכונה
Google לא תקוע על האתר שלכם. הוא קיבל החלטה, והסטטוס אומר לכם איזו החלטה.
סטטוס | מה זה אומר בפועל | סיבות נפוצות | מתי לשלוח |
|---|---|---|---|
Discovered – currently not indexed | Google יודע שהכתובת קיימת (מ-sitemap או מקישורים) אבל עוד לא זחל אליה | עדיפות זחילה נמוכה, קישורים פנימיים חלשים או חסרים, לחץ על תקציב הזחילה באתרים גדולים, אתר חדש לגמרי, רינדור JS איטי או כבד, sitemap שמשתנה כל הזמן | אחרי ששיפרתם את אותות העדיפות (בעיקר קישורים פנימיים), ואז פעם אחת |
Crawled – currently not indexed | Google אסף את הכתובת ובחר שלא להוסיף אותה לאינדקס | תוכן כפול או כמעט כפול, תוכן דליל, canonical שמצביע לכתובת אחרת, noindex בזמן הזחילה, soft 404, ערך נתפס נמוך | רק אחרי ששיניתם משהו בפועל: תוכן, canonical או noindex |
Indexed | היא באינדקס | — | לעולם לא |
Excluded | נזחל והושמט בכוונה (noindex, canonical, כפילות שנבחרה, חסימה) | — | לעולם לא; בדקו אם ההשמטה מכוונת |
החוק במשפט אחד: שלחו רק כתובות URL שבאמת שיניתן או שראויות למבט שני. Indexing API הוא ערוץ התראה, לא ביטול של דירוג. שליחת עמוד דליל דרכו 10 פעמים מחזירה את אותה החלטה 10 פעמים.
למה להריץ את זה ב-agent מלכתחילה
לכפתור «בקשת אינדוקס» של GSC אין API ציבורי, כך שאין דרך רשמית ללחוץ עליו דרך סקריפט. האוטומציה הקרובה ביותר היא Google Indexing API, שמקבל התראות כתובות URL ישירות. agent מרוויח את מקומו כאן משלוש סיבות:
- הלולאה מכנית וארוכה: מלאי → בדיקה → סיווג → תיקון → שליחה → אימות. היא חוזרת מדי שבוע.
- צריך שובל ביקורת: אתם רוצים קובץ שאומר אילו כתובות URL נשלחו, מתי ולמה.
- צריך שער אישור: החלק שכותב ל-Google צריך להיבדק על ידי אדם. Hermes בנוי סביב ההפרדה הזו בדיוק, עם skills, תיקיות פרויקט וחוקי אישור.
לפני שמתחילים: מה צריך
- Hermes Agent מותקן. בדקו עם
hermes chatלפני שממשיכים. - נכס GSC שבבעלותכם, בפורמט
sc-domain:example.com(לא כתובת ה-URL המלאה). - גישת קריאה: לקוח OAuth של Google Cloud ל-Search Console API (client ID + secret). סקריפטים של skill ה-GSC משתמשים בזה כדי לרשום sitemaps, להריץ ניתוחי חיפוש ולבדוק כתובות URL.
- גישת כתיבה: פרויקט Google Cloud עם Indexing API מופעל ומפתח JSON של service account. הוסיפו את אימייל ה-service account כבעלים תחת GSC ← הגדרות ← משתמשים והרשאות. אם השליחה מחזירה 403 — זה השלב שהוחמץ.
- Python 3 עם
pip install google-auth google-api-python-client. - תיקיית פרויקט, לדוגמה
/hermes-seo-project, עםcontext/,data/,qa/, ו-approval-rules.mdשמצהיר ששלב השליחה דורש תמיד חתימה אנושית.
שלב 1: בניית מלאי כתובות URL
העתיקו את שני ה-skills של GSC לתיקיית ה-skills של Hermes (~/.hermes/skills): את skill הקריאה (sitemaps, ניתוחי חיפוש, בדיקת כתובות URL) ואת skill האינדוקס (סקריפטי השליחה). Hermes יכול גם לטעון אותם דרך skill_view אם ה-harness כבר מקטלג אותם.
ואז בקשו מ-Hermes, בסשן צ'אט מתיקיית הפרויקט:
רשום את כל ה-sitemaps עבור sc-domain:example.com, אסוף כל כתובת URL עם תאריך ה-lastmod שלה, וכתוב את התוצאה ל-data/url-inventory.csv. סמן כל sitemap שנכשל באחזור.
Hermes מריץ את פקודת ה-sitemap דרך כלי הטרמינל שלו וכותב את ה-CSV. איך נראה פלט טוב: CSV ללא כפילויות עם URL, lastmod ו-sitemap המקור. בדיקת איכות: בדקו חמש שורות אקראיות והשוו את הספירה הכוללת לדוח ה-sitemap ב-GSC. אם הרשימה ריקה או שהאימות נכשל, הריצו שוב את זרימת האימות של GSC; סקריפטי הקריאה צריכים token OAuth חדש.
שלב 2: בדיקה וסיווג
עכשיו הסוכן בודק את המלאי בקבוצות דרך URL Inspection API, שמחזיר את מצב הכיסוי הנוכחי של כל עמוד. בקשו את השלב הבא:
בדוק כל כתובת URL ב-data/url-inventory.csv. חלק אותן לשלושה קבצים: data/to-submit.txt (לא מאונדקסות, ראויות לשליחה), data/skip.txt (עם שורת סיבה לכל כתובת URL), ו-data/needs-fix.txt (לא מאונדקסות וחסומות על ידי משהו שאנחנו יכולים לשנות).
ל-API הבדיקה יש מגבלת קצב לכל נכס (בדקו את המכסה הנוכחית שלכם ב-Google Cloud Console; מדובר באלפי בקשות ביום אבל לא בלתי מוגבל). לאתרים גדולים, הגבילו את המעבר הזה לכתובות URL עם תאריכי lastmod הכי חדשים — אלה שבאמת שיניתן ברבעון הזה. בדיקת איכות: דגמו את רשימת הדילוג. רובה צריך להיות noindex, canonical שמצביע למקום אחר וכפילויות, לא עמודים שחשובים לכם. אם הסוכן הפיק רשימת needs-fix ריקה באתר עם אלפי כתובות URL, כנראה ששלב המלאי החמיץ עמודים. הרחיבו את הקלט.
שלב 3: טריאז' לפני השליחה
זה השלב שאנשים מדלגים עליו. מפו כל כתובת URL תקועה לסיבה ולתיקון, בסדר הזה:
סיבה | תיקון | לשלוח אחרי התיקון? |
|---|---|---|
אין קישורים פנימיים לעמוד | הוסיפו קישורים הקשריים מעמודים קשורים ומאונדקסים | כן |
אתר או עמוד חדש לגמרי | אין מה לתקן; שלחו פעם אחת וחכו 1–2 שבועות | כן, פעם אחת |
חסימה ב-robots.txt | הסירו את החסימה מהנתיב | כן |
נזחל אבל כפול או דליל | כתבו מחדש, אחדו או הסירו את העמוד | רק אחרי שינוי תוכן אמיתי |
canonical מצביע לכתובת אחרת | תקנו את ה-canonical אם הוא שגוי; אם הוא מכוון, הפסיקו לשלוח את הכתובת הזו | רק אם תיקנתם |
noindex בזמן הזחילה | הסירו את ה-noindex ותנו ל-Google לזחול שוב | כן, אחרי ההסרה |
soft 404 או פאג'ינציה/ארכיון ללא ערך | תקנו את העמוד או הסירו אותו | לא — דילוג קבוע |
בקשו מ-Hermes לנסח את תור התיקונים כטבלה: URL, סיבה חשודה, ראיה (תוצאת הבדיקה או בדיקת תוכן), פעולה מוצעת, רמת סיכון. אשרו כל שורה בצ'אט. approval-rules.md שלכם צריך לחייב את זה: הסוכן מכין, אתם מאשרים, וכלום מעל סיכון נמוך לא נשלח בלי חתימה.
שער האישור מפריד בין ההכנה של הסוכן לשלב הכתיבה.
התיקונים עצמם הם עבודת SEO רגילה: כתיבה מחדש של תוכן, ניקוי canonical, קישורים פנימיים. ה-pipeline הזה מכסה את חצי השליחה; מאמרי הביקורת והרענון בסדרת Hermes מכסים את חצי התיקון.
רשימת השליחה היא החיתוך של «בר תיקון» ו«ראוי לאינדוקס».
שלב 4: שליחה דרך Indexing API
כשהתור מאושר, שימו את כתובות ה-URL ב-data/approved-urls.txt ותנו ל-Hermes להריץ את skill האינדוקס:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtסוג ההתראה כברירת מחדל הוא URL_UPDATED, וזה מה שאתם רוצים לעמודים חדשים או שהשתנו. שלושה מספרים שחשוב לזכור: המכסה כברירת מחדל היא 200 כתובות URL ביום ו-600 בקשות בדקה; ו-403 אומר שה-service account אינו בעלים של הנכס. אם הרשימה המאושרת עולה על 200, חלקו אותה על פני ימים; Hermes יכול לתזמן את הקבוצות הנותרות.
לעולם אל תשלחו עמודים שכבר מאונדקסים, ולעולם אל תשלחו את רשימת הדילוג. התראות מבוזבזות רק שורפות מכסה ויוצרות רעש.
שלב 5: אימות, ואז המתנה
מיד אחרי השליחה, status אומר לכם רק אם ל-Google יש מטא-דאטה להתראה שלכם, לא אם העמוד מאונדקס. הבדיקה האמיתית מגיעה ימים אחר כך.
בקשו מ-Hermes, 3–7 ימים אחרי הקבוצה:
בדוק שוב את כתובות ה-URL ב-data/approved-urls.txt ודווח על שינויי סטטוס בהשוואה לריצה האחרונה.
תנועה בריאה היא discovered → crawled → indexed. ככה זה נראה במשך כמה שבועות: רשימת הלא מאונדקסים מתכווצת, והתיקונים שבאמת עשיתם (קישורים פנימיים חדשים, טקסט שנכתב מחדש) מופיעים באינדקס. זכרו: נתוני GSC מגיעים בפיגור של כמה ימים, ו-Google מזחל שוב לפי לוח הזמנים שלו. כתובת URL שנשארת «Crawled – currently not indexed» במשך 10–14 ימים אחרי תיקון אמיתי היא אות איכות, לא בעיית שליחה. החזירו אותה לעבודת תוכן.
לשמור על הלולאה
הפכו את ה-pipeline לשגרה שבועית: כתובות URL חדשות ומעודכנות מאז הריצה האחרונה → בדיקה → סיווג → טריאז' → אישור → שליחה → לוג. Hermes יכול להריץ את החלקים לקריאה בלבד (מלאי, בדיקה, סיווג) ללא השגחה, לפי לוח זמנים, ולהציג לכם תור בכל יום שני. שמרו על שלב השליחה מאחורי שער האישור שלכם, ונהלו לוג שוטף ב-qa/indexing-log.md: תאריך שליחה, URL, סוג התראה, תוצאה. שישה חודשים של לוג כזה הם הדרך היחידה הכנה למדוד אם ה-pipeline עובד.
מגבלות כנות
- Google מתעד את Indexing API לעמודים עם נתונים מובנים של
JobPostingאוBroadcastEvent. השימוש בו לעמודים רגילים הוא נוהג SEO נפוץ, אבל Google לא מבטיח אינדוקס או תמיכה לכל סוג עמוד. - אין API ציבורי לכפתור «בקשת אינדוקס». Indexing API הוא האוטומציה הקרובה ביותר, לא אותו כפתור.
- שליחה לא יוצרת עדיפות. אם עמוד נשאר לא מאונדקס אחרי שתיקנתם אותו, שלחתם אותו וחיכיתם — התשובה הבאה היא איכות תוכן, לא התראה נוספת.
שאלות נפוצות
האם Indexing API עובד לעמודים רגילים? הוא מקבל כל כתובת URL שתשלחו אליו. התיעוד הרשמי של Google מגביל אותו לעמודי JobPosting ו-BroadcastEvent, אז התייחסו לשליחה של עמודים רגילים כאל best-effort: מועילה, נפוצה, ולעולם לא מובטחת.
למה הכתובת שלי נשארה «Discovered – currently not indexed» אחרי ששלחתי אותה? הסטטוס הזה אומר בדרך כלל עדיפות זחילה, לא כשל. בדקו קישורים פנימיים שמצביעים לעמוד, אם robots.txt חוסם את הנתיב, והאם העמוד כבד ב-JavaScript. ואז חכו: באתרים חדשים, מ-discovery לזחילה יכול לקחת שבוע-שבועיים.
האם 200 כתובות URL ביום מספיק? לרוב האתרים — כן, כי אתם אמורים לשלוח רק כתובות שבאמת שיניתן. אם יש לכם יותר בקביעות, תעדפו לפי ערך עסקי ובקשו הגדלת מכסה ב-Google Cloud Console.
האם Indexing API ידרג עמודים מהר יותר? לא. הוא מודיע ל-Google שכתובת URL השתנתה. החלטות הדירוג נפרדות, והן מתקבלות על ידי המערכות של Google, לא על ידי נפח ההתראות שלכם.
במה זה שונה מלחיצה על «בקשת אינדוקס» ב-Search Console? אותה כוונה, מנגנון שונה. הכפתור הוא ממשק בלבד ללא API ציבורי; Indexing API הוא הערוץ הניתן לסקריפט. אף אחד מהם לא מבטל את שיקול הדעת של Google בשאלה אם עמוד שייך לאינדקס.
הכותב: ג'וליאן מרסר, מומחה טכני לקידום אתרים ב-Auspia מזה 14 שנה. ג'וליאן כותב על יכולת זחילה, אינדוקס, סכמה והיסודות הטכניים שמאפשרים גם ל-Google וגם למערכות AI לקרוא אתר כמו שצריך.
