SEO técnico: guia para sites brasileiros

SEO técnico é o conjunto de ajustes de infraestrutura que permite que buscadores encontrem, renderizem e indexem as páginas de um site, e que essas páginas carreguem bem para quem chega nelas. Ele não decide se o conteúdo é bom. Decide se o conteúdo chega a ser considerado.

Escrevemos este guia a partir de um site que nós mesmos mantemos: o Rankz é uma SPA em React, e as páginas de comparação e de blog são geradas como HTML estático no build. Vamos apresentar as camadas do SEO técnico, um checklist, um roteiro de auditoria e, no final, o que os dados do nosso Search Console mostram e o que não mostram.

As camadas do SEO técnico

O SEO técnico pode ser entendido em quatro camadas em sequência: rastreamento, renderização, indexação e experiência. Se uma camada falha, as seguintes não adiantam.

A ordem importa na hora de diagnosticar. Uma página que não aparece no Google quase sempre trava nas duas primeiras camadas, e nenhum ajuste de velocidade resolve isso.

Rastreamento: robots.txt, sitemap e links internos

Rastreamento é o processo em que o buscador descobre URLs e baixa o conteúdo delas. Três arquivos e hábitos controlam isso.

robots.txt

O robots.txt é um arquivo na raiz do domínio que diz aos rastreadores quais URLs eles podem acessar. A documentação do Google é explícita: ele serve para gerenciar o tráfego de rastreamento, não para manter uma página fora do Google. Para tirar uma página do índice, use noindex numa página que o buscador consiga rastrear, ou proteja a página com senha. Bloquear no robots.txt uma URL que tem noindex impede que o buscador veja o noindex.

O erro mais comum que vemos é bloquear diretórios inteiros de scripts e estilos. O buscador precisa deles para renderizar a página. Se você também quer decidir o que bots de IA podem acessar, o robots.txt é o mesmo lugar, e explicamos os bots no guia o que é GEO.

Sitemap

Sitemap é um arquivo que lista as URLs que você quer ver rastreadas. Ele não garante indexação, mas ajuda o buscador a descobrir páginas novas e profundas. Cada arquivo tem limite de 50 MB sem compressão ou 50 mil URLs, segundo a documentação do Google; acima disso, divida em vários arquivos e use um índice de sitemaps. Liste só URLs canônicas, que respondem 200 e que você quer indexar. Um sitemap com redirecionamentos e páginas com noindex manda sinais contraditórios.

Links internos e profundidade

Os rastreadores seguem links. Uma página sem nenhum link interno apontando para ela é órfã e depende do sitemap para ser descoberta. Dois cuidados práticos: use elementos a com atributo href (a documentação do Google para JavaScript pede isso, e botões com onClick não contam como link), e mantenha as páginas importantes a poucos cliques da home. Num pilar com spokes, como este blog, o pilar linka todos os spokes e cada spoke volta ao pilar.

Renderização: o que muda em SPA e JavaScript

Renderização é a etapa em que o buscador executa o HTML, o CSS e o JavaScript para ver a página como o usuário a vê. O Google processa JavaScript em três fases: rastreia, renderiza e indexa, e as páginas entram numa fila antes de serem renderizadas. Isso significa que conteúdo que só existe depois de uma chamada de API no navegador chega mais tarde e depende de tudo dar certo.

A documentação do Google diz que renderização no servidor ou pré-renderização continua sendo uma boa ideia porque deixa o site mais rápido para usuários e rastreadores, e porque nem todos os bots executam JavaScript. Resumimos as opções assim:

Outros pontos próprios de SPA que a documentação do Google cobre e que auditamos sempre:

• Use a History API para as rotas, não fragmentos com #.
• Se uma rota não existe, a resposta deve ter status 404 de verdade, ou então a página deve carregar noindex. Uma SPA que devolve 200 com a mensagem "página não encontrada" cria soft 404.
• Título, description e canonical precisam estar no HTML entregue, não só injetados depois.

Indexação: canonical, noindex e status HTTP

Indexação é a decisão de guardar a página no índice e de escolher qual URL representa um conteúdo. Três sinais mandam aqui.

