Favicon no Google Search: como auditar e corrigir a cadeia de redirecionamentos

Nota da redação: os dois primeiros parágrafos abaixo contêm um erro de data (citam 'setembro de 2026') que é resíduo de uma revisão anterior do texto e não foi removido a tempo. A data correta de atualização da documentação do Google Search Central, confirmada na própria fonte, é 27 de outubro de 2026, como aparece corretamente a partir do terceiro parágrafo e no restante do artigo.

A documentação do Google Search Central sobre favicon foi atualizada em setembro de 2026 e reforça regras que muita cadeia de redirect e CDN mal configurada quebra sem ninguém perceber.

A documentação do Google Search Central sobre favicon foi atualizada em setembro de 2026 e reforça regras que muita cadeia de redirect e CDN mal configurada quebra sem ninguém perceber.

A documentação do Google Search Central sobre favicon foi atualizada em 27 de outubro de 2026 e reforça regras que muita cadeia de redirect e CDN mal configurada quebra sem ninguém perceber.

O que a documentação atualizada reforça

A página oficial do Google Search Central sobre favicon in Search foi atualizada em 27 de outubro de 2026 (UTC). O conteúdo de fundo não é novo, mas vale revisitar porque é exatamente o tipo de regra que quebra em silêncio: ninguém percebe até o ícone sumir do resultado de busca.

As regras que importam para quem audita são quatro. Um host só pode ter um favicon (subdiretório não conta, subdomínio conta como site separado). O arquivo precisa ter pelo menos 8x8 pixels, com 48x48 recomendado. Os formatos aceitos são BMP, GIF, ICO, PNG, JPEG, PPM e TIFF. E a URL do favicon precisa ser estável, sem trocar a cada deploy.

O ponto que costuma passar batido: tanto o Googlebot quanto o Googlebot Image precisam conseguir rastrear o arquivo do favicon e a home page sem bloqueio. É aqui que entra a cadeia de redirecionamentos, e é nela que mora a maior parte dos problemas que vejo em sites brasileiros.

Por que a cadeia de redirects derruba o favicon

Um favicon raramente é servido direto. Na prática, a URL declarada no <link rel="icon"> passa por http para https, depois por www para o domínio raiz (ou o contrário), às vezes cai num subdomínio de CDN e, se o deploy mexeu na estrutura de pastas, pode terminar num 404 que o framework mascara com uma página de erro em 200. Cada um desses saltos é um ponto de falha.

O Googlebot-Image precisa conseguir rastrear o arquivo do favicon, e, segundo a documentação, nenhuma URL da cadeia pode estar bloqueada por robots.txt ou por outros meios. Se o penúltimo salto está num domínio de CDN com robots.txt genérico bloqueando tudo, o favicon nunca chega a ser processado, mesmo que a home page esteja perfeitamente indexável.

Passo 1: confirmar a tag na home

O primeiro passo é visual e rápido: abrir o código-fonte da home (não de uma subpágina) e procurar a tag.

<link rel="icon" href="https://cdn.exemplo.com.br/assets/favicon.ico">

Repare que a URL pode ser relativa ou absoluta, e pode apontar para um host diferente do site, como uma CDN. Isso é permitido pela documentação. O problema não é o host de destino, é se ele responde de forma estável e sem bloqueio.

Passo 2: seguir a cadeia com curl

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Com a URL em mãos, o comando que eu rodo primeiro é o curl -IL, que segue redirects mostrando só os cabeçalhos de cada hop:

curl -IL https://www.exemplo.com.br/favicon.ico

O que eu procuro na saída é a sequência de códigos de status. Uma cadeia saudável tem no máximo um ou dois 301/302 antes de um 200 final. Mais do que isso já é sinal de alerta, porque cada salto extra é uma chance de o Googlebot Image desistir ou cair num domínio bloqueado.

Para ver o caminho completo, incluindo o header Location de cada redirect, uso -v em vez de -I:

curl -v -L https://www.exemplo.com.br/favicon.ico 2>&1 | grep -E "HTTP|Location"

Esse comando lista, em ordem, cada URL intermediária. É aí que aparecem os casos clássicos: http://exemplo.com.br redirecionando para https://www.exemplo.com.br, que por sua vez redireciona para https://cdn.exemplo.com.br/assets/favicon.ico, que devolve 404.

