SEO para front-end: Core Web Vitals e outras dicas práticas para programadores

Por Thiago Thomaz · 18 de outubro de 2026

Código HTML de um menu de site em uma tela escura

Resposta curta: SEO para front-end é a parte do SEO que depende do código: HTML semântico com um único H1, title e description únicos, um endereço por página (com canonical), conteúdo já presente no HTML, boas métricas de Core Web Vitals (LCP até 2,5 s, INP até 200 ms e CLS até 0,1), imagens otimizadas, dados estruturados e sitemap correto.

Boa parte do SEO acontece no código. O texto e os links de outros sites contam muito, mas um site que o Google não consegue ler direito, que demora para carregar ou que tem cada página em três endereços diferentes começa em desvantagem, por melhor que seja o conteúdo.

Este artigo é para quem programa o front-end. Juntei o que aplico nos sites que desenvolvo, incluindo uma configuração que precisei ajustar neste próprio site.

1. HTML semântico e títulos em ordem

O Google entende a página pela estrutura do HTML. O básico que mais faz diferença:

um único <h1> por página, com o assunto principal (de preferência com o termo que as pessoas pesquisam);
<h2> e <h3> em ordem, sem pular nível só por causa do tamanho da fonte (tamanho é com CSS);
<main>, <nav>, <header>, <footer> e <article> no lugar de <div> genérica;
links de verdade: navegação com <a href="/pagina">. Um <div onclick> ou um botão que muda a rota por JavaScript não é seguido como link pelo Google.

De quebra, tudo isso melhora a acessibilidade, porque leitores de tela usam a mesma estrutura.

2. Title e meta description únicos por página

Cada página precisa do seu próprio <title> e da sua própria <meta name="description">:

<title>Criação de Sites no Rio de Janeiro | Thiago Thomaz</title>
<meta name="description" content="Sites institucionais e landing pages rápidos, feitos para o celular e preparados para o Google." />

O title aparece como o link azul no Google. Mantenha o termo principal no começo e algo em torno de 60 caracteres.
A description não muda a posição, mas muitas vezes é o texto que aparece embaixo do link, e um bom texto leva mais gente a clicar.
<meta name="keywords"> é ignorada pelo Google há mais de uma década. Pode tirar.

3. Um endereço por página (e o problema da barra no final)

Para o Google, /contato, /contato/, www.site.com/contato e http://site.com/contato podem ser quatro páginas diferentes. Escolha um formato e faça todos os outros redirecionarem para ele com 301 ou 308, além de declarar o endereço oficial:

<link rel="canonical" href="https://www.seusite.com.br/contato" />

Um caso real: este site é gerado pelo Astro e hospedado no Cloudflare Pages. No formato padrão do Astro, cada página vira uma pasta (/contato/index.html), e o Cloudflare redireciona /contato para /contato/. Com links e canonical sem barra, cada link interno passaria por um redirecionamento, e essas URLs aparecem no Search Console como “Página com redirecionamento”. A solução foi gerar cada página como arquivo (build.format: "file" e trailingSlash: "never" no Astro). Assim o endereço sem barra é servido direto, e os links, o canonical e o sitemap usam o mesmo formato.

A lição vale para qualquer stack: links internos, canonical e sitemap devem usar exatamente o mesmo endereço final, sem passar por redirecionamento.

4. Renderização: o conteúdo precisa estar no HTML

O Google executa JavaScript, mas em uma segunda etapa e com limites. Uma SPA que monta todo o conteúdo no navegador (o HTML chega com um <div id="root"></div> vazio) depende dessa etapa para ser entendida, e outros buscadores e assistentes de IA nem sempre executam JavaScript.

Para páginas de conteúdo (institucional, serviços, blog), prefira geração estática (SSG) ou renderização no servidor (SSR): o HTML já chega com o texto. Astro, Next.js, Nuxt e SvelteKit fazem isso. Um teste rápido é abrir o código-fonte da página (Ctrl+U) e procurar o texto principal. Se não estiver lá, o Google depende do JavaScript para lê-lo.

5. Core Web Vitals: o que são e como melhorar

São as três métricas de experiência que o Google mede com dados reais de usuários do Chrome. Os limites considerados bons são:

