واجهة Google للفهرسة

الخلاصة — تتيح Google Indexing API لأصحاب المواقع إبلاغ Google برمجيًا بأن «هذه الصفحة تغيّرت، يُرجى إعادة زحفها» بدل النقر على الأزرار. لكن هناك قيدًا تتجاهله معظم الأدلة: لا تدعمها Google رسميًا إلا لصفحات إعلانات الوظائف وصفحات البث المباشر. وليست اختصارًا لتسريع فهرسة تدويناتك أو صفحات منتجاتك؛ وقد كررت Google ذلك مرارًا.

ما Google Indexing API؟

عندما تنشر صفحة أو تعدّلها، تنتظر عادةً عودة Google لإعادة زحفها وفق جدولها. أما Indexing API فتتيح لك إرسال إشعار إلى Google مباشرةً: «عنوان URL هذا جديد أو محدَّث»، أو «لم يعد عنوان URL هذا موجودًا، فأزِله». ويتم ذلك برمجيًا، عبر برنامج صغير يتصل بخوادم Google، لا بالنقر داخل لوحة تحكم.

يبدو ذلك قويًا، وهو كذلك فعلًا — لكن ضمن الحالات المحددة التي صُممت لها.

المعلومة الأساسية

لا تدعم Google رسميًا Indexing API إلا لنوعين من الصفحات:

1. إعلانات الوظائف — صفحات تتضمن بيانات JobPosting المنظَّمة (إعلانات تنتهي صلاحيتها ويلزم حذفها بسرعة).
2. عمليات البث المباشر — صفحات تتضمن بيانات BroadcastEvent المنظَّمة (أحداث فيديو مباشر لا تكون مهمة إلا أثناء البث).

هذا كل شيء. فكلا النوعين محتوى حساس للوقت ويصبح قديمًا سريعًا، ولذلك أنشأت Google لهما مسارًا سريعًا.

إذا لم تكن لديك إعلانات وظائف أو عمليات بث مباشر، فإن Indexing API ليست أداتك — مهما زعم مكوّن إضافي أو خدمة SaaS أنها «تفهرس صفحاتك خلال ساعات».

الخرافة التي ينبغي تجاهلها

أكبر خرافة منتشرة على الإنترنت هي: “Use the Indexing API to get any page indexed fast.” (الترجمة العربية) «استخدم Indexing API لفهرسة أي صفحة بسرعة». لا تعمل الواجهة بهذه الطريقة، وقد وصفت Google مرارًا استخدامها للصفحات العادية بأنه إساءة استخدام. يفعلها البعض رغم ذلك لأن الأدوات تبيعها كحيلة نمو، لكن Google تستطيع — وتقول إنها ستفعل — إلغاء وصولك عند إساءة استخدامها.

وهناك فخ ثانٍ: عندما ترسل عنوان URL وتتلقى استجابة «نجاح»، فهذا يعني فقط أن Google استلمت طلبك. ولا يعني أن الصفحة فُهرست. تطمس أدوات كثيرة هذا الفارق، بينما توضحه وثائق Google نفسها.

ما البديل لتسريع الفهرسة؟

بالنسبة إلى الصفحات العادية، مثل التدوينات والمنتجات والمقالات، الوسائل الفعالة ليست مثيرة لكنها حقيقية:

• أرسل خريطة موقع XML في Google Search Console.
• أنشئ روابط داخلية إلى صفحاتك الجديدة من صفحات أخرى في موقعك.
• اجعل الصفحة جديرة فعلًا بالفهرسة؛ ركّز على الجودة لا الحشو السطحي.
• للحالات الفردية، استخدم «طلب الفهرسة» في أداة فحص عنوان URL داخل Search Console، باعتدال.

هل تريد النسخة التقنية، بما فيها الإعداد وطرق API الفعلية والحصص واقتباسات Google الدقيقة؟ انتقل إلى علامة التبويب متقدم.

الخلاصة — Indexing API هي واجهة REST بالإصدار v3، موثَّقة عبر Google Cloud، وتقبل إشعارات URL_UPDATED وURL_DELETED. ولا تدعمها Google رسميًا إلا لصفحات JobPosting وBroadcastEvent المضمَّنة في VideoObject (البث المباشر)، لا للمحتوى العام. تؤكد استجابة 200 من نقطة نهاية الحالة استلام الطلب، لا الفهرسة. وقد ازدادت لهجة Google صرامة بمرور السنين: 2022 («لا معنى له») ← سبتمبر 2024 (إضافة تحذير من الرسائل غير المرغوب فيها إلى الوثائق) ← مايو 2025 (مولر: «يسيء مرسلو الرسائل غير المرغوب فيها استخدام Indexing API… استخدمها كما ينبغي، أو لا تستخدمها»). وقد يؤدي سوء الاستخدام، بما فيه فتح حسابات متعددة لرفع الحصة، إلى إلغاء الوصول. وللصفحات العامة، اعتمد على خرائط الموقع والروابط الداخلية والجودة والاستخدام العرضي لخيار «طلب الفهرسة» في GSC، وتذكّر أن Google لا تدعم IndexNow.

ما Indexing API فعليًا؟

