Om ossTjenesterArbeidArtikler
← Back to ArticlesVil du helst slippe å gjøre det selv? Vi melder nettstedet ditt inn til Baidu til fast pris.Se tjenesten for Baidu-registrering →

Baidu-verifisering: HTML-fil, metatag og CNAME

Beijing central business district skyline at dusk

Du har fått en Baidu-oppgave i fanget, og det første som står i veien er et verifiseringsbilde. Baidu tar ikke imot et sitemap, åpner ikke indeksrapportene og lar deg ikke sende inn en eneste URL før selskapet er overbevist om at domenet er ditt. Det finnes tre måter å bevise det på, de oppfører seg ulikt, og feilene du støter på er ikke dem du kjenner fra Google Search Console.

Her er implementasjonsdetaljene for hver metode, sammen med grunnene til at verifiseringen som regel feiler og hvordan du sjekker hver av dem fra terminalen.

Hvor verifiseringen hører hjemme

Baidus verktøy for nettredaktører heter Baidu Search Resource Platform (百度搜索资源平台) og ligger på ziyuan.baidu.com. De fleste kaller det fortsatt Baidu Zhanzhang. Du legger til et nettsted, velger en verifiseringsmetode, og Baidu henter noe fra domenet ditt for å bekrefte at du har kontroll. Først da åpner lenkeinnsending, opplasting av sitemap og crawl-diagnostikken seg.

To ting ved måten Baidu definerer et nettsted på lurer folk før de i det hele tatt har valgt metode:

  • Protokollen og verten er en del av identiteten. https://example.com og https://www.example.com er to forskjellige nettsteder for Baidu, og det samme gjelder http://-versjonene. Legg inn nøyaktig det origin de kanoniske URL-ene dine bruker. Verifiserer du feil variant, peker alt du sender inn etterpå mot en eiendom som ikke har noe av trafikken din.
  • Hentingen kommer fra fastlands-Kina. Det som beviser eierskap må være tilgjengelig derfra, over det åpne internett, uten en utfordringsside foran seg. Det ene faktumet forklarer de fleste feilene nederst i denne artikkelen.

Før noe av dette kommer kontoen. Du trenger en Baidu-konto bare for å komme fram til verifiseringsbildet, og registreringen er knyttet til SMS-bekreftelse på et mobilnummer fra fastlands-Kina. Det er en reell sperre for et selskap i Europa eller Storbritannia, og verdt å vite om før du bruker en hel ettermiddag på DNS. Mer om det til slutt.

Metode 1: HTML-verifiseringsfilen

Den vanligste metoden, og den du bør velge når du kan deploye en statisk fil.

Baidu genererer en fil for nettstedet ditt og lar deg laste den ned. Navnet ser slik ut:

baidu_verify_codeva-XXXXXXXXXX.html

Eldre eiendommer fikk navn på formen baidu_verify_XXXXXXXXXX.html, og enkelte paneler viser prefikset code- i stedet for codeva-. Ikke prøv å rekonstruere navnet eller tokenet fra et blogginnlegg: last ned filen Baidu gir deg, eller kopier strengen ut av panelet tegn for tegn. Innholdet i filen er kort, som regel bare selve tokenet.

Den må serveres fra roten av det origin du registrerte:

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

Ikke i en underkatalog, ikke bak et språkprefiks, ikke på en annen vert.

Hvor filen skal ligge, etter stack

| Stack | Plassering | | --- | --- | | Vite, Create React App, SvelteKit (static), Nuxt | public/ eller static/ i prosjektroten | | Next.js (begge routere) | public/ | | Hugo, Astro | henholdsvis static/ og public/ | | Laravel | public/ | | Django | en static/-katalog som samles med collectstatic, eller serveres direkte av nginx | | ASP.NET Core | wwwroot/ | | WordPress | webroten ved siden av wp-config.php, over SFTP | | Ren nginx eller Apache | dokumentroten |

