איך לתקן כתובות URL במצב «Discovered / Crawled – Currently Not Indexed» עם DeepSeek Harness

DeepSeek Harness (dsh) מריץ סוכנים שיכולים לעשות עבודה אמיתית, ומעט עבודות SEO מתאימות לו יותר מאשר pipeline של כתובות URL לא מאונדקסות: לקרוא רשימה, לבדוק כל כתובת URL, לסווג, לחכות לאישור, לשלוח, לאמת. כל שלב הוא פקודה או קובץ — וזה בדיוק התחום שבו סוכן harness טוב.

שתי שאלות קובעות איך תגדירו את זה. רוצים קבוצה חד-פעמית שאפשר לסקריפט ולהכניס ל-cron? הריצו headless. רוצים לראות את זה עובד, לענות לשאלות שלו ולאשר כל קבוצה בחלון צ'אט? השתמשו ב-Web UI. המדריך הזה מציג את שני המסלולים, וה-pipeline מתחתיהם זהה. אם אתם רוצים את ההסבר המעמיק של מה «Discovered – currently not indexed» ו-«Crawled – currently not indexed» אומרות בפועל ואיך קוראים אותן, סיפרנו על זה בגרסת Hermes Agent של זרימת העבודה הזו; כאן אנחנו מתמקדים בביצוע דרך dsh.

בחירת המסלול

Headless לקבוצות, Web UI לריצות ראשונות — אותו pipeline מתחת.

שני המסלולים חולקים חוק אחד: שלב הכתיבה (שליחה ל-Google) נשאר מאחורי שער אישור אנושי. במצב headless זה אומר שבודקים את הקובץ שהסוכן הפיק לפני שמרשים לו להריץ את פקודת השליחה; במצב web מאשרים בצ'אט.

מה יוצא לכם ביד

תיקיית פרויקט indexing/ שמכילה: את מלאי כתובות ה-URL, הרשימות המסווגות (to-submit.txt, skip.txt, needs-fix.txt), תור השליחה המאושר ולוג ריצות. בכל ריצה dsh מפיק דוח קצר: כמה נשלחו, כמה דולגו ולמה, ומה השתנה מאז הפעם הקודמת. ההקמה הראשונה לוקחת 60–90 דקות (רובן אישורי Google); ריצה שבועית לוקחת 15 דקות.

לפני שמתחילים

• dsh מותקן ומוגדר. עדכנו לגרסה הנוכחית עם npx @deepseek-ai/dsh@latest web אם צריך. מפתח ה-API וההגדרות שלכם נמצאים תחת ~/.dsh/ (profiles, sessions, settings.yaml), ו-dsh web שעובד או משימת headless מוצלחת מאשרים את ההתקנה.
• נכס GSC שבבעלותכם, בפורמט sc-domain:example.com.
• אישורי קריאה: לקוח OAuth ל-Search Console API (client ID + secret) לסקריפטי הקריאה.
• אישורי כתיבה: פרויקט Google Cloud עם Indexing API מופעל, מפתח JSON של service account, ואימייל ה-service account שנוסף כבעלים תחת GSC ← הגדרות ← משתמשים והרשאות. 403 בשליחה אומר שהשלב הזה נכשל.
• שתי תיקיות הסקריפטים של GSC ב-workspace: skill הקריאה (sitemaps, ניתוחי חיפוש, בדיקת כתובות URL) ו-skill האינדוקס (index_submit.py). Python 3 עם pip install google-auth google-api-python-client.
• תיקיית פרויקט, לדוגמה ~/gsc-indexing-project עם data/, scripts/, logs/.

החלק של Google זהה לכל סוכן, והתיעוד של skill ה-gsc-indexing מדריך אתכם בשלבי Cloud Console: הפעלת Indexing API, יצירת service account, הורדת המפתח, הוספה כבעלים.

מסלול א': ריצת headless חד-פעמית

