SEO & GEO — Relatório de Oportunidades

Documento interno. Análise do estado atual e oportunidades de otimização para busca orgânica (Google) e busca gerada por IA (ChatGPT, Perplexity, Gemini, Claude).

1. O que já está implementado (pontos positivos)

  • lang="pt-BR" no HTML — sinaliza idioma e região corretamente
  • <title> e <meta name="description"> em todas as páginas via Layout
  • <link rel="canonical"> dinâmico gerado pelo Astro
  • robots meta com max-snippet:-1, max-image-preview:large — permite previews ricos no Google
  • noindex/nofollow por página via Keystatic (controle granular)
  • Sitemap XML gerado automaticamente pelo @astrojs/sitemap
  • Site estático (Astro) — carregamento extremamente rápido, favorece Core Web Vitals
  • Breadcrumbs visuais em páginas internas
  • URLs limpas e semânticas (/servicos/manutencao/computador/)
  • Busca interna com índice estático (search.json) — não prejudica performance

2. O que está faltando — Alta Prioridade

2.1 Open Graph e Twitter Card (Social + IA)

Nenhuma tag OG está implementada. Isso afeta:

  • Compartilhamento em redes sociais (preview sem imagem/título)
  • Indexação por crawlers de IA (Perplexity, ChatGPT usam OG para contexto)

O que adicionar no <head> do Layout:

<meta property="og:type" content="website" />
<meta property="og:url" content={canonicalUrl} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:image" content="https://henrique.pro/og-default.jpg" />
<meta property="og:locale" content="pt_BR" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content={title} />
<meta name="twitter:description" content={description} />
<meta name="twitter:image" content="https://henrique.pro/og-default.jpg" />

Criar uma imagem OG padrão (1200x630px) e versões específicas por página de serviço.

2.2 JSON-LD — Dados Estruturados (Schema.org)

Ausência total de dados estruturados. Este é o maior gap técnico. O Google e os modelos de IA usam schema.org para entender o negócio com precisão.

Schema LocalBusiness (na home e em todas as páginas)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Henrique.pro",
  "description": "Suporte técnico de TI e informática avançado para residências e empresas em todo o Brasil.",
  "url": "https://henrique.pro",
  "telephone": "+55-xx-xxxxx-xxxx",
  "areaServed": "BR",
  "priceRange": "$$",
  "knowsAbout": ["Suporte TI", "Manutenção de Computadores", "Redes", "Programação"],
  "serviceType": "Serviço de TI"
}

Schema Service (em cada página de serviço)

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Manutenção de Computador",
  "provider": { "@type": "LocalBusiness", "name": "Henrique.pro" },
  "description": "...",
  "areaServed": "BR"
}

Schema BreadcrumbList (em todas as páginas internas)

Já existe o breadcrumb visual — basta adicionar o schema equivalente. O Google exibe isso como sitelinks nos resultados.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Início", "item": "https://henrique.pro" },
    { "@type": "ListItem", "position": 2, "name": "Serviços", "item": "https://henrique.pro/servicos" },
    { "@type": "ListItem", "position": 3, "name": "Manutenção", "item": "https://henrique.pro/servicos/manutencao" }
  ]
}

Schema Person (na página Sobre)

Posiciona você como autoridade, não só o negócio.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Henrique",
  "jobTitle": "Especialista em TI",
  "url": "https://henrique.pro/sobre",
  "knowsAbout": ["Suporte TI", "Redes", "Desenvolvimento Web", "Manutenção"]
}

Em qualquer página que tiver perguntas e respostas. O Google destaca FAQs nos resultados e os modelos de IA as consomem diretamente.

2.3 Imagem OG por serviço

Criar imagens OG dinâmicas ou estáticas por categoria de serviço aumenta o CTR em compartilhamentos e o entendimento por crawlers visuais de IA.

3. SEO de Conteúdo — Oportunidades

3.1 Páginas de serviço precisam de mais conteúdo

As páginas de subcategoria (/servicos/manutencao/computador/) provavelmente têm pouco texto. Para ranquear, cada página precisa responder perguntas reais:

  • O que é o serviço
  • Quando contratar
  • Como funciona o atendimento
  • Quanto tempo leva
  • Quais regiões são atendidas

