Om osYdelserCasesArtikler
← Back to ArticlesVil du helst ikke selv? Vi anmelder dit website til Baidu til fast pris.Se ydelsen Baidu-registrering →

Baidu-verifikation af websites: HTML-fil, meta-tag og CNAME

Beijing central business district skyline at dusk

Du har fået en Baidu-opgave i hånden, og det første, der spærrer vejen, er et verifikationsbillede. Baidu tager ikke imod et sitemap, åbner ikke sine indeksrapporter og lader dig ikke indsende en eneste URL, før det står klart, at domænet er dit. Der findes tre måder at bevise det på, de opfører sig forskelligt, og de fejl, du løber ind i, er ikke dem, du kender fra Google Search Console.

Her er implementeringsdetaljerne for hver metode, plus de grunde til, at verifikationen som regel fejler, og hvordan du tjekker hver enkelt fra en terminal.

Hvor verifikationen foregår

Baidus webmasterprodukt hedder Baidu Search Resource Platform (百度搜索资源平台) og ligger på ziyuan.baidu.com; i daglig tale hedder det stadig Baidu Zhanzhang. Du tilføjer et site, vælger en verifikationsmetode, og Baidu henter noget fra dit domæne for at bekræfte, at du har kontrollen. Først derefter åbnes linkindsendelse, sitemap-upload og crawldiagnostikken.

To ting ved propertymodellen driller folk, allerede før de har valgt metode:

  • Protokol og host er en del af identiteten. https://example.com og https://www.example.com er to forskellige sites i Baidus øjne, og det samme gælder http://-udgaverne. Tilføj præcis den origin, dine kanoniske URL'er bruger. Verificerer du den forkerte, peger alt, hvad du indsender bagefter, på en property, som ingen af dine besøgende kommer via.
  • Hentningen kommer fra det kinesiske fastland. Uanset hvad der beviser ejerskabet, skal det kunne nås derfra over det åbne internet, uden en challenge-side foran. Det ene forhold forklarer de fleste af fejlene nederst i artiklen.

Og før alt det står en konto. Uden en Baidu-konto når du slet ikke frem til verifikationsbilledet, og registreringen er bundet til SMS-bekræftelse på et mobilnummer fra det kinesiske fastland. Det er en reel forhindring for en virksomhed i Europa eller Storbritannien, og det er værd at vide, før du bruger en eftermiddag på DNS. Mere om det til sidst.

Metode 1: HTML-verifikationsfilen

Den mest udbredte metode, og den, du bør vælge, når du kan lægge en statisk fil ud.

Baidu genererer en fil til dit site og stiller den til download. Navnet ser sådan ud:

baidu_verify_codeva-XXXXXXXXXX.html

Ældre properties fik navne på formen baidu_verify_XXXXXXXXXX.html, og nogle paneler viser præfikset code- i stedet for codeva-. Prøv ikke at rekonstruere navnet eller tokenet ud fra et blogindlæg: hent den fil, Baidu giver dig, eller kopier strengen ud af panelet tegn for tegn. Filens indhold er kort, som regel selve tokenet og intet andet.

Den skal serveres fra roden af den origin, du registrerede:

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

Ikke i en undermappe, ikke bag et sprogpræfiks, ikke på en anden host.

Hvor filen skal ligge, efter stack

| Stack | Placering | | --- | --- | | Vite, Create React App, SvelteKit (static), Nuxt | public/ eller static/ i projektroden | | Next.js (begge routere) | public/ | | Hugo, Astro | henholdsvis static/ og public/ | | Laravel | public/ | | Django | en static/-mappe, som collectstatic samler op, eller serveret direkte af nginx | | ASP.NET Core | wwwroot/ | | WordPress | webroden ved siden af wp-config.php, over SFTP | | Ren nginx eller Apache | document root |

Tjek det, 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 vil se HTTP/2 200, en content-type på text/html, ingen location-header og en body, der er præcis tokenet. Tre resultater betyder, at du ikke er færdig:

  • En 301 eller 302. Noget normaliserer stien, oftest en regel om afsluttende skråstreg eller et sprogredirect, der sender enhver umatchet sti til /en/.... Læg en undtagelse ind før catch-all-reglen.
  • En 200, der returnerer din app-shell. Det er den klart hyppigste falske succes. En single page-app med en catch-all-rute svarer på enhver sti med index.html og status 200, så filen »findes«, men body'en er din React-markup. Baidu læser body'en, finder intet token og afviser. Server den statiske fil før SPA-fallbacket.
  • En 404, der bliver hængende efter deploy. Som regel har et CDN cachet det negative svar. Ryd cachen for præcis den sti, og tjek igen med curl -H 'Cache-Control: no-cache'.