Indexing API قناة دفع برمجية: واجهة REST بالإصدار v3، تُوثَّق عبر حساب خدمة في Google Cloud، وتتصل بها لإبلاغ Google بأن عنوان URL أُضيف أو حُدّث (URL_UPDATED)، أو ينبغي حذفه (URL_DELETED). تعمل إلى جانب خرائط الموقع وSearch Console كوسيلة تساعد Google على اكتشاف عناوين URL وتحديثها، لكنها أضيق هذه الوسائل من حيث أنواع المحتوى.

في عرضي كيف يعمل البحث، أدرج Indexing API مصدرًا لاكتشاف عناوين URL مع وسم «حالات استخدام محدودة»؛ وهذه العبارة تختصر القصة كلها. الواجهة حقيقية وتعمل، لكن استخدامها المعتمد لا يشمل إلا جزءًا ضئيلًا من الويب.

ما الذي تدعمه Google رسميًا؟

هذه هي الحقيقة المحورية، لذا سأعرضها بصياغة Google نفسها. تقول الوثائق: “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (الترجمة العربية) «لا يمكن استخدامها إلا لزحف الصفحات التي تتضمن إما JobPosting أو BroadcastEvent مضمَّنًا في VideoObject». هذا كل شيء؛ نوعان فقط من البيانات المنظَّمة:

• JobPosting — صفحات إعلانات الوظائف. تنتهي صلاحيتها، والوظائف القديمة تسيء إلى تجربة المستخدم، لذا يهم تحديثها أو حذفها في الوقت المناسب.
• BroadcastEvent داخل VideoObject — صفحات أحداث البث المباشر. لا تكون ذات صلة إلا أثناء البث وفي الفترة المحيطة به مباشرةً.

لماذا هذان النوعان فقط؟ لأن كليهما بطبيعته حساس للوقت وقصير العمر. وتوضح Google أن الإبلاغ السريع عن التغييرات أهم بكثير لهما مقارنةً بالصفحات دائمة الصلاحية التي يتكفل بها الزحف العادي.

آلية العمل

المتطلبات المسبقة

الإعداد ليس بسيطًا، فهذه ليست ميزة تعمل بنقرة واحدة:

• مشروع Google Cloud مفعَّل فيه Indexing API. وبصياغة Google: “need to tell Google about your client and activate access to the API.” (الترجمة العربية) «يلزم إبلاغ Google بعميلك وتفعيل الوصول إلى API».
• حساب خدمة مع ملف مفتاح JSON محفوظ بأمان.
• إثبات ملكية الموقع في Search Console، ثم إضافة حساب الخدمة بصفته مالكًا مفوَّضًا للموقع.
• OAuth: تقول Google: “Every call to the Indexing API must be authenticated with an OAuth token that you get in exchange for your private key,” (الترجمة العربية) «يجب توثيق كل استدعاء إلى Indexing API برمز OAuth تحصل عليه مقابل مفتاحك الخاص»، باستخدام النطاق https://www.googleapis.com/auth/indexing.

الطريقتان، إضافةً إلى فحص الحالة

• URL_UPDATED — تقول Google: “To notify Google of a new URL to crawl or that content at a previously-submitted URL has been updated.” (الترجمة العربية) «لإبلاغ Google بعنوان URL جديد لزحفه، أو بأن محتوى عنوان URL أُرسل سابقًا قد حُدِّث». أرسل العنوان عبر POST مع "type": "URL_UPDATED". يعيد الاستدعاء الناجح HTTP 200، وتقول Google حرفيًا إن ذلك “means that Google may try to recrawl this URL soon,” (الترجمة العربية) «يعني أن Google قد تحاول إعادة زحف عنوان URL هذا قريبًا»، لا أنها ستفعل حتمًا ولا أن الزحف سيؤدي إلى الفهرسة.
• URL_DELETED — قبل طلب الحذف، تشترط Google أن “the URL must return a 404 or 410 status code or the page must contain” (الترجمة العربية) «يعيد عنوان URL رمز الحالة 404 أو 410، أو تحتوي الصفحة على» وسم meta بقيمة noindex. الشرط أحد الخيارين، لا «احذف الصفحة وأضف noindex أيضًا». بعد تحقق أحدهما، أرسل العنوان عبر POST مع "type": "URL_DELETED" كي تحذفه Google.
• الحالة (GET) — تعيد بيانات وصفية (latest_update وlatest_remove وnotify_time). والتحذير الحاسم حرفيًا أن طلب GET “only returns whether you successfully submitted a request.” (الترجمة العربية) «لا يعيد سوى ما إذا كنت قد أرسلت طلبًا بنجاح». ولا يخبرك هل فهرست Google شيئًا أو حذفته بالفعل.
• التجميع — لتقليل اتصالات HTTP، يمكنك “combine up to 100 calls to the Indexing API into a single HTTP request.” (الترجمة العربية) «جمع ما يصل إلى 100 استدعاء لـ Indexing API في طلب HTTP واحد». وتظل الحصة محسوبة لكل عنوان URL؛ فعشرة طلبات داخل دفعة واحدة تستهلك عشرة طلبات من الحصة.

