Sitemap, robots.txt e canonical: configuração

Por que esses três arquivos geram tantos erros

Sitemap, robots.txt e canonical são tecnicamente simples — texto plano e tags HTML — e mesmo assim concentram a maioria dos problemas técnicos de SEO em sites corporativos. A razão é cultural: como parecem triviais, ficam órfãos. Ninguém é dono explícito. O time de desenvolvimento configura no lançamento e nunca mais revisa. A equipe de marketing assume que "está funcionando" porque o site aparece no Google. Meses depois, o Google Search Console aponta milhares de páginas com problema e ninguém entende quando começou.

Os erros mais comuns: sitemap listando URLs que retornam 404 ou que têm tag noindex (Google interpreta como sinal contraditório), robots.txt bloqueando CSS e JavaScript que o Googlebot precisa para renderizar o site corretamente, canonical apontando para versão errada da página (com parâmetro de rastreamento, com HTTP em vez de HTTPS, com www quando o site canônico é sem www), e canonical conflitando com hreflang em sites multi-país. Cada um desses problemas reduz cobertura no índice e, em casos extremos, derruba ranking de páginas estratégicas.

Sitemap XML: estrutura e boas práticas

O sitemap XML é o documento que lista as URLs que a empresa quer que os buscadores conheçam. É um arquivo de texto em XML, geralmente em /sitemap.xml ou /sitemap_index.xml, contendo entradas com URL, data da última modificação e — opcionalmente — frequência de mudança e prioridade.

Estrutura básica. Cada entrada tem um elemento <url> com pelo menos <loc>https://www.exemplo.com.br/pagina</loc>. A data de modificação (lastmod) é o sinal mais útil: indica ao Google quando reavaliar a página. Os elementos changefreq e priority foram em grande parte abandonados pelo Google — ainda válidos sintaticamente, mas raramente influenciam o comportamento do robô.

Limites técnicos. Um arquivo sitemap suporta no máximo 50 mil URLs ou 50 MB descompactados. Sites maiores precisam de sitemap index — um arquivo que aponta para vários sitemaps menores. Estrutura recomendada para sites de porte médio em diante: sitemap-paginas.xml, sitemap-posts.xml, sitemap-produtos.xml, sitemap-categorias.xml, todos referenciados em sitemap.xml (que vira o index).

Conteúdo correto. Liste apenas URLs canônicas com resposta HTTP 200 (sucesso). Nunca liste páginas com noindex, com redirecionamento (3xx), com erro (4xx, 5xx), ou versões não-canônicas. O sitemap é declaração de intenção de indexação — listar páginas que você não quer indexadas envia sinal contraditório ao Google.

Submissão. Submeta o sitemap no Google Search Console (Sitemaps no menu) e no Bing Webmaster Tools. Inclua referência também no robots.txt com linha "Sitemap: https://www.exemplo.com.br/sitemap.xml" para que outros buscadores descubram automaticamente.

Atualização. Em sites estáticos, regenerar a cada deploy. Em sites com CMS dinâmico (WordPress, blog corporativo, e-commerce), o plugin ou módulo cuida da atualização automática a cada publicação. Em plataformas customizadas, garantir que o sitemap seja regenerado sempre que houver mudança de URL, publicação, despublicação ou redirecionamento.

Robots.txt: o que faz e o que não faz

O robots.txt é um arquivo de texto em /robots.txt na raiz do domínio que dá instruções para robôs de buscadores. Sua função: dizer o que pode ou não ser rastreado. Sua principal armadilha: muita gente acredita que ele controla indexação, e não controla.

Sintaxe básica. Diretivas mais comuns:

User-agent: * — aplica a todos os robôs;
User-agent: Googlebot — aplica apenas ao robô do Google;
Disallow: /admin/ — não rastreie essa pasta;
Allow: /admin/publico/ — exceção dentro de uma pasta bloqueada;
Sitemap: https://www.exemplo.com.br/sitemap.xml — indica o sitemap.

O que controla. O robots.txt controla rastreamento — se o robô vai ou não acessar uma URL para ler o conteúdo. Bloquear no robots.txt significa que o Googlebot não vai gastar orçamento de rastreamento naquela URL.

O que NÃO controla. Robots.txt não controla indexação. Uma página bloqueada no robots.txt pode aparecer no índice do Google se outras páginas linkarem para ela — o Google vê a URL mas não consegue ler o conteúdo, e às vezes a mostra nas buscas com mensagem "descrição não disponível porque o robots.txt bloqueia". Para impedir indexação, use a tag meta robots noindex na própria página — mas para o Google ler essa tag, a página NÃO pode estar bloqueada no robots.txt.

Armadilha clássica. Bloquear no robots.txt e esperar noindex é o erro de configuração mais comum. Funciona ao contrário: deixar a página acessível ao Googlebot E marcar com meta robots noindex.

Não bloqueie CSS e JavaScript. Em algum momento entre 2010 e 2015, era comum bloquear pastas /css/ e /js/ no robots.txt para "economizar rastreamento". O Google evoluiu: hoje renderiza páginas como um navegador, e precisa carregar CSS e JS para entender o layout. Bloquear esses recursos faz o Googlebot ver versão quebrada da página e pode prejudicar ranking.

