قد لا يعود الشخص الذي يقرر شراء منتج SaaS الخاص بك إنسانًا. فعندما يقول مستخدم لـChatGPT: "ساعدني في العثور على برنامج لإدارة المشاريع يتكامل مع Slack، ويدعم SSO، وتقل تكلفته الشهرية عن 5,000"، سيتولى الوكيل قراءة عشرة مواقع، واستخراج الحقائق الأساسية، ثم تقديم ثلاثة خيارات. عندها لن تُقرأ صفحة منتجك كمادة تسويقية، بل كورقة مواصفات. وإذا تعذّر استخراج السعر أو قائمة التكاملات أو الفروق بين الباقات، فستختفي ببساطة من القائمة المختصرة قبل أن تحصل حتى على فرصة للرفض.
حدث هذا التحول بوتيرة أسرع مما توقّعته معظم فرق B2B. فالتجارة الوكيلة لا تقتصر على أن "يساعدك الذكاء الاصطناعي في إتمام الدفع"، بل تعني أن الوكلاء يتولون البحث والمقارنة والفرز قبل الشراء، فيما يقتصر دور الإنسان على القرار النهائي. بعبارة أخرى، ظهر حارس بوابة جديد أمام صنّاع القرار الذين اعتدت محاولة إقناعهم: برنامج لا يقرأ قصة العلامة التجارية، بل يتعامل مع حقائق منظّمة. وإذا لم يستطع قراءتك، فلن يراك صانع القرار.
الوكيل ليس المستخدم الذي اعتدت التعامل معه
تخيّل الوكيل زائرًا نافد الصبر: لا يمرر الشاشة، ولا ينتظر المؤثرات الحركية. لن ينتظر ظهور قسم الواجهة الرئيسي تدريجيًا، ولن تبهره شهادات مجتمع المستخدمين، ولن يتنقل عبر قائمة منسدلة بثلاثة مستويات ليعثر على السعر. ما يفعله آلي ومباشر: يزحف إلى الصفحة، ويحلل بنيتها، ويستخرج الحقول المطلوبة، ويقارنها بالخيارات الأخرى، ثم يقرر إن كنت تستحق الظهور في القائمة المختصرة التي سيطّلع عليها البشر.
هنا تكمن فجوة قاسية. قد تبدو صفحتك رائعة للبشر، بصورها الكبيرة ومساحاتها البيضاء وتفاعلاتها المتقنة؛ لكن الوكيل قد لا يرى سوى مجموعة من عناصر <div> تفتقر إلى دلالة سليمة، وسعر مخفي داخل صورة، ومحتوى أساسي يعتمد على التحميل الديناميكي عبر JavaScript، ومواصفات مهمة مدفونة في ملف PDF يجب تنزيله. ما يراه الإنسان قد تعجز الآلة عن التقاطه. وفي عالم التجارة الوكيلة، ما لا تستطيع الآلة التقاطه لا وجود له.
ما الذي يبحث عنه الوكلاء فعليًا في صفحتك؟
عند إجراء عمليات تدقيق GEO للعملاء، نستخدم اختبارًا مباشرًا للغاية: نقدّم HTML الأصلي لصفحة المنتج إلى النموذج، ثم نسأله: "كم تبلغ تكلفة هذا المنتج؟ وما التكاملات التي يدعمها؟ ولمن يناسب؟" إذا عجز عن الإجابة أو قدّم إجابة خاطئة، فمن المرجح أن يعجز الوكيل أيضًا. وعمليًا، تتكرر الحقائق التي يبحث عنها الوكلاء ضمن الفئات التالية:
- السعر والفوترة: أرقام وعملات ودورات فوترة واضحة، لا مجرد عبارة "تواصل معنا للحصول على عرض سعر".
- الإمكانات والتكاملات: ما الذي يستطيع البرنامج فعله، وما الأنظمة التي يتصل بها؟ والأفضل عرضها في قائمة واضحة قابلة للاستخراج.
- الفئات المناسبة والقيود: حجم الفرق التي يناسبها المنتج، والقطاعات المستهدفة، وأي حدود قصوى أو متطلبات مسبقة للاستخدام.
- الفروق بين الباقات: ما الذي يتغير من باقة إلى أخرى؟ استخدم حقولًا قابلة للمقارنة بدلًا من الصفات التسويقية.
- إشارات الثقة: الشروط، والامتثال الأمني، وسياسة الاسترداد؛ وهي عناصر يراجعها الوكلاء مبكرًا عند خدمة المشترين الأكثر حذرًا.