الحصص

تتكون حصة Google الافتراضية من ثلاثة أبعاد منفصلة، لا من رقم واحد فقط:

• 200 طلب نشر يوميًا لكل مشروع — تشمل استدعاءات URL_UPDATED وURL_DELETED مجتمعةً. وهذا هو الرقم الذي تستشهد به معظم الأدلة.
• 180 طلب getMetadata (حالة) في الدقيقة لكل مشروع.
• 380 طلبًا في الدقيقة لكل مشروع عبر جميع نقاط النهاية مجتمعةً.

تصف Google الأرقام الثلاثة بأنها “initial default quota for testing” (الترجمة العربية) «الحصة الافتراضية الأولية للاختبار». ويتطلب تجاوزها “requires additional approval for usage and resource provisioning,” (الترجمة العربية) «موافقة إضافية على الاستخدام وتوفير الموارد» عبر نموذج طلب. كما تشير إلى أن “the quota may increase or decrease based on the document quality.” (الترجمة العربية) «الحصة قد تزيد أو تنقص بناءً على جودة المستند». أما «الحيلة» الشائعة بإنشاء حسابات خدمة أو مشاريع متعددة لرفع الحصة اليومية، فهي بالضبط ما تحظره Google (انظر أدناه).

هل يمكنك استخدامها للصفحات العادية؟ ما تقوله Google فعليًا

الإجابة المختصرة: لا، ليس بطريقة مدعومة. وقد حافظت Google على موقف ثابت بدرجة لافتة، مع ازدياد صراحته بمرور الوقت.

تتضمن الوثائق تحذيرًا من الرسائل غير المرغوب فيها. قرابة سبتمبر 2024، أضافت Google إلى دليل البدء السريع نصًا صريحًا: “All submissions through the Indexing API undergo rigorous spam detection,” (الترجمة العربية) «تخضع جميع الطلبات المقدَّمة عبر Indexing API لاكتشاف صارم للرسائل غير المرغوب فيها»، و*“any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.”* (الترجمة العربية) «قد تؤدي أي محاولة لإساءة استخدام Indexing API، بما فيها استخدام حسابات متعددة أو وسائل أخرى لتجاوز حصص الاستخدام، إلى إلغاء الوصول».

يكرر ممثلو Google هذا منذ سنوات. في مايو 2022، شرح جون مولر الأمر بتشبيه مركبات البناء: الواجهة “is meant for very specific kinds of content,” (الترجمة العربية) «مخصّصة لأنواع محددة جدًا من المحتوى»، واستخدامها في غير ذلك “doesn’t really make sense.” (الترجمة العربية) «ليس له معنى فعليًا». وبحلول مايو 2025 صارت لهجته أشد: “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases,” (الترجمة العربية) «نرى كثيرًا من مرسلي الرسائل غير المرغوب فيها يسيئون استخدام Indexing API بهذه الطريقة، لذا أوصي بالالتزام بحالات الاستخدام الموثَّقة والمدعومة»، ثم “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (الترجمة العربية) «سأستخدمها كما ينبغي فحسب، أو لن أستخدمها. ولو أردنا الإيحاء بإمكان استخدامها دون اعتبار لذلك، لوثّقنا الأمر بهذه الصورة».

هذا المسار — «لا معنى له» في 2022 ← تحذير من الرسائل غير المرغوب فيها في الوثائق عام 2024 ← «يسيء مرسلو الرسائل غير المرغوب فيها استخدامها… استخدمها كما ينبغي أو لا تستخدمها» في 2025 — نمط ممتد لسنوات لا تصريح عابر. وأشارت تغطيات أخرى إلى أن المدوّنين ومتخصصي SEO يغمرون الواجهة فعليًا بمعاملة المواقع العادية كأنها مؤهلة.

الخطر الحقيقي، بصياغة دقيقة. لا يذهب مولر إلى حد الجزم بوجود عقوبة خوارزمية. والصياغة الأمينة هي أن الاستخدام غير مدعوم ومخالف للإرشادات، وقد لا يبقى المحتوى المرسَل بصورة غير سليمة مفهرسًا، ويمكن إلغاء وصولك. لا تبالغ بوصفه إجراءً يدويًا مضمونًا، ولا تتظاهر أيضًا بأنه بلا تبعات.

خرافة نقطة نهاية الحالة

تستحق هذه المسألة سطرًا مستقلًا لأن أدوات كثيرة تخطئ فيها: الإرسال الناجح هو تأكيد استلام، لا وعدًا بالفهرسة. فطلب الحالة GET “only returns whether you successfully submitted a request.” (الترجمة العربية) «لا يعيد سوى ما إذا كنت قد أرسلت طلبًا بنجاح». وإذا عرضت لوحة تحكم شارة «مفهرس» خضراء استنادًا إلى 200، فهي تستنتج شيئًا لم تخبرها به API قط.

Indexing API مقابل طلب الفهرسة مقابل IndexNow

تختلط هذه الآليات الثلاث باستمرار، لكنها مختلفة:

• Indexing API من Google: برمجية، لكن نطاق محتواها محصور في JobPosting وBroadcastEvent. وهي الأضيق بين الثلاث.
• طلب الفهرسة في أداة فحص عنوان URL ضمن GSC: يصلح لأي صفحة تملكها، لكنه يدوي ولعنوان واحد كل مرة ومخصص للاستخدام العرضي. وهو طلب لا ضمان.
• IndexNow: بروتوكول دفع مفتوح وعابر لمحركات البحث (Bing وYandex وYep وSeznam وNaver)، ولا تستخدمه Google. إنه النظير العابر للمحركات لـ Indexing API، وهو ما أدعمه عمليًا؛ فقد ساعدت في إطلاق تكامل IndexNow داخل Ahrefs Site Audit. لكنه لا يصل إلى Google.

(ستجد المقارنة الكاملة في علامة التبويب الأطر.)

ما البديل للصفحات العامة؟

إذا لم تكن تنشر وظائف أو عمليات بث مباشر، فليست Indexing API أداتك، وقد قالت Google ذلك مرارًا. الأدوات الحقيقية المتاحة لك لدى Google هي الأدوات المعتادة غير البراقة:

• خرائط الموقع — للتغطية والاكتشاف.
• الروابط الداخلية — تعاني الصفحات اليتيمة؛ أما الصفحات المرتبطة فتُكتشف.
• جودة المحتوى — تحدد Google ما يستحق الفهرسة؛ وتظل الصفحات السطحية في حالة «تم اكتشاف الصفحة، ولم تتم فهرستها حاليًا» مهما دفعتها.
• «طلب الفهرسة» في GSC — للحالات الفردية الحقيقية، وباعتدال.

لدفع التحديثات إلى محركات أخرى (Bing وأشباهه، لا Google)، فإن IndexNow هي الأداة المناسبة. وإذا كان ما يهمك هو سبب عدم فهرسة الصفحات أصلًا، فهذه مسألة وتيرة زحف وجودة، لا مسألة API.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• ما هي؟ واجهة REST بالإصدار v3، موثَّقة عبر Google Cloud، لدفع إشعارات URL_UPDATED وURL_DELETED إلى Google.
• المعلومة الأهم: لا تُدعم رسميًا إلا لصفحات JobPosting وBroadcastEvent (البث المباشر)، لا للمحتوى العام. وكلاهما حساس للوقت بطبيعته.
• الخرافة الأولى: «تفهرس أي صفحة بسرعة». هذا غير صحيح؛ وتصف Google الاستخدام الأوسع بأنه إساءة استخدام. لا يؤكد الإرسال الناجح إلا أن Google استلمت الطلب، لا أن شيئًا قد فُهرس.
• اشتد موقف Google بمرور الوقت: «لا معنى له» في 2022 ← إضافة تحذير من الرسائل غير المرغوب فيها إلى الوثائق في سبتمبر 2024 ← مولر في مايو 2025: «يسيء مرسلو الرسائل غير المرغوب فيها استخدامها… استخدمها كما ينبغي، أو لا تستخدمها».
• المخاطر: الاستخدام غير مدعوم ومخالف للإرشادات؛ وقد يؤدي استعمال حسابات متعددة لتجاوز حصة نحو 200 طلب يوميًا إلى إلغاء الوصول. لا يعني ذلك بالضرورة عقوبة يدوية، لكن المحتوى قد لا يظل مفهرسًا.
• ليست IndexNow، وهو بروتوكول عابر للمحركات تستخدمه Bing وYandex وغيرهما ولا تستخدمه Google، وليست طلب الفهرسة في GSC، الذي يصلح لأي صفحة لكنه يدوي وعرضي.
• للصفحات العادية: خرائط الموقع + الروابط الداخلية + الجودة + الاستخدام العرضي لطلب الفهرسة في GSC.

الوثائق الرسمية

وثائق Google من المصادر الأولية.

Google — Indexing API

• دليل البدء السريع لـ Indexing API — النظرة العامة، وقصر الاستخدام على JobPosting وBroadcastEvent، وتحذير اكتشاف الرسائل غير المرغوب فيها.
• كيفية استخدام Indexing API — طريقتا URL_UPDATED وURL_DELETED، والتحذير المتعلق بنقطة نهاية الحالة.
• المتطلبات المسبقة — مشروع Cloud وحساب الخدمة ونطاق OAuth والملكية المفوَّضة في Search Console.
• الحصة والأسعار — الحصة الافتراضية (200) والموافقة المطلوبة للحصول على المزيد.

Google — سياق الصفحات العامة

• مطالبة Google بإعادة زحف عناوين URL — خرائط الموقع ومسار «طلب الفهرسة» في Search Console للمحتوى العادي.
• الدليل المتعمق لكيفية عمل بحث Google — موضع اكتشاف عناوين URL وتسلسل الزحف ← الفهرسة ← العرض.

اقتباسات من المصدر

تصريحات موثَّقة من Google. ينقلك كل رابط عميق إلى المقطع المقتبس في صفحة المصدر.

