Verificação de sites no Baidu: os métodos do ficheiro HTML e da meta tag, e o que aconteceu ao CNAME

Alguém lhe passou uma tarefa do Baidu e a primeira coisa que lhe aparece pela frente é um ecrã de verificação. O Baidu não aceita um sitemap, não abre os relatórios de indexação e não o deixa enviar um único URL enquanto não tiver a certeza de que o domínio é seu. Hoje há dois métodos para o provar. Comportam-se de forma diferente, e as falhas não são as que conhece do Google Search Console. O terceiro método, que a maioria dos guias ainda descreve, um registo CNAME, está suspenso desde janeiro de 2023.

Este artigo trata dos pormenores de implementação dos dois métodos que funcionam, do que a suspensão do CNAME significa se o usou antes e das razões por que a verificação costuma falhar, com a forma de verificar cada uma a partir de um terminal.

Onde fica a verificação

O produto do Baidu para webmasters é a Baidu Search Resource Platform (百度搜索资源平台), em ziyuan.baidu.com, ainda muito conhecida por Baidu Zhanzhang. Adiciona um site, escolhe um método de verificação, e o Baidu obtém algo a partir do seu domínio para confirmar que o controla. Só então ficam disponíveis a submissão de links, o carregamento do sitemap e os diagnósticos de rastreio.

Há duas coisas no modelo de propriedades que apanham as pessoas desprevenidas antes mesmo de escolherem um método:

• O protocolo e o host fazem parte da identidade. https://example.com e https://www.example.com são dois sites diferentes aos olhos do Baidu, e as versões http:// também. Adicione a origem exata que os seus URLs canónicos usam. Se verificar a errada, tudo o que submeter depois diz respeito a uma propriedade que não recebe nenhum do seu tráfego.
• O pedido vem da China continental. O que quer que prove a propriedade tem de estar acessível a partir de lá, pela Internet pública, sem uma página de desafio à frente. Este facto, por si só, explica a maior parte das falhas descritas no fim deste artigo.

Antes de tudo isto, há uma conta. Sem uma conta Baidu nem sequer se chega ao ecrã de verificação, e o registo depende de uma confirmação por SMS num número de telemóvel da China continental. Para uma empresa na Europa ou no Reino Unido, é um muro a sério, e convém sabê-lo antes de passar uma tarde a mexer em modelos e implementações. Voltamos a isto no fim.

Método 1: o ficheiro de verificação HTML

É o método mais comum e o preferível quando consegue publicar um ficheiro estático.

O Baidu gera um ficheiro para o seu site e disponibiliza-o para descarregar. O nome é deste género:

baidu_verify_codeva-XXXXXXXXXX.html

As propriedades mais antigas receberam nomes no formato baidu_verify_XXXXXXXXXX.html, e alguns painéis mostram um prefixo code- em vez de codeva-. Não tente reconstruir o nome ou o token a partir de um artigo de blogue: descarregue o ficheiro que o Baidu lhe dá, ou copie a string do painel carácter a carácter. O conteúdo do ficheiro é curto, normalmente o próprio token e mais nada.

Tem de ser servido a partir da raiz da origem que registou:

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

Não numa subpasta, não atrás de um prefixo de idioma, não noutro host.

Onde colocar o ficheiro, consoante a stack

Verifique-o como o Baidu o fará

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

O que quer ver é HTTP/2 200, um content-type de text/html, nenhum cabeçalho location e um conteúdo que seja exatamente o token. Há três resultados que significam que ainda não acabou:

• Um 301 ou 302. Há alguma coisa a normalizar o caminho, quase sempre uma regra de barra final ou um redirecionamento de idioma que envia todos os caminhos sem correspondência para /en/.... Acrescente uma exceção antes da regra genérica.
• Um 200 que devolve a estrutura da sua aplicação. É, de longe, o falso positivo mais comum. Uma aplicação de página única com uma rota genérica responde a todos os caminhos com o index.html e o estado 200, por isso o ficheiro «existe», mas o conteúdo é o seu markup React. O Baidu lê o conteúdo, não encontra o token e rejeita-o. Sirva o ficheiro estático antes do fallback da SPA.
• Um 404 que persiste depois da implementação. Normalmente é uma CDN que guardou em cache a resposta negativa. Limpe a cache desse caminho exato e volte a verificar com curl -H 'Cache-Control: no-cache'.

Depois, mantenha o ficheiro no repositório. O Baidu volta a verificar a propriedade periodicamente, e um site que perde o ficheiro de verificação desaparece do painel sem aviso.

Método 2: a meta tag HTML

Use-o quando pode editar modelos mas não pode colocar ficheiros na raiz web, que é a situação normal num CMS gerido ou numa plataforma de alojamento.

O Baidu dá-lhe uma tag deste tipo, para colocar no <head> da página inicial:

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

O atributo name é sempre baidu-site-verification, escrito exatamente assim, com os hífenes. O valor de content é o token do painel.

Há três regras que decidem se funciona:

1. Tem de estar dentro do <head>. Um parser que a encontre no <body> considera o head já fechado. O que for injetado depois do primeiro elemento que não pertence ao head chega tarde demais.
2. Tem de estar no HTML que o servidor envia. Abra o view-source: ou, melhor ainda, curl -sS https://example.com | grep baidu-site-verification. Se a tag só aparece no inspetor de elementos das DevTools, foi acrescentada por JavaScript depois da hidratação, e não conta. É isto que a estraga nas aplicações React e Vue renderizadas no cliente, e é por isso que o método do ficheiro é mais fácil numa SPA.
3. Tem de sobreviver à framework. Os gestores de head eliminam duplicados e higienizam o conteúdo. O Next.js quer a tag no export de metadata, e não num <meta> solto dentro de um componente. O React Helmet descarta as tags renderizadas fora do seu provider. Alguns plugins de segurança de CMS removem meta tags com nomes desconhecidos. Um gestor de tags não a consegue colocar, porque corre do lado do cliente.

Colocação específica por framework:

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

Num site renderizado no servidor, coloque-a no modelo base, ao lado das tags de charset e de viewport, e esqueça o assunto. No Hugo, é o layouts/_default/baseof.html; no Django, o modelo base de que todas as páginas herdam.

O registo CNAME: suspenso desde janeiro de 2023

Guias mais antigos, incluindo a primeira versão deste, descrevem um terceiro método: um registo CNAME no DNS. A 13 de janeiro de 2023, o Baidu suspendeu a verificação por CNAME (aviso do Baidu) e encaminhou os proprietários de sites para a verificação por ficheiro e por tag HTML. A 10 de outubro de 2026, o Baidu não tinha publicado nenhum aviso a repô-la.

Se um site foi verificado por CNAME antes dessa data, o registo tem este aspeto:

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

Num painel de DNS, aparece assim:

O que a suspensão significa para si:

• Um site novo não o pode usar. O Baidu deixou de aceitar CNAME para um site que ainda não esteja verificado. Use o ficheiro ou a meta tag acima.
• Uma verificação por CNAME já existente mantém-se. O aviso do Baidu diz que os sites já verificados não são afetados.
• Não apague o registo. Se ele desaparecer e a verificação caducar, o aviso remete-o para o ficheiro ou para a meta tag. Recriar o CNAME não a recupera.
• Não ative um proxy à frente dele. No Cloudflare, um registo com proxy (nuvem laranja) deixa de se resolver como CNAME a partir do exterior, por isso uma nova verificação posterior falha. Mantenha o registo de verificação só em DNS.

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

dig +short @8.8.8.8 abcdef123456.example.com CNAME

Se ambos devolverem ziyuan.baidu.com., o registo antigo está intacto. Se a consola mostrar o site como não verificado, volte a verificá-lo com o ficheiro ou com a meta tag em vez de mexer no DNS.