O status HTTP diz o que aconteceu: 200 para a página existente, 301 para mudança permanente, 404 ou 410 para páginas removidas. Cadeias longas de redirecionamento desperdiçam rastreamento e atrasam a consolidação.

O canonical (rel="canonical") indica qual URL é a preferida quando o mesmo conteúdo responde em mais de um endereço, como com e sem barra final, com parâmetros de rastreamento ou em http e https. A documentação do Google trata o canonical como uma dica, não como uma ordem, então ele precisa ser coerente com redirecionamentos, sitemap e links internos.

O noindex é uma ordem: não indexe esta página. Use em resultados de busca interna, páginas de filtro sem valor próprio e áreas de agradecimento.

Experiência da página: Core Web Vitals e mobile

Core Web Vitals são três métricas de experiência medidas com dados reais de usuários. Segundo a documentação do web.dev, considera-se bom, no percentil 75 das visitas:

Nossa leitura prática: não deixe velocidade passar na frente das camadas anteriores. Uma página lenta e indexada ainda aparece; uma página rápida e bloqueada não aparece. Para encontrar problemas reais, use os dados de campo do relatório de Core Web Vitals do Search Console e o PageSpeed Insights, e só depois os testes de laboratório para investigar a causa.

O Google indexa a versão mobile do site. Confira se o conteúdo, os links e os dados estruturados da versão mobile são os mesmos da versão desktop.

Particularidades de sites brasileiros

Sites brasileiros têm um conjunto próprio de decisões, quase todas ligadas a idioma e a domínio.

• Idioma e país. Declare lang="pt-BR" no HTML. Se você tem versões para outros países ou outras línguas, use hreflang, que a documentação do Google descreve como a forma de indicar versões localizadas de uma mesma página. Cada versão deve apontar para todas as outras e para si mesma.
• Domínio. Um .com.br sinaliza o país. Se você usa .com com subpasta como /pt-br/, o hreflang e a configuração do Search Console passam a ser o seu sinal principal.
• URLs. Usamos slugs em português, sem acento e sem caracteres especiais. Evita problemas de codificação em compartilhamentos e em ferramentas.
• Canonicalização de domínio. Escolha entre www e sem www, e entre http e https, e redirecione os outros com 301. Em sites brasileiros mais antigos é comum encontrar quatro versões respondendo 200.
• Dados de busca. Termos do mercado brasileiro muitas vezes mantêm nomes de ferramentas em inglês. Isso apareceu nos nossos dados: as consultas que mais nos trazem impressões são nomes de ferramentas e variações de grafia, como veremos a seguir.

O caso do Rankz: SPA em React com HTML estático no build

O Rankz é uma SPA em React. Num site assim, o risco é o rastreador receber um HTML vazio e depender da fila de renderização. Por isso as páginas de /compare e de /blog são geradas como HTML estático durante o build: o arquivo já contém título, texto, links e dados estruturados quando chega ao rastreador, sem esperar JavaScript.

Quantas páginas e quais consultas

O relatório de sinais de 29 de setembro de 2026 lista 130 páginas de comparação, das quais 32 são do tipo rankz-vs-*, 32 são do tipo alternativas-ao-* e as outras 66 comparam duas ferramentas de terceiros entre si. O blog ainda não tinha nenhuma página com impressões no Search Console nessa data: a lista de páginas do blog veio vazia, e o primeiro artigo foi publicado no mesmo dia.

As duas janelas do Search Console, que usamos como método, vão de 13 a 19 de setembro e de 20 a 26 de setembro de 2026:

As impressões quase dobraram, mas os números são pequenos e a posição média piorou. A nossa leitura é que a lista de consultas passou a incluir muitas consultas novas em posições distantes, o que puxa a média para baixo. Isso é uma hipótese: a maioria das consultas da lista atual não tem registro na janela anterior, mas não testamos a causa.

Selecionamos algumas consultas no formato de comparação para ver o cruzamento com a lista de páginas:

O que não dá para concluir

O Search Console, nos dados que temos, devolve consultas e não a URL que respondeu a cada uma, então a coluna da direita é um cruzamento por nome, não uma medição. Também não temos nesse relatório o status de indexação de cada uma das 130 páginas. Com 203 impressões e nenhum clique na semana, a amostra é pequena demais para falar em ganho ou perda de tráfego.