Sjekk den slik Baidu kommer til å gjøre

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 som er text/html, ingen location-header, og en body som er nøyaktig tokenet. Tre resultater betyr at du ikke er ferdig:

  • En 301 eller 302. Noe normaliserer stien, oftest en regel for skråstrek på slutten eller en språkredirect som sender alle ukjente stier til /en/.... Legg inn et unntak før catch-all-regelen.
  • En 200 som returnerer app-skallet ditt. Dette er den klart vanligste falske godkjenningen. En single page-app med en catch-all-rute svarer på hver eneste sti med index.html og status 200, så filen «finnes», men innholdet er React-markupen din. Baidu leser body, finner ingen token og avviser. Server den statiske filen før SPA-fallbacken.
  • En 404 som henger igjen etter deploy. Som regel en CDN som har cachet det negative svaret. Tøm cachen for akkurat den stien, og sjekk på nytt med curl -H 'Cache-Control: no-cache'.

La filen bli liggende i repoet etterpå. Baidu sjekker eierskapet på nytt med jevne mellomrom, og et nettsted som mister verifiseringsfilen sin forsvinner stille ut av panelet.

Metode 2: HTML-metataggen

Bruk denne når du kan redigere maler, men ikke legge filer i webroten. Det er den normale situasjonen på et driftet CMS eller en plattformtjeneste.

Baidu gir deg en tagg av denne formen, som skal inn i <head> på forsiden:

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

Attributtet name er alltid baidu-site-verification, stavet nøyaktig slik, bindestreker inkludert. Verdien i content er tokenet fra panelet.

Tre regler avgjør om det virker:

  1. Den må ligge inne i <head>. En parser som finner den i <body>, regner head som allerede lukket. Alt som injiseres etter det første elementet utenfor head, kommer for sent.
  2. Den må ligge i HTML-en serveren sender. Åpne view-source:, eller enda bedre: curl -sS https://example.com | grep baidu-site-verification. Hvis taggen bare dukker opp i elementinspektøren i DevTools, ble den lagt til av JavaScript etter hydrering, og da teller den ikke. Det er dette som ryker på klientrendrede React- og Vue-apper, og grunnen til at filmetoden er enklere på en SPA.
  3. Den må overleve rammeverket. Head-håndterere deduplikerer og saniterer. Next.js vil ha den i metadata-eksporten, ikke som en løs <meta> inne i en komponent. React Helmet dropper tagger som rendres utenfor provideren sin. Enkelte sikkerhetsutvidelser i CMS-er fjerner metatagger med ukjente navn. En tag manager kan ikke plassere den, fordi tag manageren kjører på klienten.

Plassering per rammeverk:

// 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 serverrendret nettsted legger du den i basismalen ved siden av charset- og viewport-taggene, og så glemmer du den. På Hugo er det layouts/_default/baseof.html, på Django basismalen alle sider utvider.

Metode 3: CNAME-posten

DNS-metoden er den du velger når du ikke kan deploye i det hele tatt, når nettstedet står bak en boks du ikke kontrollerer, eller når du vil at sjekken skal overleve enhver framtidig utrulling. Den beviser dessuten kontroll over hele domenet, ikke bare over ett dokument.

Baidu viser deg en tilfeldig vertsetikett du skal opprette under domenet ditt, som peker mot Baidu:

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

I de fleste DNS-paneler skriver du bare inn etiketten til venstre, fordi sonen er underforstått:

| Felt | Verdi | | --- | --- | | Type | CNAME | | Navn / Host | abcdef123456 | | Verdi / Mål | ziyuan.baidu.com | | TTL | 3600, eller det laveste panelet tillater mens du tester |

Fire ting går galt her, om og om igjen:

  • Domenet blir lagt på to ganger. Skriver du abcdef123456.example.com i et panel som allerede underforstår sonen, får du abcdef123456.example.com.example.com. Viser panelet det fullt kvalifiserte navnet etter lagring, så les det tilbake.
  • Punktumet på slutten av målet. I en rå sonefil tolkes ziyuan.baidu.com uten avsluttende punktum relativt til sonen og blir ziyuan.baidu.com.example.com. Paneler ordner dette for deg; named og Terraform-filer gjør det ikke.
  • En proxy foran posten. På Cloudflare svarer en proxyet post (oransje sky) ikke lenger som en CNAME utenfra: det autoritative svaret blir Cloudflares A-poster. Sett verifiseringsposten til DNS only.
  • Å vente kortere enn TTL-en. Har en resolver allerede et negativt svar i cache for det navnet, gjelder den gamle TTL-en. Sjekk hva verden faktisk ser, ikke hva panelet ditt sier.
dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.

dig +short @8.8.8.8 abcdef123456.example.com CNAME

La posten stå. Å slette den etter en vellykket sjekk inviterer til en mislykket ny verifisering senere.

Når oppsettet ser riktig ut og verifiseringen likevel feiler

Du har curlet filen, den svarer 200, og Baidu sier fortsatt nei. Gå gjennom denne listen:

  • En botsjekk eller en WAF-regel. Cloudflare Bot Fight Mode, administrerte regler i AWS WAF og de fleste «under angrep»-innstillinger svarer med en JavaScript-mellomside og 403 eller 503 til alt som ikke kjører skript. Baidus henter gjør ikke det. Legg verifiseringsstien, eller crawleren, i tillatelseslisten.
  • Geoblokkering. Mange europeiske nettsteder blokkerer eller struper trafikk fra fastlands-Kina for å bremse skraping. Verifiseringshentingen kommer fra nøyaktig det området. Kontroller at ingenting ute i kanten kaster den.
  • User agent filtreres bort. Crawleren identifiserer seg som Baiduspider. Enkelte sikkerhetsoppsett behandler ukjente crawler-strenger som skrapere. Vil du bekrefte at en forespørsel er ekte før du slipper den inn, gir omvendt DNS på kilde-IP-en *.baidu.com eller *.baidu.jp, og oppslaget forover må stemme.
  • robots.txt blokkerer den. En Disallow: / under en wildcard-user-agent, eller en User-agent: Baiduspider-blokk noen har lagt igjen, stopper hentingen før den begynner.
  • Et TLS-problem nettleseren skjuler. Et manglende mellomsertifikat repareres stille av nettlesere på skrivebordet, men ikke av enkle klienter. Kjør domenet gjennom en ekstern TLS-test i stedet for å stole på en grønn hengelås.
  • Feil origin er verifisert. Filen ligger på www.example.com, mens eiendommen i Baidu sier example.com. Ingenting i feilmeldingen vil fortelle deg det.
  • Treg første byte. Servere i Europa uten noe fotfeste i Kina svarer sakte på en forespørsel fra Beijing, og en kald serverless-start i tillegg kan overskride tidsgrensen for hentingen. Å prøve på nytt på et annet tidspunkt hjelper faktisk.

Hvilken metode du bør velge

Deploy en statisk fil hvis du har en byggepipeline: den er minst utsatt for å bli tuklet med underveis og enklest å teste. Ta metataggen hvis du lever i et CMS og sidene dine rendres på serveren. Ta CNAME-en hvis du ikke får røre nettstedet i det hele tatt, eller hvis du vil ha eierskapet bevist på domenenivå én gang og aldri mer.

Uansett hva du velger: la det stå permanent, og skriv det inn i infrastrukturnotatene ved siden av de andre DNS-postene dine. Den som sletter en mystisk fil om atten måneder, er deg.

Det metodene ikke løser

Alle tre metodene forutsetter at du allerede er logget inn på en Baidu-konto. Registreringen bekreftes med SMS til et mobilnummer fra fastlands-Kina, og for mange eiendommer krever Baidu i tillegg identitetsverifisering (实名认证) mot et kinesisk ID-kort eller en kinesisk bedriftslisens. Et selskap i Frankfurt eller Manchester med en helt riktig satt opp DNS-sone kommer likevel ikke fram til verifiseringsbildet.

Det er der Baidu-innsendingstjenesten vår kommer inn. Du peker oss mot domenet, gjennomfører én eierskapssjekk på din side, og vi kjører innsendingen og rapporterer hva Baidu faktisk indekserte, til en fast pris per domene. Uten kinesisk telefonnummer, uten kinesisk selskap, uten egen Baidu-konto.

Vil du ha det store bildet først, dekker den komplette guiden til innsending hos Baidu sitemaps, push-API-et og hva Baidus rangering faktisk belønner. Vil du heller snakke om det, book en samtale.

Tjeneste

Vi kan ta hele jobben

Dokumentasjon på domeneeierskap, innsending av nettstedskart og URL-er, og en indekseringsrapport etter to uker. Ett domene, fast pris, uten kinesisk telefonnummer, kinesisk selskap eller egen Baidu-konto.

Se tjenesten for Baidu-registrering
← Back to All Articles