إصلاح عناوين URL بحالة «Discovered / Crawled – Currently Not Indexed» باستخدام DeepSeek Harness

DeepSeek Harness (dsh) يشغّل وكلاء يقومون بعمل حقيقي — وقليل من مهام SEO يناسب هذا أفضل من خط عناوين URL غير المفهرسة: اقرأ القائمة، وافحص كل عنوان URL، وصفّفه، وانتظر الاعتماد، وأرسل، وتحقق. كل مرحلة أمر أو ملف — بالضبط المنطقة التي يعيش فيها وكلاء النظام.

سؤالان يحددان إعدادك. هل تحتاج دفعة لمرة واحدة يمكن برمجتها ووضعها في cron؟ اختر headless. هل تريد رؤية كل شيء يعمل، والرد على أسئلة الوكيل، واعتماد الدفعات واحدة تلو الأخرى في المحادثة؟ استخدم Web UI. هذا الدليل يعرض المسارين؛ خط الأنابيب الأساسي متطابق. الشرح المتعمق للحالتين (بما في ذلك لماذا يزحف Google إلى بعض الصفحات ولا يزحف إلى أخرى) موجود في نسخة Hermes Agent من هذه العملية. هنا نركّز على التنفيذ عبر dsh.

اختيار المسار

الدفعات — headless، الإعداد الأولي — Web UI. خط الأنابيب أدناه متطابق.

يشترك المساران في قاعدة واحدة: مرحلة الكتابة (الإرسال إلى Google) تبقى خلف بوابة موافقة بشرية. في الوضع headless هذا يعني أنك تستعرض الملفات التي أنشأها الوكيل قبل السماح له بتنفيذ أوامر الإرسال. في وضع الويب تعتمد في المحادثة.

ما الذي ستحصل عليه

مجلد مشروع 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 لحساب الخدمة، وبريد حساب الخدمة مضافًا كـمالك في GSC ← الإعدادات ← المستخدمون والأذونات. 403 عند الإرسال = هذه الخطوة فاشلة.
• مجلدا نصوص GSC في workspace: مهارة القراءة (sitemap وSearch Analytics وفحص عناوين URL) ومهارة الفهرسة (index_submit.py). Python 3 وpip install google-auth google-api-python-client.
• مجلد مشروع، مثل ~/gsc-indexing-project يتضمن data/ وscripts/ وlogs/.

جزء Google متطابق لأي وكيل؛ توثيق مهارة gsc-indexing يرافقك عبر وحدة تحكم Cloud: تفعيل Indexing API، إنشاء حساب خدمة، تنزيل المفتاح، إضافته كمالك.

المسار أ: دفعة headless

الوضع headless هو dsh --profile headless "مهمة": مهمة واحدة، إجابة واحدة، نهاية. تضع الخط كله في استدعاء واحد أو تقسّمه على عدة تشغيلات أثناء تصحيح الأخطاء.

التشغيل الأول (من مجلد المشروع):

dsh --profile headless "نفّذ المرحلة 1 من خط فهرسة GSC. بنص gsc_query.py اذكر sitemap لـ sc-domain:example.com، واستخرج كل عناوين URL مع lastmod، وأزل التكرار، واكتب إلى data/url-inventory.csv. أعط ملخصًا."

النتيجة الجيدة: CSV حقيقي بملخص متسق مع تقرير sitemap في GSC وبدون أعمدة مخترعة. فحص الجودة: افتح الملف وتحقق من خمسة عناوين URL عشوائية. إذا أبلغ الوكيل عن خطأ مصادقة، كرر تدفق OAuth الخاص بـ GSC وحاول مجددًا؛ نص القراءة يحتاج رمزًا جديدًا.

المرحلة 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 والتكرارات. إذا كانت needs-fix فارغة في موقع بآلاف عناوين URL، وسّع النافذة المدخلة.