Mínimo recomendado: 300-500 palavras por página de serviço.

3.2 Blog ou Cheatsheet como vetor de tráfego

A página /cheatsheet já existe — é um canal perfeito para capturar buscas informacionais. Conteúdo tipo:

  • "Como resolver erro X no Windows"
  • "O que fazer quando o notebook não liga"
  • "Diferença entre formatação e reinstalação"

Essas buscas têm intenção de solução de problema — o leitor que resolve com seu conteúdo tende a contratar quando não consegue.

3.3 Páginas por cidade/região

A estrutura /br/[cidade]/ já existe no código. Conteúdo localizado rankeia muito bem para buscas como "suporte técnico São Paulo" ou "técnico de informática Campinas".

Cada página regional deveria ter:

  • H1 com cidade + serviço
  • Parágrafo mencionando bairros e regiões
  • Schema LocalBusiness com endereço/área específica

4. GEO — Otimização para IA (ChatGPT, Perplexity, Gemini, Claude)

Os modelos de linguagem respondem perguntas de usuários sobre serviços. Para aparecer nessas respostas:

4.1 Escreva como os modelos leem

IA prefere conteúdo estruturado e diretivo:

  • Use listas, subtítulos claros, definições explícitas
  • Responda a pergunta no primeiro parágrafo, depois aprofunde
  • Evite linguagem de marketing vaga ("soluções inovadoras") — seja específico ("atendimento em até 2 horas")

4.2 Autoridade de entidade

Os LLMs vinculam profissionais a áreas de conhecimento pelo volume de menções consistentes. Estratégias:

  • Presença no LinkedIn com especialidades listadas
  • Google Business Profile atualizado com categorias corretas
  • Menções em diretórios técnicos (Reclame Aqui, GetNinjas como presença, não dependência)
  • Citações em fóruns técnicos (GitHub, Stack Overflow com perfil linkando o site)

4.3 Criar um arquivo llms.txt

Padrão emergente (proposto por Jeremy Howard) — arquivo /llms.txt na raiz do site com uma descrição clara do negócio, serviços e propósito. Crawlers de IA como o do Perplexity já o consomem.

# henrique.pro

> Suporte técnico de TI e informática avançado para residências e empresas em todo o Brasil.

Especialidades: manutenção de computadores, notebooks, redes, suporte remoto, programação, consultoria de TI.

Diferencial: atendimento para casos complexos que outros técnicos não conseguem resolver.

## Serviços
- [Suporte TI](https://henrique.pro/servicos/suporte-ti/)
- [Manutenção](https://henrique.pro/servicos/manutencao/)
- [Programação](https://henrique.pro/servicos/programacao/)
- [Segmentos](https://henrique.pro/servicos/segmentos/)

4.4 Schema speakable (para assistentes de voz e IA)

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".hero-content", ".subcat-group-title"]
  }
}

5. Core Web Vitals e Performance

O site já tem vantagem por ser Astro estático. Pontos a monitorar:

  • LCP (Largest Contentful Paint): garantir que a fonte Inter não bloqueie render. Já tem preconnect para Google Fonts — considerar font-display: swap explícito.
  • CLS (Cumulative Layout Shift): a barra sticky que aparece ao scroll pode causar CLS se não estiver fora do fluxo. Está com position: fixed — correto.
  • INP (Interaction to Next Paint): os scripts is:inline executam no main thread. Verificar se os observers causam jank em mobile.

Ferramenta: Google Search Console (configurar se ainda não estiver) + PageSpeed Insights por URL.

6. Avaliações — Rich Snippets e Sistema Próprio

6.1 O que são Review Snippets e por que importam

Review snippets são as estrelas douradas que aparecem nos resultados do Google abaixo do título da página. Eles aumentam o CTR em até 35% e são um sinal de confiança tanto para usuários quanto para modelos de IA ao recomendar profissionais.

O Google exibe estrelas quando a página contém o schema Review ou AggregateRating com dados verificáveis. A regra central: as avaliações precisam ser coletadas no próprio site — o Google não aceita schema de reviews que redireciona para dados de terceiros (Google Maps, Reclame Aqui etc.) como justificativa para exibir estrelas nas suas próprias páginas.

6.2 Schema de Avaliação Nativa

Para que o Google exiba estrelas nos resultados de páginas de serviço:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Manutenção de Computador",
  "provider": { "@type": "LocalBusiness", "name": "Henrique.pro" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "47",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Carlos M." },
      "reviewRating": { "@type": "Rating", "ratingValue": "5" },
      "reviewBody": "Resolveu um problema que dois outros técnicos não conseguiram. Atendimento rápido e claro.",
      "datePublished": "2025-03-15"
    }
  ]
}