وثائق Google — القيد

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (الترجمة العربية) «لا يمكن استخدام Indexing API إلا لزحف الصفحات التي تتضمن إما JobPosting أو BroadcastEvent مضمَّنًا في VideoObject». — Google Search Central، دليل البدء السريع لـ Indexing API. الانتقال إلى الاقتباس
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” (الترجمة العربية) «تتيح Indexing API لأصحاب المواقع إبلاغ Google مباشرةً عند إضافة صفحات إعلانات الوظائف أو فيديوهات البث المباشر أو حذفها». الانتقال إلى الاقتباس

وثائق Google — تحذير الرسائل غير المرغوب فيها (أُضيف إلى الوثائق قرابة سبتمبر 2024)

• “All submissions through the Indexing API undergo rigorous spam detection.” (الترجمة العربية) «تخضع جميع الطلبات المقدَّمة عبر Indexing API لاكتشاف صارم للرسائل غير المرغوب فيها». الانتقال إلى الاقتباس
• “Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (الترجمة العربية) «قد تؤدي أي محاولة لإساءة استخدام Indexing API، بما فيها استخدام حسابات متعددة أو وسائل أخرى لتجاوز حصص الاستخدام، إلى إلغاء الوصول». الانتقال إلى الاقتباس

وثائق Google — التحذير المتعلق بنقطة نهاية الحالة (تفنيد الخرافة)

• “The GET request doesn’t tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request.” (الترجمة العربية) «لا يخبرك طلب GET متى تفهرس Google عنوان URL أو تحذفه؛ بل يعيد فقط ما إذا كنت قد أرسلت طلبًا بنجاح». — Google Search Central، كيفية استخدام Indexing API. الانتقال إلى الاقتباس

وثائق Google — الحصة

• “The default value is set to 200.” (الترجمة العربية) «القيمة الافتراضية مضبوطة على 200». (طلبات النشر يوميًا) — Google Search Central، الحصة والأسعار. الانتقال إلى الاقتباس
• “The default value is set to 180.” (الترجمة العربية) «القيمة الافتراضية مضبوطة على 180». (طلبات حالة getMetadata في الدقيقة)، و “The default value is set to 380.” (الترجمة العربية) «القيمة الافتراضية مضبوطة على 380». (جميع نقاط النهاية في الدقيقة) — وهما بُعدا الحصة الآخران اللذان تتجاهلهما معظم الأدلة. الانتقال إلى 180 · الانتقال إلى 380
• “The quota may increase or decrease based on the document quality.” (الترجمة العربية) «قد تزيد الحصة أو تنقص بناءً على جودة المستند». — Google Search Central، الحصة والأسعار. الانتقال إلى الاقتباس

وثائق Google — التجميع والحذف

• “…you can combine up to 100 calls to the Indexing API into a single HTTP request.” (الترجمة العربية) «يمكنك جمع ما يصل إلى 100 استدعاء لـ Indexing API في طلب HTTP واحد». — Google Search Central، كيفية استخدام Indexing API. الانتقال إلى الاقتباس
• “…the URL must return a 404 or 410 status code or the page must contain” (الترجمة العربية) «يجب أن يعيد عنوان URL رمز الحالة 404 أو 410، أو يجب أن تحتوي الصفحة على» وسم meta بقيمة noindex — قبل طلب الحذف. — Google Search Central، كيفية استخدام Indexing API. الانتقال إلى الاقتباس
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” (الترجمة العربية) «تعني استجابة HTTP 200 أن Google قد تحاول إعادة زحف عنوان URL هذا قريبًا». — Google Search Central، كيفية استخدام Indexing API (بشأن URL_UPDATED). الانتقال إلى الاقتباس

جون مولر، مسؤول دعم بحث Google — Bluesky، نحو مايو 2025

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.” (الترجمة العربية) «نرى كثيرًا من مرسلي الرسائل غير المرغوب فيها يسيئون استخدام Indexing API بهذه الطريقة، لذا أوصي بالالتزام بحالات الاستخدام الموثَّقة والمدعومة».
• “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (الترجمة العربية) «الأصح أن تُستخدم على الوجه السليم، وإلا فلا تُستخدم. ولو أردنا القول إن استخدامها جائز على أي حال، لذكرنا ذلك صراحةً في الوثائق». قراءة التغطية

جون مولر، Google — جلسة ساعات عمل SEO، مايو 2022 (تشبيه «مركبات البناء»)

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.” (الترجمة العربية) «إن Indexing API مخصّصة لأنواع محددة جدًا من المحتوى، واستخدامها لأنواع أخرى لا معنى له فعليًا».
• “It’s not that it’s illegal or that it will cause problems if you put construction vehicles on your medical website. But it doesn’t really make sense.” (الترجمة العربية) «ليست المسألة أن وضع مركبات بناء في موقعك الطبي غير قانوني أو سيسبب مشكلات، لكنه لا معنى له فعليًا». قراءة التغطية

ورقة مرجعية لـ Indexing API

حالات الاستخدام المدعومة (وهذه هي القائمة كاملةً)

الطريقتان

التجميع: اجمع حتى 100 استدعاء في طلب HTTP واحد، لكن الحصة تظل محسوبة لكل عنوان URL، لا لكل دفعة.

حقائق سريعة

