إثبات ملكية الموقع في Baidu: ملف HTML ووسم Meta وسجل CNAME
وصلتك مهمة تخص Baidu، وأول ما يعترض طريقك شاشة تحقق. لن يقبل Baidu خريطة موقع، ولن يفتح تقارير الفهرسة، ولن يسمح لك بدفع رابط واحد قبل أن يطمئن إلى أن النطاق نطاقك. هناك ثلاث طرق لإثبات ذلك، ولكل منها سلوكها، وأسباب الفشل ليست تلك التي اعتدت عليها في Google Search Console.
فيما يلي تفاصيل تنفيذ كل طريقة، والأسباب المعتادة لفشل التحقق، وكيفية فحص كل واحدة منها من سطر الأوامر.
أين يقع التحقق
منتج Baidu الموجّه لمشرفي المواقع هو Baidu Search Resource Platform (百度搜索资源平台) على ziyuan.baidu.com، ولا يزال يُعرف على نطاق واسع باسم Baidu Zhanzhang. تضيف الموقع، وتختار طريقة تحقق، ثم يجلب Baidu شيئًا من نطاقك ليتأكد من أنك تتحكم به. عندئذ فقط يُفتح لك تقديم الروابط ورفع خريطة الموقع وتشخيص الزحف.
أمران في طريقة تعريف الموقع يوقعان الناس في الخطأ قبل اختيار الطريقة أصلًا:
- البروتوكول والمضيف جزء من هوية الموقع.
https://example.comوhttps://www.example.comموقعان مختلفان في نظر Baidu، وكذلك نسختاهما علىhttp://. أضف الأصل نفسه الذي تستخدمه روابطك الأساسية. وإذا تحققت من الأصل الخطأ، فكل ما تقدمه بعد ذلك يعود إلى ملكية لا تمر بها أي من زياراتك. - الجلب يأتي من البر الصيني الرئيسي. ما يثبت الملكية يجب أن يكون متاحًا من هناك، عبر الإنترنت العام، ودون صفحة تحقق أمامه. هذه الحقيقة وحدها تفسر معظم حالات الفشل المذكورة في آخر المقال.
وقبل هذا كله يأتي الحساب. لا تصل إلى شاشة التحقق أصلًا دون حساب Baidu، والتسجيل مرتبط بتأكيد عبر رسالة قصيرة إلى رقم هاتف محمول من البر الصيني الرئيسي. وهذا جدار حقيقي أمام أي شركة في أوروبا أو المملكة المتحدة، ومن الأفضل معرفته قبل أن تنفق بعد ظهيرة كاملة على إعدادات DNS. وتفصيل ذلك في نهاية المقال.
الطريقة الأولى: ملف التحقق بصيغة HTML
الطريقة الأكثر شيوعًا، وهي المفضلة متى كان بإمكانك نشر ملف ثابت.
ينشئ Baidu ملفًا خاصًا بموقعك ويتيحه للتنزيل. ويبدو الاسم هكذا:
baidu_verify_codeva-XXXXXXXXXX.html
المواقع الأقدم مُنحت أسماء بالصيغة baidu_verify_XXXXXXXXXX.html، وبعض اللوحات تعرض البادئة code- بدل codeva-. لا تحاول تركيب الاسم أو الرمز اعتمادًا على تدوينة قرأتها: نزّل الملف الذي يعطيك إياه Baidu، أو انسخ النص من اللوحة حرفًا بحرف. ومحتوى الملف قصير، وهو غالبًا الرمز وحده.
ويجب تقديمه من جذر الأصل الذي سجّلته:
https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
لا من مجلد فرعي، ولا خلف بادئة لغة، ولا على مضيف آخر.
أين يوضع الملف بحسب المنصة
| المنصة | الموضع |
| --- | --- |
| Vite وCreate React App وSvelteKit (static) وNuxt | public/ أو static/ في جذر المشروع |
| Next.js (بكلا الموجّهين) | public/ |
| Hugo وAstro | static/ وpublic/ على الترتيب |
| Laravel | public/ |
| Django | مجلد static/ يجمعه collectstatic، أو يقدمه nginx مباشرة |
| ASP.NET Core | wwwroot/ |
| WordPress | جذر الويب بجوار wp-config.php، عبر SFTP |
| nginx أو Apache مباشرة | جذر المستندات |
افحصه كما سيفحصه Baidu
curl -sSI https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
curl -sS https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
المطلوب هو HTTP/2 200، وcontent-type من نوع text/html، وغياب ترويسة location، ومتن يطابق الرمز تمامًا. وثلاث نتائج تعني أنك لم تنتهِ بعد:
- استجابة 301 أو 302. شيء ما يعيد تشكيل المسار، وغالبًا ما يكون قاعدة الشرطة المائلة الأخيرة أو تحويلًا لغويًا يرسل كل مسار غير معروف إلى
/en/.... أضف استثناءً قبل القاعدة الشاملة. - استجابة 200 تعيد هيكل التطبيق. هذا أشيع سبب لنجاح كاذب. تطبيق الصفحة الواحدة ذو المسار الشامل يجيب على كل مسار بالملف
index.htmlوبالحالة 200، فيبدو الملف موجودًا بينما المتن في الحقيقة شيفرة React الخاصة بك. يقرأ Baidu المتن، فلا يجد الرمز، فيرفض. قدّم الملف الثابت قبل المسار الاحتياطي لتطبيق الصفحة الواحدة. - استجابة 404 تستمر بعد النشر. غالبًا شبكة توصيل محتوى خزّنت الرد السلبي. امسح ذلك المسار تحديدًا من الذاكرة المؤقتة، ثم أعد الفحص بـ
curl -H 'Cache-Control: no-cache'.
وأبقِ الملف في المستودع بعد ذلك. فـ Baidu يعيد التحقق من الملكية دوريًا، والموقع الذي يفقد ملف التحقق يسقط من اللوحة بصمت.
الطريقة الثانية: وسم Meta في HTML
استخدمها حين يمكنك تعديل القوالب دون وضع ملفات في جذر الويب، وهي الحالة المعتادة على نظام إدارة محتوى مُدار أو استضافة منصة.
يعطيك Baidu وسمًا بهذا الشكل، ليوضع في <head> الصفحة الرئيسية:
<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />
قيمة الخاصية name هي دائمًا baidu-site-verification، بهذا الرسم تحديدًا وبشرطاته. أما قيمة content فهي الرمز الظاهر في اللوحة.
وثلاث قواعد تحدد نجاحها:
- يجب أن يكون داخل
<head>. فالمحلل الذي يجده في<body>يعتبر الرأس مغلقًا سلفًا، وكل ما يُحقن بعد أول عنصر خارج الرأس يأتي متأخرًا. - يجب أن يكون في HTML الذي يرسله الخادم. افتح
view-source:، أو الأفضل:curl -sS https://example.com | grep baidu-site-verification. فإذا ظهر الوسم في مفتش عناصر DevTools وحده، فقد أضافته JavaScript بعد الترطيب، وهو لا يُحتسب. وهذا ما يعطل الطريقة في تطبيقات React وVue المُقدَّمة من جانب العميل، ولهذا يكون الملف أسهل في تطبيقات الصفحة الواحدة. - يجب أن ينجو من إطار العمل. فمديرو الرأس يحذفون المكرر وينقّون المحتوى. Next.js يريده في تصدير metadata لا كوسم
<meta>شارد داخل مكوّن. وReact Helmet يسقط الوسوم المُقدَّمة خارج مزوّده. وبعض إضافات الحماية في أنظمة إدارة المحتوى تحذف وسوم meta ذات الأسماء غير المعروفة. ولا يصلح مدير الوسوم لوضعه، لأنه يعمل من جانب العميل.
مواضع الوضع بحسب إطار العمل:
// Next.js App Router, app/layout.js
export const metadata = {
other: { 'baidu-site-verification': 'codeva-XXXXXXXXXX' },
}
// WordPress, functions.php of a child theme
add_action('wp_head', function () {
echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);
وعلى موقع يُقدَّم من الخادم، ضعه في القالب الأساسي بجوار وسمي charset وviewport وانسَ أمره. في Hugo هذا هو layouts/_default/baseof.html؛ وفي Django القالب الأساسي الذي ترث منه كل الصفحات.
الطريقة الثالثة: سجل CNAME
طريقة DNS هي الخيار حين يتعذر عليك النشر أصلًا، أو حين يكون الموقع خلف جهاز لا تتحكم به، أو حين تريد للفحص أن ينجو من كل عملية نشر لاحقة. وهي فوق ذلك تثبت التحكم بالنطاق كله لا بمستند واحد.
يعرض لك Baidu اسم مضيف عشوائيًا تنشئه تحت نطاقك، ويشير إلى Baidu:
abcdef123456.example.com. 3600 IN CNAME ziyuan.baidu.com.
وفي معظم لوحات DNS تُدخل الجزء الأيسر وحده، لأن النطاق مُفترض ضمنًا:
| الحقل | القيمة |
| --- | --- |
| النوع | CNAME |
| الاسم / المضيف | abcdef123456 |
| القيمة / الهدف | ziyuan.baidu.com |
| TTL | 3600، أو أدنى قيمة تسمح بها اللوحة أثناء الاختبار |
وأربعة أخطاء تتكرر هنا مرة بعد مرة:
- إضافة النطاق مرتين. كتابة
abcdef123456.example.comفي لوحة تضيف النطاق تلقائيًا تنتجabcdef123456.example.com.example.com. وإذا عرضت لوحتك الاسم الكامل بعد الحفظ، فاقرأه من جديد. - النقطة الأخيرة في الهدف. في ملف منطقة خام، يُفسَّر
ziyuan.baidu.comمن دون النقطة الأخيرة نسبةً إلى المنطقة فيصيرziyuan.baidu.com.example.com. واللوحات تتولى هذا عنك؛ أماnamedوملفات Terraform فلا. - وسيط أمام السجل. في Cloudflare، السجل الموجَّه عبر الوكيل (السحابة البرتقالية) لا يُحل من الخارج بوصفه CNAME بعد ذلك: تصبح الإجابة الرسمية سجلات A التابعة لـ Cloudflare. اضبط سجل التحقق على DNS only.
- الانتظار أقل من مدة TTL. إذا كان أحد محللات الأسماء يحتفظ بإجابة سلبية مخزنة لذلك الاسم، فالمدة القديمة هي السارية. افحص ما يراه العالم فعلًا، لا ما تقوله لوحتك.
dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.
dig +short @8.8.8.8 abcdef123456.example.com CNAME
واترك السجل في مكانه. فحذفه بعد نجاح الفحص يفتح الباب لفشل إعادة تحقق لاحقة.
لماذا يفشل التحقق رغم أن الإعداد يبدو صحيحًا
جلبت الملف بـ curl فأعاد 200، ومع ذلك يرفض Baidu. راجع هذه القائمة:
- تحدٍّ للروبوتات أو قاعدة WAF. Cloudflare Bot Fight Mode وقواعد AWS WAF المُدارة ومعظم إعدادات «تحت الهجوم» تعيد صفحة اعتراضية تعتمد على JavaScript بالحالة 403 أو 503 لأي عميل لا يشغّل السكربتات. وجالب Baidu لا يشغّلها. اسمح بمسار التحقق، أو بالزاحف نفسه.
- الحجب الجغرافي. كثير من المواقع الأوروبية تحجب حركة البر الصيني الرئيسي أو تحدّ منها للحد من كشط المحتوى. وطلب التحقق يأتي من ذلك النطاق بالذات. تأكد أن لا شيء على الحافة يسقطه.
- تصفية وكيل المستخدم. يعرّف الزاحف نفسه باسم
Baiduspider. وبعض أنظمة الحماية تعامل أسماء الزواحف غير المألوفة كأنها أدوات كشط. وإن أردت التأكد من أن الطلب أصلي قبل السماح به: يُحيل عكس DNS لعنوان المصدر إلى*.baidu.comأو*.baidu.jp، ويجب أن يطابقه البحث الأمامي. robots.txtيمنعه. وجودDisallow: /تحت وكيل مستخدم شامل، أو منع صريح بصيغةUser-agent: Baiduspiderتركه شخص آخر، يوقف الجلب قبل أن يبدأ.- مشكلة TLS تخفيها المتصفحات. الشهادة الوسيطة الناقصة تصلحها متصفحات سطح المكتب بصمت، ولا تصلحها أدوات الجلب البسيطة. مرّر نطاقك على فاحص TLS خارجي بدل الاطمئنان إلى القفل الأخضر.
- التحقق من الأصل الخطأ. الملف موجود على
www.example.comبينما الملكية في Baidu مسجلة باسمexample.com. ولن تدلك رسالة الخطأ على ذلك إطلاقًا. - بطء أول بايت. الخوادم الأوروبية التي لا حضور لها في الصين تجيب ببطء عن طلب قادم من بكين، وإذا أضيف إلى ذلك بدء بارد لدالة بلا خادم، فقد يتجاوز الأمر مهلة الجلب. وإعادة المحاولة في ساعة أخرى تفيد فعلًا.
أي طريقة تختار
انشر ملفًا ثابتًا إن كان لديك خط بناء: فهو الأقل عرضة للعبث والأسهل في الفحص. وخذ وسم meta إن كنت تعمل داخل نظام إدارة محتوى وصفحاتك تُقدَّم من الخادم. وخذ CNAME إن تعذر عليك لمس الموقع، أو إن أردت إثبات الملكية على مستوى النطاق مرة واحدة دون العودة إليها.
وأيًّا كان اختيارك، أبقِه في مكانه دائمًا واكتبه في ملاحظات بنيتك التحتية، بجوار بقية سجلات DNS. فالشخص الذي سيحذف ملفًا غامضًا بعد ثمانية عشر شهرًا هو أنت.
ما لا تحله هذه الطرق
كل واحدة من هذه الطرق الثلاث تفترض أنك مسجَّل الدخول إلى حساب Baidu. والتسجيل يُؤكَّد برسالة قصيرة إلى رقم هاتف محمول من البر الصيني الرئيسي، ويطلب Baidu في كثير من الحالات تحققًا من الهوية الحقيقية (实名认证) ببطاقة هوية وطنية صينية أو رخصة عمل صينية. وشركة في فرانكفورت أو مانشستر، مهما كانت منطقة DNS لديها مضبوطة بإتقان، لا تصل إلى شاشة التحقق.
وهنا يأتي دور خدمة التسجيل في بايدو. تدلّنا على النطاق، وتُنجز فحص ملكية نطاق واحدًا من جهتك، ونتولى نحن التسجيل ونوافيك بما فهرسه Baidu فعليًا، بسعر ثابت لكل نطاق. لا تحتاج إلى رقم هاتف صيني، ولا إلى كيان صيني، ولا إلى حساب خاص بك في بايدو.
وإن أردت الصورة الأوسع أولًا، فإن الدليل الكامل للتسجيل في بايدو يغطي خرائط المواقع وواجهة الدفع البرمجية وما يكافئه ترتيب Baidu فعلًا. وإن كنت تفضّل الحديث المباشر، احجز مكالمة.
خدمة
يمكننا تولي هذا كله نيابة عنك
إثبات ملكية النطاق، وإرسال خريطة الموقع وعناوين URL، وتقرير عن الفهرسة بعد أسبوعين. نطاق واحد بسعر ثابت، دون رقم هاتف صيني أو كيان صيني أو حساب خاص بك في بايدو.
اطّلع على خدمة التسجيل في بايدو