Верификација на сопственост кај Baidu: датотека, мета ознака и CNAME

Ви доделиле задача околу Baidu, а првото нешто што ве запира е екранот за верификација. Baidu нема да прими карта на сајтот, нема да ги отвори извештаите за индексирање и нема да ви дозволи да поднесете ниту еден URL додека не се увери дека доменот е ваш. Постојат три начини да го докажете тоа, се однесуваат различно, а грешките што се појавуваат не се оние што ги знаете од Google Search Console.

Следуваат деталите за изведба на секој метод, причините поради кои верификацијата обично паѓа и начинот да ги проверите сите три од терминал.

Каде стои верификацијата

Алатката на Baidu за вебмастери е Baidu Search Resource Platform (百度搜索资源平台) на ziyuan.baidu.com, сè уште најчесто наречена Baidu Zhanzhang. Додавате сајт, избирате метод за верификација, а Baidu презема нешто од вашиот домен за да потврди дека вие го контролирате. Дури тогаш се отклучуваат поднесувањето линкови, прикачувањето карта на сајтот и дијагностиката на индексирањето.

Две работи околу тоа како Baidu ги дефинира сајтовите ги изненадуваат луѓето уште пред да изберат метод:

Протоколот и хостот се дел од идентитетот. https://example.com и https://www.example.com за Baidu се два различни сајта, исто како и нивните http:// верзии. Додајте го точно оној origin што го користат вашите канонски URL-а. Ако верификувате погрешен, сè што ќе поднесете потоа се однесува на сопственост низ која не поминува ниту еден ваш посетител.
Преземањето доаѓа од континентална Кина. Она што ја докажува сопственоста мора да биде достапно оттаму, преку јавниот интернет, без страница со проверка пред него. Тој единствен факт ги објаснува повеќето неуспеси наведени на крајот од текстов.

Пред сето тоа стои сметката. Без Baidu сметка воопшто не стигнувате до екранот за верификација, а регистрацијата е врзана за SMS потврда на мобилен број од континентална Кина. За фирма во Европа или во Обединетото Кралство тоа е вистински ѕид и вреди да го знаете пред да потрошите цело попладне на DNS. Повеќе за тоа на крајот.

Метод 1: HTML датотеката за верификација

Најчестиот метод и оној што треба да го изберете кога можете да поставите статична датотека.

Baidu генерира датотека за вашиот сајт и ви ја нуди за преземање. Името изгледа вака:

baidu_verify_codeva-XXXXXXXXXX.html

На постарите сопствености им беа издадени имиња од видот baidu_verify_XXXXXXXXXX.html, а некои панели прикажуваат префикс code- наместо codeva-. Не обидувајте се да го составите името или токенот според објава на блог: преземете ја датотеката што ви ја дава Baidu или копирајте ја низата од панелот, знак по знак. Содржината на датотеката е кратка, обично самиот токен и ништо друго.

Мора да се сервира од коренот на origin-от што сте го регистрирале:

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 што го враќа скелетот на апликацијата. Ова е далеку најчестото лажно поминување. Едностранична апликација со catch-all рута одговара на секоја патека со index.html и статус 200, па датотеката „постои“, но телото е вашиот React код. Baidu го чита телото, не наоѓа токен и одбива. Сервирајте ја статичната датотека пред SPA fallback-от.
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> смета дека главата е веќе затворена. Сè што се вметнува по првиот елемент надвор од главата доаѓа предоцна.
Мора да биде во HTML-от што го испраќа серверот. Отворете view-source: или, уште подобро, curl -sS https://example.com | grep baidu-site-verification. Ако ознаката се гледа само во инспекторот на DevTools, ја додал JavaScript по хидрацијата и не се брои. Токму ова ја руши кај React и Vue апликации што се рендерираат кај клиентот, и затоа кај SPA методот со датотека е полесен.
Мора да ја преживее рамката. Менаџерите на <head> дедуплицираат и чистат. Next.js ја сака во metadata извозот, а не како случајна <meta> во некоја компонента. React Helmet ги отфрла ознаките рендерирани надвор од неговиот provider. Некои безбедносни додатоци за CMS бришат мета ознаки со непознати имиња. Tag manager не може да ја постави, зашто самиот tag manager работи кај клиентот.

Поставување според рамката:

// Next.js App Router, app/layout.js
export const metadata = {
  other: { 'baidu-site-verification': 'codeva-XXXXXXXXXX' },
}