Porque é que a verificação falha quando a configuração parece correta

Já testou o ficheiro com curl, ele devolve 200, e o Baidu continua a dizer que não. Percorra esta lista:

• Um desafio anti-bots ou uma regra de WAF. O Bot Fight Mode do Cloudflare, as regras geridas do AWS WAF e a maioria das definições «under attack» devolvem uma página intermédia em JavaScript, com um 403 ou um 503, a qualquer cliente que não execute scripts. O sistema de obtenção do Baidu não os executa. Coloque o caminho de verificação, ou o crawler, na lista de permissões.
• Bloqueio geográfico. Muitos sites europeus bloqueiam ou limitam o tráfego da China continental para travar o scraping. O pedido de verificação vem exatamente dessa gama. Confirme que nada na periferia da rede o está a descartar.
• O user agent é filtrado. O crawler identifica-se como Baiduspider. Algumas soluções de segurança tratam strings de crawlers desconhecidos como scrapers. Se quiser confirmar que um pedido é genuíno antes de o colocar na lista de permissões, o DNS inverso do IP de origem resolve para *.baidu.com ou *.baidu.jp, e a resolução direta tem de corresponder.
• O robots.txt bloqueia-o. Um Disallow: / sob um user-agent genérico, ou um bloco explícito User-agent: Baiduspider deixado por outra pessoa, trava o pedido antes de começar.
• Um problema de TLS que os navegadores escondem. Um certificado intermédio em falta é corrigido sem aviso pelos navegadores de computador, mas não pelos clientes mais simples. Passe o seu domínio por um verificador de TLS externo em vez de confiar num cadeado verde.
• Verificar a origem errada. O ficheiro está em www.example.com, a propriedade no Baidu diz example.com. A mensagem de erro não lhe vai dizer nada disto.
• Primeiro byte lento. Os servidores na Europa sem presença na China respondem devagar a um pedido vindo de Pequim e, se a isso se juntar um arranque a frio de uma função serverless, pode ultrapassar-se o tempo limite do pedido. Tentar de novo a outra hora ajuda mesmo.

Que método usar

Publique um ficheiro estático se tiver um pipeline de build: é o que tem menos probabilidade de ser estragado e o mais fácil de testar. Opte pela meta tag se vive num CMS e as suas páginas são renderizadas no servidor. Se não puder mexer no site de todo, o DNS já não é alternativa: alguém com acesso à raiz web ou aos modelos tem de colocar um dos dois.

Escolha o que escolher, deixe-o no sítio para sempre e registe-o nas suas notas de infraestrutura. Daqui a dezoito meses, quem vai apagar o ficheiro misterioso é a mesma pessoa que o lá pôs.

O que os métodos não resolvem

Os dois métodos partem do princípio de que já tem sessão iniciada numa conta Baidu. O registo é confirmado por SMS para um número de telemóvel da China continental e, em muitas propriedades, o Baidu pede também a verificação de identidade real (实名认证) com um documento de identificação chinês ou uma licença comercial chinesa. Uma empresa em Frankfurt ou em Manchester, com um ficheiro de verificação perfeitamente publicado, continua sem conseguir chegar ao ecrã de verificação.

É aí que entra o nosso serviço de submissão ao Baidu. Indica-nos o domínio, faz do seu lado uma única verificação de propriedade do domínio, e nós tratamos da submissão, a um preço fixo por domínio. Sem número de telefone chinês, sem entidade chinesa, sem conta Baidu própria. Assim que o domínio estiver verificado, recebe também 12 meses de dados do Baidu Webmaster Tools desse domínio no nosso portal, onde pode acompanhar a indexação e o rastreio e submeter novos URLs por conta própria.

Se quiser primeiro ter uma visão mais ampla, o guia completo de submissão ao Baidu cobre os sitemaps, a API de envio e o que o algoritmo de ordenação do Baidu realmente recompensa. Se preferir falar sobre o assunto, marque uma chamada.