O aggregateRating pode ser colocado também no schema LocalBusiness da home para que as estrelas apareçam no resultado da página principal.

6.3 Ideia de Implementação — Sistema de Avaliação Próprio

Dado o projeto futuro de diretório para profissionais de alto nível, um sistema nativo de avaliação é estratégico por três razões: controle total dos dados, schema válido para rich snippets, e diferenciação frente a plataformas genéricas como GetNinjas.

Arquitetura sugerida (Astro + backend leve)

O site atual é estático (Astro), o que exige um backend para receber e armazenar avaliações. Opções viáveis sem adicionar complexidade desnecessária:

Opção A — Formulário + banco simples (recomendada para início)

  • Frontend: formulário de avaliação em Astro com componente React (já suportado no projeto)
  • Backend: endpoint em src/pages/api/avaliar.ts usando Astro SSR (o projeto já usa @astrojs/node)
  • Armazenamento: banco simples como PlanetScale (MySQL serverless) ou Supabase (PostgreSQL)
  • Moderação: avaliação entra com status pendente, você aprova antes de publicar
  • Geração do schema: na hora do build, as avaliações aprovadas são buscadas e injetadas no JSON-LD de cada página de serviço

Opção B — Solução headless de reviews (para escalar como diretório)

  • Usar um serviço como Trustindex ou uma implementação própria com Keystatic como CMS de moderação
  • Cada avaliação aprovada vira um arquivo .json em src/data/avaliacoes/[servico]/
  • O build lê esses arquivos e gera os schemas automaticamente

Fluxo de avaliação confiável (anti-fake)

Para que o Google e os usuários confiem nas avaliações, o sistema precisa de autenticidade verificável:

  1. Avaliação vinculada a atendimento: o cliente só recebe o link de avaliação após conclusão do serviço, enviado via WhatsApp ou email com token único de uso único
  2. Token com validade: o link expira em 7 dias e só pode ser usado uma vez por CPF/email
  3. Campos mínimos: nome (pode ser parcial), tipo de serviço realizado, nota (1-5), comentário livre
  4. Moderação manual: toda avaliação passa por aprovação antes de aparecer no site e no schema
  5. Data e serviço no schema: o datePublished e o vínculo com o serviço específico são obrigatórios para o Google considerar o review legítimo

Estrutura de dados sugerida

{
  "id": "av_20250315_001",
  "servico_slug": "manutencao/computador",
  "autor_nome": "Carlos M.",
  "nota": 5,
  "comentario": "Resolveu um problema que dois outros técnicos não conseguiram.",
  "data": "2025-03-15",
  "token_usado": "tk_abc123",
  "status": "aprovado"
}

Quando fizer sentido construir

O sistema de avaliações nativo compensa quando você tiver volume mínimo de atendimentos para popular com reviews reais. Com menos de 10 avaliações, o schema de AggregateRating pode ser contraproducente (Google penaliza ratings com poucos reviews se parecerem manipulados). Estratégia:

  • Fase 1 (agora): coletar avaliações no Google Business Profile e no WhatsApp, guardar os textos
  • Fase 2 (ao lançar o diretório): migrar as avaliações reais para o sistema próprio com consentimento do cliente, construindo o banco inicial com credibilidade

6.4 Reviews e IA (GEO)

Modelos como ChatGPT e Perplexity, ao responder "qual técnico de TI contratar", ponderam menções positivas consistentes em múltiplas fontes. Além do sistema próprio:

  • Peça avaliações no Google Business Profile ativamente — é a fonte com maior peso nos LLMs hoje
  • Avaliações com texto descritivo ("resolveu problema de placa-mãe") valem mais que notas sem comentário, tanto para SEO quanto para IA
  • Responda todas as avaliações recebidas — o Google lê as respostas como sinal de engajamento ativo

