عندما يقرأ محرك ذكاء اصطناعي صفحة ويب، يبدأ بتفكيك HTML: يستبعد شريط التنقل والقائمة الجانبية ورسائل ملفات تعريف الارتباط وبرامج التتبع، ثم يحتفظ بما يراه المحتوى الأساسي. قد يخطئ في هذه العملية من دون أن تتمكن من معرفة موضع الخطأ. لذلك، بدلاً من صقل البنية الدلالية في HTML والمراهنة على أن النموذج سيفهم التخطيط في كل مرة، أعطه نسخة Markdown منسقة من المحتوى مباشرة. عندما تختفي ضوضاء التخطيط من المحتوى نفسه، لا يعود النموذج مضطراً إلى التخمين، ويصبح استخراج الاقتباسات أكثر استقراراً ودقة.
لماذا يفضّل الذكاء الاصطناعي قراءة Markdown على HTML؟
المسألة الأساسية هي نسبة المحتوى إلى الضوضاء. قد تضم الشفرة المصدرية لصفحة SaaS نموذجية ما بين ستة وسبعة آلاف رمز، بينما لا يمثل المحتوى الفعلي سوى جزء صغير منها. أما الباقي فيتكون من أسماء الفئات والأنماط المضمّنة ومسارات SVG وبرامج التحليل. بعد استيعاب الصفحة، يحتاج النموذج أولاً إلى تصفية كل ذلك للعثور على الجمل التي تصلح للإجابة عن الأسئلة. تختصر نسخة Markdown الفقرة نفسها إلى جزء يسير من حجمها الأصلي: العنوان واضح، والقائمة واضحة، والنقاط المحورية ظاهرة. تحمل البنية معناها الدلالي بذاتها، فلا تترك للنموذج مساحة كبيرة للتخمين.
تزداد أهمية ذلك في محركات الإجابة. فعند إنشاء الإجابات، تستخرج ChatGPT وPerplexity وGoogle AI Overviews فقرات قابلة للاقتباس من الصفحات المرشحة. وكلما كانت الصفحة أنظف وفقراتها أكثر اكتمالاً واستقلالاً في المعنى، زادت فرص اقتباسها كاملة. تعاملنا مع حالة متكررة لدى العملاء: مقال جيد الصياغة، لكنه محاط بطبقات من عناصر div ومكوّنات تُعرض من جهة العميل، فلا يلتقط النموذج سوى نصف الجملة. بعد الانتقال إلى نقطة نهاية Markdown، أصبحت الفقرة نفسها متاحة بالكامل ولم يعد المرجع ينقطع في مواضع غريبة.
نقطة النهاية /md: نسخة قابلة للقراءة آلياً من كل صفحة
الفكرة هي توفير نسخة Markdown مقابلة لكل صفحة عامة، وفق نمط URL واضح يمكن توقعه. هناك طريقتان شائعتان: إضافة .md إلى عنوان URL الأصلي، بحيث يقابل /blog/aeo-basics المسار /blog/aeo-basics.md، أو إضافة /md إلى نهاية المسار. كلاهما مناسب؛ الأهم هو ثبات القاعدة وسهولة استنتاجها. في App Router ضمن Next.js، يمكن تنفيذ ذلك باستخدام Route Handler: أنشئ ملف مسار يقرأ بيانات المحتوى نفسها التي تستخدمها صفحة HTML، ثم أخرج الاستجابة مع Content-Type بقيمة text/markdown.
- مصدر بيانات واحد: يجب أن تقرأ صفحة HTML ونقطة نهاية Markdown المحتوى نفسه، سواء كان MDX أو قاعدة بيانات أو كائن محتوى. لا تحتفظ بنسختين منفصلتين، لأنهما ستفقدان التزامن عاجلاً أم آجلاً.
- أضف link rel=alternate type=text/markdown إلى رأس HTML لتوضح للزاحف مكان النسخة القابلة للقراءة آلياً.
- احتفظ في Markdown بالمحتوى الأساسي فقط: العناوين والفقرات والقوائم والجداول وكتل الشفرة والروابط، واحذف قوائم التنقل والتذييلات والمقالات ذات الصلة واللافتات التسويقية.
- احتفظ بمعلومات المصدر الضرورية: استخدم front matter في بداية الملف أو سطر H1 الأول لعرض العنوان وعنوان URL الأصلي وتاريخ التحديث، حتى يسهل على النموذج تعريف المصدر.
- أعد ترويسة التخزين المؤقت الصحيحة كي تتمكن شبكة CDN من تقديم نقطة النهاية من دون الرجوع إلى الخادم الأصلي مع كل طلب.
استخدم التفاوض على المحتوى للتبديل التلقائي بين الصيغ
إلى جانب عناوين URL الثابتة، يمكن لعنوان URL نفسه إعادة صيغ مختلفة بحسب هوية صاحب الطلب. ويستند القرار إلى عاملين: ترويسة Accept وUser-Agent. إذا حمل الطلب Accept: text/markdown، أو كان User-Agent تابعاً لزاحف ذكاء اصطناعي معروف مثل GPTBot أو ClaudeBot أو PerplexityBot أو Google-Extended، يُعاد توجيه الطلب داخلياً إلى مسار Markdown في طبقة middleware، بينما تظل المتصفحات العادية تتلقى HTML. يرى المستخدم الصفحة الكاملة، ويحصل النموذج على نص نظيف، ويبقى عنوان URL ثابتاً طوال العملية.
النص العادي كخيار احتياطي: عندما يكون Markdown أكثر مما يلزم
بعض الوكلاء والزواحف لا يحللون صياغة Markdown ولا يتعاملون إلا مع النص العادي. وفي حالات أخرى، مثل ملخصات المصادر التي تستخدمها المساعدات الصوتية، لا يلزم سوى المحتوى في أكثر صوره إيجازاً. هنا يصبح خيار النص العادي الاحتياطي مفيداً. تُطبق الآلية نفسها المستخدمة في نقطة نهاية Markdown، لكن المخرج يكون text/plain: تفصل أسطر جديدة بين العنوان والفقرات، ويُرفق عنوان URL بنص الرابط بين قوسين. وتضمن هذه الطبقات الاحتياطية وجود نسخة مقروءة مهما كان مستوى قدرة الطرف الآخر على التحليل.
- llms.txt: ضع /llms.txt في الدليل الجذري للموقع، واستخدم Markdown لسرد الصفحات المهمة مع أوصاف موجزة؛ وكأنك تقدم للنموذج خريطة تنقل.
- llms-full.txt: اجمع المحتوى الأساسي كاملاً في ملف واحد، ليسهل على النموذج قراءته دفعة واحدة من دون الزحف إلى كل صفحة على حدة.
- نقطة نهاية .md لكل صفحة: نسخة قابلة للقراءة آلياً من كل مقال وكل صفحة منتج.
- خيار النص العادي الاحتياطي: مخرج text/plain بالحد الأدنى للأدوات التي لا تحلل Markdown.
كيف تتحقق من قدرة الذكاء الاصطناعي على القراءة فعلياً؟
تحقق من التنفيذ بعد إطلاقه، ولا تفترض أنه سيعمل تلقائياً. أسرع طريقة هي استخدام curl لمحاكاة طلب زاحف: أرسل Accept: text/markdown أو عيّن User-Agent الخاص بزاحف الذكاء الاصطناعي، ثم تأكد من أن Markdown المُعاد نظيف، وأن رمز الحالة هو 200، وأن ترويسة التخزين المؤقت صحيحة. بعد ذلك، راجع سجلات الخادم لتتأكد من أن زواحف مثل GPTBot وClaudeBot تصل بالفعل إلى نقطة نهاية Markdown بدلاً من الاستمرار في جلب HTML المشوش. ويمكن لأدوات مثل isitagentready أن تساعدك أيضاً على فحص قابلية الصفحة للقراءة بواسطة الوكلاء بسرعة.
تعتمد قابلية استشهاد الذكاء الاصطناعي بمحتواك على قدرته على قراءته بوضوح. ومنحه نسخة Markdown يزيل تماماً خطوة «تخمين التخطيط» من العملية.— Tenten GEO
ابدأ بصفحة واحدة بدلاً من إعادة بناء الموقع بأكمله دفعة واحدة
ابدأ بالصفحات الأعلى زيارات وبالصفحات التي تريد أن يستشهد بها الذكاء الاصطناعي أكثر من غيرها. أضف إليها نقاط نهاية .md وخيار النص العادي الاحتياطي، ثم قِس سلوك زواحف الذكاء الاصطناعي لمدة تتراوح بين أسبوعين وأربعة أسابيع قبل أن تقرر تعميم الحل على الموقع بأكمله. بهذه الطريقة تضبط المخاطر وتستخدم سجلات فعلية لإقناع الفريق. وإذا أردت أولاً معرفة مدى قابلية صفحاتك للقراءة بواسطة الذكاء الاصطناعي وأين تكمن الفجوات، يراجع تدقيق GEO من Tenten GEO لمدة 30 يوماً مشكلات القابلية للقراءة آلياً صفحةً بصفحة. ولمناقشة وضعك، انتقل إلى /contact لحجز جلسة تشخيص GEO مدتها 30 دقيقة.
