كيف تربط وكيل ذكاء اصطناعي بـ Google Search Console؟ (6 طرق)

هناك ست طرق عملية لمنح وكيل ذكاء اصطناعي (AI agent) إمكانية الوصول إلى بيانات Google Search Console: موصّل OAuth مُستضاف، أو خادم MCP من تطوير المجتمع، أو واجهة Search Console API مباشرةً، أو التصدير المجمّع إلى BigQuery، أو جسر عبر جداول البيانات، أو ميزة الإعداد المدعوم بالذكاء الاصطناعي المدمجة في Search Console نفسها دون أي وكيل. يتراوح وقت الإعداد بين دقيقتين ومعظم يوم عمل، والطريقة المناسبة تتوقف على سؤال واحد: هل تحتاج إلى بيانات تاريخية تتجاوز 16 شهرًا؟

هذه النقطة الأخيرة هي مفترق الطرق، فلنبدأ بها. تُرجع واجهة Search Analytics API حدًا أقصى قدره 25,000 صف في كل طلب، وتحتفظ بسجل يمتد 16 شهرًا فقط. بعد 16 شهرًا تختفي البيانات، لا نقصد أنها تُخفى بل تُحذف فعلًا. وإذا كنت تحتاج إلى سجل أطول، فطريقة واحدة فقط في هذه القائمة تمنحك ذلك، ويجب أن تبدأ بها قبل أن تحتاج إليها.

الطريقة 1: موصّل OAuth مُستضاف

الإعداد: من 2 إلى 5 دقائق. بلا برمجة.

تمنح أحد منتجات وكلاء SEO تفويضًا على حسابك في Google، ثم تختار الموقع (property)، فيُحفظ الاتصال على الخادم ويُعاد استخدامه في كل استعلام. هذا ما ينبغي أن يستخدمه معظم المسوّقين، والسبب ليس الكسل، بل أن حالات الفشل تُعالَج نيابةً عنك. فالموصّل المبني جيدًا يكتشف غياب الاتصال ويطلب منك إنشاءه بدلًا من التخمين، ويحدد الموقع الصحيح حين تملك عدة مواقع، ويتجاوز سقف الـ25,000 صف بالترقيم (pagination) دون أن تفكر في الأمر.

في تطبيقنا الخاص، أداة Search Console موسومة بأنها للقراءة فقط، وتتحقق من وجود اتصال نشط عند أول استدعاء، وإن لم يوجد تعرض طلب اتصال تفاعليًا برابط مباشر إلى شاشة التكاملات، ثم تستأنف المحادثة فور عودتك.

المقابل: تحصل على مجموعة الأدوات التي بناها المزوّد فقط. فإذا أردت صيغة استعلام لم ينفّذها، فلن تحصل عليها.

الطريقة 2: خادم MCP لـ Search Console

الإعداد: من 15 إلى 45 دقيقة. يتطلب ارتياحًا للعمل التقني.

بروتوكول سياق النموذج (Model Context Protocol) معيار مفتوح بنظام العميل والخادم لربط مساعدي الذكاء الاصطناعي بالأنظمة الخارجية، ولذلك يستطيع أي عميل يدعم MCP، مثل Claude Desktop وClaude Code وCursor وغيرها، استدعاء خادم Search Console مباشرةً.

التحفظ المهم هنا: على عكس GA4 الذي تنشر له Google خادم MCP خاصًا بها، لا يوجد خادم MCP رسمي من Google لـ Search Console. المتوفر هو مجموعة جيدة من التطبيقات المجتمعية مثل mcp-server-gsc، الذي يجلب بيانات تحليلات البحث حتى سقف الـ25,000 صف مع دعم التصفية بالتعبيرات النمطية (regex)، ويعمل للقراءة فقط.

الإعداد عبارة عن كتلة JSON في عميل MCP تشير إلى الخادم مع بيانات الاعتماد الخاصة بك:

