# SEO técnico: guia para sites brasileiros > SEO técnico explicado para sites brasileiros: rastreamento, renderização, indexação, Core Web Vitals e um checklist, com o caso do próprio Rankz. - **Cluster**: SEO técnico - **Autor**: Ivan Cordeiro Junior, Especialista em SEO - **Publicado em**: 2026-10-13 - **Atualizado em**: 2026-10-13 - **Tempo de leitura**: 12 min - **URL**: https://rankz.marfin.co/blog/guia-de-seo-tecnico ## Resumo SEO técnico é garantir que buscadores consigam rastrear, renderizar e indexar suas páginas e que elas carreguem bem. Comece por robots.txt, sitemap, status HTTP, canonical e HTML que funcione sem JavaScript, e meça Core Web Vitals. Em SPA, gere HTML estático no build, como fazemos no Rankz. --- 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. | Camada | Pergunta que responde | Principais controles | |---|---|---| | Rastreamento | O buscador consegue chegar à URL? | robots.txt, sitemap, links internos, status HTTP | | Renderização | O buscador enxerga o conteúdo final? | HTML no servidor ou no build, JavaScript, links com href | | Indexação | A URL entra no índice, e qual versão? | noindex, canonical, duplicidade, soft 404 | | Experiência | A página é rápida e usável? | Core Web Vitals, mobile, HTTPS | 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](https://rankz.marfin.co/blog/o-que-e-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: | Abordagem | O que o rastreador recebe | Quando faz sentido | |---|---|---| | Renderização no cliente | HTML quase vazio e um bundle JS | Áreas logadas, painéis, onde SEO não importa | | Renderização no servidor (SSR) | HTML montado a cada requisição | Conteúdo que muda a todo momento ou é personalizado | | HTML estático no build | HTML pronto, gerado uma vez | Páginas editoriais e de comparação que mudam pouco | 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: | Métrica | O que mede | Limite para "bom" | |---|---|---| | LCP (Largest Contentful Paint) | Tempo até o maior elemento visível carregar | até 2,5 segundos | | INP (Interaction to Next Paint) | Tempo de resposta às interações | até 200 milissegundos | | CLS (Cumulative Layout Shift) | Quanto o layout se desloca durante o carregamento | até 0,1 | 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: | Janela | Impressões | Cliques | Posição média | |---|---|---|---| | 13 a 19/09/2026 | 108 | 1 | 11,1 | | 20 a 26/09/2026 | 203 | 0 | 19,0 | 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: | Consulta | Impressões | Posição média | Página correspondente na lista | |---|---|---|---| | serpstat vs seranking | 22 | 24,0 | `se-ranking-vs-serpstat` | | se ranking vs surfer | 5 | 29,0 | `se-ranking-vs-surferseo` | | se ranking vs mangools | 3 | 72,3 | `mangools-vs-se-ranking` | | mangools vs semrush | 2 | 85,5 | `mangools-vs-semrush` | | frase vs moz pro | 3 | 58,0 | nenhuma | | wincher vs moz | 1 | 6,0 | nenhuma | ### 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. | Item | O que verificar | Onde verificar | |---|---|---| | robots.txt | Não bloqueia páginas, scripts ou estilos necessários | `/robots.txt` e relatório de robots.txt no Search Console | | Sitemap | Só URLs canônicas, com status 200 e indexáveis | Search Console, seção Sitemaps | | Status HTTP | Sem cadeias de redirecionamento, sem 404 em links internos | Rastreador de site | | Canonical | Uma URL preferida por conteúdo, igual no sitemap | Código-fonte e inspeção de URL | | noindex | Só nas páginas que você quer fora do índice | Rastreador e inspeção de URL | | Renderização | O conteúdo principal aparece no HTML entregue | Inspeção de URL, "ver HTML renderizado" | | Soft 404 | Rotas inexistentes respondem 404 ou carregam noindex | Relatório de indexação de páginas | | Core Web Vitals | LCP, INP e CLS dentro dos limites no campo | Search Console e PageSpeed Insights | | Mobile | Mesmo conteúdo e links que no desktop | Inspeção de URL com agente mobile | | Idioma | `lang="pt-BR"` e hreflang coerente | Código-fonte | | Links internos | Sem páginas órfãs; links com `href` | Rastreador de site | ## 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](https://rankz.marfin.co/compare/alternativas-ao-screaming-frog) e [alternativas ao Sitebulb](https://rankz.marfin.co/compare/alternativas-ao-sitebulb), e também em [Rankz vs Screaming Frog](https://rankz.marfin.co/compare/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](https://rankz.marfin.co/blog/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 - [Google Search Central: Guia de SEO para iniciantes](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) (Google Search Central) - [Google Search Central: Noções básicas de SEO para JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) (Google Search Central) - [Google Search Central: Introdução ao robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro) (Google Search Central) - [Google Search Central: Como criar e enviar um sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) (Google Search Central) - [Google Search Central: Consolidar URLs duplicadas](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) (Google Search Central) - [Google Search Central: Versões localizadas da página (hreflang)](https://developers.google.com/search/docs/specialty/international/localized-versions) (Google Search Central) - [web.dev: Web Vitals](https://web.dev/articles/vitals) (Google, web.dev)