Lad filen blive i repositoriet bagefter. Baidu tjekker ejerskabet igen med jævne mellemrum, og et site, der mister sin verifikationsfil, forsvinder stille og roligt ud af panelet.

Metode 2: HTML-meta-tagget

Brug denne, når du kan redigere templates, men ikke lægge filer i webroden, hvilket er den normale situation på et hostet CMS eller en platformudbyder.

Baidu giver dig et tag på denne form, som skal ind i <head> på forsiden:

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

name-attributten er altid baidu-site-verification, stavet nøjagtigt sådan, bindestreger inklusive. content-værdien er tokenet fra panelet.

Tre regler afgør, om det virker:

  1. Det skal ligge inde i <head>. En parser, der finder det i <body>, betragter head som allerede lukket. Alt, der indsættes efter det første element uden for head, kommer for sent.
  2. Det skal stå i den HTML, serveren sender. Åbn view-source: eller, endnu bedre, curl -sS https://example.com | grep baidu-site-verification. Optræder tagget kun i elementinspektøren i DevTools, er det tilføjet af JavaScript efter hydrering, og så tæller det ikke. Det er dét, der ødelægger det på klientrenderede React- og Vue-apps, og derfor er filmetoden nemmere på en SPA.
  3. Det skal overleve frameworket. Head-managere fjerner dubletter og renser ud. Next.js vil have det i metadata-eksporten og ikke som et løsrevet <meta> i en komponent. React Helmet smider tags væk, der renderes uden for dens provider. Nogle sikkerhedsplugins til CMS'er fjerner meta-tags med ukendte navne. En tag manager kan ikke placere det, for den kører på klientsiden.

Placering afhængigt af framework:

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

