Потвърждаване на сайт в Baidu: методите с HTML файл и мета таг и какво стана с CNAME

Някой ви е възложил задача, свързана с Baidu, и първото, което ви се изпречва, е екран за потвърждаване. Baidu няма да приеме карта на сайта (sitemap), няма да отвори отчетите си за индексирането и няма да ви позволи да изпратите нито един URL адрес, докато не се увери, че домейнът е ваш. Днес това се доказва по два метода. Те се държат различно, а причините за неуспех не са тези, които познавате от 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://. Добавете точно онзи произход (origin), който използват каноничните ви URL адреси. Ако потвърдите грешния, всичко, което изпратите след това, ще се отнася до собственост, през която не минава нищо от трафика ви.
Изтеглянето идва от континентален Китай. Онова, което доказва собствеността, трябва да е достъпно оттам, през публичния интернет, без страница с проверка пред него. Само този факт обяснява повечето неуспехи, описани в края на статията.

Преди всичко това има и акаунт. Без акаунт в Baidu изобщо не можете да стигнете до екрана за потвърждаване, а регистрацията е обвързана с потвърждение чрез SMS на мобилен номер от континентален Китай. За компания в Европа или Обединеното кралство това е истинска стена и е добре да го знаете, преди да прекарате един следобед в шаблони и внедрявания. Повече за това в края.

Метод 1: 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, който връща обвивката на приложението. Това е най-честото фалшиво „минало". Едностранично приложение (SPA) с общ маршрут отговаря на всеки път с index.html и статус 200, така че файлът „съществува", но тялото е вашата React разметка. Baidu чете тялото, не намира токен и отхвърля потвърждаването. Сервирайте статичния файл преди резервния маршрут на SPA.
404, което остава и след внедряване. Обикновено CDN е кеширал отрицателния отговор. Изчистете кеша точно за този път и проверете отново с curl -H 'Cache-Control: no-cache'.

След това оставете файла в хранилището. Baidu периодично проверява собствеността наново, а сайт, който загуби файла си за потвърждаване, тихо изчезва от панела.

Метод 2: HTML мета тагът

Използвайте го, когато можете да редактирате шаблони, но не и да слагате файлове в корена на сайта, което е обичайното положение при управлявана CMS или платформен хостинг.

Baidu ви дава таг в следния вид, който се поставя в <head> на началната страница:

<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />

Атрибутът name винаги е baidu-site-verification, изписан точно така, включително тиретата. Стойността на content е токенът от панела.

Три правила решават дали ще проработи:

Трябва да е вътре в <head>. Парсер, който го намери в <body>, приема, че head вече е затворен. Всичко, вмъкнато след първия елемент, който не принадлежи на head, идва твърде късно.
Трябва да е в HTML, който сървърът изпраща. Отворете view-source: или, още по-добре, curl -sS https://example.com | grep baidu-site-verification. Ако тагът се вижда само в инспектора на елементи в DevTools, той е добавен от JavaScript след хидратацията и не се брои. Точно това го проваля при React и Vue приложения, рендирани в браузъра, и затова методът с файл е по-лесен за SPA.
Трябва да оцелее във фреймуърка. Мениджърите на head премахват дубликати и почистват съдържанието. Next.js иска тагът да е в експорта на метаданните, а не като самотен <meta> в някой компонент. React Helmet изпуска тагове, рендирани извън неговия provider. Някои плъгини за сигурност в CMS премахват мета тагове с непознати имена. Мениджър на тагове не може да го постави, защото работи от страна на клиента.

Поставяне според фреймуърка:

// 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 панел се показва като:

Поле	Стойност
Тип	`CNAME`
Име / хост	`abcdef123456`
Стойност / цел	`ziyuan.baidu.com`
TTL	каквото е било зададено тогава, често 3600

Какво означава спирането за вас:

Нов сайт не може да го използва. Baidu вече не приема CNAME за сайт, който не е потвърден. Използвайте файла или мета тага по-горе.
Съществуващо потвърждаване чрез CNAME остава валидно. Известието на Baidu казва, че вече потвърдените сайтове не са засегнати.
Не изтривайте записа. Ако изчезне и потвърждаването отпадне, известието ви препраща към файла или мета тага. Повторното създаване на CNAME няма да го върне.
Не включвайте прокси пред него. В Cloudflare записът през прокси (оранжевият облак) вече не се разрешава като CNAME отвън, така че следваща повторна проверка се проваля. Дръжте записа за потвърждаване в режим само DNS.

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

