Imagine seis meses de conteúdo bem escrito descobrindo tarde demais que uma linha no robots.txt bloqueava o site inteiro. Não é hipótese: acontece o ano todo com empresas reais. SEO técnico é a infraestrutura que permite ao Google acessar, ler e indexar suas páginas. Quando ela quebra, nenhum conteúdo ou link compensa: não se ranqueia o que não se consegue ler. Este guia é o pilar técnico do nosso guia de SEO do zero.
Antes de escrever mais um artigo, audite a base. Um site tecnicamente saudável com conteúdo mediano frequentemente vence um site tecnicamente quebrado com ótimo conteúdo: porque o Google não premia o que não consegue ler direito.
Rastreabilidade: a porta de entrada do Googlebot
Rastreabilidade é o grau em que os robôs conseguem acessar suas páginas. Antes de qualquer ranking, o Googlebot precisa alcançar a página, baixá-la e processá-la. Quatro pontos dominam o jogo:
- robots.txt: o arquivo em seudominio.com/robots.txt diz ao Googlebot o que evitar. Erro clássico: bloquear por engano pastas de CSS/JS: o Google precisa renderizar o site como o navegador renderiza, e sem CSS/JS ele enxerga um site quebrado.
- Orçamento de rastreio: o Google aloca um tempo finito por site. Sites pequenos (até ~1.000 páginas) raramente têm problema; catálogos enormes com URLs de filtro e parâmetro desperdiçam o orçamento em lixo e atrasam o conteúdo novo.
- Códigos de resposta: 200 carrega e indexa; 301 move e transfere ~90–99% da força; 302 é temporário (para mudança permanente use 301); 404 remove; soft 404 (página diz "não encontrado" respondendo 200) é o pior dos mundos: gasta orçamento enganando o robô.
- Renderização de JavaScript: o Google executa JS, mas com fila de dias ou semanas. Site cujo conteúdo só aparece depois de JavaScript (SPAs sem render no servidor) pode ficar semanas sendo lido como página quase vazia. HTML estático ou SSR resolve.
Indexação: o que entra (e o que NÃO deve entrar) no Google
Página rastreada não é página indexada: e a indexação é onde mora o controle fino. A página só ranqueia se entrar no índice; e existem páginas que você não quer no índice:
| Tipo de página | Indexar ou noindex? | Por quê |
|---|---|---|
| Home, páginas de serviço, artigos do blog | Indexar | São o ativo de busca do negócio |
| Página "obrigado", confirmação de formulário | noindex | Conteúdo vazio; pode vazar em busca sem valor |
| Login, conta, carrinho, checkout | noindex | Utilitária; ninguém busca e só gasta sinal |
| Busca interna do site (/?s=termo) | noindex / bloquear | Milhares de URLs duplicadas e vazias |
| Página de localidade ou filtro com conteúdo real | Indexar | Só se tiver conteúdo único de verdade |
| Ambiente de teste/staging | noindex + proteção | Nunca deve competir com o site real |
Página com noindex listada no sitemap envia dois recados contrários: "rastreie" (sitemap) e "não indexe" (tag). O Google tende a obedecer o noindex: mas a contradição gasta orçamento e esconde erros de configuração. Regra: só entra no sitemap quem pode e deve ser indexado.
A ferramenta gratuita que organiza tudo isso é o Google Search Console: relatório de Páginas (indexadas vs. não indexadas, com motivo), inspeção de URL (como o Googlebot Smartphone renderiza cada página) e sitemaps enviados. Se você só tiver uma ferramenta de SEO, que seja essa.
HTTPS e segurança: o piso de confiança
- Certificado válido em todas as páginas: o Google confirmou HTTPS como sinal de ranqueamento desde 2014, e os navegadores marcam sites HTTP como "não seguro", queimando o clique antes de qualquer ranking.
- Zero conteúdo misto: página HTTPS carregando imagem ou script por HTTP perde o cadeado e pode quebrar visualmente. Depois de migrar, audite os recursos.
- Migração correta: certificou → serviu HTTPS por padrão → 301 de cada URL HTTP para a HTTPS equivalente (não só da home) → atualizou canonical, sitemap e links internos. Flutuação de ranking de 1–3 semanas é normal na migração; dano permanente é sinal de migração errada.
Core Web Vitals: a experiência medida pelo Google
| Métrica | O que mede | Bom | Causa clássica de problema |
|---|---|---|---|
| LCP | Tempo para o maior elemento visível carregar | ≤ 2,5s | Imagem de topo pesada, servidor lento |
| CLS | Estabilidade visual (quanto a página "pula") | ≤ 0,1 | Imagem sem width/height, banner que empurra |
| INP | Resposta da página ao toque/click | ≤ 200ms | JavaScript pesado bloqueando a página |
Perspectiva honesta: Core Web Vitals é critério de desempate: dá vantagem quando as concorrentes são parecidas em conteúdo e autoridade, não milagre para conteúdo raso. Estudos independentes mostram variação média de 0,3–0,5 posição entre páginas que passam e não passam com conteúdo equivalente. Trate como piso, não como estratégia. Como medir: Search Console (dados reais de usuários), PageSpeed Insights (por URL) e a aba Performance do DevTools. A diferença entre métrica de laboratório e de campo: e como acelerar sem trocar de plano: está no guia de Core Web Vitals e no texto sobre site lento em hospedagem compartilhada.
Mobile-first: o Google ranqueia seu celular, não seu desktop
Desde 2019 e completado em 2023, o Google indexa a versão mobile de todas as páginas: mesmo para quem busca no desktop. Conteúdo que só existe na versão desktop ficou invisível para todos. O que isso obriga na prática:
- Paridade de conteúdo: mesmo texto, mesmos links e mesmo schema no mobile. Accordions e tabs são aceitos (o conteúdo está no HTML); remoção de seções não é.
- Viewport correto em todas as páginas e texto-base de 16px para cima.
- Alvos de toque de 48×48px com espaçamento: dedo não é cursor.
- Sem pop-up de tela cheia na entrada: o Google pune interstitials intrusivos em mobile; banner de cookie exigido por lei é exceção.
O teste decisivo: Search Console → Inspeção de URL → "Testar URL ao vivo": compare o HTML renderizado pelo Googlebot Smartphone com sua página desktop. O guia de SEO mobile cobre a otimização completa.
Canonical e URLs: uma página, um endereço
Quando o mesmo conteúdo responde em várias URLs (com/sem barra, http/https, com parâmetro), o Google divide a força entre os "duplicados" ou escolhe a versão errada. A tag rel="canonical" no head diz qual é a versão oficial: autorreferente em todas as páginas, mesmo sem duplicação visível, é o padrão de segurança. E redirect 301 é o canonical mecânico: mudou a URL? 301 direto, sem correntes A→B→C, que perdem força a cada salto.
| Fonte de duplicação | Correção recomendada |
|---|---|
| http:// vs https:// | 301 de todas as URLs HTTP para HTTPS + canonical atualizado |
| www vs não-www | Escolher um padrão, 301 do outro, manter em todo lugar |
| Barra final /pagina e /pagina/ | Escolher um padrão, 301 do outro, canonical autorreferente |
| Parâmetros de campanha/filtro (?utm=, ?sort=) | Canonical para a URL limpa |
| Versão de impressão ou feed | Canonical apontando para a página original |
Sitemap XML e arquitetura: mostrando o mapa do site
O sitemap é a lista oficial das páginas que você quer indexadas: enviada pelo Search Console e declarada no robots.txt. Só entra: URL com resposta 200, sem noindex, canônica. E arquitetura é a geometria que distribui força: quanto menos cliques separa a home de uma página importante (regra prática: até 3), mais ela recebe. A arquitetura moderna de conteúdo é o cluster de tópicos: página-pilar + páginas de apoio interligadas, que é exatamente a estrutura deste silo (o método está no guia de clusters de tópicos). Página sem nenhum link interno apontando (órfã) tem potencial drasticamente reduzido: encontre órfãs, conserte com links contextuais.
Dados estruturados: falar a língua do Google
Schema em JSON-LD é dado explícito sobre a página: "isto é um artigo, escrito por X, publicado em Y". Não é fator de ranqueamento direto, mas habilita os rich results (estrela, FAQ, breadcrumb) que aumentam CTR: e entregam contexto limpo para os sistemas de busca com IA. Para PME de serviço, os quatro essenciais: LocalBusiness, Service, FAQPage e BreadcrumbList. Valide sempre no Teste de Pesquisa Avançada antes de publicar: schema errado pode virar ação manual. O passo a passo está no guia de dados estruturados.
Checklist técnico trimestral
- robots.txt acessível e sem bloqueio acidental de CSS/JS/páginas-chave.
- TTFB (tempo de resposta do servidor) abaixo de ~800ms nas páginas principais.
- Nenhuma corrente de redirect com mais de 1 salto; nenhum link interno quebrado.
- Sitemap só com URLs canônicas indexáveis; nenhum noindex listado.
- Relatório de Páginas do GSC revisado: erros e avisos investigados.
- HTTPS sem aviso de conteúdo misto em nenhuma página.
- Core Web Vitals em campo (GSC) verde nas páginas principais.
- Paridade mobile confirmada por inspeção de URL renderizada.
- Canonical autorreferente em todas as páginas; sem sinais conflitantes.
- Schema validado no Teste de Pesquisa Avançada; nenhum erro na aba Aprimoramentos.
- Nenhuma página importante órfã: todas com 2+ links internos.
Fundação garantida, o ganho vem da camada de conteúdo: veja o guia de SEO on-page para otimizar cada página e a redação SEO para o método de escrita. Se os Core Web Vitals estão vermelhos, comece pelo guia de velocidade.