• تتكون الحصة الافتراضية من ثلاثة أجزاء: 200 طلب نشر يوميًا، و180 طلب حالة (getMetadata) في الدقيقة، و380 طلبًا في الدقيقة عبر جميع نقاط النهاية. ويحتاج تجاوزها إلى موافقة Google، كما قد تتغير الحصة مع جودة المستند.
• 200 لا تعني مفهرسًا. تؤكد استجابة النجاح استلام الطلب، ولا شيء أكثر.
• استخدام حسابات متعددة لتجاوز الحصة = إلغاء الوصول، وفق الوثائق.
• التوثيق: مشروع Google Cloud + حساب خدمة + OAuth، بالنطاق https://www.googleapis.com/auth/indexing، مع إضافة حساب الخدمة مالكًا مفوَّضًا في GSC.
• ليست IndexNow، وهي عابرة للمحركات ولا تشمل Google. كما أنها ليست بديلًا لخرائط الموقع أو طلب الفهرسة في GSC.

استدعاء نشر بسيط (للمحتوى المدعوم فقط)

هذا هو شكل إشعار URL_UPDATED واحد. لا تستخدمه إلا للصفحات التي تتضمن بيانات JobPosting أو BroadcastEvent المنظَّمة؛ فهذا هو نطاق API المعتمد. حُذفت خطوة التوثيق، أي مبادلة مفتاح حساب الخدمة برمز OAuth، اختصارًا. وعمليًا ستستخدم مكتبة عميل Google API للحصول على الرمز.

الطلب

POST https://indexing.googleapis.com/v3/urlNotifications:publish
Authorization: Bearer <OAUTH_TOKEN>
Content-Type: application/json

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_UPDATED"
}

للإشارة إلى حذف (بعد اختفاء الصفحة أو ضبطها على noindex):

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_DELETED"
}

فحص الحالة — لاحظ أن الاستجابة لا تخبرك إلا باستلام الطلب، لا بما إذا كان شيء قد فُهرس:

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fsenior-seo-analyst
Authorization: Bearer <OAUTH_TOKEN>

تعني 200 هنا «استلمنا طلبك»، وهي ليست تأكيدًا على أن Google فهرست عنوان URL أو حذفته.

تجميع عدة عناوين URL: يمكنك جمع ما يصل إلى 100 استدعاء منفرد في طلب HTTP واحد متعدد الأجزاء إلى https://indexing.googleapis.com/batch بدل إرسال 100 طلب منفصل. لكن الحصة تظل محسوبة لكل عنوان URL، لذا تستهلك دفعة من 100 استدعاء 100 طلب من حصتك اليومية. وتتولى مكتبات عملاء Google API للغات Java وPython وJavaScript وPHP و.NET تنسيق الدفعات نيابةً عنك؛ ونادرًا ما يستحق بناؤه يدويًا العناء.

Indexing API مقابل طلب الفهرسة مقابل IndexNow

إطار القرار: حدّد نوع ما لديك ومحرك البحث الذي يهمك، ثم اختر القناة.

كيفية الاختيار

1. لديك إعلانات وظائف أو عمليات بث مباشر وتريد الأتمتة؟ ← Indexing API.
2. تريد دفع صفحات عامة إلى Bing أو Yandex أو Yep؟ ← IndexNow.
3. تريد من Google إعادة زحف صفحة عادية واحدة، مرة واحدة؟ ← «طلب الفهرسة» في GSC.
4. تريد فهرسة صفحات عامة على نطاق واسع في Google؟ ← لا يوجد زر دفع. استخدم خرائط الموقع والروابط الداخلية والجودة. وتحلَّ بالصبر؛ راجع وتيرة الزحف.

النموذج الذهني: تبدو Indexing API الأقوى بين الثلاث لأنها API، لكنها الأضيق من حيث أنواع المحتوى. القوة والنطاق ليسا الشيء نفسه.

الأدوات

• Google Cloud Console — أنشئ المشروع وفعّل Indexing API وأنشئ مفتاح JSON الخاص بحساب الخدمة الذي ستوثق به.
• Google Search Console — فحص عنوان URL — هذه أداتك الحقيقية للصفحات العادية: تحقّق من كيفية زحف عنوان URL وعرضه وفهرسته، واستخدم «طلب الفهرسة» للحالات الفردية العرضية.
• Google Search Console — خرائط الموقع والتغطية — أرسل خرائط الموقع واعرف ما فُهرس وما يحمل حالة «تم اكتشاف الصفحة، ولم تتم فهرستها حاليًا» أو استُبعد.
• مكتبات عملاء Google API — أنظف وسيلة للتعامل مع مبادلة رمز OAuth في استدعاءات Indexing API بدل تنفيذ توقيع JWT يدويًا.
• تكامل IndexNow (مثل Ahrefs Site Audit) — قناة الدفع العابرة للمحركات، أي Bing وغيرها لا Google. وهي الأداة المناسبة عندما تريد سلوك الدفع البرمجي الذي يتمنى الناس خطأً أن توفره Indexing API للصفحات العامة.

موارد تستحق وقتك

مقالات ذات صلة كتبتها