المرحلة 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 تعني أن حساب الخدمة ليس مالك الملكية؛ 429 تعني اصطدامك بالحصة 200/يوم أو 600/دقيقة — وزّع القائمة على أيام. إذا مات التشغيل في منتصفه، استأنفه عبر dsh --profile headless --resume <session>.

المسار ب: Web UI والجدول الأسبوعي

dsh web يفتح واجهة المتصفح على 127.0.0.1:3080. المراحل نفسها، لكن عبر المحادثة وتفاعليًا: يطلب الوكيل تأكيد قوائم التصنيف ومرة أخرى قبل كل أمر إرسال. هذا التدفق الحي للاعتماد هو السبب الرئيسي لاختيار هذا المسار في الإعداد الأولي: ترى ما سيفعله الوكيل بملكية Google الخاصة بك قبل أن يفعله.

عندما يستقر الخط، أضف الإيقاع. إضافة 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. الأسباب نفسها أيًا كان النظام الذي ينفذ الخط.

التحقق ثم الانتظار

بعد كل دفعة تحقق من الإشعار عبر status: هذا يثبت فقط أن Google يملك بيانات تعريف العنوان، لا أن الصفحة مفهرسة. أعد فحص عناوين URL المرسلة بعد 3–7 أيام وقارن الحالات. النمط الصحي هو discovered ← crawled ← indexed خلال 1–2 أسبوع. بيانات GSC تأتي بتأخير بضعة أيام، وGoogle يعيد الزحف وفق جدوله — عنوان URL يبقى في «Crawled – currently not indexed» لمدة 10–14 يومًا بعد إصلاحات حقيقية هو حكم على جودة المحتوى، لا مشكلة إرسال. ملف السجل يجعل ذلك مرئيًا: التاريخ وURL ونوع الإشعار وحالة الفحص في التشغيل التالي. هذا هو المقياس: قائمة غير المفهرسة تنكمش مع الوقت، لا عدد الإشعارات.

قيود صادقة

• Indexing API موثقة رسميًا لصفحات JobPosting وBroadcastEvent. إرسال الصفحات العادية ممارسة شائعة، لكن Google لا يعطي ضمانات ولا يعد بدعم لأي نوع صفحات.
• زر «طلب الفهرسة» في Search Console لا يملك API عامًا. Indexing API أقرب قناة قابلة للبرمجة، لكنها ليست نسخة من الزر.
• الأتمتة لا تصنع أولوية. إذا بقيت الصفحة غير مفهرسة بعد الإصلاح والإرسال، فالخطوة التالية عمل على المحتوى، لا تشغيل مجدول آخر.

الأسئلة الشائعة

هل يمكنني العمل في headless فقط، دون Web UI؟ نعم. dsh --profile headless "مهمة" ينفذ المهمة وينتهي. تبقى بيانات الاعتماد في ~/.dsh/، ونصوص القراءة تعمل بالطريقة نفسها. مرر الخط من البداية إلى النهاية مرة واحدة في Web UI قبل البدء بالبرمجة.

إذا مات التشغيل، هل أفقد عملي؟ لا. استأنف عبر dsh --profile headless --resume <session> وأعد تشغيل نص الإرسال؛ يزيل التكرار، لذا إعادة إرسال عناوين URL المُشعَر إليها مسبقًا من الدفعة نفسها آمنة.

أدير عدة ملكيات GSC. هل يجب إعادة كل شيء لكل موقع؟ تقبل النصوص الوسيط --site sc-domain:...، لذا يمكن لـ workspace واحد أن يحوي جرد وسجلات عدة ملكيات. أبقِ ملف القائمة المعتمدة وأمر الإرسال لكل ملكية؛ خطأ حصة في موقع لا يمنع البقية.

الكاتبة: كاميل رودس، معمارية أكثر من 300 سير عمل للمحتوى بالذكاء الاصطناعي في Auspia. تكتب عن أتمتة المحتوى وأنظمة النشر والعمليات التي تحوّل وكلاء الذكاء الاصطناعي إلى عمليات نمو موثوقة.