7. Priorização — O que fazer primeiro

PrioridadeAçãoImpacto
1JSON-LD LocalBusiness na homeAlto — identidade do negócio para Google e IA
2Open Graph + Twitter Card no LayoutAlto — CTR e indexação de IA
3JSON-LD BreadcrumbList nas páginas internasMédio — sitelinks e navegação
4Conteúdo nas páginas de serviço (300+ palavras)Alto — ranqueamento orgânico
5llms.txt na raizBaixo esforço, alto potencial GEO
6JSON-LD Service por subcategoriaMédio — rich results para serviços
7Google Business Profile completo + coleta ativa de reviewsAlto — busca local, Maps e IA
8JSON-LD FAQPage em páginas-chaveMédio — featured snippets
9Schema Person na página SobreMédio — autoridade de entidade
10Imagens OG por serviçoMédio — CTR em compartilhamentos
11Sistema de avaliação nativo (Fase 1: coleta via token)Alto — rich snippets de estrelas + base para diretório
12Schema AggregateRating nas páginas de serviçoAlto — estrelas nos resultados do Google
13SEO de imagens (alt, WebP, lazy, schema ImageObject)Médio — busca de imagens + velocidade
14HTML semântico (article, section, aside, time, address)Médio — compreensão por IA e acessibilidade
15Heading hierarchy auditada por páginaAlto — fator de ranqueamento direto
16Internal linking estratégico entre serviçosAlto — PageRank interno + descoberta
17hreflang para futura expansão regionalBaixo (agora), Alto (ao escalar)

8. SEO de Imagens — Práticas de Ponta

Imagens são o segundo maior vetor de tráfego orgânico depois do texto. A busca de imagens do Google e os crawlers de IA consomem atributos e formatos específicos.

8.1 Formato e peso

  • WebP obrigatório — 25-35% menor que JPEG/PNG com qualidade equivalente. Astro tem @astrojs/image para conversão automática no build.
  • AVIF quando possível — ainda mais eficiente que WebP, já suportado por 95% dos browsers modernos. Use <picture> com fallback:
<picture>
  <source srcset="/imagem.avif" type="image/avif" />
  <source srcset="/imagem.webp" type="image/webp" />
  <img src="/imagem.jpg" alt="Técnico realizando manutenção de computador em São Paulo" width="800" height="600" loading="lazy" decoding="async" />
</picture>
  • Tamanho máximo por imagem: 100-150KB para imagens de conteúdo, 200KB para hero
  • Sempre declarar width e height explícitos para evitar CLS

8.2 Atributo alt — a parte mais negligenciada

O alt é lido pelo Google, pelos modelos de IA e pelos leitores de tela. Regras:

  • Descritivo e específico: "técnico consertando notebook Dell com tela quebrada" em vez de "foto"
  • Com palavra-chave natural quando fizer sentido contextual — nunca forçado
  • Imagens decorativas: alt="" (string vazia, nunca omitir o atributo)
  • Ícones SVG: aria-hidden="true" (já implementado no projeto)
  • Máximo 125 caracteres

Exemplos corretos para este site:

alt="Manutenção de computador desktop sendo realizada por técnico especializado"
alt="Diagrama de rede local configurada para empresa de pequeno porte"
alt="Notebook com tela azul da morte sendo diagnosticado"

8.3 Nomes de arquivo

O Google indexa o nome do arquivo como sinal contextual:

manutencao-computador-sao-paulo.webp   ✓
IMG_20240315_001.jpg                   ✗
foto1.png                              ✗

Use kebab-case, palavras-chave relevantes, sem caracteres especiais.

8.4 Schema ImageObject

Para imagens principais de páginas de serviço, adicionar schema:

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "url": "https://henrique.pro/imagens/manutencao-computador.webp",
  "width": 1200,
  "height": 800,
  "caption": "Manutenção de computador — Henrique.pro",
  "encodingFormat": "image/webp"
}

8.5 Lazy loading e prioridade

<!-- Hero (above the fold): NUNCA lazy, deve carregar imediatamente -->
<img src="hero.webp" alt="..." loading="eager" fetchpriority="high" />