// WordPress, functions.php на подтемата
add_action('wp_head', function () {
  echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);

Кај сајт што се рендерира на серверот, ставете ја во основниот шаблон до ознаките за charset и viewport и заборавете на неа. Кај Hugo тоа е layouts/_default/baseof.html; кај Django, основниот шаблон што го наследуваат сите страници.

Метод 3: CNAME записот

DNS методот е вистинскиот избор кога воопшто не можете да деплојувате, кога сајтот е зад уред што не го контролирате или кога сакате проверката да ги преживее сите идни деплои. Освен тоа, докажува контрола врз целиот домен, а не врз еден документ.

Baidu ви покажува случајна ознака на хост што треба да ја создадете под вашиот домен, насочена кон Baidu:

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

Во повеќето DNS панели ја внесувате само левата ознака, зашто зоната се подразбира:

| Поле | Вредност | | --- | --- | | Тип | CNAME | | Име / Host | 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. Ако некој resolver веќе кеширал негативен одговор за тоа име, важи стариот 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 и повеќето поставки од типот „under attack“ враќаат JavaScript страница со 403 или 503 на секој клиент што не извршува скрипти. Преземачот на Baidu не извршува. Дозволете ја патеката за верификација или самиот crawler.
Гео-блокирање. Многу европски сајтови го блокираат или ограничуваат сообраќајот од континентална Кина за да го намалат стругањето содржина. Верификациското преземање доаѓа токму од тој опсег. Уверете се дека ништо на работ на мрежата не го отфрла.
Филтриран user agent. Crawler-от се претставува како Baiduspider. Некои безбедносни решенија ги третираат непознатите crawler стрингови како scraper-и. Ако сакате да потврдите дека барањето е вистинско пред да го дозволите: обратниот DNS на изворната IP адреса се решава на *.baidu.com или *.baidu.jp, а директното барање мора да се совпадне.
robots.txt го блокира. Disallow: / под wildcard user-agent, или експлицитен блок User-agent: Baiduspider што го оставил некој друг, го запира преземањето пред да почне.
TLS проблем што прелистувачите го кријат. Прелистувачите на десктоп тивко поправаат отсутен посреднички сертификат, едноставните преземачи не. Пуштете го доменот низ надворешна TLS проверка наместо да му верувате на зелениот катанец.
Верификуван е погрешен origin. Датотеката стои на www.example.com, а во Baidu сопственоста е заведена како example.com. Ништо во пораката за грешка нема да ви го каже тоа.
Бавен прв бајт. Сервери во Европа без присуство во Кина одговараат бавно на барање од Пекинг, а ладен старт на serverless функција врз тоа може да го надмине лимитот за преземање. Обид во друг час навистина помага.

Кој метод да го изберете

Поставете статична датотека ако имате build процес: најмалку е веројатно нешто да ја расипе и најлесно се тестира. Земете ја мета ознаката ако живеете во CMS, а страниците ви се рендерираат на серверот. Земете го CNAME ако воопшто не можете да го допрете сајтот, или ако сакате сопственоста да се докаже на ниво на домен еднаш и потоа никогаш повторно.

Што и да изберете, оставете го трајно и запишете го во белешките за инфраструктурата, до другите DNS записи. Човекот што за осумнаесет месеци ќе избрише некоја мистериозна датотека ќе бидете вие.

Она што методите не го решаваат

Сите три методи претпоставуваат дека веќе сте најавени на Baidu сметка. Регистрацијата се потврдува со SMS на мобилен број од континентална Кина, а за многу сопствености Baidu бара и верификација на вистински идентитет (实名认证) со кинеска лична карта или кинеска бизнис лиценца. Фирма во Франкфурт или во Манчестер, со беспрекорно наместена DNS зона, сепак не стигнува до екранот за верификација.

Тука влегува нашата услуга за пријава на Baidu. Ни го посочувате доменот, поминувате една проверка на сопственост на доменот на ваша страна, а ние ја спроведуваме пријавата и известуваме што навистина индексирал Baidu, по фиксна цена по домен. Не ви треба кинески телефонски број, кинеска фирма ниту ваша сметка на Baidu.

Ако прво сакате поширока слика, целосниот водич за пријава на Baidu ги опфаќа картите на сајтот, push API-то и она што рангирањето на Baidu навистина го наградува. Ако повеќе сакате да поразговараме, закажете разговор.