Canonical: a tag que orienta a versão preferida

A tag canonical é um elemento HTML — <link rel="canonical" href="https://www.exemplo.com.br/pagina-canonica"> — declarado no <head> de cada página, indicando ao buscador qual é a URL preferida quando há conteúdo similar ou duplicado em URLs diferentes.

Por que existe. A mesma página pode ser acessada por múltiplas URLs: com e sem www, com HTTP e HTTPS, com parâmetros de filtro (?cor=azul), com parâmetros de rastreamento (?utm_source=email), com paginação (?page=2), com variações de ordem de parâmetros. Para o buscador, são URLs diferentes mostrando conteúdo igual ou parecido — sem orientação, ele decide sozinho qual versão indexar, frequentemente errando.

Autorreferência. A regra mais robusta é que toda página declare canonical para si mesma — <link rel="canonical" href="URL exata e canônica da própria página">. Isso evita que parâmetros, versões com hash ou variações criem ambiguidade.

Paginação. Em séries paginadas (página 2, 3, 4 de blog ou categoria), cada página deve ter canonical autorreferencial. A prática antiga de apontar canonical de todas as páginas para a primeira é considerada errada pelo Google — o conteúdo de cada página é diferente. As tags rel="prev" e rel="next" foram descontinuadas pelo Google em 2019 como sinal de paginação.

Parâmetros UTM e rastreamento. URLs com ?utm_source, ?utm_campaign, ?ref ou outros parâmetros de rastreamento devem ter canonical apontando para a versão limpa, sem parâmetros. Isso evita que o índice fique cheio de duplicatas geradas por campanhas.

Canonical é hint, não comando. O Google trata canonical como sinal forte, mas não obrigatório. Se a tag canonical conflitar com outros sinais (sitemap, links internos, hreflang, conteúdo realmente diferente), o Google pode escolher versão diferente da declarada. Coerência entre todos os sinais é fundamental.

Hreflang e canonical. Em sites multi-país, a tag canonical de cada versão idiomática deve apontar para si mesma, não para a versão "original". O hreflang declara as alternativas linguísticas; o canonical declara a versão preferida dentro do mesmo idioma e país. Conflito entre os dois é causa frequente de problema em sites internacionais.

Hierarquia de sinais: o que vence o quê

Quando sitemap, robots.txt, canonical, meta robots e redirecionamentos enviam sinais diferentes, é importante saber como o Google resolve o conflito:

Robots.txt vence rastreamento. Se uma página está bloqueada no robots.txt, o Google não acessa. Não importa o que diga a meta robots — o Google nunca chega a ler a tag.

Meta robots vence indexação. Se a página é acessível ao Googlebot e tem <meta name="robots" content="noindex">, ela não entra no índice. Esse é o mecanismo correto para excluir páginas do índice.

Redirecionamento vence sitemap. Se o sitemap lista uma URL que redireciona para outra, o Google segue o redirecionamento e considera a URL de destino. Sitemap nunca deve listar URLs com redirecionamento.

Canonical é forte, mas negociável. O Google considera a tag canonical, mas pode escolher outra URL se outros sinais (links internos, sitemap, comportamento de usuário) sugerirem versão diferente. Coerência entre todos os sinais é fundamental.

HTTPS vence HTTP automaticamente. Em sites que servem HTTPS, o Google prefere a versão segura mesmo sem canonical explícita, mas configurar canonical e redirecionamento 301 de HTTP para HTTPS continua sendo boa prática.

Erros frequentes e como diagnosticar

Sitemap com URLs 404. Acontece quando o site é remodelado e o sitemap não é regenerado. O Google Search Console aponta no relatório "Páginas" ? "Não indexadas" ? "Não encontrada (404)". Solução: regenerar sitemap a cada mudança estrutural e auditar trimestralmente com crawler.

Sitemap com URLs noindex. Página marcada com noindex aparece no sitemap. O Search Console marca como "Excluída por tag noindex". Solução: filtrar páginas com noindex antes de gerar o sitemap.

Robots.txt bloqueando CSS/JS. Resíduo de configurações antigas. O Search Console em "Inspecionar URL" ? "Recursos da página" mostra recursos bloqueados. Solução: remover Disallow para /wp-content/, /static/, /assets/ ou pastas similares de recursos.

Canonical apontando para URL com tracking. Página com parâmetro UTM tem canonical apontando para a mesma URL com parâmetro, em vez da versão limpa. Solução: regra explícita no CMS removendo parâmetros conhecidos antes de gerar canonical.

Canonical apontando para 404. Após mudança de URL, a canonical das páginas redirecionadas aponta para destino que não existe mais. Solução: auditoria de canonical após qualquer mudança de URL.

Canonical apontando para HTTP em site HTTPS. Resíduo de migração mal feita. Solução: forçar HTTPS na geração de canonical, redirecionamento 301 permanente de HTTP para HTTPS.

Conflito canonical + hreflang. Versão em português aponta canonical para versão em inglês. Resultado: Google ignora a versão em português. Solução: cada versão linguística tem canonical autorreferencial e hreflang declara as alternativas.