كيف تختار ChatGPT وGemini وPerplexity وCopilot المنتجات التي تذكرها، وما الصحيح في نصائح GEO، وما الذي تصلحه في بيانات منتجاتك وخلاصاتها، وكيف تقيس الإحالات، مع قائمة تحقق من عشر نقاط.
Author
Anichur Rahaman
تابعنا في الجزء الأول من هذه السلسلة صاحبة متجر صغير لمعدات الرحلات الخارجية، لم يُظهر وكيل التسوق الذكي سترتها الأكثر مبيعًا قط. رتّبت بيانات منتجاتها، فبدأت طلبات الوكلاء تصل. والآن، صباح يوم ثلاثاء في الثامنة وأربعين دقيقة، تطرق بابًا آخر: تكتب لمساعد ذكاء اصطناعي عام ما قد يكتبه أي زبون: «سترة مضادة للماء بأقل من 150 دولارًا تصل قبل يوم الجمعة». يعيد المساعد أربع سترات، لكل منها سبب ورابط. أما سترتها الأكثر مبيعًا، بسعر 129 دولارًا، فليست بينها.
وحين تبحث عن السبب تجد أن المشكلة ليست في الترتيب. صفحتها تعرض 129 دولارًا، لكن خلاصة منتجاتها ما زالت تحمل سعر الشهر الماضي، 159 دولارًا، وتعدّ مقاسًا متوفرًا بينما تعرضه الصفحة منتهيًا. وجد المساعد روايتين للمنتج نفسه، فلم يستطع التحقق من أيٍّ منهما، ولم يذكر أيًّا منهما. (الأرقام للتوضيح فقط، ولا تخص متجرًا حقيقيًا.)
لذلك تغيّر سؤال صاحب المتجر. لم يعد السؤال «كيف أتصدّر النتائج؟» فقط، بل «هل يعرف المساعد أن منتجي موجود، وهل يثق ببياناتي، وهل سيذكره بالاسم؟». والممارسة التي نشأت حول هذا السؤال تُعرف بـتحسين المحركات التوليدية (generative engine optimization، أو GEO). نتناول فيما يلي كيف تبني المساعدات توصياتها، وأي نصائح GEO تصمد، وما يجب إصلاحه في بيانات المنتجات، وكيف تقيس النتيجة، ثم قائمة تحقق من عشر نقاط.
هذا هو الجزء الثاني من سلسلة من ثلاثة أجزاء بعنوان «البيع لوكلاء الذكاء الاصطناعي». شرح الجزء الأول ما هي التجارة الوكيلية وما الذي كان متاحًا فعلًا حتى أغسطس 2026. ويتناول الجزء الثالث إتمام الشراء والدفع الجاهزَين للوكلاء.
تختلف المساعدات في طريقة بنائها، لكن شكل العملية متقارب. يقرأ المساعد الطلب، ثم يجمع منتجات مرشّحة من عدة أنواع من المصادر، ويستبعد ما لا يستطيع التحقق منه، ثم يكتب إجابة قصيرة مرتّبة.
تنقسم المصادر إلى أربع مجموعات:
الخطوة الحاسمة هي الثالثة. المنتج الذي ينقصه السعر، أو يتعارض مخزونه بين مصدرين، أو لا توجد له سياسة إرجاع معلنة، لا يُرتَّب في مرتبة متأخرة، بل يُستبعد من الإجابة عادةً، لأن المساعد الذي يوصي بما لا يستطيع إثباته يسيء إلى نفسه. وهذا هو خطر «الاختفاء» الذي ذكرناه في الجزء الأول.
الكثير مما يُباع اليوم باسم GEO هو تحسين محركات بحث عادي بعنوان جديد. وتقول Google ذلك صراحة: ففي إرشاداتها حول ميزات الذكاء الاصطناعي في البحث، تؤكد أنه لا توجد متطلبات إضافية للظهور في AI Overviews أو AI Mode، ولا ملفات أو ترميزات خاصة يجب إضافتها، وأن أفضل ممارسات SEO المعتادة ما زالت سارية (Google Search Central).
الذي يتغيّر هو موضع التركيز. يقارن الجدول التالي بين الاثنين.
| السؤال | SEO التقليدي | GEO للمتاجر |
|---|---|---|
| ما الهدف؟ | ترتيب صفحة لكلمة مفتاحية | أن يُذكر اسمك في الإجابة مع رابط |
| من يقرأ صفحتك؟ | زاحف، ثم إنسان | نظام استرجاع يقتبس منها أو يلخّصها |
| ما الذي يكسب؟ | الصلة والروابط وتجربة الصفحة | حقائق يمكن التحقق منها وبيانات متسقة وإثباتات مستقلة |
| أي محتوى يفيد أكثر؟ | صفحات تستهدف عبارة بحث | صفحات تجيب عن أسئلة المقارنة و«الأفضل لمن» بلغة بسيطة |
| كيف تقيس؟ | الترتيب والنقرات | الإحالات من المساعدات والذكر والطلبات حسب المصدر |
| ماذا ترسل؟ | خريطة موقع | خريطة موقع مع خلاصات منتجات حيث تقبلها المنصات |
واصل أساسيات SEO، وأضف طبقة ثانية من العمل على بيانات المنتجات والإثباتات المستقلة.
تعلّمت محركات البحث قراءة صفحات المنتجات منذ سنوات، وتبني المساعدات على الإشارات نفسها. وهناك أربعة عناصر هي الأهم.
رقم GTIN (الرقم المطبوع تحت الباركود)، أو العلامة التجارية مع رقم MPN للمنتجات التي لا تحمل GTIN، يتيح للنظام أن يدرك أن قائمتك وقائمة منافسك تخصان المنتج نفسه. وبلا معرّف تتم المطابقة بالعنوان، والعناوين فوضوية عادةً.
استخدم ترميز schema.org بصيغة JSON-LD. والأنواع المفيدة للمتجر هي Product وOffer (السعر والعملة والتوفر) وAggregateRating وReview، إضافة إلى MerchantReturnPolicy وOfferShippingDetails للسياسات. وتوثّق Google هذه الأنواع ضمن البيانات المنظّمة للمنتجات وقوائم التجار وسياسات الإرجاع. هذا الترميز ليس حيلة لرفع الترتيب، بل نسخة مقروءة آليًا مما هو مكتوب أصلًا في الصفحة.
يجب أن يتطابق السعر في الترميز وفي الصفحة وفي الخلاصة، وأن يطابق ما تحسبه سلة الشراء فعلًا. والتعارض هو أكثر أسباب رفض الخلاصات وفقدان الثقة بالمنتج. وهذه مشكلة في هندسة البيانات أكثر منها مشكلة تسويق: فإذا عُدّل السعر والمخزون في ثلاثة أماكن، فسيختلفان حتمًا.
عبارة «إرجاع مجاني خلال 30 يومًا دون أي رسوم، واسترداد المبلغ بطريقة الدفع الأصلية خلال خمسة أيام عمل» هي معلومة. أما «إرجاع سهل» فليست كذلك. انشر تكلفة التوصيل ومدته حسب المنطقة، وموعد إغلاق الطلبات اليومي، ومهلة الإرجاع، بجمل واضحة، وكرّرها في الترميز.
الخلاصة ملف بقائمة منتجاتك يُرفع إلى منصة وفق جدول زمني. وفي أغسطس 2026 أصبح المشهد أكثر انفتاحًا مما كان قبل عام، لكنه يختلف من مساعد إلى آخر. راجع الشروط الحالية لكل برنامج قبل أن تعتمد على أي شيء هنا، فهي تتغير كثيرًا.
| المنصة | كيف تصل بيانات المنتج | ما عليك فعله |
|---|---|---|
| Google AI Mode وAI Overviews وتسوّق Gemini | Shopping Graph من Google، ويغذّيه Merchant Center وترميز الصفحات | أنشئ حسابًا في Merchant Center، وفعّل القوائم المجانية، وأبقِ الخلاصة محدّثة |
| ChatGPT | يقبل برنامج التجار لدى OpenAI خلاصات المنتجات، بصيغة JSONL الخاصة به أو بصيغة CSV أو TSV المتوافقة مع Google | قدّم طلبًا عبر برنامج التجار وأبقِ التوفر محدّثًا. وقد توفّر المنصات المستضافة البيانات نيابة عنك |
| Perplexity | برنامج تجار يعمل مع خلاصات بصيغة Google | سجّل في البرنامج وأعد استخدام خلاصة Merchant Center نفسها |
| Microsoft Copilot | برنامج Copilot Merchant Program القائم على Microsoft Merchant Center | أرسل خلاصة نظيفة مع سياسات الإرجاع والدعم |
الأولى أن مواصفة المنتجات بصيغة Google صارت اللغة المشتركة: فمعظم المنصات أعلاه تستطيع قبولها، لذا تنجز خلاصة واحدة جيدة الصيانة معظم العمل. والثانية أن مواصفة OpenAI نفسها تشترط تسعة حقول في كل صف: معرّف العنصر والعنوان والوصف والرابط والعلامة التجارية واسم البائع ورابط الصورة والتوفر والسعر مع رمز العملة (وثائق مطوّري OpenAI). وإن كنت لا تستطيع ملء هذه الحقول التسعة بثبات لكامل كتالوجك، فابدأ بإصلاح ذلك قبل أي شيء آخر.
أشرنا في الجزء الأول إلى أن الشراء داخل ChatGPT جرى تقليصه في مارس 2026. ومع ذلك تبقى الخلاصة مهمة، لأنها تدعم الاكتشاف حتى حين تتم عملية الشراء في موقعك.
يسأل الناس المساعدات: «ما الأفضل لمطبخ صغير؟» و«ما بديل العلامة س؟» و«أيها يدوم أطول؟». وموقعك قادر على الإجابة عن هذه الأسئلة أفضل من أي جهة أخرى، لأنك تعرف منتجك.
اختبار بسيط: اقرأ صفحة منتجك كأنك مساعد لا يرى الصور. هل تعرف لمن المنتج، وكم سعره، ومتى يصل، وماذا يحدث إن لم يناسب صاحبه؟
ستجد نصائح بإضافة ملف llms.txt إلى موقعك. وهذه حالته حتى أغسطس 2026.
llms.txt اقتراح وليس معيارًا. اقترحه Jeremy Howard عام 2024 على شكل ملف markdown يوجّه أنظمة الذكاء الاصطناعي إلى أنفع صفحات الموقع، وهو موثّق في llmstxt.org. ولا تشرف عليه أي هيئة معايير. وتقول إرشادات Google إنك لا تحتاج إلى ملفات جديدة مقروءة آليًا أو ملفات نصية خاصة بالذكاء الاصطناعي لتظهر في ميزاتها، وقد صرّح John Mueller من Google علنًا بأن أي نظام ذكاء اصطناعي لا يستخدم llms.txt حاليًا. كما لم يجد تحليل أجرته SE Ranking على نحو 300 ألف نطاق أي صلة قابلة للقياس بين وجود الملف وزيادة استشهاد مساعدي الذكاء الاصطناعي بالموقع.
نشره لا يكلّف شيئًا يُذكر، وقد يكون معقولًا لمواقع التوثيق. أما للمتجر فليس هو المكان الذي يعود عليك فيه الوقت بنتيجة؛ العائد في بيانات المنتجات والخلاصات والإثباتات المستقلة.
ترسل المساعدات زوّارًا، لكنها لا تضع دائمًا وسمًا واضحًا. وللتعامل مع ذلك أربعة أجزاء عملية.
توقّع أرقامًا صغيرة في البداية. فقيمة التتبع أن تعرف أي الصفحات والمنتجات تفضّلها المساعدات، فتكرّر ما ينجح.
إذا غاب المنتج عن الإجابات، فاجتز أربعة فحوص بالترتيب. كل فحص يفتح الباب للذي بعده: فترميز مثالي في صفحة غير مفهرسة لا يغيّر شيئًا.
الفحص الثالث هو الذي يتكرر، لأن الزحف والترميز يُضبطان مرة واحدة، أما السعر والمخزون فيتغيران كل يوم. وهكذا خسرت صاحبة المتجر سترتها في المشهد الافتتاحي: صفّ قديم واحد في الخلاصة.
نفّذها بالترتيب، فكل خطوة تدعم التي بعدها.
وإن نفّذت الخطوات من الأولى إلى الخامسة فقط، فستسبق كثيرًا من المتاجر، لأنها تصلح البيانات التي تقوم عليها بقية الخطوات.
نعود إلى صاحبة المتجر وسترتها بسعر 129 دولارًا. حين جعلت سجل المنتج المصدر الوحيد للصفحة والترميز والخلاصة، اختفى الصف القديم ذو الـ159 دولارًا. وبعد شهر طرحت على المساعد السؤال نفسه، فجاءت سترتها ثالثة بين أربع، بالسعر الصحيح ومع ذكر مهلة الإرجاع. السترة لم تتغير، وإنما تغيّرت البيانات وحدها. (ما زلنا في المشهد التوضيحي نفسه.)
أن يوصي بك المساعد هو نصف المهمة فقط. فحين يرسل المساعد متسوّقًا إليك، أو يحاول إتمام الشراء بنفسه، يجب أن يعمل الدفع وإتمام الطلب للوكيل كما يعملان للإنسان. وهذا موضوع الجزء الثالث: كيف تدفع الوكلاء، وما الضوابط الموجودة، وكيف تبقي الاحتيال والمبالغ المستردة تحت السيطرة.
Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.
About the Author
Anichur Rahaman
Continue Reading