מצב headless הוא dsh --profile headless "משימה": משימה אחת, תשובה אחת, יציאה. שימו את כל ה-pipeline בהנחיה אחת, או חלקו אותו למספר ריצות בזמן שאתם מתקנים באגים.

ריצה ראשונה, מתיקיית הפרויקט:

dsh --profile headless "הרץ את שלב 1 של pipeline האינדוקס של GSC. רשום sitemaps עבור sc-domain:example.com עם הסקריפט gsc_query.py, אסוף כל כתובת URL עם lastmod, הסר כפילויות, וכתוב ל-data/url-inventory.csv. דווח על הספירה הכוללת."

איך נראה פלט טוב: CSV אמיתי עם ספירה שתואמת לדוח ה-sitemap ב-GSC, וללא עמודות מומצאות. בדיקת איכות: פתחו את הקובץ ובדקו חמש כתובות URL אקראיות. אם הסוכן מדווח על שגיאת אימות, הריצו שוב את זרימת ה-OAuth של GSC ונסו שוב; סקריפטי הקריאה צריכים token חדש.

שלב 2:

dsh --profile headless "בדוק את כתובות ה-URL ב-data/url-inventory.csv דרך URL Inspection API וחלק אותן ל-data/to-submit.txt, ל-data/skip.txt (עם סיבה בשורה אחת) ול-data/needs-fix.txt. כלול רק כתובות URL עם lastmod ב-90 הימים האחרונים."

הסוכן מריץ את סקריפט הבדיקה בקבוצות (ל-API יש מגבלת קצב לכל נכס; בדקו את המכסה הנוכחית שלכם ב-Google Cloud Console). בדקו את החלוקה: רשימת הדילוג צריכה להיות נשלטת על ידי noindex, canonical-הרחקה וכפילויות. אם אתר עם אלפי כתובות URL מפיק רשימת needs-fix ריקה, הרחיבו את חלון הקלט.

שלב 3 הוא שער האישור, והוא אף פעם לא רץ ללא השגחה:

dsh --profile headless "קרא את data/needs-fix.txt ו-data/skip.txt. נסח תור תיקונים ושליחה כטבלה: URL, סיבה חשודה (אין קישורים פנימיים, כפילות, canonical, noindex, דלילות, soft 404), ראיה, פעולה מוצעת, רמת סיכון. אל תשלח שום דבר."

אתם בודקים את הטבלה בדוח שהוא מדפיס, עורכים את data/to-submit.txt כך שיכיל רק את כתובות ה-URL שאתם מאשרים, ואז מריצים שלב 4:

dsh --profile headless "שלח את כתובות ה-URL ב-data/approved-urls.txt דרך סקריפט האינדוקס (index_submit.py submit --urls-file data/approved-urls.txt). הרץ check-auth קודם. רשום כל תוצאה ל-logs/submissions.log."

פלט צפוי: שורת תוצאה לכל כתובת URL, ללא 403. מסלולי התאוששות: 403 אומר שה-service account אינו בעלים של הנכס; 429 אומר שפגעתם במכסת 200 ליום או 600 לדקה; חלקו את הרשימה על פני ימים. אם ריצה מתה באמצע, dsh --profile headless --resume <session> ממשיך אותה.

מסלול ב': Web UI ולוח שבועי

dsh web פותח את ממשק הדפדפן ב-127.0.0.1:3080. עוברים על אותם שלבים בצ'אט, אבל אינטראקטיבית: הסוכן מבקש מכם לאשר את הרשימות המסווגות לפני ניסוח התור, ושוב לפני הרצת פקודת השליחה. זרימת האישור החיה הזו היא הסיבה המרכזית לבחור במסלול הזה בהקמה ראשונה: אתם רואים מה הסוכן עומד לעשות לנכס Google שלכם לפני שהוא עושה את זה.

כשה-pipeline מתייצב, הוסיפו את הקצב. תוסף ה-Schedule של dsh רושם את schedule_create, שמריץ משימה חוזרת על טיימר בתוך סשן חי:

schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."

אם הפרופיל שלכם לא טוען את תוסף ה-Schedule, אותה תוצאה מגיעה משורת cron שעוטפת את פקודת ה-headless:

0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "הרץ את הבדיקה השבועית של אינדוקס GSC ונסח את תור השליחה." >> logs/weekly.log 2>&1

הלוח זמנים מריץ את שלוש התחנות הראשונות; השליחה נשארת מאחורי שער אנושי.

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

חוקי הטריאז' שהסוכן מיישם

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

הקריאה המעמיקה של שתי הסטטוסות, כולל למה Google מזחל לחלק מהעמודים ולא לאחרים, נמצאת במדריך Hermes Agent. הסיבות זהות לא משנה איזה harness מריץ את ה-pipeline.

אימות, ואז המתנה

אחרי כל קבוצה, אמתו את ההתראה עם status: זה רק מוכיח של-Google יש מטא-דאטה עבורה, לא שהעמוד מאונדקס. שלושה עד שבעה ימים אחר כך, בדקו שוב את כתובות ה-URL שנשלחו והשוו בין המצבים. הדפוס הבריא הוא discovered → crawled → indexed בתוך שבוע-שבועיים. נתוני GSC מגיעים בפיגור של כמה ימים, ו-Google מזחל מחדש לפי לוח הזמנים שלו, אז כתובת URL שעדיין תקועה ב-«Crawled – currently not indexed» אחרי 10–14 ימים עם תיקון אמיתי מאחוריה היא פסק דין של איכות תוכן, לא בעיית שליחה. קובץ הלוג הוא המקום שבו זה נראה: תאריך, URL, סוג התראה ומצב הבדיקה בריצה הבאה. וזו גם המדידה: רשימת הלא מאונדקסים צריכה להתכווץ עם הזמן, לא ספירת ההתראות לגדול.

מגבלות כנות

• Indexing API מתועד רשמית לעמודי JobPosting ו-BroadcastEvent. שליחת עמודים רגילים דרכו היא נוהג נפוץ, אבל Google לא נותן שום הבטחה ולא מציע שום התחייבות תמיכה לכל סוג עמוד.
• אין API ציבורי לכפתור «בקשת אינדוקס» של Search Console. Indexing API הוא הערוץ הניתן לסקריפט הקרוב ביותר, לא העתק של הכפתור.
• אוטומציה לא יוצרת עדיפות. אם עמוד נשאר לא מאונדקס אחרי שתיקנתם ושלחתם אותו, המהלך הבא הוא עבודת תוכן, לא עוד ריצה מתוזמנת.

שאלות נפוצות

האם אפשר להריץ רק במצב headless, בלי Web UI בכלל? כן. dsh --profile headless "משימה" מריץ משימה אחת ויוצא; אישורי הגישה נשארים ב-~/.dsh/, וסקריפטי הקריאה עובדים אותו דבר. השתמשו ב-Web UI פעם אחת כדי לאמת את ה-pipeline מקצה לקצה, ואז הפכו אותו לסקריפט.

ריצה מתה באמצע הקבוצה. האם אני מאבד את העבודה? לא. המשיכו עם dsh --profile headless --resume <session>, והריצו שוב את סקריפט השליחה; הוא מסיר כפילויות, אז שליחה חוזרת של כתובת URL שכבר הודיעו עליה באותה קבוצה לא מזיקה.

אני מנהל כמה נכסי GSC. האם אני חוזר על הכל בכל אתר? הסקריפטים מקבלים ארגומנט --site sc-domain:..., אז workspace אחד יכול להחזיק מלאים ולוגים של כמה נכסים. שמרו קובץ תור מאושר אחד ופקודת שליחה אחת לכל נכס, כדי ששגיאת מכסה באתר אחד לעולם לא תחסום את האחרים.

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