Tulajdonjog igazolása a Baidu-nál: HTML-fájl, meta címke és CNAME

Kapott egy Baidu-feladatot, és rögtön az első akadály egy hitelesítési képernyő. A Baidu addig nem fogad el oldaltérképet, nem nyitja meg az indexelési jelentéseket, és egyetlen URL beküldését sem engedi, amíg meg nem győződik róla, hogy a domain valóban Öné. Három módon lehet ezt igazolni, mindhárom máshogy viselkedik, és a hibák sem azok, amelyeket a Google Search Console-ból ismer.

Az alábbiakban mindhárom módszer megvalósítása következik, azzal együtt, hogy a hitelesítés miért szokott elbukni, és hogyan ellenőrizheti mindegyiket terminálból.

Hol helyezkedik el a hitelesítés

A Baidu webmestereszköze a Baidu Search Resource Platform (百度搜索资源平台) a ziyuan.baidu.com címen, amelyet a mai napig többnyire Baidu Zhanzhang néven emlegetnek. Felvesz egy webhelyet, választ egy hitelesítési módszert, a Baidu pedig letölt valamit a domainjéről, hogy meggyőződjön róla: Ön rendelkezik felette. Csak ezután nyílik meg a linkbeküldés, az oldaltérkép feltöltése és a bejárási diagnosztika.

A webhelyek azonosításának módjában két dolog buktatja meg az embert még a módszer kiválasztása előtt:

A protokoll és a hosztnév az azonosító része. A https://example.com és a https://www.example.com a Baidu szemében két különböző webhely, és ugyanez igaz a http:// változataikra. Pontosan azt az origint vegye fel, amelyet a kanonikus URL-jei használnak. Ha rosszul választ, minden későbbi beküldése egy olyan tulajdonhoz tartozik, amelyre egyetlen látogatója sem érkezik.
A lekérés a kínai szárazföldről érkezik. Aminek a tulajdonjogot igazolnia kell, annak onnan is elérhetőnek kell lennie, a nyílt interneten, ellenőrző oldal nélkül. Ez az egyetlen tény magyarázza a cikk végén felsorolt hibák többségét.

Mindezek előtt azonban ott a fiók. Baidu-fiók nélkül a hitelesítési képernyőig sem jut el, a regisztrációt pedig kínai szárazföldi mobilszámra küldött SMS erősíti meg. Egy európai vagy egyesült királyságbeli cégnek ez valódi fal, és jobb tudni róla, mielőtt egy egész délutánt a DNS-re fordít. A végén bővebben is szó lesz róla.

1. módszer: a HTML hitelesítő fájl

A leggyakoribb megoldás, és ha statikus fájlt tud kitenni, érdemes ezt választani.

A Baidu létrehoz egy fájlt a webhelyéhez, és letöltésre kínálja. A neve így néz ki:

baidu_verify_codeva-XXXXXXXXXX.html

A régebbi tulajdonok baidu_verify_XXXXXXXXXX.html alakú nevet kaptak, és egyes felületeken codeva- helyett code- előtag szerepel. Ne próbálja meg blogbejegyzés alapján kikövetkeztetni sem a nevet, sem a tokent: töltse le a Baidu által adott fájlt, vagy másolja ki a karakterláncot a felületről, betűhíven. A fájl tartalma rövid, jellemzően maga a token és semmi más.

A fájlt a regisztrált origin gyökeréből kell kiszolgálni:

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

Nem alkönyvtárból, nem nyelvi előtag mögül, és nem másik hosztról.

Hová kerül a fájl az egyes rendszerekben

| Rendszer | Hely | | --- | --- | | Vite, Create React App, SvelteKit (static), Nuxt | public/ vagy static/ a projekt gyökerében | | Next.js (mindkét router esetén) | public/ | | Hugo, Astro | static/, illetve public/ | | Laravel | public/ | | Django | a collectstatic által összegyűjtött static/ könyvtár, vagy közvetlenül az nginx szolgálja ki | | ASP.NET Core | wwwroot/ | | WordPress | a webgyökér a wp-config.php mellett, SFTP-n keresztül | | Sima nginx vagy Apache | a dokumentumgyökér |

Ellenőrizze úgy, ahogy a Baidu fogja

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

HTTP/2 200 a jó válasz, text/html értékű content-type fejléccel, location fejléc nélkül, a törzsben pedig pontosan a tokennel. Három eredmény jelzi, hogy még nincs kész:

301-es vagy 302-es válasz. Valami átírja az útvonalat, jellemzően egy záró perjelre vonatkozó szabály vagy egy nyelvi átirányítás, amely minden ismeretlen útvonalat a /en/... alá küld. Vegyen fel kivételt a gyűjtőszabály elé.
200-as válasz az alkalmazás vázával. Messze ez a leggyakoribb hamis siker. Az egyoldalas alkalmazás gyűjtőútvonala minden kérésre az index.html fájllal és 200-as státusszal felel, így a fájl „létezik”, a törzse viszont az Ön React kódja. A Baidu a törzset olvassa, nem talál tokent, és elutasítja. A statikus fájlt az SPA tartalék útvonala elé kell sorolni.
404, amely a telepítés után is megmarad. Rendszerint egy CDN őrzi a gyorsítótárban a nemleges választ. Ürítse ki pontosan azt az útvonalat, majd ellenőrizze újra a curl -H 'Cache-Control: no-cache' paranccsal.

A fájlt utána is hagyja a repóban. A Baidu időnként újraellenőrzi a tulajdonjogot, és amelyik webhelyről eltűnik a hitelesítő fájl, az szó nélkül kiesik a felületről.

2. módszer: a HTML meta címke

Akkor válassza ezt, ha sablonokat tud szerkeszteni, de fájlt nem tud a webgyökérbe tenni: felügyelt CMS-en vagy platformszolgáltatónál ez a megszokott helyzet.

A Baidu ilyen alakú címkét ad, a kezdőlap <head> szekciójába:

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

A name attribútum értéke mindig baidu-site-verification, pontosan így leírva, kötőjelekkel együtt. A content értéke a felületen látható token.

Három szabályon múlik, hogy működik-e:

A <head> szekción belül kell lennie. Ha az elemző a <body>-ban találja meg, a fejlécet addigra lezártnak tekinti. Az első nem fejléc-elem után beszúrt bármi már késő.
Benne kell lennie a szerver által küldött HTML-ben. Nyissa meg a view-source: nézetet, vagy ami még jobb: curl -sS https://example.com | grep baidu-site-verification. Ha a címke csak a DevTools elemvizsgálójában látszik, akkor a hidratálás után tette oda a JavaScript, és nem számít. Kliensoldalon renderelt React és Vue alkalmazásoknál pontosan ez a buktató, és ezért egyszerűbb egy SPA esetén a fájlos módszer.
Túl kell élnie a keretrendszert. A fejléckezelők deduplikálnak és szűrnek. A Next.js a metadata exportban szeretné látni, nem elszórt <meta> elemként valamelyik komponensben. A React Helmet eldobja a providerén kívül renderelt címkéket. Egyes CMS biztonsági bővítmények kiszedik az ismeretlen nevű meta címkéket. Címkekezelővel pedig nem lehet kitenni, mert a címkekezelő kliensoldalon fut.

Elhelyezés keretrendszerenként:

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