• ما Googlebot وكيف يعمل؟ — موضع Indexing API بين مصادر Google لاكتشاف عناوين URL، مثل الروابط وخرائط الموقع وRSS وGSC وAPI.
• كيفية إصلاح «تم اكتشاف الصفحة، ولم تتم فهرستها حاليًا» — المرجع الحقيقي لسؤال «لماذا لا تُفهرس صفحاتي؟»؛ فالحل هو الجودة والروابط الداخلية، لا API للدفع.
• دليل المبتدئين إلى SEO التقني — موضع الزحف والفهرسة في الصورة الكبرى.

محاضراتي

• كيف يعمل البحث (SlideShare) — شرحي للاكتشاف والزحف والعرض والفهرسة والترتيب. وتصف شريحة اكتشاف عناوين URL استخدامات Indexing API بأنها «محدودة». وينطبق تنبيهي الدائم: «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا بنسبة 100%».

عن IndexNow (الشقيق العابر للمحركات — لاحظ أن Google لا تستخدمه)

• تكامل IndexNow في Ahrefs Site Audit — قناة الدفع التي أدعمها فعلًا لـ Bing وYandex وYep، لا Google.
• كيفية إرسال الصفحات إلى IndexNow داخل Site Audit.

من الآخرين

• Google تضيف تحذيرًا من الرسائل غير المرغوب فيها إلى وثائق Indexing API (Search Engine Journal، سبتمبر 2024) — يوثّق توقيت إضافة لغة اكتشاف الرسائل غير المرغوب فيها.
• Google تقول مجددًا: توقفوا عن استخدام Indexing API للمحتوى غير المدعوم (Search Engine Roundtable، مايو 2025) — يغطي باري شوارتز تحذير مولر على Bluesky من إساءة استخدام الواجهة.
• إساءة استخدام Indexing API قد تؤدي إلى مشكلات SEO (StanVentures، مايو 2025) — يعيد نشر اقتباسات مولر من Bluesky في مايو 2025 حرفيًا ويشرح خطر إلغاء الوصول.
• Google تجيب: هل استخدام Indexing API لموقع عادي جيد أم سيئ؟ (iLoveSEO، مايو 2022) — نص تشبيه مولر بـ«مركبات البناء» في ساعات العمل.
• Google تقول إن المدوّنين يغمرون Indexing API (Optimixed) — يغطي إغراق المدوّنين ومتخصصي SEO للواجهة بالاستخدام غير الرسمي.
• r/TechSEO — مجتمع تشخيص مشكلات الزحف والفهرسة.

مشكلات شائعة

مشكلات يواجهها المستخدمون فعليًا مع Indexing API، مرتبةً على صورة العَرَض ← السبب ← الحل.

«تلقيت استجابة 200 لكن الصفحة ما زالت غير مفهرسة»

• العَرَض: ينجح استدعاء URL_UPDATED أو طلب الحالة GET، لكن الصفحة لا تظهر في البحث، أو يظل Search Console يعرض «تم اكتشاف الصفحة، ولم تتم فهرستها حاليًا».
• السبب: لا تؤكد 200 إلا أن Google استلمت الإشعار. تقول وثائق Google إن نقطة نهاية الحالة “only returns whether you successfully submitted a request” (الترجمة العربية) «لا تعيد سوى ما إذا كنت قد أرسلت طلبًا بنجاح»، ولا تخبرك هل زُحف شيء أو فُهرس أو حُذف.
• الحل: توقف عن معاملة استجابة API كتأكيد للفهرسة. افحص حالة الفهرسة الفعلية في أداة فحص عنوان URL داخل Search Console أو تقرير التغطية. وإذا بقيت الصفحة غير مفهرسة بعد مدة معقولة، فالمشكلة في الاكتشاف أو الجودة، كما يوضح قسم «ما البديل؟» في علامة التبويب المتقدمة، لا في استدعاء API.

«أُلغي وصولي إلى Indexing API»

• العَرَض: تبدأ الاستدعاءات التي كانت تعمل بالفشل، أو يعرض Google Cloud أو Search Console أن وصول حساب الخدمة قد سُحب.
• السبب: تقول Google بوضوح: “any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (الترجمة العربية) «قد تؤدي أي محاولة لإساءة استخدام Indexing API، بما فيها استخدام حسابات متعددة أو وسائل أخرى لتجاوز حصص الاستخدام، إلى إلغاء الوصول». والسبب الشائع هو إرسال صفحات لا تتضمن JobPosting أو BroadcastEvent، أو إنشاء حسابات خدمة إضافية للالتفاف على الحصة الافتراضية البالغة نحو 200 طلب يوميًا.
• الحل: راجع ما أرسلته. إذا كان محتوى عامًا، مثل تدوينات أو صفحات منتجات أو أي شيء بلا بيانات JobPosting أو BroadcastEvent المنظَّمة، فتوقف. لا توثّق Google دعم API له، وقد قال مولر مباشرةً: “I’d just use it properly, or not use it.” (الترجمة العربية) «سأستخدمها كما ينبغي فحسب، أو لن أستخدمها». ولا يوجد مسار اعتراض موثَّق سوى الالتزام بحالة الاستخدام المدعومة مستقبلًا.

«لا يبدو أن إرسال الصفحات العادية يفعل شيئًا»