// WordPress, functions.php i et child theme
add_action('wp_head', function () {
  echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);

På et serverrenderet site lægger du det ind i basisskabelonen ved siden af charset- og viewport-taggene og glemmer det. På Hugo er det layouts/_default/baseof.html, på Django den basisskabelon, alle sider udvider.

Metode 3: CNAME-posten

DNS-metoden er den, du skal vælge, når du slet ikke kan deploye, når sitet ligger bag en appliance, du ikke styrer, eller når du vil have, at tjekket overlever enhver fremtidig udrulning. Den beviser desuden kontrol over hele domænet frem for over ét dokument.

Baidu viser dig et tilfældigt værtslabel, som du skal oprette under dit domæne og pege på Baidu:

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

I de fleste DNS-paneler indtaster du kun labelet til venstre, fordi zonen er underforstået:

| Felt | Værdi | | --- | --- | | Type | CNAME | | Navn / Host | abcdef123456 | | Værdi / Mål | ziyuan.baidu.com | | TTL | 3600, eller den laveste værdi panelet tillader, mens du tester |

Fire ting går galt her, gang på gang:

  • Domænet bliver sat på to gange. Skriver du abcdef123456.example.com i et panel, der i forvejen tilføjer zonen, får du abcdef123456.example.com.example.com. Viser dit panel det fuldt kvalificerede navn efter gemt, så læs det igennem.
  • Punktummet til sidst i målet. I en rå zonefil bliver ziyuan.baidu.com uden det afsluttende punktum læst relativt til zonen og bliver til ziyuan.baidu.com.example.com. Paneler klarer det for dig; named og Terraform-filer gør ikke.
  • En proxy foran posten. På Cloudflare slår en proxyet post (orange sky) ikke længere op som CNAME udefra: det autoritative svar bliver Cloudflares A-poster. Sæt verifikationsposten til DNS only.
  • At vente kortere tid end TTL'en. Har en resolver allerede et negativt svar cachet for det navn, gælder den gamle TTL. Tjek, hvad omverdenen rent faktisk ser, i stedet for hvad dit panel påstår.
dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.

dig +short @8.8.8.8 abcdef123456.example.com CNAME

Lad posten blive stående. Sletter du den efter et vellykket tjek, inviterer du til en fejlet genverifikation senere.

Hvorfor verifikationen fejler, selv om opsætningen ser rigtig ud

Du har curlet filen, den svarer 200, og Baidu siger stadig nej. Arbejd dig ned gennem listen:

  • En bot-challenge eller en WAF-regel. Cloudflare Bot Fight Mode, AWS WAF managed rules og de fleste »under attack«-indstillinger sender en JavaScript-mellemside med 403 eller 503 til enhver klient, der ikke kører scripts. Det gør Baidus henter ikke. Læg verifikationsstien, eller crawleren, på allowlisten.
  • Geoblokering. Masser af europæiske sites blokerer eller begrænser trafik fra det kinesiske fastland for at dæmme op for scraping. Verifikationshentningen kommer fra netop det område. Sikr dig, at intet i kanten smider den væk.
  • User agent'en bliver filtreret fra. Crawleren melder sig som Baiduspider. Nogle sikkerhedsstakke opfatter ukendte crawlerstrenge som scrapere. Vil du bekræfte, at en forespørgsel er ægte, før du slipper den ind: reverse DNS på kilde-IP'en slår op på *.baidu.com eller *.baidu.jp, og det fremadrettede opslag skal stemme overens.
  • robots.txt blokerer den. Et Disallow: / under en wildcard-user-agent, eller en eksplicit User-agent: Baiduspider-blok, som en anden har efterladt, standser hentningen, før den går i gang.
  • Et TLS-problem, browsere skjuler. Et manglende mellemcertifikat repareres stiltiende af desktopbrowsere og ikke af simple hentere. Kør dit domæne gennem en ekstern TLS-tjekker i stedet for at stole på en grøn hængelås.
  • At verificere den forkerte origin. Filen ligger på www.example.com, mens propertyen i Baidu står som example.com. Ingen fejlmeddelelse fortæller dig det.
  • Langsom første byte. Servere i Europa uden kinesisk tilstedeværelse svarer langsomt på en forespørgsel fra Beijing, og en kold serverless-opstart oven i det kan overskride timeouten for hentningen. Det hjælper faktisk at prøve igen på et andet tidspunkt af døgnet.

Hvilken metode du skal vælge

Læg en statisk fil ud, hvis du har en build-pipeline: den er sværest at ødelægge undervejs og nemmest at teste. Tag meta-tagget, hvis du lever i et CMS, og dine sider er serverrenderede. Tag CNAME'en, hvis du slet ikke kan røre sitet, eller hvis du vil have ejerskabet bevist på domæneniveau én gang og aldrig røre det igen.

Uanset hvad du vælger: lad det blive stående permanent, og skriv det ind i dine infrastrukturnoter ved siden af dine øvrige DNS-poster. Den, der om atten måneder sletter en mystisk fil, er dig selv.

Det, metoderne ikke løser

Alle tre metoder forudsætter, at du allerede er logget ind på en Baidu-konto. Registreringen bekræftes med SMS til et mobilnummer fra det kinesiske fastland, og for mange properties beder Baidu desuden om identitetsbekræftelse (实名认证) mod et kinesisk nationalt ID eller en kinesisk virksomhedslicens. En virksomhed i Frankfurt eller Manchester med en fejlfrit opsat DNS-zone kommer stadig ikke frem til verifikationsbilledet.

Det er der, vores Baidu-anmeldelsesydelse kommer ind. Du peger os på domænet, gennemfører ét tjek af domæneejerskabet i din ende, og vi kører anmeldelsen og rapporterer, hvad Baidu reelt indekserede, til fast pris pr. domæne. Intet kinesisk telefonnummer, intet kinesisk selskab, ingen egen Baidu-konto.

Vil du have det store billede først, dækker den komplette guide til Baidu-anmeldelse sitemaps, push-API'et og hvad Baidus rangering rent faktisk belønner. Vil du hellere tale om det, book et opkald.

Ydelse

Vi kan klare det hele for dig

Dokumentation for domæneejerskab, indsendelse af sitemap og URL'er samt en indekseringsrapport efter to uger. Ét domæne, fast pris, uden kinesisk telefonnummer, kinesisk selskab eller egen Baidu-konto.

Se ydelsen Baidu-registrering
← Back to All Articles