Verifiering av webbplatser hos Baidu: HTML-filen, metataggen och vad som hände med CNAME

Någon har lämnat över en Baidu-uppgift till dig, och det första som står i vägen är en verifieringsskärm. Baidu tar inte emot en webbplatskarta, öppnar inte sina indexrapporter och låter dig inte skicka en enda URL förrän Baidu är övertygat om att domänen är din. Två metoder visar det i dag. De beter sig olika, och felen är inte de du känner igen från Google Search Console. Den tredje metoden, som de flesta guider fortfarande beskriver, en CNAME-post, har varit avstängd sedan januari 2023.

Här går vi igenom implementationen av de båda metoder som fungerar, vad avstängningen av CNAME betyder om du har använt den tidigare, och varför verifieringen oftast misslyckas, med hur du kontrollerar varje orsak från en terminal.

Var verifieringen kommer in

Baidus produkt för webbansvariga är Baidu Search Resource Platform (百度搜索资源平台) på ziyuan.baidu.com, som fortfarande ofta kallas Baidu Zhanzhang. Du lägger till en webbplats, väljer en verifieringsmetod, och Baidu hämtar något från din domän för att bekräfta att du har kontroll över den. Först då låses inskickning av länkar, uppladdning av webbplatskarta och diagnostiken för genomsökning upp.

Två saker i egendomsmodellen ställer till det redan innan man har valt metod:

Protokollet och värdnamnet ingår i identiteten. https://example.com och https://www.example.com är två olika webbplatser för Baidu, och detsamma gäller http://-versionerna. Lägg till exakt den origin som dina kanoniska URL:er använder. Verifierar du fel origin hänvisar allt du skickar in efteråt till en egendom som inte har någon av din trafik.
Hämtningen görs från Fastlandskina. Det som bevisar ägarskapet måste gå att nå därifrån, över det publika internet, utan en kontrollsida framför. Det enda faktumet förklarar de flesta felen längst ner i den här artikeln.

Innan något av detta behövs ett konto. Ett Baidu-konto krävs för att över huvud taget nå verifieringsskärmen, och registreringen är knuten till en SMS-bekräftelse till ett mobilnummer i Fastlandskina. Det är en verklig mur för ett företag i Europa eller Storbritannien, och det är värt att känna till innan du lägger en eftermiddag på mallar och driftsättningar. Mer om det i slutet.

Metod 1: HTML-filen för verifiering

Den vanligaste metoden, och den att föredra när du kan driftsätta en statisk fil.

Baidu genererar en fil för din webbplats och erbjuder den för nedladdning. Namnet ser ut så här:

baidu_verify_codeva-XXXXXXXXXX.html

Äldre egendomar fick namn i formen baidu_verify_XXXXXXXXXX.html, och vissa paneler visar prefixet code- i stället för codeva-. Försök inte återskapa namnet eller token utifrån ett blogginlägg: ladda ner filen som Baidu ger dig, eller kopiera strängen från panelen tecken för tecken. Filens innehåll är kort, oftast bara själva token och inget annat.

Den måste serveras från roten av den origin du registrerade:

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

Inte i en underkatalog, inte bakom ett språkprefix, inte på ett annat värdnamn.

Var filen hamnar, per stack

Stack	Plats
Vite, Create React App, SvelteKit (`static`), Nuxt	`public/` eller `static/` i projektets rot
Next.js (båda routrarna)	`public/`
Hugo, Astro	`static/` respektive `public/`
Laravel	`public/`
Django	en `static/`-katalog som samlas in av `collectstatic`, eller som serveras direkt av nginx
ASP.NET Core	`wwwroot/`
WordPress	webbroten bredvid `wp-config.php`, via SFTP
Ren nginx eller Apache	dokumentroten

Kontrollera den som Baidu gör

curl -sSI https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
curl -sS  https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

Du vill se HTTP/2 200, en content-type med värdet text/html, ingen location-header och ett innehåll som är exakt token. Tre resultat betyder att du inte är klar:

En 301 eller 302. Något normaliserar sökvägen, oftast en regel om avslutande snedstreck eller en språkomdirigering som skickar varje okänd sökväg till /en/.... Lägg in ett undantag före den generella regeln.
En 200 som returnerar ditt appskal. Det här är det vanligaste falska godkännandet. En single page-app med en generell route svarar på varje sökväg med index.html och status 200, så filen ”finns”, men innehållet är din React-markup. Baidu läser innehållet, hittar ingen token och avvisar det. Servera den statiska filen före SPA-reservläget.
En 404 som ligger kvar efter driftsättningen. Oftast ett CDN som har cachat det negativa svaret. Rensa just den sökvägen och kontrollera igen med curl -H 'Cache-Control: no-cache'.

Behåll filen i repot efteråt. Baidu kontrollerar ägarskapet på nytt med jämna mellanrum, och en webbplats som tappar sin verifieringsfil försvinner tyst ur panelen.

Metod 2: HTML-metataggen

Använd den här när du kan redigera mallar men inte lägga filer i webbroten, vilket är det normala läget i ett hanterat CMS eller hos en plattformsleverantör.

Baidu ger dig en tagg av den här formen, som ska in i startsidans <head>:

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

Attributet name är alltid baidu-site-verification, stavat exakt så, med bindestrecken. Värdet i content är token från panelen.

Tre regler avgör om det fungerar:

Den måste ligga inuti <head>. En parser som hittar den i <body> betraktar head som redan stängt. Allt som injiceras efter det första elementet som inte hör till head kommer för sent.
Den måste finnas i den HTML som servern skickar. Öppna view-source: eller, ännu bättre, curl -sS https://example.com | grep baidu-site-verification. Syns taggen bara i elementinspektören i DevTools har den lagts till av JavaScript efter hydreringen, och då räknas den inte. Det är det som gör att den fallerar i klientrenderade React- och Vue-appar, och det är därför filmetoden är enklare för en SPA.
Den måste överleva ramverket. Hanterare för head tar bort dubbletter och sanerar innehåll. Next.js vill ha den i metadata-exporten i stället för en lös <meta> i en komponent. React Helmet släpper taggar som renderas utanför dess provider. Vissa säkerhetstillägg för CMS tar bort metataggar med okända namn. En tagghanterare kan inte placera den, eftersom tagghanteraren körs på klientsidan.

Placering per ramverk:

// 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);

På en serverrenderad webbplats lägger du den i basmallen bredvid taggarna för charset och viewport och glömmer den sedan. I Hugo är det layouts/_default/baseof.html; i Django den basmall som alla sidor ärver från.

CNAME-posten: avstängd sedan januari 2023

Äldre guider, däribland den första versionen av den här, beskriver en tredje metod: en CNAME-post i DNS. Den 13 januari 2023 stängde Baidu av CNAME-verifieringen (Baidus meddelande) och hänvisade webbplatsägare till verifiering med fil eller HTML-tagg i stället. Per den 10 oktober 2026 har Baidu inte publicerat något meddelande om att den kommer tillbaka.

Om en webbplats verifierades med CNAME före dess ser posten ut så här:

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

I en DNS-panel visas den som:

Fält	Värde
Typ	`CNAME`
Namn / värd	`abcdef123456`
Värde / mål	`ziyuan.baidu.com`
TTL	det som sattes då, ofta 3600

Vad avstängningen betyder för dig:

En ny webbplats kan inte använda den. Baidu godtar inte längre CNAME för en webbplats som inte redan är verifierad. Använd filen eller metataggen ovan.
En befintlig CNAME-verifiering gäller fortfarande. Baidus meddelande säger att webbplatser som redan är verifierade inte påverkas.
Radera inte posten. Försvinner den och verifieringen förfaller, hänvisar meddelandet dig till filen eller metataggen. Att skapa CNAME-posten igen tar inte tillbaka verifieringen.
Slå inte på en proxy framför den. Hos Cloudflare löses en proxad post (orange moln) inte längre upp som CNAME utifrån, så en senare kontroll misslyckas. Låt verifieringsposten vara DNS only.

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

dig +short @8.8.8.8 abcdef123456.example.com CNAME

