ترحيل llms.txt v2: قائمة فحص عملية

لا يحوّل الإصدار 2 ملف llms.txt إلى عامل لترتيب Google. بل يوسع الاقتراح من ملف جذري واحد إلى نظام اكتشاف واعٍ بالمسارات للوكلاء. نفّذ الترحيل فقط إذا كانت الوكلاء المتوافقة جزءًا من حالة استخدامك، واحتفظ بالملف الحالي أثناء اختبار المكونات الجديدة.

أهم النقاط

• يبقى H1 الجزء المطلوب الوحيد من الملف.
• يمكن لملف مسار أكثر تحديدًا أن يصف الصفحات الواقعة تحت ذلك المسار فقط.
• بدائل Markdown وdescribedby وسائل لاكتشاف الموارد، وليست إشارات للبحث.

ما الذي تغير في llms.txt v2؟

يسمح الاقتراح الآن بـllms.txt في جذر المنشأ أو في أي مسار. ويمكن لـ/docs/llms.txt مثلًا وصف /docs/، بينما يصف الملف الجذري الموقع الأوسع. وعندما يمكن انطباق عدة ملفات، ينبغي للوكيل استخدام الملف الأكثر تحديدًا.

يقترح v2 أيضًا نسخًا نظيفة من الصفحات بلغة Markdown. ويمكن للصفحة إتاحة هذه النسخة عبر rel="alternate" type="text/markdown" وتحديد الخريطة المنطبقة عليها باستخدام rel="describedby". وقد تظهر هذه العلاقات في HTML أو في ترويسة HTTP من نوع Link.

تظل صيغة الملف نفسها صغيرة عمدًا. ويُشترط H1. أما الملخص والمقدمة التفسيرية وأقسام H2 وأوصاف الروابط فاختيارية. ويظل Optional عنوانًا تحريريًا مفيدًا، لكن v2 لا يمنحه دلالات معالجة خاصة. راجع مرجع الصيغة قبل تشديد أداة التحقق بما يتجاوز القواعد المنشورة.

جردٌ قبل تغيير أي شيء

ابدأ بتسجيل كل ملف حالي وإعادة توجيه ونوع محتوى ومستهلك. وينبغي لملف جذري يعيد HTTP 200 اليوم أن يستمر في إعادة 200 أثناء الترحيل. وسيؤدي تغيير عنوان URL لمجرد اعتماد v2 إلى كسر العملاء الذين يعرفون العرف الجذري بالفعل.

قسّم الموقع إلى نطاقات متميزة فعلًا. قد تبرر شجرة وثائق استخدام /docs/llms.txt، أما موقع تسويقي من خمس صفحات فعلى الأرجح لا يبرره. ينبغي أن تقلل ملفات المسارات السياق غير ذي الصلة، لا أن تكرر الملف الجذري حرفيًا.

تحقق مما إذا كان Markdown النظيف موجودًا أصلًا. لا تعلن عن بديل ليس سوى تحويل رقيق أو صفحة خطأ أو محتوى قديم. تظل صفحة HTML الوثيقة الأساسية في البحث، بينما يمثل مورد Markdown تمثيلًا قابلًا للقراءة آليًا للعملاء المتوافقين.

تسلسل الترحيل

1. تحقّق من الملف الجذري الحالي باستخدام أداة التحقق من llms.txt.
2. أبقِ عنوان URL المستقر وصحح أخطاء الصياغة الحقيقية فقط.
3. حدّد نطاق كل مسار وأنشئ ملفًا أصغر فقط عندما يكون حد المحتوى حقيقيًا.
4. أنشئ Markdown من المصدر نفسه المستخدم في HTML لمنع الانحراف التحريري.
5. أضف علاقتي alternate وdescribedby إلى قالب HTML.
6. اختبر حالة HTTP ونوع المحتوى وإعادات التوجيه وعناوين URL المرتبطة في CI.
7. أطلق ضمن نطاق صغير، وافحص سجلات الخادم، ثم وسّع النطاق.

يغطي دليل أفضل الممارسات التنظيم والأمن بما يتجاوز الصياغة. وبالنسبة إلى أنماط الإنتاج، قارن بـأمثلة متحقق منها دون افتراض أن النشر يثبت الاستهلاك.

التحقق والقيود

قام معيارنا «12 أغسطس 2026» بفحص 294 صفحة مرتبطة بـ 113 استجابة جذرية تبدأ بعلامة H1. أعلنت واحدة وثلاثون صفحة من أصل 286 صفحة يمكن الوصول إليها عن بديل Markdown، وكشفت أربع صفحات عن ملف rel="describedby". وهذا يمثل خط أساس للتنفيذ القابل للملاحظة، وليس دليلاً على أن الوكلاء يفضلون أيًا من العلاقتين.

تذكر Google أن «البحث» لا يستخدم ملف llms.txt أو أي ملفات نصية خاصة أخرى بالذكاء الاصطناعي. لذا، فإن الترحيل الناجح يعني موارد مستقرة، ونطاقًا صحيحًا، واكتشافًا نظيفًا، وطلبات قابلة للقياس من العملاء ذوي الصلة. ولا يعني ذلك تحسين الترتيب.

هل يجب أن أستبدل ملفي الجذري الحالي؟

لا. تحتفظ v2 بموقع الجذر وتضيف خيارات على مستوى المسار. احتفظ بعناوين URL المستقرة ما لم يتطلب عيب موثق إجراء تغيير.

هل يُشترط أن تحتوي كل صفحة HTML على Markdown؟

لا. يُقترح استخدام بدائل لـ Markdown للصفحات التي يساعد فيها النص النظيف الوكلاء. قد لا يكون للصفحات المرئية أو التفاعلية ما يعادلها بشكل مفيد.

هل ينبغي أن تفهرس Google عنوان URL الخاص بـMarkdown؟

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