إثبات ملكية الموقع في Baidu: ملف HTML ووسم Meta، وما الذي حدث لسجل CNAME

وصلتك مهمة تخص Baidu، وأول ما يعترض طريقك شاشة تحقق. لن يقبل Baidu خريطة موقع، ولن يفتح تقارير الفهرسة، ولن يسمح لك بدفع رابط واحد قبل أن يطمئن إلى أن النطاق نطاقك. واليوم تثبت ذلك طريقتان. لكل منهما سلوكها، وأسباب الفشل ليست تلك التي اعتدت عليها في Google Search Console. أما الطريقة الثالثة التي ما زالت معظم الأدلة تشرحها، أي سجل CNAME، فهي معلّقة منذ يناير 2023.

فيما يلي تفاصيل تنفيذ الطريقتين العاملتين، وما يعنيه تعليق CNAME إن كنت تستخدمه من قبل، والأسباب المعتادة لفشل التحقق، مع كيفية فحص كل منها من سطر الأوامر.

أين يقع التحقق

منتج Baidu الموجّه لمشرفي المواقع هو Baidu Search Resource Platform (百度搜索资源平台) على ziyuan.baidu.com، ولا يزال يُعرف على نطاق واسع باسم Baidu Zhanzhang. تضيف الموقع، وتختار طريقة تحقق، ثم يجلب Baidu شيئًا من نطاقك ليتأكد من أنك تتحكم به. عندئذ فقط يُفتح لك تقديم الروابط ورفع خريطة الموقع وتشخيص الزحف.

أمران في طريقة تعريف الموقع يوقعان الناس في الخطأ قبل اختيار الطريقة أصلًا:

• البروتوكول والمضيف جزء من هوية الموقع. https://example.com وhttps://www.example.com موقعان مختلفان في نظر Baidu، وكذلك نسختاهما على http://. أضف الأصل نفسه الذي تستخدمه روابطك الأساسية. وإذا تحققت من الأصل الخطأ، فكل ما تقدمه بعد ذلك يعود إلى ملكية لا تمر بها أي من زياراتك.
• الجلب يأتي من البر الصيني الرئيسي. ما يثبت الملكية يجب أن يكون متاحًا من هناك، عبر الإنترنت العام، ودون صفحة تحقق أمامه. هذه الحقيقة وحدها تفسر معظم حالات الفشل المذكورة في آخر المقال.

وقبل هذا كله يأتي الحساب. لا تصل إلى شاشة التحقق أصلًا دون حساب Baidu، والتسجيل مرتبط بتأكيد عبر رسالة قصيرة إلى رقم هاتف محمول من البر الصيني الرئيسي. وهذا جدار حقيقي أمام أي شركة في أوروبا أو المملكة المتحدة، ومن الأفضل معرفته قبل أن تنفق بعد ظهيرة كاملة على القوالب وعمليات النشر. وتفصيل ذلك في نهاية المقال.

الطريقة الأولى: ملف التحقق بصيغة HTML

الطريقة الأكثر شيوعًا، وهي المفضلة متى كان بإمكانك نشر ملف ثابت.

ينشئ Baidu ملفًا خاصًا بموقعك ويتيحه للتنزيل. ويبدو الاسم هكذا:

baidu_verify_codeva-XXXXXXXXXX.html

المواقع الأقدم مُنحت أسماء بالصيغة baidu_verify_XXXXXXXXXX.html، وبعض اللوحات تعرض البادئة code- بدل codeva-. لا تحاول تركيب الاسم أو الرمز اعتمادًا على تدوينة قرأتها: نزّل الملف الذي يعطيك إياه Baidu، أو انسخ النص من اللوحة حرفًا بحرف. ومحتوى الملف قصير، وهو غالبًا الرمز وحده.

ويجب تقديمه من جذر الأصل الذي سجّلته:

https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

لا من مجلد فرعي، ولا خلف بادئة لغة، ولا على مضيف آخر.

أين يوضع الملف بحسب المنصة

افحصه كما سيفحصه 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 فهي الرمز الظاهر في اللوحة.

وثلاث قواعد تحدد نجاحها:

1. يجب أن يكون داخل <head>. فالمحلل الذي يجده في <body> يعتبر الرأس مغلقًا سلفًا، وكل ما يُحقن بعد أول عنصر خارج الرأس يأتي متأخرًا.
2. يجب أن يكون في HTML الذي يرسله الخادم. افتح view-source:، أو الأفضل: curl -sS https://example.com | grep baidu-site-verification. فإذا ظهر الوسم في مفتش عناصر DevTools وحده، فقد أضافته JavaScript بعد الترطيب، وهو لا يُحتسب. وهذا ما يعطل الطريقة في تطبيقات React وVue المُقدَّمة من جانب العميل، ولهذا يكون الملف أسهل في تطبيقات الصفحة الواحدة.
3. يجب أن ينجو من إطار العمل. فمديرو الرأس يحذفون المكرر وينقّون المحتوى. 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: معلّق منذ يناير 2023

تشرح الأدلة الأقدم، ومنها النسخة الأولى من هذا الدليل، طريقة ثالثة: سجل CNAME في DNS. وفي 13 يناير 2023 علّق Baidu التحقق عبر CNAME (إعلان Baidu) ووجّه أصحاب المواقع إلى التحقق بالملف وبوسم HTML بدلًا منه. وحتى 10 أكتوبر 2026 لم ينشر Baidu أي إعلان بإعادته.

إذا كان الموقع قد تحقق عبر CNAME قبل ذلك، فالسجل يبدو هكذا:

abcdef123456.example.com.  3600  IN  CNAME  ziyuan.baidu.com.

وفي لوحة DNS يظهر هكذا:

ما يعنيه التعليق بالنسبة إليك:

• لا يمكن لموقع جديد استخدامه. لم يعد Baidu يقبل CNAME لموقع لم يجرِ التحقق منه بعد. استخدم الملف أو وسم meta المشروحين أعلاه.
• التحقق القائم عبر CNAME ما زال ساريًا. يذكر إعلان Baidu أن المواقع التي تحققت من قبل لا تتأثر.
• لا تحذف السجل. إذا اختفى وسقط التحقق، يحيلك الإعلان إلى الملف أو وسم meta. وإعادة إنشاء CNAME لن تعيد التحقق.
• لا تفعّل وكيلًا أمامه. في Cloudflare، السجل الموجَّه عبر الوكيل (السحابة البرتقالية) لا يُحل من الخارج بوصفه CNAME بعد ذلك، فيفشل أي فحص لاحق. أبقِ سجل التحقق على DNS only.

dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.

dig +short @8.8.8.8 abcdef123456.example.com CNAME

إذا أعاد الأمران ziyuan.baidu.com. فالسجل القديم سليم. وإذا أظهرت لوحة التحكم الموقع على أنه غير متحقق منه، فأعد التحقق بالملف أو وسم meta بدلًا من تعديل DNS.

لماذا يفشل التحقق رغم أن الإعداد يبدو صحيحًا

جلبت الملف بـ 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 إن كنت تعمل داخل نظام إدارة محتوى وصفحاتك تُقدَّم من الخادم. وإن تعذر عليك لمس الموقع أصلًا، فلم يعد DNS طريقًا للالتفاف على ذلك: على شخص يصل إلى الجذر العام للموقع أو إلى القوالب أن يضع إحدى الطريقتين.

وأيًّا كان اختيارك، أبقِه في مكانه دائمًا واكتبه في ملاحظات بنيتك التحتية. فالشخص الذي سيحذف ملفًا غامضًا بعد ثمانية عشر شهرًا هو أنت.

ما لا تحله هذه الطرق

كلتا الطريقتين تفترض أنك مسجَّل الدخول إلى حساب Baidu. والتسجيل يُؤكَّد برسالة قصيرة إلى رقم هاتف محمول من البر الصيني الرئيسي، ويطلب Baidu في كثير من الحالات تحققًا من الهوية الحقيقية (实名认证) ببطاقة هوية وطنية صينية أو رخصة عمل صينية. وشركة في فرانكفورت أو مانشستر، مهما كان ملف التحقق لديها منشورًا بإتقان، لا تصل إلى شاشة التحقق.

وهنا يأتي دور خدمة التسجيل في بايدو. تدلّنا على النطاق، وتُنجز فحص ملكية نطاق واحدًا من جهتك، ونتولى نحن التسجيل ونوافيك بما فهرسه Baidu فعليًا، بسعر ثابت لكل نطاق. لا تحتاج إلى رقم هاتف صيني، ولا إلى كيان صيني، ولا إلى حساب خاص بك في بايدو. وبعد التحقق من النطاق، تحصل كذلك على 12 شهرًا من بياناته في Baidu Webmaster Tools عبر بوابتنا، حيث تتابع الفهرسة والزحف وترسل روابط جديدة بنفسك.

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