<!-- Conteúdo abaixo do fold: sempre lazy -->
<img src="servico.webp" alt="..." loading="lazy" decoding="async" />

8.6 Sitemap de imagens

O @astrojs/sitemap não inclui imagens por padrão. Para indexação de imagens no Google Image Search, adicionar ao sitemap:

<url>
  <loc>https://henrique.pro/servicos/manutencao/computador/</loc>
  <image:image>
    <image:loc>https://henrique.pro/imagens/manutencao-computador.webp</image:loc>
    <image:title>Manutenção de Computador</image:title>
    <image:caption>Serviço especializado de manutenção de computadores</image:caption>
  </image:image>
</url>

9. HTML Semântico — Tags que o Google e a IA leem

O HTML semântico não é só acessibilidade — é sinal direto de estrutura de conteúdo para crawlers.

9.1 Hierarquia de headings (H1-H6)

Regra absoluta: uma única H1 por página, descrevendo exatamente o tema central.

H1: Manutenção de Computador em São Paulo        ← uma só
  H2: O que inclui o serviço                     ← seções principais
    H3: Diagnóstico de hardware                  ← subsections
    H3: Limpeza e substituição de componentes
  H2: Como funciona o atendimento
  H2: Perguntas frequentes
    H3: Qual o prazo de entrega?

Erros comuns a evitar:

  • H1 vazio ou genérico ("Bem-vindo")
  • Pular níveis (H1 → H3 sem H2)
  • Usar headings para estilo em vez de estrutura
  • Múltiplas H1 na mesma página

9.2 Tags semânticas essenciais

<!-- Conteúdo principal da página -->
<main>...</main>

<!-- Artigo autônomo (post de blog, case study) -->
<article>
  <header>
    <h1>Como resolver erro de tela azul no Windows 11</h1>
    <time datetime="2025-03-15">15 de março de 2025</time>
  </header>
  <p>...</p>
  <footer>
    <address>
      Por <a href="/sobre">Henrique</a> — Especialista em TI
    </address>
  </footer>
</article>

<!-- Seção temática com heading próprio -->
<section aria-labelledby="titulo-servicos">
  <h2 id="titulo-servicos">Serviços de Manutenção</h2>
</section>

<!-- Conteúdo complementar (relacionados, sidebar) -->
<aside aria-label="Serviços relacionados">...</aside>

<!-- Navegação nomeada (múltiplos nav na página) -->
<nav aria-label="Navegação principal">...</nav>
<nav aria-label="Breadcrumb">...</nav>

9.3 Tag <address> para dados de contato

O Google usa <address> para extrair informações de contato do negócio:

<address>
  <strong>Henrique.pro</strong><br />
  Atendimento em todo o Brasil<br />
  <a href="tel:+5511999999999">+55 (11) 99999-9999</a><br />
  <a href="mailto:contato@henrique.pro">contato@henrique.pro</a>
</address>

9.4 Tag <time> para datas

Importante para crawlers identificarem frescor do conteúdo:

<time datetime="2025-03-15T10:00:00-03:00">15 de março de 2025</time>

9.5 Atributos aria-label e aria-labelledby

Além de acessibilidade, ajudam crawlers a entender regiões da página:

<section aria-labelledby="h-avaliacoes">
  <h2 id="h-avaliacoes">O que nossos clientes dizem</h2>
</section>

9.6 Meta tags complementares (além de title e description)

<!-- Autor do conteúdo -->
<meta name="author" content="Henrique" />

<!-- Data de publicação/atualização (para artigos) -->
<meta property="article:published_time" content="2025-03-15" />
<meta property="article:modified_time" content="2025-06-01" />

<!-- Tema de cor para mobile (aparece na barra do navegador) -->
<meta name="theme-color" content="#0284c7" />

<!-- Prevenção de tradução automática para conteúdo técnico -->
<meta name="google" content="notranslate" />  <!-- só se necessário -->

10. Internal Linking — PageRank Interno e Descoberta

O Google distribui autoridade de página em página via links internos. Um site bem linkado internamente ranqueia melhor mesmo com menos backlinks externos.

10.1 Estratégia de hub and spoke

