«Discovered – currently not indexed» و«Crawled – currently not indexed» هما السطران الأكثر تكرارًا في تقرير «الصفحات في الفهرس» داخل Search Console — والأكثر سوء فهم. يبدوان كعطل تقني، لكنهما في الحقيقة قرار من Google بشأن أولوية صفحاتك وجودتها. إعادة الإرسال مرارًا لا تغيّر شيئًا. إصلاح السبب — نعم.
هذا الدليل دورة كاملة يمكنك تفويضها بالكامل إلى وكيل Hermes: استخرج قائمة عناوين URL، وافحص كل صفحة، وحدد السبب الحقيقي، واعتمد قائمة الإصلاحات، وأرسل عبر Google Indexing API فقط الصفحات التي تستحق الفهرسة. النتيجة: خط أنابيب أسبوعي قابل للتكرار بدلًا من جلسة نقرات لمرة واحدة.
ما الذي ستحصل عليه
- جرد مصنّف: عناوين URL عالقة في «discovered»، وأخرى تم الزحف إليها لكنها غير مفهرسة، وتلك التي لم يكن ينبغي إرسالها أصلًا
- قائمة معتمدة لـ Indexing API وقائمة المستبعدين مع الأسباب
- مرحلة تحقق تُظهر ما إذا كانت إرسالاتك نجحت
ما المطلوب: وكيل Hermes مثبّت ويعمل (hermes chat يفتح جلسة. خطوات التثبيت المحدثة: التوثيق الرسمي على hermes-agent.nousresearch.com/docs)، وملكية Search Console تملكها أنت، ومجموعتا بيانات اعتماد من Google (واحدة لقراءة GSC والأخرى لـ Indexing API). الإعداد الأولي نحو 60–90 دقيقة، ثم نحو 15 دقيقة أسبوعيًا. «مكتمل» تعني: عناوين URL المرسلة تُظهر تغييرًا حقيقيًا في الحالة عبر API الفحص خلال أسبوعين — أو لديك دليل مقنع على عدم حدوث ذلك.
قراءة الحالتين بشكل صحيح
Google لم يعلق على موقعك. لقد اتخذ قرارًا — والحالة تخبرك أي قرار.
الحالة | ماذا تعني فعلًا | الأسباب الشائعة | متى تُرسل |
|---|---|---|---|
Discovered – currently not indexed | Google يعرف عنوان URL (من sitemap أو الروابط) لكنه لم يزحف إليه بعد | أولوية زحف منخفضة، روابط داخلية ضعيفة أو غائبة، ضغط على ميزانية الزحف في المواقع الكبيرة، موقع جديد، عرض JS بطيء أو ثقيل، sitemap يتغير باستمرار | مرة واحدة، بعد تحسين إشارات الأولوية (خاصة الروابط الداخلية) |
Crawled – currently not indexed | Google حصل على عنوان URL لكنه قرر عدم فهرسته | محتوى مكرر أو شبه مكرر، محتوى ضعيف، canonical يشير إلى عنوان URL آخر، noindex وقت الزحف، soft 404، تقييم كمنخفض القيمة | فقط إذا غيّرت شيئًا فعلًا: المحتوى أو canonical أو noindex |
Indexed | في الفهرس | — | لا تُرسل |
Excluded | تم الزحف إليه واستبعاده عمدًا (noindex، canonical، اختيار النسخة المكررة، حظر) | — | لا تُرسل؛ تحقق مما إذا كان الاستبعاد مقصودًا |
بجملة واحدة: أرسل فقط عناوين URL التي غيّرتها فعلًا أو التي تستحق نظرة ثانية. Indexing API قناة إشعارات، وليست إلغاءً للترتيب. إرسال صفحة ضعيفة عشر مرات يعيد نفس الحكم عشر مرات.
لماذا يجب أن يفعل هذا وكيل
زر «طلب الفهرسة» في GSC لا يملك API عامًا — لا توجد طريقة رسمية للنقر عليه عبر برنامج نصي. أقرب أتمتة هي Google Indexing API، التي تقبل إشعارات عناوين URL مباشرة. الوكيل يضيف قيمة لثلاثة أسباب:
- الدورة ميكانيكية وطويلة: جرد ← فحص ← تصنيف ← إصلاح ← إرسال ← تحقق. كل أسبوع.
- يلزم سجل تدقيق: تحتاج ملفًا يوضح عناوين URL المرسلة، ومتى، ولماذا.
- يلزم بوابة موافقة: الجزء الذي يكتب إلى Google يجب أن يفحصه إنسان. Hermes مبني حول هذا الفصل تحديدًا — المهارات ومجلدات المشروع وقواعد الموافقة.
ما المطلوب قبل البدء
- وكيل Hermes مثبّت. اختبر
hermes chatقبل المتابعة. - ملكية GSC تملكها أنت. بصيغة
sc-domain:example.com(ليس عنوان URL كاملًا). - وصول للقراءة: عميل OAuth من Google Cloud (client ID + secret) لـ Search Console API. تستخدمه نصوص مهارة GSC لـ sitemap وSearch Analytics وفحص عناوين URL.
- وصول للكتابة: مشروع Google Cloud مفعّل فيه Indexing API ومفتاح JSON لحساب الخدمة. أضف بريد حساب الخدمة كـمالك في GSC ← الإعدادات ← المستخدمون والأذونات. إذا أعاد الإرسال 403 — فهذه الخطوة المفقودة.
- Python 3 و
pip install google-auth google-api-python-client. - مجلد مشروع. مثل
/hermes-seo-projectيتضمنcontext/وdata/وqa/وapproval-rules.mdالذي يشترط أن تتطلب مرحلة الإرسال دائمًا توقيعًا بشريًا.
الخطوة 1: جمع جرد عناوين URL
انسخ مهارتي GSC إلى دليل مهارات Hermes (~/.hermes/skills): مهارة القراءة (sitemap وSearch Analytics وفحص عناوين URL) ومهارة الفهرسة (نص الإرسال). إذا كان النظام يفهرس المهارات، يمكن تحميلها أيضًا عبر skill_view.
ثم اطلب من Hermes في جلسة محادثة، من مجلد المشروع:
اذكر كل sitemap لـ sc-domain:example.com، واستخرج كل عنوان URL مع lastmod واكتبها في data/url-inventory.csv. علّم على أي sitemap فشل جلبها.
ينفّذ Hermes أوامر sitemap عبر أداة الطرفية ويكتب CSV. النتيجة الجيدة: CSV بلا تكرار يتضمن URL وlastmod وsitemap المصدر. فحص الجودة: تحقق من خمسة صفوف عشوائية وقارن الإجمالي بتقرير sitemap في GSC. إذا كانت القائمة فارغة أو فشل المصادقة، كرر تدفق مصادقة GSC؛ نص القراءة يحتاج رمز 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 إلى عناوين أخرى والتكرارات، وليس الصفحات المهمة لك. إذا أعطى موقع بآلاف عناوين URL قائمة needs-fix فارغة، فمرحلة الجرد على الأرجح فقدت صفحات. وسّع النطاق المدخل.
الخطوة 3: الفرز قبل الإرسال
الخطوة التي يتجاهلها الجميع. طابق عناوين URL العالقة مع السبب والإصلاح بهذا الترتيب:
السبب | الإصلاح | الإرسال بعد الإصلاح؟ |
|---|---|---|
لا يوجد رابط داخلي واحد للصفحة | أضف روابط سياقية من صفحات مفهرسة | نعم |
موقع أو صفحة جديدة تمامًا | لا شيء لإصلاحه؛ أرسل مرة وانتظر 1–2 أسبوع | نعم، مرة واحدة |
حظر في robots.txt | أزل الحظر عن هذا المسار | نعم |
تم الزحف إليه لكنه مكرر أو ضعيف | أعد الكتابة أو الدمج أو الحذف | فقط بعد تغيير حقيقي في المحتوى |
canonical يشير إلى عنوان URL آخر | أصلح canonical إن كان خاطئًا؛ إن كان مقصودًا فتوقف عن إرسال هذا العنوان | فقط بعد الإصلاح |
noindex وقت الزحف | أزل noindex ودع Google يعيد الزحف | نعم، بعد الإزالة |
soft 404، ترقيم صفحات/أرشيفات عديمة الفائدة | أصلح الصفحة أو احذفها | لا — استبعاد دائم |
اطلب من Hermes تحضير قائمة الإصلاحات كجدول: URL، السبب المحتمل، الدليل (نتيجة الفحص أو مراجعة المحتوى)، الإجراء المقترح، مستوى المخاطرة. اعتمد كل صف في المحادثة. يجب أن يشترط approval-rules.md هذا: الوكيل يجهّز، وأنت تعتمد، ولا يُرسل أي شيء فوق المخاطرة المنخفضة دون توقيع.
بوابة الموافقة تفصل إعداد الوكيل عن مرحلة الكتابة.
الإصلاحات نفسها عمل SEO عادي: إعادة كتابة المحتوى، تنظيف canonical، روابط داخلية. هذا الخط يغطي نصف العمل — الإرسال. النصف الآخر تغطيه مقالات التدقيق والتحديث من سلسلة Hermes.
قائمة الإرسال هي تقاطع «قابل للإصلاح» و«جدير بالفهرسة».
الخطوة 4: الإرسال عبر Indexing API
عند اعتماد القائمة، ضع عناوين URL في data/approved-urls.txt ودع Hermes ينفّذ مهارة الفهرسة:
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 تعني أن حساب الخدمة ليس مالك الملكية. إذا تجاوزت القائمة المعتمدة 200، قسمها على عدة أيام؛ يمكن لـ Hermes جدولة الدفعات المتبقية.
لا ترسل أبدًا الصفحات المفهرسة بالفعل أو قائمة المستبعدين. الإشعارات المهدرة تحرق الحصة وتحدث ضجيجًا فقط.
الخطوة 5: التحقق ثم الانتظار
status مباشرة بعد الإرسال يخبرك فقط إن كانت Google تملك بيانات الإشعار، وليس إن كانت الصفحة مفهرسة. التأكيد الحقيقي يأتي بعد أيام.
بعد 3–7 أيام من الدفعة، اطلب من Hermes:
أعد فحص عناوين URL في data/approved-urls.txt وأبلغ عن تغييرات الحالة مقارنة بآخر تشغيل.
التقدم الصحي هو discovered ← crawled ← indexed. هكذا يبدو عبر الأسابيع: قائمة غير المفهرسة تنكمش، وإصلاحاتك الحقيقية (روابط داخلية جديدة، نصوص مُعاد كتابتها) تظهر في الفهرس. تذكر: بيانات GSC تأتي بتأخير بضعة أيام، وGoogle يعيد الزحف وفق جدوله الخاص. عنوان URL يبقى في «Crawled – currently not indexed» لمدة 10–14 يومًا بعد إصلاحات حقيقية هو إشارة جودة، لا مشكلة إرسال؛ انقله إلى عمل المحتوى.
إبقاء الدورة تعمل
حوّل الخط إلى روتين أسبوعي: عناوين URL جديدة أو متغيرة من آخر تشغيل ← فحص ← تصنيف ← فرز ← اعتماد ← إرسال ← سجل. يمكن لـ Hermes تنفيذ الجزء للقراءة فقط (الجرد والفحص والتصنيف) دون إشراف، وفق جدول، وإحضار القائمة إليك كل اثنين. تبقى مرحلة الإرسال خلف بوابة الموافقة، مع سجل مستمر في qa/indexing-log.md: تاريخ الإرسال وURL ونوع الإشعار والنتيجة. نصف عام من السجل هو المقياس الوحيد الصادق لنجاح الخط.
قيود صادقة
- يوثق Google Indexing API للصفحات ذات البيانات المنظمة
JobPostingأوBroadcastEvent. استخدامه على الصفحات العادية ممارسة SEO شائعة، لكن Google لا يضمن الفهرسة أو الدعم لأي نوع صفحات. - زر «طلب الفهرسة» لا يملك API عامًا. Indexing API هي أقرب أتمتة، لكنها ليست الزر نفسه.
- الإرسال لا يصنع أولوية. إذا بقيت الصفحة غير مفهرسة بعد الإصلاح والإرسال والانتظار، فإن الإجابة التالية هي جودة المحتوى، لا إشعار آخر.
الأسئلة الشائعة
هل يعمل Indexing API مع الصفحات العادية؟ يقبل أي عنوان URL ترسله. التوثيق الرسمي من Google يستهدف صفحات JobPosting وBroadcastEvent، فتعامل مع إرسال الصفحات العادية كأفضل جهد: مفيد وشائع، لكنه غير مضمون أبدًا.
لماذا تبقى الحالة «Discovered – currently not indexed» بعد الإرسال؟ هذه الحالة تعني عادة أولوية الزحف لا الفشل. تحقق من الروابط الداخلية إلى الصفحة، وما إذا كان robots.txt يحظر المسار، وإلى أي مدى تعتمد الصفحة على JavaScript. ثم انتظر: في المواقع الجديدة قد تمر 1–2 أسبوع من الاكتشاف إلى الزحف.
هل 200 عنوان URL يوميًا كافٍ؟ لمعظم المواقع نعم — وعلى أي حال يجب إرسال عناوين URL المتغيرة فعلًا فقط. إذا كان العدد أكبر بانتظام، رتبها حسب القيمة التجارية واطلب زيادة الحصة في Google Cloud Console.
هل تسرّع Indexing API الترتيب؟ لا. تخبر Google فقط أن العنوان تغير. الترتيب قرار منفصل لأنظمة Google، مستقل عن عدد الإشعارات المرسلة.
ما الفرق عن النقر على «طلب الفهرسة» في Search Console؟ الهدف نفسه، الآلية مختلفة. الزر واجهة خالصة بلا API عام؛ Indexing API قناة قابلة للبرمجة. ولا يلغي أي منهما قرار Google بشأن استحقاق الصفحة للفهرسة.
الكاتب: جوليان ميرسر، ممارس تحسين محركات البحث التقني في Auspia بخبرة 14 عامًا. يكتب عن قابلية الزحف والفهرسة والـ schema والأسس التقنية التي تجعل الموقع مقروءًا لـ Google ولأنظمة الذكاء الاصطناعي معًا.