البيانات المنظّمة: من إضافة تجميلية إلى واجهة تخاطب
لا يزال كثيرون ينظرون إلى ترميز Schema.org باعتباره إضافة اختيارية من عصر SEO، قد تمنح النتيجة تقييمًا بالنجوم. لكن دوره يتغير في التجارة الوكيلة: فهو يصبح واجهة التخاطب الرسمية بينك وبين الوكيل. فعبر أنواع مثل Product وOffer وOrganization وFAQPage، تعرض الأسعار وحالة التوفر والأسئلة الشائعة بصيغة تفهمها الآلة فورًا، بدل أن تترك الوكيل يخمّن أي جزء من التصميم يعرض السعر وأي قسم يشرح الباقة.
HTML الدلالي ومحتوى يسهل استخراجه
يتولى الترميز المنظّم الحقول الصريحة، أما بقية المحتوى فتعتمد على HTML الدلالي. عند استخراج النص، يستعين الوكيل ببنية العناوين والقوائم والجداول لتمييز الجمل المهمة والخيارات المتوازية. فالصفحة التي ترتب محتواها عبر <h2> و<h3>، وتقارن الباقات في جدول حقيقي، وتعرض الإمكانات ضمن قائمة، تمنح النموذج بنية نظيفة وواضحة. أما الصفحة التي تحشر كل شيء داخل عناصر <div> ثم ترتبه بصريًا عبر CSS، فلا تقدم للآلة سوى كلمات بلا تسلسل هرمي.
يناسب منطق Markdown هذا السياق جيدًا. إذا أمكنك وصف الصفحة بوضوح كما لو كانت "Markdown في ذهنك"، بعناوين وقوائم وأعمدة متراصة، فهي على الأرجح ملائمة للوكلاء. أما الصفحة التي لا تُفهم إلا بصريًا، فعادةً ما يصعب على الوكلاء فهمها. لهذا نوصي العملاء كثيرًا باستخدام isitagentready لإجراء فحص ذاتي: تأكد أولًا من أن الآلة تستطيع قراءة المحتوى، ثم ناقش جودة ما تقرؤه.
التسعير وقابلية إتمام المعاملة: النقطة الأكثر عرضة لتعطّل الوكلاء
بعد معالجة المحتوى والبنية، تستطيع معظم الفرق تحقيق تحسن بإضافة البيانات المنظّمة. لكن العقبة الأصعب تبقى قابلية إتمام المعاملة. فالتجربة المثالية اليوم تتجاوز عرض المعلومات، لتتيح للمستخدم بدء تجربة أو إضافة عملية شراء أو إجراء حجز. وهذا يتطلب مدخلًا يمكن للبرنامج تشغيله، وإجراءات واضحة، ونموذجًا مستقرًا، وخطوة تالية لا تعتمد على تقدير بشري. فإذا كانت الخطوة التالية تفرض تعبئة نموذج من عشرة أعمدة، وانتظار اتصال من فريق المبيعات، وتبادل ثلاث رسائل للحصول على عرض سعر، فسيتوقف الوكيل عند هذه النقطة ويعيد المستخدم إلى المسار اليدوي؛ بينما قد يكون المستخدم قد انتقل بالفعل إلى منتج منافس يتيح إكمال العملية حتى نهايتها.
راجعنا عددًا كبيرًا جدًا من صفحات المنتجات التي يظن أصحابها أن معلوماتها مكتملة، لكن النموذج يعجز عن استخراج السعر منها. وغالبًا لا يتجاوز الفارق طريقة كتابة الحقائق: هل عُرضت بصيغة قابلة للقراءة آليًا أم لا؟— Tenten GEO
قائمة تحقق قابلة للقراءة آليًا يمكنك البدء بها اليوم
لتحويل ما سبق إلى خطوات قابلة للتنفيذ، نوصي عملاءنا عادةً بالبدء بهذه البنود الخمسة، مرتبة بحسب العائد المتوقع:
- اعرض الأسعار والفروق بين الباقات كنصوص وجداول حقيقية قابلة للزحف داخل الصفحة، ولا تخفها في صور أو ملفات PDF.
- أضف إلى صفحة المنتج الرئيسية بيانات منظّمة من أنواع Product وOffer وFAQPage، وتأكد من تطابقها التام مع محتوى الصفحة.
- أعد تنظيم المحتوى باستخدام HTML الدلالي: تسلسل واضح للعناوين، وقوائم للإمكانات، وجداول لمقارنة الباقات.
- حوّل أكثر أسئلة ما قبل الشراء شيوعًا إلى فقرات مستقلة قابلة للاستخراج، بحيث تضم كل فقرة سؤالًا واحدًا وإجابة واحدة.
- تحقق مما إذا كان البرنامج يستطيع إكمال "الخطوة التالية"، سواء كانت تجربة أو حجزًا أو طلب عرض سعر؛ وعلى الأقل وفّر مسارًا لا يتطلب انتظار تدخل شخص آخر.
لا تتطلب هذه القائمة إعادة بناء الموقع. فمعظم البنود لا تتجاوز إضافة بنية أو حقائق إلى الصفحات الحالية وإزالة نقاط الاحتكاك منها. الأصعب هو تحديد موضع النقص: هل تعجز الآلة عن قراءة الصفحة أصلًا، أم تقرؤها لكنها لا تجد معلومات كافية لإدراج المنتج في القائمة المختصرة؟ إذا أردت معرفة كيف يرى الوكلاء صفحة منتجك وأين يتعطلون، يمكنك حجز جلسة تشخيص GEO مدتها 30 دقيقة، وسنراجعها معك باستخدام اختبارات استخراج فعلية.



