SEO técnico para quem não é programador: o essencial

SEO técnico é o conjunto de configurações que permite ao Google acessar, carregar e entender as páginas do seu site: robots.txt, sitemap, canonical, noindex, HTTPS, versão mobile e renderização de JavaScript. Você não precisa programar para dominar o essencial. Precisa saber o que verificar, quais erros custam caro e o que pedir ao desenvolvedor, com as palavras certas.

Este guia faz parte do guia completo de SEO e parte do que você viu em como o Google rastreia, indexa e ranqueia: se uma das etapas falha, o melhor conteúdo do mundo não aparece.

Resumo rápido

• O SEO técnico cuida da elegibilidade: a página precisa poder ser rastreada, indexada e exibida corretamente.
• O robots.txt controla o que o Googlebot pode rastrear, mas não é um jeito de esconder páginas da Busca. Para isso existe o noindex.
• O sitemap ajuda o Google a descobrir URLs, sem garantir que serão rastreadas ou indexadas.
• O canonical indica qual versão de uma página repetida você prefere. É um sinal, não uma ordem.
• O Google usa a versão mobile do conteúdo para indexar e ranquear, e prefere HTTPS.
• O erro técnico mais caro costuma ser simples: um bloqueio esquecido depois de um lançamento.

Como ler: se você é leigo, leia a tabela-resumo, o exemplo hipotético e a lista do que pedir ao desenvolvedor. Se já trabalha com SEO, vá aos blocos "Para quem já trabalha com SEO" e às interações entre robots.txt, noindex e canonical.

O que é SEO técnico e por que ele vem primeiro?

SEO técnico é a parte do SEO que garante a "infraestrutura" para o resto funcionar. Ele vem primeiro porque falhas técnicas anulam o trabalho de conteúdo: uma página bloqueada, com noindex ou que não carrega para o robô simplesmente não entra no índice.

Em linguagem simples: pense em uma loja. O SEO técnico é a porta destrancada (robots.txt), o mapa do shopping atualizado (sitemap), a placa que diz "a loja oficial é esta, não a filial parecida" (canonical), o aviso "fechado para o público" (noindex) e o piso que aguenta o peso de quem entra (servidor, HTTPS, velocidade). O cliente nem percebe quando está tudo certo, mas desiste na primeira porta trancada.

Os requisitos técnicos mínimos fazem parte do Google Search Essentials, e a própria documentação lembra que cumpri-los não garante que o Google rastreie, indexe ou exiba a página.

O que cada item faz? Visão geral

A tabela resume o essencial, como checar sem programar e o que pedir ao desenvolvedor.

Item	Para que serve	Como checar sem programar	O que pedir ao dev
robots.txt	Diz ao Googlebot onde ele não deve rastrear	Abra seudominio.com.br/robots.txt no navegador	"Confirme que o robots.txt de produção não bloqueia páginas importantes"
Sitemap	Lista URLs que você quer que o Google conheça	Abra /sitemap.xml e veja o relatório de Sitemaps no Search Console	"Gere o sitemap só com URLs 200 e indexáveis, e atualize quando publicarmos"
Canonical	Indica a versão preferida de páginas repetidas	Inspeção de URL: compare a canônica declarada e a escolhida	"Cada página deve ter canonical absoluta, apontando para si mesma ou para a versão preferida"
Noindex	Impede que a página apareça na Busca	Inspeção de URL: "Indexação permitida?"	"Remova o noindex dessas URLs" (ou aplique nas que devem sair)
HTTPS	Conexão segura	Cadeado no navegador, sem avisos	"Redirecione todo HTTP para HTTPS com 301"
Mobile	O Google indexa a versão mobile	Abra a página no celular e compare o conteúdo	"O conteúdo e as tags da versão mobile devem ser iguais aos da desktop"
Renderização	Garante que o Google veja o conteúdo	"Testar URL ao vivo" na Inspeção de URL	"O texto principal e os links precisam estar no HTML entregue pelo servidor"

Para que serve o robots.txt, e o que ele não faz?

O robots.txt é um arquivo na raiz do site que diz aos rastreadores quais URLs eles podem acessar. Serve para controlar o tráfego de robôs no servidor. A documentação do Google é direta: ele não é um mecanismo para manter uma página fora do Google.

O motivo: uma URL bloqueada no robots.txt ainda pode ser indexada, só sem descrição, se outros sites linkarem para ela. Para tirar uma página dos resultados, use noindex ou proteção por senha.

Exemplo simples:

User-agent: *
Disallow: /busca/
Disallow: /carrinho/

Sitemap: https://www.exemplo.com.br/sitemap.xml

Leitura: todos os robôs podem rastrear o site, exceto /busca/ e /carrinho/. Cuidado com a linha que derruba tudo: Disallow: / bloqueia o site inteiro.

