SEO Técnico

O que é o briefing inicial

O briefing é a primeira conversa estruturada do projeto. Ele alinha expectativas, descobre restrições escondidas e define o que é sucesso.

Como conduzir

1. Apresentação do projeto e do que será feito.
2. Perguntas abertas sobre o problema que motivou o projeto.
3. Perguntas fechadas sobre restrições (prazo, orçamento, marca, técnico).
4. Resumo verbal: "ouvi X, Y e Z — confirma?".
5. Próximos passos e prazos para resposta.

Critérios de qualidade

• Foi gravado/transcrito (com autorização).
• O cliente confirmou o resumo.
• Foram identificados os principais riscos.

Por que auditar

Sem entender o estado atual, qualquer plano é chute. A auditoria identifica gaps, oportunidades e bloqueios técnicos.

Como fazer

1. Defina o escopo da auditoria (o que está em escopo, o que não está).
2. Use ferramentas adequadas ao domínio do projeto.
3. Documente achados com evidências (prints, dados, links).
4. Classifique por severidade e esforço de correção.

Critérios de qualidade

• Cada achado tem evidência.
• Achados estão priorizados.
• Cliente entendeu o relatório.

Por que auditar tecnicamente antes de qualquer outra coisa

Site com problema técnico não ranqueia, por mais que o conteúdo seja excelente. Cabeçalho HTTP errado, robots.txt bloqueando seções inteiras, links quebrados ou redirect chains de cinco hops são problemas invisíveis ao olho humano mas catastróficos para o mecanismo de busca. A auditoria técnica é o ponto-zero de qualquer trabalho de SEO sério.

O Screaming Frog é a ferramenta padrão da indústria porque simula o comportamento de um crawler real (incluindo Googlebot via User-Agent customizado) e expõe a estrutura técnica do site em granularidade que ferramentas-web não conseguem.

Como conduzir o crawl

Antes de tudo, defina o escopo. Site institucional pequeno costuma caber em crawl completo. E-commerce com 50 mil produtos exige amostragem ou crawl segmentado por subdiretório. Estabeleça o limite no Configuration → Limits para não consumir RAM excessiva ou rate-limitar o servidor do cliente.

Configure User-Agent como Googlebot (Configuration → User-Agent) — assim você vê o site como o mecanismo de busca vê. Alguns sites entregam conteúdo diferente baseado em User-Agent (cloaking inadvertido) e isso só aparece com simulação fiel.

Habilite renderização JavaScript em Configuration → Spider → Rendering se o cliente usa SPA (React, Vue, Angular). Sem isso, você só vê o HTML inicial — geralmente vazio.

Execute o crawl respeitando robots.txt (Configuration → Spider → Crawl → Respect noindex/nofollow). Você quer ver exatamente o que o Googlebot enxergaria.

O que procurar nos resultados

Status HTTP é a primeira leitura. Status 200 é o desejado. 301 em massa indica migração mal feita. 404 em páginas linkadas internamente são oportunidades de tráfego perdido. 500 são bugs do servidor que sangram autoridade. Exporte cada lista separadamente.

Redirect chains de mais de dois hops degradam o crawl budget e a experiência. Sobre o relatório Bulk Export → Response Codes → Redirection Chains. Cada chain de três ou mais saltos é correção prioritária.

Duplicação de title e meta description é alerta comum em e-commerce e blogs grandes. Pages com title vazio são pior ainda. Use o relatório Page Titles → Duplicate e Page Titles → Missing.

Páginas órfãs aparecem em Sitemap → Orphan URLs. Se o sitemap declara URLs que não estão no crawl, ou se URLs no crawl não estão no sitemap, há divergência arquitetural que precisa investigação.

Imagens sem alt text saem em Images → Missing Alt Text. Não é crítico para SEO em 2026, mas crítico para acessibilidade e cada vez mais penalizado pelo Google.

Critérios de qualidade

Cada achado deve ter evidência exportada do Screaming Frog (CSV ou screenshot). Sem evidência, o cliente não consegue priorizar nem rastrear correção depois.

Achados priorizados em quatro níveis: crítico (bloqueia indexação ou ranqueamento direto), alto (degrada performance), médio (oportunidade), baixo (estética técnica).

Estimativa de esforço por achado em horas. Sem estimativa, o cliente não consegue planejar sprints de correção.

O PDF final deve ser legível por não-técnico — diretor de marketing, não desenvolvedor. Linguagem clara, screenshots, gráficos quando possível.