{
  "mcpServers": {
    "search-console": {
      "command": "npx",
      "args": ["-y", "mcp-server-gsc"],
      "env": { "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json" }
    }
  }
}

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

الطريقة 3: واجهة Search Console API مع حساب خدمة

الإعداد: من ساعة إلى 3 ساعات. ستكتب شيفرة برمجية.

أكبر قدر من التحكم، وأكبر قدر من العمل. الخطوات بالترتيب:

1. أنشئ مشروعًا على Google Cloud، أو استخدم مشروعًا قائمًا.
2. فعّل عليه Search Console API.
3. أنشئ حساب خدمة (service account) ونزّل مفتاح JSON الخاص به.
4. أضف عنوان البريد الإلكتروني لحساب الخدمة كمستخدم على موقع Search Console نفسه، بصلاحية «مقيّدة» (للقراءة فقط).
5. صادِق الوكيل باستخدام المفتاح واستدعِ searchanalytics.query.

الخطوة 4 هي التي ينساها الجميع. إنشاء بيانات اعتماد في Cloud لا يمنحها حق الوصول إلى الموقع، فهما نظاما صلاحيات منفصلان، وتخطي الثاني ينتج خطأ 403 عامًا يبدو وكأنه مشكلة في تفعيل الـAPI لا مشكلة في الوصول إلى الموقع. توقّع أن تخسر عشرين دقيقة بسبب هذا مرة واحدة على الأقل.

هذا مثال على أبسط جسم استعلام مع الترقيم:

{
  "startDate": "2026-04-01",
  "endDate":   "2026-06-30",
  "dimensions": ["query", "page"],
  "rowLimit":  25000,
  "startRow":  0
}

زِد قيمة startRow بمقدار 25,000 في كل صفحة، وتوقف حين تُرجع الاستجابة صفوفًا أقل مما طلبت. وكل ما عدا ذلك، من إدارة الحصص وإعادة المحاولة إلى تجديد الرموز المميزة (tokens)، صار مسؤوليتك أنت.

المقابل: مرونة كاملة، لكنك صرت مسؤولًا عن إدارة الحصص والترقيم وإعادة المحاولة وتجديد الرموز. اختر هذه الطريقة حين يحتاج الوكيل إلى صيغة استعلام لا يقدمها أي موصّل، أو حين يجب أن تبقى البيانات داخل بنيتك التحتية.

الطريقة 4: التصدير المجمّع إلى BigQuery

الإعداد: نحو ساعة، يُضاف إليها ما يصل إلى 48 ساعة قبل وصول أول تصدير.

هذه هي الطريقة الوحيدة التي تحل مشكلة الـ16 شهرًا، وهي التي ينبغي أن تُعدّها اليوم حتى لو لم تكن تحتاج إليها بعد، لأنها تراكم السجل من الآن فصاعدًا لا بأثر رجعي.

وفقًا لوثائق Google الخاصة بالتصدير المجمّع للبيانات، الخطوات هي:

1. أنشئ مشروعًا على Google Cloud أو اختر مشروعًا مفعّلًا فيه الفوترة. هذا شرط لا خيار.
2. فعّل عليه BigQuery API وBigQuery Storage API.
3. امنح حساب خدمة Search Console دورين على المشروع: BigQuery Job User وBigQuery Data Editor.
4. في Search Console، افتح «الإعدادات» ثم «التصدير المجمّع للبيانات»، وأدخل معرّف مشروع Cloud وموقع مجموعة البيانات (dataset).
5. انتظر. يصل أول تصدير خلال 48 ساعة، ثم تعمل عمليات التصدير يوميًا بعد ذلك.

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

بمجرد وصول البيانات إلى BigQuery، يستعلم وكيلك بلغة SQL بدلًا من Search Console API، وبهذا تتخلص من سقف الصفوف ونافذة الاحتفاظ دفعةً واحدة. تبقى التكاليف ضمن الفئة المجانية في BigQuery للمواقع الصغيرة، وتصبح حقيقية للمواقع الكبيرة، لذا اطلب من الوكيل التصفية على عمود تاريخ التقسيم (partition) بدلًا من مسح الجدول كاملًا. فالوكيل الذي يكتب SELECT * بلا قيود على ثلاث سنوات من بيانات موقع كبير سيُنتج فاتورة لن تنساها.