dig +short @8.8.8.8 abcdef123456.example.com CNAME

Ако и двете команди върнат ziyuan.baidu.com., старият запис е непокътнат. Ако конзолата показва сайта като непотвърден, потвърдете го наново с файла или мета тага, вместо да редактирате DNS.

Защо потвърждаването се проваля, когато настройката изглежда правилна

Проверили сте файла с curl, той връща 200, а Baidu пак казва „не". Минете през този списък:

Проверка за ботове или правило на WAF. Cloudflare Bot Fight Mode, управляваните правила на AWS WAF и повечето настройки от типа „under attack" връщат междинна страница с JavaScript и код 403 или 503 на всеки клиент, който не изпълнява скриптове. Изтеглящият робот на Baidu не ги изпълнява. Добавете пътя за потвърждаване или робота в списъка с разрешени.
Географско блокиране. Немалко европейски сайтове блокират или ограничават трафика от континентален Китай, за да намалят извличането на съдържание. Изтеглянето за потвърждаване идва точно от този диапазон. Уверете се, че нищо на периферията не го отрязва.
Потребителският агент се филтрира. Роботът се представя като Baiduspider. Някои системи за сигурност третират непознатите низове на роботи като скрейпъри. Ако искате да се уверите, че заявката е истинска, преди да я разрешите, обратното DNS търсене на изходния IP адрес се разрешава до *.baidu.com или *.baidu.jp, а правото търсене трябва да съвпада.
robots.txt го блокира. Disallow: / под потребителски агент със заместващ знак или изричен блок User-agent: Baiduspider, оставен от някой друг, спира изтеглянето още преди да е започнало.
Проблем с TLS, който браузърите прикриват. Липсващ междинен сертификат се поправя тихо от настолните браузъри, но не и от простите клиенти за изтегляне. Проверете домейна си с външен инструмент за TLS, вместо да се доверявате на зеленото катинарче.
Потвърждаване на грешния произход. Файлът е на www.example.com, а собствеността в Baidu е example.com. Нищо в съобщението за грешка няма да ви го подскаже.
Бавен първи байт. Сървъри в Европа без присъствие в Китай отговарят бавно на заявка от Пекин, а студен старт на serverless функция отгоре може да надхвърли времето за изчакване на изтеглянето. Повторен опит в друг час наистина помага.

Кой метод да използвате

Внедрете статичен файл, ако имате процес за компилиране и внедряване: той най-малко рискува да бъде осакатен и най-лесно се тества. Изберете мета тага, ако работите в CMS и страниците ви се рендират на сървъра. Ако изобщо не можете да пипате сайта, DNS вече не е заобиколен път: някой с достъп до корена на сайта или до шаблоните трябва да постави едното от двете.

Каквото и да изберете, оставете го на място завинаги и го впишете в бележките си за инфраструктурата. Човекът, който след осемнайсет месеца ще изтрие някакъв загадъчен файл, ще бъдете вие.

Това, което методите не решават

И двата метода предполагат, че вече сте влезли в акаунт в Baidu. Регистрацията се потвърждава чрез SMS на мобилен номер от континентален Китай, а за много собствености Baidu изисква и проверка на самоличността с истинско име (实名认证) срещу китайска лична карта или китайски търговски лиценз. Компания във Франкфурт или Манчестър с безупречно внедрен файл за потвърждаване пак не може да стигне до екрана за потвърждаване.

Тук се намесва нашата услуга за изпращане на сайтове в Baidu. Посочвате ни домейна, извършвате от своя страна една проверка за собственост на домейна, а ние изпълняваме изпращането, на фиксирана цена за домейн. Без китайски телефонен номер, без китайско юридическо лице, без собствен акаунт в Baidu. След като домейнът бъде потвърден, получавате и 12 месеца данни от Baidu Webmaster Tools за него в нашия портал, където можете да следите индексирането и обхождането и сами да изпращате нови URL адреси.

Ако първо искате по-широката картина, пълното ръководство за изпращане на сайт в Baidu разглежда картите на сайта, push API и какво всъщност награждава класирането на Baidu. Ако предпочитате да го обсъдим, запазете разговор.