واجهة برمجة تطبيقات Search Console

كيفية سحب بيانات Google Search Console وإدارتها برمجياً، بما يشمل واجهات Search Analytics وURL Inspection وSitemaps وSites، وOAuth والحصص، ومتى تستخدم BigQuery بدلاً منها.

نُشر أول مرة: 23 يونيو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات

بالنسبة إلى ملكيات مواقع الويب، تتيح واجهة Google Search Console API موارد Search Analytics وURL Inspection وSitemaps وSites عبر OAuth 2,0. تعيد Search Analytics حتى 25 000 من أعلى الصفوف في الطلب الواحد؛ وتقتصر URL Inspection على 2 000 طلب يومياً و600 طلب في الدقيقة لكل ملكية. لدى Search Console أيضاً ملكيات لمنصات Instagram وTikTok وX وYouTube، لكن وثائق Google الحالية لا تحدد معرفات API القديمة أو دعم نقاط النهاية لها، ولذلك لا يدعي هذا الدليل توافقها مع API.

الخلاصة — Search Console API هي أربع واجهات REST تحت webmaster-tools/v1: Search Analytics وURL Inspection وSitemaps وSites. تستخدم كلها OAuth 2,0 وتقتصر على الملكيات التي تم التحقق منها. تعيد Search Analytics من 1 إلى 25 000 صف لكل طلب، والافتراضي 1 000، لكنها “does not guarantee to return all data rows but rather top ones” (الترجمة العربية): «لا تضمن إعادة جميع صفوف البيانات، بل الصفوف الأعلى فقط»، ولذلك تنتقل عند الحاجة إلى اكتمال واسع النطاق إلى التصدير المجمع في BigQuery. وتخضع URL Inspection لحد صارم قدره 2 000 طلب يومياً و600 طلب في الدقيقة لكل موقع؛ وهذا الحساب هو ما يقيد مراقبة الفهرسة على نطاق كبير.

Evidence for this claim The Search Console API exposes Search Analytics, Sitemaps, Sites, and URL Inspection operations. Scope: Current Search Console API surface. Confidence: high · Verified: Google Developers: Search Console API Evidence for this claim Search Analytics results are bounded by API quotas and may omit some rows; the API does not guarantee every data row. Scope: Current Search Analytics query behavior and quotas. Confidence: high · Verified: Search Console API: Search Analytics query

يقتصر دليل API هذا على ملكيات مواقع الويب. لا تفترض أن نقاط نهاية Sites أو Search Analytics أو URL Inspection أو Sitemaps تدعم ملكيات منصات Instagram أو TikTok أو X أو YouTube حتى توثق Google المعرف وعقد نقطة النهاية.

نظرة سريعة إلى واجهات API الأربع

تصوغ Google وظيفة API بأنها تتيح لك “view, add, or remove properties and sitemaps, run advanced queries for Google Search results data for the properties that you manage in Search Console, and test individual pages.” (الترجمة العربية): «عرض الملكيات وخرائط الموقع أو إضافتها أو إزالتها، وتشغيل استعلامات متقدمة لبيانات نتائج بحث Google للملكيات التي تديرها في Search Console، واختبار صفحات فردية». وينطبق ذلك بوضوح على الموارد الأربعة، وكلها تحت webmaster-tools/v1:

  • Search Analytics API — تقرير الأداء برمجياً: النقرات ومرات الظهور ونسبة النقر والموضع حسب البعد، مثل الاستعلام والصفحة والبلد والجهاز وشكل الظهور في البحث والتاريخ والساعة.
  • URL Inspection API — حالة فهرسة عنوان URL واحد، وهي النظير البرمجي لأداة URL Inspection.
  • Sitemaps API — سرد خرائط الموقع والحصول عليها وإرسالها وحذفها.
  • Sites API — سرد الملكيات المتحقق منها وإضافتها وإزالتها.
