Verifica del sito su Baidu: il file HTML, il meta tag e il record CNAME

Le hanno affidato un progetto su Baidu e la prima cosa che si mette di traverso è una schermata di verifica. Baidu non accetta sitemap, non apre i suoi report di indicizzazione e non consente di inviare nemmeno un URL finché non ha la certezza che il dominio sia suo. I modi per dimostrarlo sono tre, si comportano in maniera diversa e i loro modi di fallire non somigliano a quelli noti di Google Search Console.

Di seguito il dettaglio implementativo di ciascun metodo, i motivi per cui la verifica di solito fallisce e come controllarli uno per uno da terminale.

Dove si colloca la verifica

Lo strumento per webmaster di Baidu è la Baidu Search Resource Platform (百度搜索资源平台), all'indirizzo ziyuan.baidu.com, che molti continuano a chiamare Baidu Zhanzhang. Si aggiunge un sito, si sceglie un metodo di verifica e Baidu recupera qualcosa dal dominio per confermare che sia sotto il suo controllo. Solo a quel punto si sbloccano l'invio dei link, il caricamento della sitemap e la diagnostica di scansione.

Due aspetti del modello di proprietà traggono in inganno ancora prima della scelta del metodo:

Il protocollo e l'host fanno parte dell'identità. https://example.com e https://www.example.com per Baidu sono due siti diversi, e lo stesso vale per le versioni in http://. Aggiunga esattamente l'origine che usano i suoi URL canonici. Se verifica quella sbagliata, tutto ciò che invia in seguito si riferisce a una proprietà che non porta nulla del suo traffico.
La richiesta parte dalla Cina continentale. Ciò che dimostra la proprietà deve essere raggiungibile da lì, sulla rete pubblica, senza una pagina di controllo davanti. Questo singolo fatto spiega gran parte dei fallimenti elencati in fondo all'articolo.

Prima di tutto questo, però, serve un account. Un account Baidu è indispensabile anche solo per arrivare alla schermata di verifica, e la registrazione passa da una conferma via SMS su un numero di cellulare della Cina continentale. Per un'azienda europea o britannica è un muro vero, e conviene saperlo prima di passare un pomeriggio sul DNS. Ci torniamo alla fine.

Metodo 1: il file di verifica HTML

Il metodo più diffuso, e quello da preferire ogni volta che è possibile pubblicare un file statico.

Baidu genera un file per il suo sito e lo mette a disposizione per il download. Il nome ha questo aspetto:

baidu_verify_codeva-XXXXXXXXXX.html

Alle proprietà più vecchie sono stati assegnati nomi nella forma baidu_verify_XXXXXXXXXX.html, e alcuni pannelli mostrano il prefisso code- al posto di codeva-. Non provi a ricostruire il nome o il token partendo da un post di blog: scarichi il file che Baidu le fornisce, oppure copi la stringa dal pannello carattere per carattere. Il contenuto del file è breve, di norma il token e nient'altro.

Deve essere servito dalla radice dell'origine che ha registrato:

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

Non in una sottocartella, non dietro un prefisso di lingua, non su un altro host.

Dove mettere il file, stack per stack

| Stack | Posizione | | --- | --- | | Vite, Create React App, SvelteKit (static), Nuxt | public/ o static/ nella radice del progetto | | Next.js (entrambi i router) | public/ | | Hugo, Astro | rispettivamente static/ e public/ | | Laravel | public/ | | Django | una cartella static/ raccolta da collectstatic, oppure servita direttamente da nginx | | ASP.NET Core | wwwroot/ | | WordPress | la radice web accanto a wp-config.php, via SFTP | | nginx o Apache puri | la document root |

Lo controlli come farà Baidu

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

Quello che serve è un HTTP/2 200, un content-type pari a text/html, nessun header location e un corpo che sia esattamente il token. Tre esiti indicano che non ha ancora finito:

Un 301 o un 302. Qualcosa sta normalizzando il percorso, quasi sempre una regola sulla barra finale o un redirect di lingua che manda ogni percorso non riconosciuto su /en/.... Aggiunga un'eccezione prima della regola generica.
Un 200 che restituisce il guscio dell'applicazione. È di gran lunga il falso successo più comune. Una single page application con una rotta catch-all risponde a qualsiasi percorso con index.html e stato 200, quindi il file «esiste», ma il corpo è il suo markup React. Baidu legge il corpo, non trova il token e rifiuta. Serva il file statico prima del fallback della SPA.
Un 404 che resta anche dopo il deploy. Di solito è una CDN che ha messo in cache la risposta negativa. Faccia la purge di quel percorso preciso, poi ricontrolli con curl -H 'Cache-Control: no-cache'.

Dopo la verifica lasci il file nel repository. Baidu ricontrolla la proprietà a intervalli regolari, e un sito che perde il proprio file di verifica sparisce dal pannello senza alcun preavviso.

Metodo 2: il meta tag HTML

Da usare quando può modificare i template ma non depositare file nella radice web, che è la situazione tipica su un CMS gestito o su un hosting di piattaforma.

Baidu fornisce un tag di questa forma, da inserire nel <head> della homepage:

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

L'attributo name è sempre baidu-site-verification, scritto esattamente così, trattini compresi. Il valore di content è il token che compare nel pannello.

A decidere se funziona sono tre regole:

Deve stare dentro <head>. Un parser che lo trova nel <body> considera l'head già chiuso. Tutto ciò che viene iniettato dopo il primo elemento fuori dall'head arriva troppo tardi.
Deve essere nell'HTML che invia il server. Apra view-source: oppure, meglio, lanci curl -sS https://example.com | grep baidu-site-verification. Se il tag compare solo nell'ispettore degli elementi dei DevTools, lo ha aggiunto JavaScript dopo l'idratazione e non vale. È questo a far fallire il metodo sulle applicazioni React e Vue renderizzate lato client, ed è il motivo per cui su una SPA il file è più semplice.
Deve sopravvivere al framework. I gestori dell'head deduplicano e ripuliscono. Next.js lo vuole nell'export dei metadata, non in un <meta> sparso dentro un componente. React Helmet scarta i tag renderizzati fuori dal suo provider. Alcuni plugin di sicurezza per CMS rimuovono i meta tag con nomi sconosciuti. Un tag manager non può inserirlo, perché gira lato client.

Posizionamento per framework:

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

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

Su un sito renderizzato lato server lo metta nel template di base, accanto ai tag di charset e viewport, e non ci pensi più. Su Hugo è layouts/_default/baseof.html; su Django, il template base da cui derivano tutte le pagine.

Metodo 3: il record CNAME

Il metodo DNS è quello giusto quando non può pubblicare nulla, quando il sito sta dietro un apparato che non controlla, oppure quando vuole che il controllo sopravviva a ogni deploy futuro. Dimostra inoltre il controllo dell'intero dominio, non di un singolo documento.

Baidu le indica un'etichetta host casuale da creare sotto il suo dominio, puntata su Baidu:

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

Nella maggior parte dei pannelli DNS si inserisce solo l'etichetta di sinistra, perché la zona è sottintesa:

| Campo | Valore | | --- | --- | | Tipo | CNAME | | Nome / Host | abcdef123456 | | Valore / Destinazione | ziyuan.baidu.com | | TTL | 3600, o il valore più basso consentito dal pannello durante i test |

Qui ci sono quattro errori che si ripresentano di continuo:

Il dominio viene aggiunto due volte. Scrivere abcdef123456.example.com in un pannello che sottintende già la zona produce abcdef123456.example.com.example.com. Se dopo il salvataggio il pannello mostra il nome completo, lo rilegga.
Il punto finale sulla destinazione. In un file di zona grezzo, ziyuan.baidu.com senza il punto finale viene interpretato relativamente alla zona e diventa ziyuan.baidu.com.example.com. I pannelli se ne occupano al posto suo; named e i file Terraform no.
Un proxy davanti al record. Su Cloudflare un record con proxy attivo (nuvoletta arancione) dall'esterno non si risolve più come CNAME: la risposta autoritativa diventa quella dei record A di Cloudflare. Imposti il record di verifica su DNS only.
Aspettare meno del TTL. Se un resolver ha già in cache una risposta negativa per quel nome, vale il vecchio TTL. Verifichi che cosa vede davvero il resto del mondo, non che cosa dice il suo pannello.

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