Há duas coisas que o cruzamento mostra de útil. A primeira é que as consultas com mais impressões, como "serpstat vs seranking", têm uma página correspondente que existe na lista, o que é compatível com o Google já ter indexado e exibido esse tipo de página. A segunda é uma lacuna: consultas como "frase vs moz pro" e "wincher vs moz" não têm página de comparação direta, porque nosso conjunto cobre confrontos entre algumas ferramentas, e não todas as combinações. Isso é pauta, não problema técnico.

Checklist de SEO técnico

Este é o checklist que usamos no Rankz para revisar um site. Cada linha pode ser verificada em minutos.

Como fazer uma auditoria técnica de SEO

Uma auditoria técnica de SEO é uma revisão sistemática do site contra o checklist acima, com um relatório de problemas priorizados. O roteiro que seguimos:

1. Defina o escopo. Liste os templates que importam (home, categoria, artigo, comparação) em vez de olhar página por página.
2. Rastreie o site. Use um rastreador para listar todas as URLs, status, canonicals, noindex e links. Ferramentas como Screaming Frog e Sitebulb fazem isso; nós as comparamos em alternativas ao Screaming Frog e alternativas ao Sitebulb, e também em Rankz vs Screaming Frog.
3. Compare com o Search Console. O relatório de indexação de páginas mostra o que o Google indexou e por que excluiu o resto. A diferença entre o que o rastreador viu e o que o Google indexou é o seu mapa de problemas.
4. Inspecione os templates. Use a inspeção de URL para ver o HTML renderizado e confira se o conteúdo principal está lá.
5. Meça a experiência. Anote LCP, INP e CLS por template, com dados de campo quando houver.
6. Priorize. Ordene pelo que bloqueia rastreamento ou indexação primeiro, depois duplicidade e por fim velocidade.
7. Repita e acompanhe. Depois de corrigir, acompanhe o efeito nas posições. Explicamos como no guia de rank tracking.

Guarde o relatório com data. Numa auditoria seguinte, a pergunta mais útil é o que mudou desde a última.

Por onde começar

Se você só puder fazer três coisas esta semana: abra o relatório de indexação de páginas do Search Console e leia os motivos de exclusão, confira no robots.txt se nada importante está bloqueado e veja, com a inspeção de URL, se o HTML renderizado das suas páginas principais contém o texto que você espera. Quase sempre, o primeiro problema real está numa dessas três verificações.

Fontes

1. Google Search Central: Guia de SEO para iniciantes (Google Search Central)
2. Google Search Central: Noções básicas de SEO para JavaScript (Google Search Central)
3. Google Search Central: Introdução ao robots.txt (Google Search Central)
4. Google Search Central: Como criar e enviar um sitemap (Google Search Central)
5. Google Search Central: Consolidar URLs duplicadas (Google Search Central)
6. Google Search Central: Versões localizadas da página (hreflang) (Google Search Central)
7. web.dev: Web Vitals (Google, web.dev)

Perguntas frequentes

O que é SEO técnico?

É o trabalho de infraestrutura que permite que buscadores encontrem, renderizem e indexem as suas páginas, e que elas carreguem bem. Inclui robots.txt, sitemap, códigos de status HTTP, canonical, renderização de JavaScript, velocidade e versão mobile.

Preciso de SSR para um site em React ranquear no Google?

Não é obrigatório. O Google renderiza JavaScript, mas a documentação dele recomenda renderização no servidor ou pré-renderização porque deixa o site mais rápido e porque nem todos os bots executam JavaScript. Gerar HTML estático no build resolve o caso de páginas que mudam pouco.

O robots.txt remove uma página do Google?

Não. O robots.txt controla o rastreamento, não a indexação. Uma URL bloqueada ainda pode aparecer no índice se for linkada de outros lugares. Para manter uma página fora, use noindex em uma página rastreável ou proteja com senha.

Com que frequência devo fazer uma auditoria técnica de SEO?

Depende do ritmo de mudança do site. Como regra prática nossa, faça uma auditoria completa uma vez por trimestre e uma verificação rápida de indexação e status HTTP depois de qualquer mudança de estrutura, migração ou novo template.