Evidence for this claim The Search Console API exposes Search Analytics, Sitemaps, Sites, and URL Inspection operations. Scope: Current Search Console API surface. Confidence: high · Verified: Google Developers: Search Console API

تعرض API كثيراً مما تستخدمه في الواجهة، مثل تقرير الأداء وأداة URL Inspection، كنقاط نهاية قابلة للبرمجة. لكنها ليست مرآة متطابقة؛ فلا تضمن تكافؤاً كاملاً مع الواجهة، إذ لا يوجد اختبار URL Inspection المباشر مثلاً إلا في الواجهة، كما أن الوصول إلى API أو الأتمتة لا يضمن وحده الفهرسة أو الترتيب أو تشخيص الزيارات أو الظهور في بحث الذكاء الاصطناعي.

المصادقة: OAuth 2,0 ونطاقان والملكيات المتحقق منها فقط

لا يوجد مفتاح API. كل استدعاء يستخدم OAuth 2,0، وتقول Google صراحة إن “all requests to the Google Search Console API must be authorized by an authenticated user.” (الترجمة العربية): «يجب أن يفوض مستخدم مصادق عليه جميع الطلبات إلى Google Search Console API». تسجل تطبيقاً في Google Cloud، وتطلب نطاقاً، وتحصل على رمز وصول قصير العمر. ويوجد نطاقان:

  • https://www.googleapis.com/auth/webmasters — قراءة وكتابة.
  • https://www.googleapis.com/auth/webmasters.readonly — قراءة فقط.

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

بالنسبة إلى ملكيات مواقع الويب، تهم صيغتان لمعرف الملكية: تمرر ملكية بادئة URL كعنوان الملكية كاملاً، ومثال Google هو http://www.example.com/، بينما تستخدم ملكية النطاق الصيغة sc-domain:example.com. عليك تمرير الصيغة المطابقة لطريقة التحقق من الملكية في Search Console. وفي الحالتين يحتاج حساب الخدمة أو المستخدم إلى وصول ممنوح للملكية المحددة نفسها؛ فلا تتجاوز هذه الآلية الملكية ولا تمنح وصولاً شاملاً لكل ملكيات الحساب.

أما الشرط الذي يعرقل الجميع فهو: “You must have appropriate access (owner, full, read) to any Google Search Console account that you wish to access using the API.” (الترجمة العربية): «يجب أن تملك مستوى الوصول المناسب، مالكاً أو كاملاً أو قراءة، إلى أي حساب Google Search Console تريد الوصول إليه عبر API». إذا استدعيت API لملكية لم تتحقق منها فلن تعيد شيئاً؛ وقد يكون ذلك بيانات فارغة لا خطأً واضحاً.

Search Analytics API: تقرير الأداء على نطاق واسع

ابدأ بالسقف لا بالسهولة. تحذر Google بأن “The API is bounded by internal limitations of Search Console and does not guarantee to return all data rows but rather top ones.” (الترجمة العربية): «تخضع API لقيود Search Console الداخلية ولا تضمن إعادة جميع صفوف البيانات، بل الصفوف الأعلى فقط». يوسع ترقيم الصفحات المسافة التي تستطيع قطعها في قائمة الصفوف الأعلى، لكنه لا يزيل السقف. وعندما تحتاج كل صف، فهذا هو وقت استخدام التصدير المجمع إلى BigQuery أدناه، لا قيمة rowLimit أكبر.

ومع ذلك تظل هذه الواجهة سبب استخدام معظم الناس لـAPI. تتفوق على الواجهة بسبب معامل rowLimit: “[Optional; Valid range is 1–25,000; Default is 1,000].” (الترجمة العربية): «اختياري؛ النطاق الصالح من 1 إلى 25 000؛ والافتراضي 1 000». يتوقف تصدير الواجهة عند نحو 1 000 صف، بينما تمنحك API حتى 25 000 صف لكل طلب، وتنتقل بعدها باستخدام startRow. وفي موقع له ذيل طويل من الاستعلامات، يعني ذلك رؤية بيانات أكثر، وإن لم تكن كلها.