Returnerar båda ziyuan.baidu.com. är den gamla posten intakt. Visar konsolen webbplatsen som overifierad, verifiera då igen med filen eller metataggen i stället för att ändra i DNS.

Varför verifieringen misslyckas när allt ser rätt ut

Du har kört curl mot filen, den returnerar 200, och Baidu säger ändå nej. Gå igenom den här listan uppifrån:

En botkontroll eller WAF-regel. Cloudflare Bot Fight Mode, hanterade regler i AWS WAF och de flesta lägen av typen ”under attack” returnerar en mellansida i JavaScript med 403 eller 503 till varje klient som inte kör skript. Det gör inte Baidus hämtare. Vitlista verifieringssökvägen, eller sökroboten.
Geoblockering. Många europeiska webbplatser blockerar eller begränsar trafik från Fastlandskina för att stoppa skrapning. Verifieringshämtningen kommer från just det området. Kontrollera att inget i nätverkskanten stoppar den.
User agent filtreras. Sökroboten identifierar sig som Baiduspider. Vissa säkerhetslösningar behandlar okända sökrobotsträngar som skrapor. Vill du bekräfta att en förfrågan är äkta innan du vitlistar, ger omvänd DNS-uppslagning av käll-IP:n *.baidu.com eller *.baidu.jp, och uppslagningen framåt måste stämma.
robots.txt blockerar den. En Disallow: / under en user agent med jokertecken, eller ett uttryckligt User-agent: Baiduspider-block som någon annan har lämnat kvar, stoppar hämtningen innan den börjar.
Ett TLS-problem som webbläsare döljer. Ett saknat mellanliggande certifikat repareras tyst av webbläsare på datorn, men inte av enkla hämtare. Kör din domän genom en extern TLS-kontroll i stället för att lita på ett grönt hänglås.
Fel origin verifieras. Filen ligger på www.example.com, egendomen hos Baidu säger example.com. Ingenting i felmeddelandet berättar det för dig.
Långsam första byte. Servrar i Europa utan närvaro i Kina svarar långsamt på en förfrågan från Peking, och en kallstart i en serverlös miljö ovanpå det kan överskrida tidsgränsen för hämtningen. Att försöka igen vid en annan tid på dygnet hjälper faktiskt.

Vilken metod du ska använda

Driftsätt en statisk fil om du har ett byggflöde: den är minst sannolik att förvanskas och enklast att testa. Välj metataggen om du arbetar i ett CMS och dina sidor renderas på servern. Kan du inte röra webbplatsen alls är DNS inte längre någon väg runt det: någon med åtkomst till webbroten eller mallarna måste placera en av de två.

Vilken du än väljer, låt den ligga kvar permanent och för in den i dina anteckningar om infrastrukturen. Den som raderar en mystisk fil om arton månader kommer att vara du.

Det som metoderna inte löser

Båda metoderna förutsätter att du redan är inloggad på ett Baidu-konto. Registreringen bekräftas via SMS till ett mobilnummer i Fastlandskina, och för många egendomar kräver Baidu också identitetsverifiering med riktigt namn (实名认证) mot ett kinesiskt nationellt id-kort eller en kinesisk företagslicens. Ett företag i Frankfurt eller Manchester med en perfekt driftsatt verifieringsfil kan ändå inte nå verifieringsskärmen.

Det är där vår tjänst för inskickning till Baidu kommer in. Du pekar ut domänen för oss, gör en enda kontroll av domänägarskapet på din sida, och vi sköter inskickningen, till ett fast pris per domän. Inget kinesiskt telefonnummer, ingen kinesisk juridisk person, inget eget Baidu-konto. När domänen är verifierad får du dessutom 12 månader med domänens data från Baidu Webmaster Tools i vår portal, där du kan följa indexering och genomsökning och själv skicka in nya URL:er.

Vill du se helheten först går den fullständiga guiden till inskickning hos Baidu igenom webbplatskartor, push-API:et och vad Baidus ranking faktiskt belönar. Vill du hellre prata igenom det, boka ett samtal.