Por que redirect chains matam SEO

Cada redirect é um hop adicional na requisição HTTP. Um hop é aceitável e às vezes inevitável (migração de domínio, mudança de URL de produto). Dois hops já consomem crawl budget e perdem fração de PageRank histórico. Três ou mais hops são problema sério: o Google pode desistir de seguir e marcar a página como inacessível.

Cadeias acontecem geralmente por acúmulo histórico. Site migrou de HTTP para HTTPS (1 redirect), depois trocou estrutura de URL (2 redirects), depois moveu para CDN (3 redirects). Cada migração foi correta isoladamente, mas o resultado combinado é uma cadeia que ninguém auditou.

Como mapear as cadeias

O Screaming Frog tem um relatório dedicado: Bulk Export → Response Codes → Redirection Chains. Ele lista a sequência completa para cada URL: origem → hop 1 → hop 2 → ... → destino final.

Importe esse CSV no Excel ou Google Sheets. Crie uma coluna com a contagem de hops. Filtre por hops maior que um. Essas são as cadeias para correção.

Para cada cadeia, identifique o destino final estável (o que retorna status 200) e crie uma regra de redirect 301 direto da origem para o destino final, pulando os intermediários.

Lidando com 404 órfãos

Páginas 404 não são todas iguais. Algumas merecem morrer mesmo (URL temporária de campanha encerrada). Outras tinham tráfego histórico e foram deletadas por engano ou migração mal feita.

No Search Console, vá em Performance → Pages e filtre por status. URLs 404 com cliques nos últimos 16 meses são as prioritárias. Cada uma representa tráfego perdido recorrente.

Para esses 404 prioritários, decida: ressuscitar a URL (recriar a página) ou redirect 301 para a página mais próxima semanticamente. Nunca redirect 301 para a home — isso é desperdício de autoridade e dispara soft-404 no Google.

Implementação no servidor

Em nginx, as regras vão no bloco server do arquivo de configuração do site. Use return 301 https://destino-novo absoluto para evitar ambiguidade.

location ~ ^/categoria-antiga/(.*)$ {
    return 301 https://example.com/categoria-nova/$1;
}

Em Apache, equivalente via .htaccess com RewriteRule e flag [R=301,L].

Sempre teste em staging antes de subir para produção. Um redirect mal escrito pode entrar em loop infinito e derrubar o site para usuários reais.

Critérios de qualidade

Zero redirect chains com mais de um hop no crawl pós-deploy. Validar com Screaming Frog re-rodando depois de 48h.

Todos os 404 com tráfego histórico foram tratados (redirect ou ressuscitação). Tráfego no GSC para essas URLs volta a crescer dentro de 14 dias.

Nenhuma regra causa loop ou erro 500. Monitorar Search Console e logs do servidor por uma semana.

Por que Schema.org importa em 2026

Schema.org é o vocabulário comum que mecanismos de busca, assistentes virtuais e LLMs usam para entender o que é o conteúdo de uma página. Sem ele, o Google precisa inferir tudo do HTML bruto — funciona, mas é menos preciso e perde oportunidade de rich results (estrelas em avaliações, FAQs expandidas, preço de produto na SERP).

Em 2026, com a explosão de IA generativa fazendo grounding em conteúdo web, marcar corretamente com Schema.org é também marcar para ser citado por sistemas como ChatGPT, Gemini, Perplexity. Conteúdo sem schema é conteúdo invisível para essa nova camada de descoberta.

Inventariar antes de implementar

Antes de sair colando código, mapeie quais tipos de página o cliente tem. Site institucional típico tem: home, sobre, serviços (várias), blog (lista + post individual), contato. E-commerce tem: home, categoria, produto individual, carrinho.

Para cada tipo, há um schema apropriado. Artigo de blog é Article ou BlogPosting. Produto é Product (com Offer aninhado). Empresa é Organization no rodapé de toda página. Lista de FAQ no formato pergunta-resposta é FAQPage.

Não tente schema demais. Marcar coisa errada gera warning no GSC e pode ser penalizado se Google interpretar como spam.

Como implementar JSON-LD

JSON-LD é o formato recomendado pelo Google (sobre microdata e RDFa). Vai dentro de uma tag script type="application/ld+json" no head ou body do HTML.