/servicos (hub)
  └── /servicos/manutencao (hub secundário)
        ├── /servicos/manutencao/computador (spoke)
        ├── /servicos/manutencao/notebook (spoke)
        └── /servicos/manutencao/pc-gamer (spoke)
  • Cada hub deve linkar para todos os spokes filhos
  • Cada spoke deve linkar de volta ao hub pai
  • Spokes relacionados devem se linkar entre si ("Veja também: Manutenção de Notebook")

10.2 Anchor text descritivo

<!-- Ruim -->
<a href="/servicos/manutencao/computador">clique aqui</a>
<a href="/servicos/manutencao/computador">saiba mais</a>

<!-- Bom -->
<a href="/servicos/manutencao/computador">manutenção de computador</a>
<a href="/servicos/manutencao/computador">serviço de formatação e limpeza de PC</a>

Nos textos de cada página de serviço, mencionar naturalmente serviços relacionados com links. Exemplo em página de manutenção de computador:

"Após a limpeza física, verificamos também a integridade da rede local. Se precisar de configuração de redes, oferecemos atendimento combinado com desconto."

O rodapé é uma oportunidade de linkar todas as categorias principais, presente em todas as páginas. Já existe footer no projeto — verificar se linka para páginas de serviço além da navegação principal.

11. Sinais de Autoridade — E-E-A-T

O Google avalia Experiência, Expertise, Autoridade e Confiança. Para um técnico de TI independente, isso é crítico.

11.1 Experience (Experiência)

  • Fotos reais do trabalho (não stock photos) com alt descritivo
  • Cases reais: "problema X resolvido em Y horas" com resultado concreto
  • Vídeos curtos de diagnóstico (podem ser linkados da página de serviço)

11.2 Expertise (Especialização)

  • Página "Sobre" detalhada com formação, certificações, anos de experiência
  • Schema Person com hasCredential e alumniOf
  • Publicações técnicas no Cheatsheet com autoria explícita (<address> + schema Article)

11.3 Authoritativeness (Autoridade)

  • Backlinks de qualidade: fóruns técnicos, comunidades Linux/Windows, GitHub com projetos reais
  • Participação em comunidades como Stack Overflow, Reddit r/techsupport (com link no perfil)
  • Menções em veículos de TI locais

11.4 Trustworthiness (Confiança)

  • HTTPS ativo (já deve estar com Cloudflare ou similar)
  • Política de privacidade e termos de serviço vinculados no footer
  • CNPJ/MEI visível no site (reforça legitimidade)
  • Número de telefone real e verificável
  • Schema ContactPoint no LocalBusiness
"contactPoint": {
  "@type": "ContactPoint",
  "telephone": "+55-11-99999-9999",
  "contactType": "customer service",
  "availableLanguage": "Portuguese",
  "hoursAvailable": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "08:00",
    "closes": "18:00"
  }
}

12. Checklist Final — Auditoria por Página

Use isto para auditar cada página antes de publicar:

Técnico

  • [ ] Title único, 50-60 caracteres, com palavra-chave principal
  • [ ] Meta description única, 120-160 caracteres, com CTA implícito
  • [ ] H1 único e descritivo com palavra-chave
  • [ ] Canonical URL correta
  • [ ] Open Graph completo (og:title, og:description, og:image, og:url)
  • [ ] JSON-LD apropriado para o tipo de página

Conteúdo

  • [ ] Mínimo 300 palavras (páginas de serviço), 600+ (artigos/cheatsheet)
  • [ ] Heading hierarchy lógica (H1 → H2 → H3)
  • [ ] Internal links para páginas relacionadas
  • [ ] Anchor text descritivo nos links

Imagens

  • [ ] Formato WebP ou AVIF
  • [ ] alt descritivo em todas as imagens de conteúdo
  • [ ] width e height declarados
  • [ ] loading="lazy" exceto above-the-fold
  • [ ] Nome de arquivo semântico

Acessibilidade e semântica

  • [ ] <main> envolve o conteúdo principal
  • [ ] <nav aria-label> nomeado
  • [ ] Contraste de cor adequado (já tem toggle de acessibilidade)
  • [ ] Links com texto significativo (sem "clique aqui")