Métrica	O que mede	Bom
LCP	Tempo até o maior elemento visível aparecer	até 2,5 s
INP	Rapidez da resposta a cliques e toques	até 200 ms
CLS	Quanto o layout “pula” durante o carregamento	até 0,1

O que mais resolve na prática:

Imagem principal (hero): não use loading="lazy" nela. Prefira fetchpriority="high" e um tamanho adequado à tela.
Dimensões nas imagens: width e height (ou aspect-ratio no CSS) evitam que o texto pule quando a imagem carrega.
Fontes: sirva do próprio domínio, só com os pesos que você usa, e com font-display: swap.
Menos JavaScript: cada biblioteca a mais pesa no INP. Em site institucional, quase nada precisa de framework no navegador.

Meça no PageSpeed Insights. Os dados de campo, quando existem, valem mais que a nota do laboratório.

6. Imagens

alt descritivo em imagens com conteúdo, e alt="" nas decorativas;
formatos modernos (AVIF ou WebP) e versões em tamanhos diferentes com srcset;
nomes de arquivo que dizem o que é a imagem (escritorio-advocacia-site.jpg, não IMG_2034.jpg).

7. Dados estruturados

Dados estruturados (JSON-LD com o vocabulário do schema.org) dizem ao Google, sem ambiguidade, o que é cada coisa: um negócio, um serviço, um artigo, uma lista de perguntas frequentes, a trilha de navegação.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "SEO para front-end: dicas práticas para programadores",
  "datePublished": "2026-11-02",
  "author": { "@type": "Person", "name": "Thiago Thomaz" }
}
</script>

Valide no Teste de pesquisa aprimorada e só marque o que está visível na página.

8. Sitemap, robots.txt e lastmod

robots.txt liberando o site e apontando para o sitemap. Cuidado com um Disallow: / esquecido do ambiente de testes.
sitemap.xml só com os endereços finais (sem redirecionamento e sem páginas com noindex).
<lastmod> com a data real da última alteração do conteúdo, e não a data do build. Se toda página aparece como alterada a cada deploy, o Google passa a ignorar o campo. Aqui, a data vem do último commit dos arquivos de cada página.

9. Links internos e página 404

Ligue as páginas entre si com textos de link que dizem o destino (“veja como funciona a criação de sites”, e não “clique aqui”).
Trilha de navegação (breadcrumb) ajuda o visitante e o Google a entender a hierarquia.
Página inexistente precisa responder com status 404 de verdade. Uma página “não encontrada” que responde 200 vira um “soft 404” no Search Console.

10. Depois do deploy: Search Console

Nada disso termina no código. Cadastre o site no Google Search Console, envie o sitemap e acompanhe dois relatórios:

Indexação → Páginas: o que está indexado e por que algo não está;
Desempenho: em quais pesquisas o site aparece, com cliques e posição.

Perguntas frequentes

O que é SEO front-end?

É o conjunto de práticas de SEO que ficam nas mãos de quem programa a interface: estrutura do HTML, títulos, metadados, URLs, velocidade, imagens e dados estruturados. O conteúdo e os links de outros sites completam o trabalho, mas sem essa base técnica o Google tem mais dificuldade para ler e mostrar a página.

SEO é front-end ou back-end?

Os dois participam. O front-end cuida do HTML, da velocidade no navegador e da estrutura da página. O back-end cuida de status HTTP (como o 404 de verdade), redirecionamentos, tempo de resposta do servidor e geração do sitemap. Em sites estáticos, quase tudo isso fica no front-end e no build.

Como medir o Core Web Vitals?

Pelo PageSpeed Insights, que mostra os dados de campo (de usuários reais do Chrome) quando o site tem visitas suficientes, e pelo relatório Core Web Vitals do Search Console, que agrupa as páginas por situação. Durante o desenvolvimento, o Lighthouse do Chrome dá uma medição de laboratório.

O PageSpeed é do Google?

Sim. O PageSpeed Insights é uma ferramenta gratuita do Google, que usa o Lighthouse para a análise de laboratório e os dados do Chrome UX Report (CrUX) para os dados de campo.