Para quem já trabalha com SEO: segundo as especificações do Google, os detalhes que mais pegam: o arquivo deve estar na raiz do host (cada subdomínio tem o seu), em UTF-8, com regras que diferenciam maiúsculas de minúsculas; o limite é de 500 KiB, e o que passa disso é ignorado; o Google guarda o arquivo em cache por até 24 horas. Se a resposta é 4xx (exceto 429), o Google assume que não há restrições. Se é 5xx, o Googlebot interrompe o rastreamento por até 12 horas, usa a última versão em cache por até 30 dias e, depois disso, age como se não houvesse robots.txt (em sites geralmente disponíveis). Veja mais em robots.txt e crawlers de IA.

O que é sitemap e quando preciso dele?

Sitemap é um arquivo que lista as páginas que você quer que os buscadores conheçam. Ele ajuda na descoberta, mas não garante que as URLs listadas serão rastreadas ou indexadas. Sites pequenos, bem linkados e sem mídia rica podem funcionar sem ele, e plataformas como WordPress costumam gerar um automaticamente.

Segundo a documentação de criação de sitemaps, um sitemap tem limite de 50 MB (sem compactar) ou 50.000 URLs, e acima disso é preciso dividir em vários arquivos com um índice. O Google aceita XML, RSS/Atom e texto simples, exige URLs absolutas em UTF-8 e ignora as tags <priority> e <changefreq>. A tag <lastmod> só é usada quando é consistente e verificavelmente precisa, e deve refletir mudanças significativas, não troca de rodapé.

Envie-o pelo relatório de Sitemaps do Search Console ou pela linha Sitemap: do robots.txt, incluindo só URLs que devolvem 200 e podem ser indexadas.

O que é canonical e como evitar páginas repetidas?

Canonical é a indicação da URL preferida quando o mesmo conteúdo (ou muito parecido) existe em mais de um endereço. Isso acontece com mais frequência do que parece: http e https, com e sem www, parâmetros de filtro, versões de impressão.

A documentação de URLs duplicadas descreve os métodos como sinais, e não como ordens. Recomenda URLs absolutas no rel="canonical", um canonical na própria página canônica (autorreferente), consistência nos links internos e nenhum conflito entre métodos. Exemplo:

<link rel="canonical" href="https://www.exemplo.com.br/blog/como-escolher-primeiro-violao" />

Para arquivos que não são HTML, como PDFs, o canonical pode ser enviado como cabeçalho HTTP. Duplicidade em si não é penalizada: o problema é dividir sinais e deixar o Google escolher por você.

Para quem já trabalha com SEO: a documentação ordena os sinais de canonicalização: redirecionamentos e rel="canonical" são fortes, e a inclusão no sitemap é fraca; o Google também prefere HTTPS a HTTP por padrão. Quando o Search Console mostra que a canônica escolhida pelo Google é diferente da declarada, há contradição entre sinais (links internos para outra variação, redirecionamentos, conteúdo muito parecido). E, se o canonical é injetado por JavaScript, o Google pede que seja idêntico ao do HTML original.

O que é noindex e quando usar?

Noindex é uma instrução que pede ao Google para não colocar a página no índice. Use em páginas que não devem aparecer na Busca, como resultados da busca interna do site, páginas de agradecimento e ambientes de teste (o ideal é protegê-los por senha).

O Google documenta duas formas, na página sobre como bloquear a indexação:

<meta name="robots" content="noindex">

X-Robots-Tag: noindex

A primeira vai no HTML; o cabeçalho HTTP serve também para arquivos que não são HTML. Duas pegadinhas importantes: a página não pode estar bloqueada no robots.txt, senão o Googlebot nunca vê o noindex; e o efeito não é imediato, porque pode levar meses para o Googlebot revisitar páginas de pouca importância. A Inspeção de URL do Search Console confirma se ele já enxerga a regra.

HTTPS, redirecionamentos e erros: o que verificar?

O básico é: o site inteiro em HTTPS, versões antigas redirecionando para a nova com 301, e páginas inexistentes respondendo 404, e não 200. O HTTPS está listado como parte da experiência na página pelo Google, e o sistema de canonicalização prefere HTTPS por padrão.

• 301 ou 308 (permanentes): dizem ao Google que o destino deve ser a versão canônica. Use em mudanças de domínio, de URL ou na consolidação de páginas.
• 302 ou 307 (temporários): não passam esse sinal, e a URL antiga pode continuar indexada. Use só se a mudança é temporária.
• Cadeias de redirecionamento: evite várias etapas. Os rastreadores seguem até 10 saltos, segundo a documentação de códigos HTTP do Google, mas cada salto atrasa usuário e robô.

Em linguagem simples: um redirecionamento 301 é o aviso definitivo de mudança de endereço colado na porta da loja antiga: "agora estamos ali". Um 302 é o aviso de "voltamos já", que não faz ninguém trocar o endereço na agenda.

O que o Google exige do site mobile?

O Google usa a versão mobile do conteúdo para indexar e ranquear. A documentação de mobile-first indexing pede que o site mobile tenha o mesmo conteúdo do desktop (colocar texto em abas ou acordeões é aceitável, removê-lo não), as mesmas meta tags de robots e os mesmos dados estruturados. Ela avisa também que o Google não carrega conteúdo que depende de interação, como rolar, clicar ou digitar.