dig +short @8.8.8.8 abcdef123456.example.com CNAME

Lasci il record dov'è. Cancellarlo dopo una verifica riuscita significa preparare il terreno a un fallimento della riverifica successiva.

Perché la verifica fallisce anche quando la configurazione sembra corretta

Ha fatto il curl sul file, risponde 200, e Baidu continua a dire di no. Scorra questo elenco:

Un controllo anti-bot o una regola WAF. Il Bot Fight Mode di Cloudflare, le regole gestite di AWS WAF e quasi tutte le impostazioni «under attack» restituiscono una pagina intermedia in JavaScript, con un 403 o un 503, a qualsiasi client che non esegua script. Il fetcher di Baidu non li esegue. Metta in allowlist il percorso di verifica, oppure il crawler.
Il blocco geografico. Molti siti europei bloccano o limitano il traffico dalla Cina continentale per arginare lo scraping. La richiesta di verifica arriva esattamente da quell'intervallo. Controlli che sul perimetro non ci sia nulla che la scarti.
Lo user agent viene filtrato. Il crawler si identifica come Baiduspider. Alcuni stack di sicurezza trattano le stringhe di crawler sconosciute come scraper. Se vuole confermare che una richiesta sia autentica prima di autorizzarla, il DNS inverso dell'IP di origine risolve in *.baidu.com o *.baidu.jp, e la risoluzione diretta deve corrispondere.
robots.txt lo blocca. Un Disallow: / sotto uno user-agent jolly, o un blocco esplicito User-agent: Baiduspider lasciato lì da qualcun altro, ferma la richiesta prima ancora che parta.
Un problema TLS che i browser nascondono. Un certificato intermedio mancante viene riparato in silenzio dai browser desktop, non da un semplice client HTTP. Passi il dominio in un servizio esterno di controllo TLS invece di fidarsi del lucchetto verde.
Verificare l'origine sbagliata. Il file sta su www.example.com, mentre la proprietà su Baidu dice example.com. Nel messaggio di errore non c'è nulla che glielo faccia capire.
Primo byte lento. I server europei senza presenza in Cina rispondono lentamente a una richiesta che arriva da Pechino, e un cold start serverless sopra a questo può superare il timeout della richiesta. Riprovare a un altro orario aiuta davvero.

Quale metodo scegliere

Pubblichi un file statico se ha una pipeline di build: è la soluzione che ha meno probabilità di essere rovinata per strada e la più facile da testare. Scelga il meta tag se lavora dentro un CMS e le sue pagine sono renderizzate lato server. Scelga il CNAME se non può toccare il sito, oppure se vuole che la proprietà sia dimostrata a livello di dominio una volta e non se ne parli più.

Qualunque sia la scelta, la lasci in piedi in modo permanente e la annoti nella documentazione della sua infrastruttura, accanto agli altri record DNS. La persona che fra diciotto mesi cancellerà un file misterioso sarà lei.

Quello che questi metodi non risolvono

Tutti e tre i metodi danno per scontato che lei abbia già effettuato l'accesso a un account Baidu. La registrazione viene confermata via SMS su un numero di cellulare della Cina continentale e, per molte proprietà, Baidu chiede anche una verifica dell'identità reale (实名认证) con un documento d'identità cinese o una licenza commerciale cinese. Un'azienda di Francoforte o di Manchester, con una zona DNS configurata alla perfezione, alla schermata di verifica non ci arriva comunque.

È qui che entra in gioco il nostro servizio di sottomissione a Baidu. Lei ci indica il dominio, completa una sola verifica di proprietà dalla sua parte, e noi curiamo la sottomissione e le riferiamo che cosa Baidu ha effettivamente indicizzato, a un prezzo fisso per dominio. Nessun numero di telefono cinese, nessuna entità cinese, nessun account Baidu suo.

Se preferisce prima il quadro generale, la guida completa alla sottomissione a Baidu tratta le sitemap, l'API di push e che cosa premia davvero il ranking di Baidu. Se invece preferisce parlarne a voce, prenoti una call.