// WordPress, egy gyerektéma functions.php fájlja
add_action('wp_head', function () {
  echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);

Szerveroldalon renderelt webhelyen tegye az alapsablonba, a charset és a viewport címke mellé, aztán felejtse el. Hugo esetében ez a layouts/_default/baseof.html; Django-nál az a sablon, amelyből minden oldal származik.

3. módszer: a CNAME rekord

A DNS-módszer akkor jön szóba, ha egyáltalán nem tud telepíteni, ha a webhely olyan eszköz mögött van, amelyhez nem fér hozzá, vagy ha azt szeretné, hogy az ellenőrzés minden jövőbeli újratelepítést túléljen. Ráadásul nem egyetlen dokumentum, hanem az egész domain feletti rendelkezést igazolja.

A Baidu megad egy véletlenszerű hosztcímkét, amelyet a domainje alatt kell létrehoznia, a Baidu felé mutatva:

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

A legtöbb DNS-felületen csak a bal oldali címkét kell beírni, mert a zóna adódik:

| Mező | Érték | | --- | --- | | Típus | CNAME | | Név / Host | abcdef123456 | | Érték / Cél | ziyuan.baidu.com | | TTL | 3600, vagy a teszteléshez a felület által engedett legalacsonyabb érték |

Négy hiba fordul elő újra meg újra:

A domain kétszer kerül a névbe. Ha olyan felületre írja be az abcdef123456.example.com nevet, amely a zónát magától hozzáteszi, abcdef123456.example.com.example.com lesz belőle. Ha a felület mentés után kiírja a teljes nevet, olvassa vissza.
A cél végén álló pont. Nyers zónafájlban a záró pont nélküli ziyuan.baidu.com a zónához képest értelmeződik, és ziyuan.baidu.com.example.com lesz belőle. A webes felületek ezt elintézik Ön helyett; a named és a Terraform-fájlok nem.
Proxy a rekord előtt. Cloudflare-nél a proxyzott (narancssárga felhővel jelölt) rekord kívülről már nem CNAME-ként oldódik fel: a hiteles válasz a Cloudflare A rekordja lesz. A hitelesítő rekordot állítsa DNS only módba.
A TTL-nél rövidebb várakozás. Ha egy feloldó már eltárolt egy nemleges választ arra a névre, a régi TTL érvényes. Azt nézze, mit lát a külvilág, ne azt, mit ír a felület.

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

dig +short @8.8.8.8 abcdef123456.example.com CNAME

A rekordot hagyja a helyén. Ha sikeres ellenőrzés után törli, egy későbbi újrahitelesítés fog elbukni rajta.

Miért bukik el a hitelesítés, amikor a beállítás rendben van

Lekérte curl-lel a fájlt, 200-as választ kap, a Baidu mégis nemet mond. Menjen végig ezen a listán:

Botellenőrzés vagy WAF-szabály. A Cloudflare Bot Fight Mode, az AWS WAF felügyelt szabályai és a legtöbb „támadás alatt” beállítás JavaScript-alapú közbeékelt oldalt ad vissza 403-as vagy 503-as státusszal minden kliensnek, amely nem futtat szkriptet. A Baidu lekérője nem futtat. Engedélyezze a hitelesítési útvonalat vagy magát a robotot.
Országalapú tiltás. Sok európai webhely tiltja vagy korlátozza a kínai szárazföldi forgalmat, hogy visszafogja a tartalomlehalászást. A hitelesítési lekérés pontosan onnan érkezik. Győződjön meg róla, hogy a peremhálózaton semmi nem dobja el.
Szűrt user agent. A robot Baiduspider néven azonosítja magát. Egyes biztonsági rendszerek az ismeretlen robotneveket lehalászónak tekintik. Ha engedélyezés előtt meg akar bizonyosodni a kérés valódiságáról: a forrás IP-cím fordított DNS-neve *.baidu.com vagy *.baidu.jp alá esik, és az előre irányuló feloldásnak vissza kell adnia ugyanazt a címet.
A robots.txt tiltja. Egy Disallow: / a wildcard user-agent alatt, vagy egy valaki más által otthagyott User-agent: Baiduspider blokk már azelőtt elvágja a lekérést, hogy elindulna.
TLS-hiba, amelyet a böngésző elrejt. A hiányzó köztes tanúsítványt az asztali böngészők csendben pótolják, az egyszerű lekérők nem. Futtassa át a domaint egy külső TLS-ellenőrzőn, ne a zöld lakatban bízzon.
Rossz origint hitelesít. A fájl a www.example.com címen van, a Baidu-ban felvett tulajdon pedig example.com. A hibaüzenetből erre soha nem fog rájönni.
Lassú első bájt. A kínai jelenlét nélküli európai szerverek lassan válaszolnak egy pekingi kérésre, és ha ehhez még egy serverless hidegindulás is társul, az túllépheti a lekérési időkorlátot. Egy másik napszakban tett újabb próbálkozás tényleg segít.

Melyik módszert válassza

Ha van build folyamata, telepítsen statikus fájlt: ezt rontja el a legkevesebb dolog, és ezt a legkönnyebb tesztelni. A meta címke akkor jó, ha CMS-ben dolgozik, és az oldalai szerveroldalon renderelődnek. A CNAME akkor, ha egyáltalán nem nyúlhat a webhelyhez, vagy ha a tulajdonjogot domain szinten szeretné egyszer igazolni, és soha többé nem foglalkozni vele.

Bármelyiket választja, hagyja a helyén véglegesen, és írja be az infrastruktúra jegyzetei közé, a többi DNS-rekord mellé. Aki tizennyolc hónap múlva törölni akar majd egy rejtélyes fájlt, az Ön lesz.

Amit ezek a módszerek nem oldanak meg

Mindhárom módszer abból indul ki, hogy már be van jelentkezve egy Baidu-fiókba. A regisztrációt kínai szárazföldi mobilszámra küldött SMS erősíti meg, és sok tulajdon esetében a Baidu valós személyazonosítást (实名认证) is kér kínai személyi igazolvánnyal vagy kínai cégbejegyzéssel. Egy frankfurti vagy manchesteri cég a tökéletesen beállított DNS-zónájával együtt sem jut el a hitelesítési képernyőig.

Itt jön képbe a Baidu beküldési szolgáltatásunk. Megadja nekünk a domaint, elvégez egy domain-tulajdonjogi ellenőrzést a saját oldalán, mi pedig lebonyolítjuk a beküldést, és jelentjük, mit indexelt ténylegesen a Baidu, domainenként fix díjért. Nincs szüksége kínai telefonszámra, kínai cégre vagy saját Baidu-fiókra.

Ha előbb a nagyobb képre kíváncsi, a teljes Baidu beküldési útmutató végigveszi az oldaltérképeket, a push API-t és azt, amit a Baidu rangsorolása valójában díjaz. Ha inkább beszélne róla valakivel, foglaljon egy hívást.