المقابل: تكلّف مالًا، وتتطلب أكبر قدر من البنية التحتية بين كل الخيارات، ولا تمنحك شيئًا في اليوم الأول. لكنها أيضًا الطريق الوحيد إلى تحليل يمتد عدة سنوات.

الطريقة 5: جسر عبر جداول البيانات

الإعداد: من 10 إلى 20 دقيقة. بلا برمجة.

صدّر بيانات Search Console إلى Google Sheets وفق جدول زمني باستخدام إضافة أو Apps Script، ثم وجّه وكيلًا لديه صلاحية الوصول إلى Sheets نحو الجدول. هذا هو الخيار العملي حين يكون وكيلك يقرأ جداول البيانات أصلًا وتريد أن تضع البيانات أمامه بعد ظهر اليوم.

المقابل: البيانات حديثة بقدر آخر عملية تصدير فقط، وكل شيء مُصفّى مسبقًا بحسب من أعدّ الجدول، ولا يستطيع الوكيل المتابعة باستعلام لم يتوقعه أحد، وهي بالضبط القدرة التي اقتنيت الوكيل من أجلها. تعامل معه كحل مؤقت.

الطريقة 6: بلا أي اتصال

الإعداد: لا شيء.

في Search Console ذكاء اصطناعي مدمج. فميزة الإعداد المدعوم بالذكاء الاصطناعي من Google تتيح لك وصف التحليل الذي تريده بلغة طبيعية، وتحوّله إلى فلاتر للتقرير ومقارنات واختيارات للمقاييس. اكتب مثلًا: «قارن زيارات صفحاتي التي تحتوي على /blog هذا الربع بالربع نفسه من العام الماضي»، وسيُضبط التقرير تلقائيًا.

اعرف حدودها، فـ Google تذكرها صراحةً: تعمل فقط على تقارير الأداء لنتائج البحث، لا على Discover أو News؛ وتضبط الفلاتر والمقارنات والمقاييس لكنها لا تستطيع ترتيب الجداول أو تصدير البيانات؛ وتحذّر Google من أن الذكاء الاصطناعي قد يسيء فهم الطلب، لذا عليك مراجعة الفلاتر المطبّقة قبل أن تثق بالتحليل. وهي أيضًا أداة إعداد فقط، فلن تستنتج شيئًا عبر GA4 وSearch Console معًا، ولن تحقق في سبب ما.

وبشكل منفصل، يتضمن Search Console الآن تقارير أداء الذكاء الاصطناعي التوليدي للزيارات القادمة من واجهات الذكاء الاصطناعي في Google. إذا كان سؤالك عن الظهور في هذه الواجهات، فهذا هو المصدر الموثوق، ولا يغني عنه أي تقدير من طرف ثالث.

أي طريقة تختار؟

الطريقة	الإعداد	تتجاوز 16 شهرًا	الأنسب لـ
موصّل مُستضاف	2-5 دقائق	لا	المسوّقون الذين يريدون إجابات اليوم
خادم MCP	15-45 دقيقة	لا	المطورون الذين يستخدمون عميل MCP بالفعل
الـAPI مباشرةً	1-3 ساعات	لا	صيغ استعلام مخصصة، وبقاء البيانات داخل المؤسسة
التصدير إلى BigQuery	ساعة + 48 ساعة	نعم	تحليل يمتد سنوات، والمواقع الكبيرة
جسر جداول البيانات	10-20 دقيقة	لا	حل مؤقت
الإعداد المدمج بالذكاء الاصطناعي	لا شيء	لا	بناء التقارير بسرعة أكبر، لا التحقيق

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

هل من الآمن منح وكيل صلاحية الوصول إلى Search Console؟