Para um artigo de blog típico:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Título do artigo",
  "author": { "@type": "Person", "name": "Nome do autor" },
  "datePublished": "2026-05-27",
  "image": "https://example.com/imagem.jpg"
}

Os campos exatos variam por tipo. Consulte sempre a documentação oficial em schema.org/Article (ou o tipo correspondente) e os requisitos do Google em developers.google.com/search/docs/appearance/structured-data.

Não invente campos. Não preencha com placeholder. Cada propriedade deve refletir o conteúdo real da página.

Validação obrigatória

O Rich Results Test do Google (search.google.com/test/rich-results) é a verificação canônica. Cole a URL e ele mostra exatamente quais tipos foram detectados e se há erro ou warning.

Erro bloqueia o rich result. Warning não bloqueia mas indica que algum campo opcional importante está faltando. Trate ambos.

Para sites em desenvolvimento (sem domínio público), use a opção de colar o HTML diretamente.

Critérios de qualidade

Cada template de página tem schema apropriado implementado. Lista de templates cobertos documentada no entregável.

Zero erros no Rich Results Test para todos os templates. Warnings tratados ou justificados.

Performance → Enhancements no GSC mostra os schemas detectados crescendo após 30 dias. Se nenhum aparece, há problema no fetch (verificar se Googlebot consegue acessar a página).

Code review de outro dev SEO antes do deploy. Schema mal escrito é difícil de detectar a olho nu.

A função do robots.txt

O robots.txt é o primeiro arquivo que qualquer crawler bem-educado lê antes de visitar qualquer outra URL do site. Ele diz: "esses caminhos você não precisa visitar" (Disallow) e "esses sim" (Allow).

Não é mecanismo de segurança. Arquivos bloqueados via robots.txt continuam acessíveis publicamente — só não são indexados (a maioria das vezes). Para esconder de verdade, use autenticação ou bloqueio no servidor.

Mau uso comum: bloquear /admin/ pensando que esconde do mundo. Bloquear no robots.txt expõe a existência do diretório para qualquer um que leia o arquivo. A regra é: assets sensíveis NÃO devem estar acessíveis publicamente em primeiro lugar.

Auditando o estado atual

Acesse example.com/robots.txt e leia. Procure regras Disallow que possam estar bloqueando URLs com tráfego. Erro comum: alguém colocou Disallow: / em ambiente de staging e esqueceu de remover ao subir produção. Site inteiro fica fora do Google.

Use Search Console → URL Inspection para qualquer URL crítica e veja se ela está acessível ao Googlebot. Se a inspection retorna "Blocked by robots.txt", você achou o problema.

Cuidado especial com /search/, /tag/, /?filter= e similares: muitas vezes geram milhares de URLs duplicadas e canibalizadas. Disallow nesses padrões é boa prática.

Construindo o sitemap.xml

Sitemap declara explicitamente quais URLs devem ser indexadas. É o mapa do tesouro para o Googlebot.

Cada entrada tem URL canônica, lastmod (data da última modificação), changefreq (hint de frequência de mudança) e priority (0 a 1, relativo às outras do mesmo sitemap).

Para sites com mais de 50 mil URLs ou mais de 50MB, divida em múltiplos sitemaps e crie um sitemap-index que aponta para eles.

A geração deve ser dinâmica — gerar arquivo estático e esquecer de atualizar é o caminho para sitemap desatualizado em produção. Use o framework da aplicação para gerar a cada deploy ou sob demanda.

Sintaxe básica

robots.txt mínimo recomendado:

User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /*?filter=
Allow: /

Sitemap: https://example.com/sitemap.xml

sitemap.xml simplificado:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-05-27</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
</urlset>

Submissão ao Search Console

Vá em Sitemaps no GSC. Cole a URL do sitemap (relativa ao domínio raiz) e clique Submit. Após algumas horas, o status mostra quantas URLs foram lidas e quantas foram indexadas.

Diferença grande entre lidas e indexadas é sinal de problema: URLs duplicadas, conteúdo thin, canonical apontando para outra URL.

Repita a submissão sempre que adicionar uma seção nova grande ao site. O Google geralmente busca o sitemap periodicamente, mas resubmeter acelera a descoberta.

Critérios de qualidade

robots.txt acessível em example.com/robots.txt com regras explicitamente justificadas (comentário # explicando cada Disallow não-óbvio).

sitemap.xml com 100% das URLs indexáveis e zero URLs noindex ou bloqueadas. Resubmeter sempre que houver mudança grande na estrutura.

Coverage no GSC sem erros críticos por 7 dias consecutivos. Warnings podem ser aceitáveis dependendo do tipo (ex: páginas marcadas noindex aparecem como "Excluded" — esperado).

Documentação interna do que está sendo bloqueado e por quê. Ninguém deveria precisar adivinhar a intenção de uma regra do robots.txt seis meses depois.

O que são Core Web Vitals em 2026

São três métricas que o Google usa como sinal direto de ranqueamento: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint, que substituiu FID em 2024). Cada uma mede um aspecto diferente da experiência percebida pelo usuário.

LCP mede quanto tempo até o maior elemento visível carregar. Faixa verde é abaixo de 2.5 segundos.

CLS mede o quanto o layout pula durante o carregamento. Faixa verde é abaixo de 0.1 (escala absoluta, não percentual).

INP mede o tempo de resposta a interações do usuário (clique, toque, tecla). Faixa verde é abaixo de 200 milissegundos.

Site na faixa vermelha em qualquer uma das três perde posição em ranqueamento. Site na faixa amarela tem oportunidade significativa.

Diagnóstico antes de otimização

PageSpeed Insights (pagespeed.web.dev) é o ponto de partida. Cole a URL e ele mostra as três métricas para mobile e desktop separadamente. Atenção: PageSpeed usa lab data (simulação) E field data (CrUX, dados reais de Chrome users). Field data é o que conta para ranqueamento.

Para diagnóstico profundo, abra o DevTools do Chrome em Performance, grave um carregamento, e analise o trace. O elemento LCP fica destacado, e cada layout shift aparece anotado no timeline.

Cada template (home, blog post, página de produto) tem perfil de performance diferente. Otimize separadamente.

Otimizando LCP

LCP geralmente é a imagem hero ou texto principal. Para imagens:

Use formato moderno (AVIF preferido, WebP como fallback, JPG só em último caso). AVIF reduz peso em 50% sobre WebP sem perda visual.

Dimensione a imagem para o tamanho que ela é exibida. Servir imagem 4000px de largura para um container 800px é desperdiçar bandwidth.

Use srcset e sizes para entregar versão apropriada ao viewport. Mobile não precisa da versão desktop.

Adicione fetchpriority="high" no LCP. É um hint para o browser priorizar o download.

Não use lazy loading no LCP. Lazy loading atrasa o que deveria ser a primeira coisa a carregar.

Reduzindo CLS

Layout shift acontece quando elementos aparecem na tela depois e empurram outros. Causas comuns: imagens sem dimensões declaradas, fontes web carregando depois e mudando métricas tipográficas, banners de cookies/ads injetados após o carregamento.

Para imagens, declare width e height (mesmo que a renderização final seja por CSS). O browser reserva o espaço.

Para fontes web, use font-display: swap E pré-carregue a fonte principal com preload. Considere fonts métricos próximos ao fallback do sistema.

Para elementos dinâmicos (carrosséis, embeds, ads), reserve o espaço com min-height ou aspect-ratio no CSS. Mesmo que o conteúdo não tenha carregado, o espaço está reservado.

Reduzindo INP

INP mede a latência de interação. Geralmente é JavaScript bloqueante na thread principal.

Identifique tasks longas (>50ms) no Performance do DevTools. Cada barra vermelha em Main é um bloqueio.

Quebre código longo em chunks menores. Use setTimeout, requestIdleCallback ou scheduler.yield para dar respiro ao browser.

Defer ou async scripts não críticos. Análise de tracking pode esperar dois segundos sem prejudicar a métrica.

Para sites pesados de JS (SPAs), considere code-splitting agressivo. Carregue só o JS da rota atual.

Critérios de qualidade

Páginas-tipo principais (home, post de blog, produto) na faixa verde para LCP, CLS e INP em mobile (mais difícil que desktop).

Field data no CrUX (não só lab data) reflete a melhoria — leva até 28 dias para o CrUX atualizar.

Relatório de antes/depois com screenshots do PageSpeed e commits documentados (cada otimização teve um commit identificável).

Sem regressão nos meses seguintes — performance é prática contínua, não projeto único. Documentar guia de boas práticas para o dev team manter.

Por que esperar 30 dias para julgar

SEO não é instantâneo. Correção feita hoje só aparece nos relatórios do Search Console em alguns dias, e o efeito em ranqueamento e tráfego leva semanas para se materializar.

Os ciclos típicos: indexação leva 1-7 dias para URLs novas ou modificadas. Atualização de ranqueamento leva 2-4 semanas após indexação. Estabilização das métricas (cliques, CTR) leva 4-8 semanas.

Apresentar resultado uma semana após deploy é prematuro e gera expectativa quebrada. Apresentar 30 dias após é o mínimo defensável.

Baseline antes do deploy

Antes de qualquer correção entrar em produção, capture o estado atual do Search Console em uma planilha. Métricas mínimas: impressões totais, cliques totais, CTR médio, posição média (período de 28 dias).

Para cada template afetado, faça o mesmo recorte filtrando por padrão de URL. Por exemplo, se você está corrigindo SEO técnico em /blog/, capture as métricas só de URLs que matcham /blog/.

Esse baseline é referência para o relatório de 30 dias depois. Sem baseline, não há comparação possível e qualquer claim de melhoria é especulação.

Solicitando reindexação

URL Inspection do GSC permite pedir reindexação de uma URL específica. Útil para acelerar a descoberta de mudanças em páginas críticas. Limite de cerca de 10 solicitações por dia.

Para mudanças em massa, prefira atualizar o sitemap e ressubmeter via Sitemaps. O Google pega a partir do sitemap atualizado.

Não solicite reindexação para URLs que não mudaram. É desperdício de quota e não acelera nada.

Monitoramento da cobertura

Coverage (Páginas) mostra quantas URLs foram indexadas, quantas excluídas, e por que motivo. Acompanhe diariamente nos primeiros 7 dias após deploy de correções estruturais (redirect, robots.txt, sitemap).

Aumento súbito de Excluded indica que algo da correção bloqueou URLs indevidamente. Investigue imediatamente.

Aumento de Indexed em ritmo saudável (sem picos artificiais que sugiram spam) é sinal positivo.

Categorias específicas para vigiar: "Crawled - currently not indexed" (Google viu mas não considerou bom para indexar — investigar conteúdo), "Discovered - currently not indexed" (Google viu o link mas ainda não baixou — esperar), "Submitted URL not found (404)" (regressão crítica).

Acompanhamento de Performance

Performance (Resultados de pesquisa) mostra impressões, cliques, CTR, posição média. Filtre por data e por padrão de URL relevante à correção.

Se você corrigiu Core Web Vitals, abra também Performance → Search type → Web → Filter by device → Mobile (LCP/CLS/INP afetam principalmente mobile).

Para correções de schema (rich results), vá em Performance → Search Appearance e veja se rich results estão começando a aparecer.

Tendência geral nos primeiros 14 dias: pode haver pequena oscilação para baixo (Google reavalia). Estabilização e crescimento aparecem entre dia 14 e 30.

Relatório comparativo de 30 dias

O relatório final deve responder a três perguntas: o que melhorou, o que piorou, o que não mudou.

Apresente lado a lado: métrica X no período baseline vs métrica X no período pós-deploy. Use gráficos do próprio GSC como evidência visual.

Identifique vencedores claros (templates ou URLs com crescimento expressivo) e perdedores se houver. Hipótese para cada perdedor: regressão real, sazonalidade, mudança no algoritmo, ou ruído.

Inclua aprendizados: o que faríamos diferente na próxima rodada? Quais correções tiveram impacto desproporcional ao esforço? Documentar isso evita repetir o erro do baseline em projetos futuros.

Critérios de qualidade

Baseline documentado em planilha versionada antes do deploy. Sem baseline, não vale a pena rodar este bloco.

Coverage no GSC sem regressão crítica nos 7 dias pós-deploy. Erros novos investigados e resolvidos antes do dia 14.

Relatório comparativo entregue exatamente 30 dias após deploy, com hipóteses para cada movimento de métrica significativo.

Cliente entende as métricas e os trade-offs. Apresentação executiva (não só dump de números) demonstrando o link entre correções técnicas e resultado de negócio.

Para que serve

Encerrar formalmente o projeto, entregar tudo que foi prometido e garantir que o cliente sabe operar sem você.

Estrutura

1. Conferência do escopo: tudo que estava no briefing foi entregue?
2. Documentação de tudo que foi entregue.
3. Treinamento ou repasse para o time do cliente.
4. Pesquisa de satisfação.
5. Próximos passos (manutenção, evoluções).

Critérios de qualidade

• Cliente assinou aceite formal.
• Documentação está completa e acessível.
• NPS coletado.