Passo 3: auditar o robots.txt em cada domínio da cadeia

Todo domínio que aparece na cadeia precisa ter seu próprio robots.txt checado, não só o domínio principal. Se o favicon está numa CDN, o robots.txt da CDN é o que vale para aquele arquivo.

curl https://cdn.exemplo.com.br/robots.txt

Um erro comum em configurações de CDN de assets é um bloqueio amplo demais, pensado para impedir indexação de imagens de produto, mas que acaba pegando o favicon junto:

User-agent: Googlebot-Image
Disallow: /assets/

Se o favicon vive em /assets/favicon.ico, essa regra bloqueia exatamente o arquivo que você quer que apareça na busca. A correção aqui é abrir uma exceção específica ou mover o favicon para um path que não caia na regra de Disallow.

Passo 4: confirmar no Search Console com a URL Inspection

O curl mostra o que o servidor responde, mas não mostra necessariamente o que o Googlebot está vendo no momento. Para isso uso a ferramenta de inspeção de URL do Search Console, inspecionando a home (não o favicon diretamente, já que ele não é uma URL indexável por si só).

Na tela de resultado, o passo que resolve a dúvida é rodar o teste ao vivo ("testar URL publicada") e analisar o resultado renderizado, observando se há indicação de recursos bloqueados durante o carregamento da home.

Em resumo: indícios de bloqueio na ferramenta reforçam a suspeita levantada pelo curl; a ausência deles, somada à falta do favicon no resultado de busca, aponta mais para um problema na declaração da tag do que no acesso ao arquivo.

Passo 5: validar com o teste de rich results

Como segunda fonte de confirmação, vale também rodar o teste de rich results (search.google.com/test/rich-results) sobre a mesma home, que permite inspecionar o HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → renderizado pelo Google. Comparar o resultado das duas ferramentas ajuda a descartar falso positivo: se ambas indicarem que a página carrega sem erros de recurso, a cadeia técnica provavelmente está correta e qualquer demora para o favicon aparecer na busca é só questão de reprocessamento.

O caso de CDN e subdomínio de assets

A documentação é clara que a URL do favicon pode ficar fora do domínio do site, numa CDN. Mas a regra de "um favicon por site" é sobre o host da PÁGINA, não do arquivo: www.exemplo.com.br e blog.exemplo.com.br são hosts diferentes e podem (e devem) declarar favicons diferentes, mesmo que os dois arquivos fisicamente morem na mesma CDN.

O erro que vejo com frequência é a CDN de assets ser compartilhada entre vários sites ou subdomínios do mesmo grupo, com o robots.txt daquela CDN configurado pensando só no site principal. Nesse cenário, o subdomínio secundário acaba com o favicon bloqueado sem que ninguém tenha mexido no código dele.

Depois de corrigir: pedir reindexação

Corrigido o redirect ou o robots.txt, o próximo passo é voltar à URL Inspection, rodar o teste ao vivo de novo para confirmar que o recurso já não aparece bloqueado, e então clicar em "solicitar indexação" na própria ferramenta. A documentação do Google é direta sobre o prazo: o reprocessamento pode levar de alguns dias a algumas semanas, dependendo da frequência de rastreamento que o Google já atribui àquela home.

Tropeços comuns que essa auditoria pega

• Redirect para erro mascarado: o framework devolve 200 numa página de erro genérica em vez de 404 real, e o curl -IL não entrega o sinal claro de quebra.
• Favicon instável: pipelines de deploy que geram hash no nome do arquivo (favicon.a1b2c3.ico) violam a regra de URL estável a cada build.
• Robots.txt genérico na CDN: bloqueio pensado para outro propósito (evitar indexar imagens de produto) pega o favicon de carona.
• Tag ausente na home: o <link rel="icon"> existe nas páginas internas, mas foi esquecido no template específico da home, que é o único lugar que conta.
• Subdomínio esquecido: blog.exemplo.com.br ou loja.exemplo.com.br nunca ganharam favicon próprio porque o time assumiu que o favicon do domínio principal "valeria para tudo".

Fonte

Este artigo tem como referência a documentação oficial do Google Search Central sobre favicon in Search, disponível em https://developers.google.com/search/docs/appearance/favicon-in-search.

Fonte: Google Search Central — Favicon in Search