يشكل أمران آخران النتيجة. أولاً، تتحكم dataState في حداثة البيانات: تعيد final، وهي الافتراضية، البيانات النهائية فقط؛ وتضم all بيانات حديثة جُمعت للتو؛ وتوفر hourly_all تفصيلاً بالساعة يكون جزئياً صراحة، وتحدد بيانات الاستجابة first_incomplete_date أو first_incomplete_hour، كما تنبه Google إلى أن القيم بعد تلك النقطة قد تتغير. ثانياً، ليست حصص Search Analytics رقماً واحداً؛ إذ تفصل صفحة الحدود بين حدود التحميل القائمة على الموارد والمقاسة في فترات عشر دقائق ويوم واحد، وبين حدود معدل الطلبات QPS وQPM وQPD. تستهلك النطاقات الزمنية الأوسع والأبعاد الأكثر والتصفية الأثقل حصة أكبر، وقد تبلغ حد التحميل قبل حد معدل الطلبات.

URL Inspection API: الحصة التي تقيدك فعلياً

تقول وثائق URL Inspection API إنها “view[s] the indexed, or indexable, status of the provided URL. Presently only the status of the version in the Google index is available; you cannot test the indexability of a live URL.” (الترجمة العربية): «تعرض حالة الفهرسة أو قابلية الفهرسة لعنوان URL المقدم. لا تتاح حالياً إلا حالة النسخة الموجودة في فهرس Google؛ ولا يمكنك اختبار قابلية فهرسة عنوان URL مباشر». وهذا قيد حقيقي: تستطيع أداة URL Inspection في الواجهة إجراء اختبار مباشر للصفحة كما هي الآن، بينما لا تستطيع API إلا الإبلاغ عن النسخة الموجودة في الفهرس. استخدمها لبناء مراقبة تغطية الفهرس لعدة عناوين، لا بديلاً من اختبار الواجهة المباشر.

وهنا يصبح الحساب مهماً. تحصل لكل موقع على 2 000 طلب يومياً و600 طلب في الدقيقة. أما الحد لكل مشروع فأعلى بكثير، 10 000 000 يومياً و15 000 في الدقيقة، لكن حد الموقع هو المؤثر. إذا أردت مراقبة حالة فهرسة موقع يضم 50 000 عنوان URL، فلن تستطيع فحصها كلها في يوم واحد؛ وعليك توزيعها على دفعات وأيام أو تحديد الأولويات. لا تحسب مقالات كثيرة هذه المسألة، مع أنها أكبر قيد تخطيطي للمراقبة واسعة النطاق.

وبالمقارنة، تعد Search Analytics سخية، بمقدار 1 200 طلب في الدقيقة لكل موقع ولكل مستخدم، بينما تبلغ موارد Sitemaps وSites مقدار 20 طلباً في الثانية و200 في الدقيقة لكل مستخدم. URL Inspection هي الأضيق.

واجهتا Sitemaps وSites

تدير Sitemaps API خرائط موقعك؛ فهي “submits a sitemap for a site,” (الترجمة العربية): «ترسل خريطة موقع لموقع»، و*“deletes a sitemap from this site,”* (الترجمة العربية): «تحذف خريطة موقع من هذا الموقع»، و*“retrieves information about a specific sitemap,”* (الترجمة العربية): «تسترجع معلومات عن خريطة موقع محددة»، و*“lists the sitemaps-entries submitted for this site, or included in the sitemap index file.”* (الترجمة العربية): «تسرد إدخالات خرائط الموقع المرسلة لهذا الموقع أو المضمنة في ملف فهرس خرائط الموقع». ويتضمن مورد خريطة الموقع حقولاً مثل path وlastSubmitted وisPending وisSitemapsIndex وlastDownloaded وwarnings وerrors ومصفوفة contents، وهي مفيدة لتدقيق صحة الخرائط على نطاق واسع.