آمن إلى حد معقول، بثلاثة شروط. امنحه صلاحية القراءة فقط. فصلاحيات Search Console تشمل إرسال خرائط الموقع (sitemaps) وطلب الإزالة، والوكيل لا يحتاج إلى أي من ذلك. فضّل حساب خدمة محدود النطاق على تفويض OAuth شخصي، حتى لا يتوقف سحب الصلاحية على حساب موظف واحد. وافصل أدوات الكتابة عن أدوات جلب صفحات الويب: فالوكيل الذي يقرأ صفحة أحد المنافسين يكون قد أدخل نصًا كتبه طرف خارجي إلى نافذة السياق نفسها التي تحوي تعليماتك، وإذا كانت تلك الصفحة تحمل أوامر مدسوسة فقد ينفّذها وكيل ساذج. بيئة التشغيل لدينا تعزل المحتوى المجلوب بوصفه غير موثوق، وتَسِم الدور (turn) بأنه ملوّث، وترفض كل أداة موسومة للكتابة طوال ما تبقى منه ما لم يوافق إنسان. أما الاستعلام من Search Console فموسوم للقراءة، لذا فهو آمن في الحالتين.

أخطاء الإعداد الشائعة وما تعنيه فعلًا

العَرَض	السبب المعتاد	الحل
خطأ 403 في كل استعلام رغم تفعيل الـAPI	لم يُضَف حساب الخدمة أبدًا كمستخدم على الموقع	أضف بريده الإلكتروني في إعدادات الموقع على Search Console بصلاحية «مقيّدة»
نتائج فارغة دون أي خطأ	عدم تطابق عنوان الموقع: موقع نطاق (domain) مقابل موقع بادئة عنوان URL، أو غياب الشرطة المائلة في النهاية	انسخ اسم الموقع كما يظهر في Search Console حرفيًا
الوكيل يبلغ عن إجماليات مدوّرة بشكل مريب	النتيجة مقطوعة عند سقف الـ25,000 صف وتُعامل على أنها كاملة	استخدم الترقيم عبر startRow، أو ألزم الوكيل بالإشارة إلى الاقتطاع
الأرقام تختلف عن واجهة Search Console	الاستعلامات مجهولة الهوية مستبعدة من تصدير BigQuery، أو اختلاف حدود التاريخ	متوقع في BigQuery؛ وإلا فتحقق من المنطقة الزمنية واستخدام تواريخ مطلقة
التصدير المجمّع مُعدّ لكن لا تظهر أي مجموعة بيانات	ما زلت ضمن نافذة الـ48 ساعة، أو الفوترة غير مفعّلة على المشروع	انتظر، ثم تحقق من الفوترة ومن دوري IAM
خادم MCP يعمل لكنه لا يعرض أي أدوات	مسار بيانات الاعتماد خاطئ، أو عدم تطابق إصدار البروتوكول مع العميل	تأكد من أن مسار env صحيح، ومن إصدار المواصفات الذي يدعمه الخادم

أمران يجب ضبطهما أيًّا كانت الطريقة التي تختارها

تعامل مع الترقيم بأمانة. الوكيل الذي يطلب 25,000 صف ويتلقى 25,000 بالضبط ثم يبلغ عن إجمالي، إنما يبلغ عن نتيجة مقطوعة. اطلب منه أن يستخدم الترقيم أو أن يصرّح بأن النتيجة بلغت السقف.

استخدم تواريخ مطلقة. العبارات النسبية مثل «الشهر الماضي» تُحسب وفق المنطقة الزمنية للموقع ولحظة تشغيل الاستعلام. وهي السبب الأكثر شيوعًا لتحليل Search Console واثق ومتماسك... وخاطئ.

بعد إنشاء الاتصال، يشرح مقال ما الذي يستطيع الوكيل اكتشافه فعلًا في بيانات Search Console التحليلات التي تستحق التشغيل، أما Autopilot فينفّذ مسار الموصّل المُستضاف الموصوف في الطريقة 1.