Teste simples: abra suas páginas principais no celular. O que existe só no computador pode ficar fora do que o Google indexa.

Como o JavaScript afeta o SEO?

Se o seu site mostra o conteúdo só depois de rodar JavaScript, o Google ainda consegue ver, mas em outra etapa e com algum atraso. Segundo o guia de SEO para JavaScript, o processo tem três fases (rastreio, renderização, indexação), e a recomendação é preferir renderização no servidor ou pré-renderização, que também beneficia usuários e robôs que não executam JavaScript.

O mesmo guia pede links reais com <a href>, URLs de verdade (History API, e não fragmentos #) e códigos HTTP corretos: página inexistente deve devolver 404, e não 200, ou vira um "soft 404".

O que pedir ao desenvolvedor? Lista e modelo de mensagem

Peça por problema e por evidência, e não por tecnologia:

1. Confirmar que o robots.txt de produção não tem Disallow: / e não bloqueia pastas importantes.
2. Remover noindex (meta ou cabeçalho) das páginas que devem aparecer na Busca.
3. Gerar um sitemap com URLs 200, canônicas e indexáveis, e declará-lo no robots.txt.
4. Definir rel="canonical" absoluto e autorreferente em cada página indexável.
5. Redirecionar HTTP para HTTPS e www ou não www para uma única versão, com 301.
6. Garantir que o conteúdo e os links principais estejam no HTML entregue pelo servidor.
7. Fazer a versão mobile ter o mesmo conteúdo e as mesmas tags da desktop.
8. Devolver 404 (ou 410) para páginas inexistentes, e nunca 200 com mensagem de erro.

Modelo de mensagem: "No Search Console aparece [status] para [URL], mas a página deveria estar indexada. Pode verificar se há meta robots ou X-Robots-Tag com noindex em produção? Print em anexo. Depois eu inspeciono a URL de novo."

Exemplo hipotético: o site que sumiu depois do relançamento

Exemplo hipotético: uma loja relança o site em nova plataforma. Dez dias depois, o tráfego do Google cai de forma brusca. O dono acha que "o Google penalizou" e começa a reescrever textos.

Quem conhece SEO técnico faz outra sequência. Abre /robots.txt e encontra Disallow: /, regra herdada do ambiente de testes. Abre a Inspeção de URL em uma página de produto e vê "Bloqueada pelo robots.txt". Pede ao desenvolvedor para trocar o arquivo por uma versão de produção e confere se também não ficou meta noindex em templates. Reenvia o sitemap e inspeciona as principais URLs. Depois acompanha a indexação nas semanas seguintes.

Nada disso exigiu código, só saber onde olhar. O guia de Google Search Console para iniciantes mostra como ler esses relatórios.

Perguntas frequentes

O que é SEO técnico?

É o conjunto de ajustes que garante que o Google consiga rastrear, indexar e exibir as páginas do site: robots.txt, sitemap, canonical, noindex, HTTPS, versão mobile, renderização de JavaScript e velocidade. Não melhora o conteúdo em si, mas sem ele o conteúdo pode nunca ser visto.

Qual a diferença entre robots.txt e noindex?

O robots.txt controla o que o Googlebot pode rastrear. O noindex pede para a página não ser indexada. Para esconder uma página dos resultados, use noindex, e não bloqueie a página no robots.txt, porque o Googlebot precisa acessá-la para ler a instrução. Uma URL bloqueada ainda pode aparecer sem descrição.

Todo site precisa de sitemap?

Não necessariamente. O Google diz que sites pequenos, bem linkados internamente e sem mídia rica podem prescindir dele. Para sites grandes, novos, com poucos links externos ou com muitos vídeos e imagens, o sitemap ajuda na descoberta. Em qualquer caso, ele não garante indexação.

O canonical é obrigatório?

Não, mas é recomendado. Sem ele, o Google escolhe sozinho a versão principal entre páginas parecidas, usando seus próprios sinais. Declarar um canonical absoluto e autorreferente reduz o risco de ele escolher uma variação que você não quer, embora o canonical seja um sinal, e não uma ordem.

Como saber se o Google está vendo minha página corretamente?

Use a Inspeção de URL do Search Console e rode o teste ao vivo: ele mostra se a página é rastreável, se há bloqueio por robots.txt ou noindex, qual canônica o Google escolheu e como a página foi renderizada. A versão indexada pode ser diferente da atual, porque reflete a última visita.

Próximo passo

Com a base técnica conferida, o próximo passo é revisar o site inteiro de uma vez: o guia de auditoria de SEO passo a passo reúne essas checagens em um roteiro completo. Para entender as métricas de velocidade e estabilidade, leia Core Web Vitals explicado.

Leia também:

• Robots.txt e crawlers de IA
• Google Search Console: guia para iniciantes
• SEO on-page: checklist completo para cada página