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

> SEO técnico para quem programa: HTML semântico, canonical, renderização, Core Web Vitals, imagens, dados estruturados e sitemap.

Por [Thiago Thomaz](https://www.thiagothomaz.tech/sobre) · SEO · publicado em 18 de outubro de 2026

**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">`:

```html
<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:

```html
<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](https://pagespeed.web.dev/). 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.

```html
<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](https://search.google.com/test/rich-results) 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](https://search.google.com/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](https://pagespeed.web.dev/), 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.

## Checklist

- [ ] Um H1 por página e títulos em ordem.
- [ ] Title e description únicos em cada página.
- [ ] Um endereço por página: links, canonical e sitemap iguais, sem redirecionamento.
- [ ] Conteúdo presente no HTML (SSG ou SSR).
- [ ] LCP, INP e CLS dentro do limite bom.
- [ ] Imagens com `alt`, dimensões e formatos modernos.
- [ ] Dados estruturados validados.
- [ ] `robots.txt`, sitemap e `lastmod` corretos.
- [ ] 404 com status 404.
- [ ] Search Console configurado.

Se você precisa de um site com essa base técnica, ou quer uma revisão do seu, veja a página de [criação de sites](/criacao-de-sites).

Serviço relacionado: https://www.thiagothomaz.tech/criacao-de-sites

Dúvidas? [Fale pelo WhatsApp](https://wa.me/5521987059570?text=Ol%C3%A1%2C%20Thiago!%20Li%20o%20artigo%20de%20SEO%20para%20front-end%20e%20queria%20conversar%20sobre%20um%20projeto.).

---

- Contato: [WhatsApp +55 21 98705-9570](https://wa.me/5521987059570?text=Ol%C3%A1%2C%20Thiago!%20Vi%20seu%20site%20e%20gostaria%20de%20conversar%20sobre%20um%20projeto.)
- Mapa do site para agentes: [llms.txt](https://www.thiagothomaz.tech/llms.txt) · [sitemap.xml](https://www.thiagothomaz.tech/sitemap.xml)
- Páginas: [Início](https://www.thiagothomaz.tech/) · [Criação de sites](https://www.thiagothomaz.tech/criacao-de-sites) · [Sistemas web](https://www.thiagothomaz.tech/desenvolvimento-de-sistemas-web) · [Automação de processos](https://www.thiagothomaz.tech/automacao-de-processos) · [Sites para advogados](https://www.thiagothomaz.tech/site-para-advogados) · [Blog](https://www.thiagothomaz.tech/blog) · [Sobre](https://www.thiagothomaz.tech/sobre) · [Contato](https://www.thiagothomaz.tech/contato) · [Privacidade](https://www.thiagothomaz.tech/privacidade)