SEO técnico em 2026: o checklist que aplico em todo site

Conteúdo bom que o buscador não consegue ler é conteúdo invisível. SEO técnico é a parte do trabalho que garante três coisas: que o robô encontre a página, consiga renderizar o que está nela e entenda do que ela trata. Abaixo está o checklist que eu sigo em todo site que publico, incluindo este portfólio.

1. Rastreamento: deixe o caminho livre

O primeiro filtro é o robots.txt. Ele não serve para esconder páginas do índice (para isso existe noindex), mas para dizer ao robô onde não vale a pena gastar tempo.

User-agent: *
Allow: /

Sitemap: https://dominio.com.br/sitemap.xml

Pontos que eu confiro:

• Nenhum Disallow acidental em CSS, JS ou imagens. O Google renderiza a página e precisa desses arquivos.
• Sitemap gerado no build, nunca escrito à mão. Todo framework moderno tem um plugin ou integração para isso.
• Links internos em <a href> de verdade. Navegação feita só com onClick não é seguida pelo robô.

2. Indexação: uma URL, uma versão

O problema mais comum que encontro em auditorias é conteúdo duplicado por variação de URL: com e sem barra final, com www e sem, http e https, parâmetros de rastreio. Para o buscador, cada uma é uma página diferente disputando a mesma posição.

A solução tem duas partes:

1. Redirecionamento 301 para a forma canônica no servidor.
2. <link rel="canonical"> em toda página, apontando para a URL absoluta preferida.

Em sites bilíngues, some a isso o hreflang: cada página declara a si mesma e a sua tradução, mais um x-default.

<link rel="canonical" href="https://dominio.com.br/pt/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="pt-BR" href="https://dominio.com.br/pt/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="en" href="https://dominio.com.br/en/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="x-default" href="https://dominio.com.br/pt/blog/seo-tecnico-checklist/" />

3. Renderização: HTML pronto vence JavaScript

O Google consegue executar JavaScript, mas faz isso numa segunda etapa, com fila e orçamento. Outros robôs, incluindo a maioria dos crawlers de IA, nem tentam. Por isso a regra é simples: o conteúdo principal precisa estar no HTML que sai do servidor.

Estratégia	O que o robô recebe	Quando usar
SSG (estático)	HTML completo, gerado no build	Blogs, portfólios, landing pages
SSR	HTML completo, gerado a cada requisição	Conteúdo que muda o tempo todo
SPA (só cliente)	Um <div> vazio e um bundle JS	Painéis atrás de login

Para sites de conteúdo, SSG é quase sempre a melhor escolha: até dados vindos de um banco podem ser lidos no momento do build e sair pré-renderizados.

4. Core Web Vitals: as três métricas que pesam

O Google usa os Core Web Vitals como sinal de experiência de página. Os limites considerados “bons”, medidos no percentil 75 de usuários reais:

Métrica	O que mede	Bom
LCP	Tempo até o maior elemento visível aparecer	≤ 2,5 s
INP	Atraso entre uma interação e a resposta visual	≤ 200 ms
CLS	Quanto o layout “pula” durante o carregamento	≤ 0,1

O INP substituiu o antigo FID em março de 2024 e é o que mais pega sites cheios de JavaScript. O que mais resolve, na prática:

• LCP: imagem de destaque com fetchpriority="high" e preload, em WebP ou AVIF, e fontes com display=swap.
• INP: menos JavaScript no cliente. Carregue scripts só nos componentes que realmente precisam de interação; o resto deve ser HTML puro.
• CLS: width e height em toda imagem e espaço reservado para tudo que carrega depois.

5. Metadados: title, description e Open Graph

O title continua sendo um dos sinais on-page mais fortes e é o texto clicável no resultado. Eu sigo um padrão: assunto principal primeiro, marca no fim, por volta de 60 caracteres. A meta description não ranqueia, mas vira o trecho exibido e influencia o clique, então escrevo como um anúncio honesto de 140 a 160 caracteres.

O Open Graph (og:title, og:description, og:image em 1200×630) define como o link aparece em WhatsApp, LinkedIn e outras redes. Cada artigo deste blog tem a própria imagem, criada no mesmo estilo visual do site.

6. Dados estruturados: diga com todas as letras

JSON-LD é um bloco de dados no <head> que descreve a página num vocabulário que máquinas entendem (schema.org). Neste blog, cada artigo publica três:

• BlogPosting com título, autor, data de publicação e de atualização, imagem e idioma;
• BreadcrumbList com a trilha Início → Blog → artigo;
• FAQPage com as perguntas do fim do texto.

Uma ressalva honesta: desde 2023 o Google exibe rich results de FAQ só para alguns sites governamentais e de saúde. Mesmo assim vale manter, porque a marcação deixa explícito o que é pergunta e o que é resposta, e isso ajuda qualquer sistema que leia a página, inclusive os de IA. É o assunto do próximo artigo, sobre GEO.

7. Acessibilidade é SEO

Hierarquia de títulos correta (um h1, depois h2 e h3 em ordem), alt descritivo nas imagens, links com texto que faz sentido fora de contexto e lang certo no <html>. Tudo isso ajuda leitores de tela e robôs pelo mesmo motivo: deixa a estrutura do documento explícita.

O checklist em uma tela

• robots.txt sem bloqueios acidentais e com o sitemap declarado
• Sitemap gerado no build
• Redirecionamentos 301 para a URL canônica e rel="canonical" em toda página
• hreflang recíproco e x-default em sites multilíngues
• Conteúdo principal no HTML do servidor (SSG ou SSR)
• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1
• Title e description únicos por página
• Open Graph com imagem 1200×630
• JSON-LD de pessoa ou organização e do tipo de página
• Um h1 por página, alt em imagens, lang correto

Se você quer um site que já nasce com tudo isso resolvido, é exatamente o tipo de projeto que eu faço.