أما Sites API فتسرد الملكيات المتحقق منها وتضيفها وتزيلها، وهي مفيدة عند إدارة ملكيات كثيرة تريد توفيرها أو تدقيقها برمجياً.

متى تستخدم التصدير المجمع إلى BigQuery؟

في المواقع الكبيرة، يصبح نموذج 25 000 صف لكل طلب والصفوف الأعلى فقط سقفاً. ولا تقدم Google مورداً خامساً يعيد الشكل نفسه من البيانات، بل مسار تصدير مجدولاً منفصلاً هو التصدير المجمع للبيانات إلى BigQuery. فكر في الاختيار على أنه سحب مقابل دفع مجدول، لا API أ مقابل API ب. تصفه Google هكذا: “Schedule a daily export of your Search Console performance data to BigQuery, where you can run complex queries over your data or export it to an external storage service. Using the bulk data export feature, you’ll see all the performance data available to Search Console for your property, with the exception of anonymized queries.” (الترجمة العربية): «جدول تصديراً يومياً لبيانات أداء Search Console إلى BigQuery، حيث يمكنك تشغيل استعلامات معقدة على بياناتك أو تصديرها إلى خدمة تخزين خارجية. وباستخدام التصدير المجمع سترى جميع بيانات الأداء المتاحة للملكية، باستثناء الاستعلامات مجهولة الهوية».

قاعدة القرار هي:

  • تصدير الواجهة — نحو 1 000 صف لإلقاء نظرة سريعة مرة واحدة.
  • Search Analytics API — حتى 25 000 صف لكل طلب، مع ترقيم وقابلية للبرمجة؛ مناسب للسحوبات المتوسطة عند الطلب ولوحات المعلومات.
  • التصدير المجمع إلى BigQuery — جميع بيانات الأداء المتاحة يومياً بلا حد للصفوف؛ وهو الأنسب عندما تملك عشرات الآلاف من الصفحات أو الاستعلامات.

ولا يمنحك أي منها الاستعلامات مجهولة الهوية التي تخفيها Google للخصوصية. هذه فجوة حقيقية لا خطأ يمكن التحايل عليه. أعرف حجمها مباشرة؛ فبصفتي سفير علامة Ahrefs ساعدت في إبراز دراسة سحبنا فيها كل البيانات المتاحة من API عبر عينة كبيرة جداً من المواقع، ووجدنا أن Google تخفي عبارة الكلمة المفتاحية لنسبة كبيرة من النقرات. ثم بنينا ذلك في Ahrefs Rank Tracker: سجل كامل لبيانات GSC، ونسبة النقرات المنسوبة إلى الاستعلامات مجهولة الهوية، ومنحنى CTR مخصصاً من أرقامك. حين يقول أحدهم إن API تعيد «كل بياناتك»، فهذه الشريحة المخفية هي الاستثناء الصادق.

حالات الاستخدام الشائعة

  • التقارير المؤتمتة — سحوبات مجدولة إلى Sheets أو مستودع بيانات.
  • لوحات ذكاء الأعمال — Looker Studio أو BigQuery فوق بيانات الأداء.
  • مراقبة الفهرسة والتغطية على نطاق واسع — URL Inspection موزعة ضمن حصة 2 000 طلب يومياً.
  • بناء منحنى CTR — نمذجة نسبة النقر المتوقعة حسب الموضع من بياناتك.
  • تنبيهات الشذوذ — رصد انخفاض النقرات أو مرات الظهور تلقائياً.

هكذا تعمل أيضاً أدوات الأطراف الثالثة؛ فعندما «تدمج» Ahrefs أووصلة Looker Studio مع Search Console، فإنها تستدعي واجهات API نفسها، وبصورة متزايدة تصدير BigQuery، نيابة عنك.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.