• العَرَض: ترسل URL_UPDATED لمقالة عادية أو صفحة منتج ولا يتغير شيء؛ فلا زحف أسرع ولا فهرسة أسرع.
• السبب: نوع المحتوى ليس أحد النوعين اللذين تدعمهما Google. تقول الوثائق إن Indexing API “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (الترجمة العربية) «لا يمكن استخدامها إلا لزحف الصفحات التي تتضمن إما JobPosting أو BroadcastEvent مضمَّنًا في VideoObject». والإرسال خارج هذا النطاق ليس إشارة موثَّقة أو مدعومة.
• الحل: هذه ليست علة برمجية؛ بل الأداة خاطئة. للصفحات العامة، استخدم خريطة موقع وروابط داخلية وخيار «طلب الفهرسة» العرضي في أداة فحص عنوان URL ضمن Search Console.

«أصطدم بحد الحصة»

• العَرَض: تبدأ الطلبات بالفشل أو الخضوع لتقييد المعدل، إما قرب 200 طلب يوميًا أو في دفعات أقصر حتى قبل بلوغ 200 يوميًا.
• السبب: تفرض Google ثلاث حصص افتراضية منفصلة: 200 طلب نشر (URL_UPDATED وURL_DELETED) في اليوم، و180 طلب حالة (getMetadata) في الدقيقة، و380 طلبًا في الدقيقة عبر جميع نقاط النهاية. وقد تقيّدك دفعة من فحوص الحالة عند حدود الدقيقة قبل بلوغ 200 اليومية بفارق كبير. ويتطلب تجاوز أي منها “requires additional approval for usage and resource provisioning,” (الترجمة العربية) «موافقة إضافية على الاستخدام وتوفير الموارد». وتنبّه Google إلى أن الحصة الممنوحة “may increase or decrease based on the document quality.” (الترجمة العربية) «قد تزيد أو تنقص بناءً على جودة المستند».
• الحل: إذا كنت تنشر أو تحدّث بصورة مشروعة هذا العدد من صفحات JobPosting أو BroadcastEvent يوميًا، فاطلب زيادة الحصة عبر Google Cloud. لا تنشئ حسابات خدمة أو مشاريع إضافية للالتفاف عليها؛ فهذا مذكور صراحةً ضمن إساءة الاستخدام التي تؤدي إلى إلغاء الوصول.

قوائم التحقق

قبل استخدام Indexing API

• تأكد من أن الصفحات التي تريد إرسالها تحمل فعلًا بيانات JobPosting المنظَّمة، أو BroadcastEvent مضمَّنًا في VideoObject؛ فهذان هما نوعا المحتوى الوحيدان اللذان تدعمهما Google.
• إذا لم ينطبق أي منهما، فتوقف هنا. استخدم خرائط الموقع والروابط الداخلية وجودة المحتوى وخيار «طلب الفهرسة» العرضي في GSC، لا API.
• حدّد هل سيتسع الحجم الواقعي لطلباتك ضمن الحصة الافتراضية البالغة نحو 200 طلب يوميًا، أم ستحتاج إلى طلب زيادتها.

الإعداد

• أنشئ مشروع Google Cloud أو اختر واحدًا، وفعّل Indexing API فيه.
• أنشئ حساب خدمة ونزّل ملف مفتاح JSON الخاص به، واحفظه بأمان ولا تودعه أبدًا في مستودع عام.
• أثبت ملكية موقعك في Search Console إن لم تكن قد فعلت.
• أضف بريد حساب الخدمة بصفته مالكًا مفوَّضًا للموقع في Search Console.
• تأكد من إمكان مبادلة مفتاح حساب الخدمة برمز OAuth ذي النطاق https://www.googleapis.com/auth/indexing، ويفضل عبر مكتبة عميل Google API بدل توقيع JWT يدويًا.

إرسال إشعار

• اختر الطريقة الصحيحة: URL_UPDATED لصفحة مدعومة جديدة أو معدَّلة، وURL_DELETED بعد اختفاء الصفحة أو ضبطها على noindex.
• أرسل عنوان URL عبر POST مع حقل type الصحيح إلى https://indexing.googleapis.com/v3/urlNotifications:publish.
• تعامل مع استجابة 200 على أنها تأكيد استلام فقط، لا دليلًا على فهرسة الصفحة أو حذفها.
• تابع في Search Console، عبر فحص عنوان URL أو التغطية، إذا احتجت إلى تأكيد حالة الفهرسة الفعلية.

الالتزام بالإرشادات

• لا ترسل عبر API إلا صفحات JobPosting أو BroadcastEvent، ولا شيء غير ذلك.
• لا تنشئ حسابات خدمة أو مشاريع متعددة لمجرد تجاوز الحصة؛ اطلب زيادة مشروعة بدلًا من ذلك.
• إذا لم تكن متأكدًا من أهلية صفحة، فتعامل معها على أنها «غير مؤهلة»، واستخدم لها خرائط الموقع والروابط الداخلية وطلب الفهرسة.

اختبار

خمسة أسئلة للتحقق مما فهمته فعلًا عن Indexing API.

سجل التغييرات