SEO Specialist - Otimização para Motores de Busca

O Especialista SEO é responsável por garantir que o sistema e landing pages sejam encontráveis, rápidos e bem ranqueados nos motores de busca.

Governanca Global

Esta skill segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/quality-gates.md, policies/token-efficiency.md, policies/stack-flexibility.md, policies/evals.md, policies/tool-safety.md e policies/anti-ai-writing.md.

Gate: conteúdo publicado (artigos, meta descriptions, headings) deve passar pelos 29 padrões de policies/anti-ai-writing.md antes de finalizar. Conteúdo com tells de IA penaliza percepção de autenticidade e pode afetar E-E-A-T.

Para templates de metadata, schema e checks de indexacao, consultar docs/skill-guides/seo-specialist.md apenas quando necessario.

Quando Usar

• otimizar indexacao, metadata, performance e semantica
• revisar landing pages ou paginas publicas com objetivo de descoberta

Quando Nao Usar

• para areas autenticadas sem indexacao
• para substituir Copy, Frontend ou Security como papel principal

Entradas Esperadas

• copy e estrutura da pagina
• contexto tecnico de performance e rendering
• objetivos de descoberta e palavras-chave

Saidas Esperadas

• recomendacoes de SEO tecnico e on-page
• metadata e requisitos de performance claros
• handoff claro para Frontend/Reviewer

Responsabilidades

1. Otimizar meta tags em todas as páginas (title, description, canonical, Open Graph, Twitter Card)
2. Implementar schema markup (JSON-LD) para dados estruturados
3. Garantir excelência em Core Web Vitals (LCP, FID, CLS, INP, TTFB)
4. Configurar sitemap.xml e robots.txt
5. Otimizar imagens e fontes para performance máxima
6. Garantir acessibilidade (impacta diretamente o SEO)
7. Assegurar HTML semântico em toda a aplicação
8. Conduzir keyword research e entregar a lista de keywords priorizada ANTES do Copy escrever
9. Definir o brief técnico de link building (off-page) — execução fica com Marketing/Conteúdo

Keyword Research

A pesquisa de palavra-chave é o passo 0 de qualquer projeto de SEO: descobrir como o usuário vai procurar pelo produto/serviço antes de escrever uma linha de conteúdo ou definir uma URL. Fonte: "SEO Prático" (Adriano Almeida, Casa do Código), cap. 4.

O output desta etapa é uma tabela de keywords decididas que alimenta o resto do pipeline: Copy (13/50) usa pra escrever, Frontend (04) usa pra URL/headings, e a própria 14 usa pra meta tags. SEO fornece as keywords; não inventa o produto.

Workflow de descoberta

1. Brainstorm bruto. Antes de ferramenta nenhuma, liste no papel como você acha que as pessoas buscariam. O livro chega a ~30 termos em 5 min pro caso "risoto" (como fazer risoto, receitas de arroz gourmet...). Peça a um amigo imparcial pra fazer o mesmo — quem está "atrás do balcão" tem visão enviesada de como o cliente pensa.
2. Entenda a cabeça do usuário (intent). A busca "perfeita" raramente é a que o usuário digita. Quem procura "risoto" pode procurar "arroz cremoso". Mapeie variações que vão além da descrição literal do produto.
3. Pesquise no próprio buscador (análise de concorrente). Busque cada termo no Google. Repare em: quais sites grandes ocupam o topo, quantos resultados são blogs (sinal de que dá pra entrar), adjetivos recorrentes nos títulos (são keywords que você não tinha mapeado), e se a keyword aparece na URL dos rankeados.
4. Explore a cauda longa. Termos genéricos ("carne") têm mais busca, mas concorrência feroz e intent difuso. Termos cauda longa ("quais os cortes de carne mais macios") têm menos busca mas conversão muito maior porque casam com intent específico.
5. Expanda com ferramentas. Use as ferramentas pra achar variações que nem um especialista lembraria (tabela em references/keyword-research.md).
6. Agrupe em dois baldes: conteúdo vs. negócio/venda. Keywords de conteúdo → pauta de blog pra atrair tráfego amplo. Keywords de negócio/venda → a página de venda do serviço, descrita como as pessoas realmente buscam.
7. Priorize por volume × dificuldade (KEI). Quando o conhecimento de negócio não basta, use o KEI (Keyword Effectiveness Index) — balanço entre volume e competitividade:

   KEI = (buscas por dia) ^ 2 / número de resultados
   

   Ex. ("chef em casa": 720 buscas/mês, 1,5M resultados): KEI = (720/30)^2 / 1.500.000 = 0,000384. Quanto maior o KEI, melhor. Volume vem do Google Keyword Planner; nº de resultados vem do total do Google pra busca exata. Cuidado com termos ambíguos ("personal" colide com personal trainer/stylist, inflando resultados).

Detalhe denso (ferramentas, exemplo KEI completo, template de tabela) em references/keyword-research.md — abrir só ao executar um keyword research de fato.

Fan-out query mapper (cobertura de sub-perguntas)

Antes de fechar a lista de keywords de uma página/pauta, decomponha a keyword principal nas sub-perguntas que um usuário — ou um LLM respondendo por fan-out de busca — precisaria resolver pra considerar o tópico coberto. Ex.: "como fazer risoto" decompõe em "qual arroz usar", "precisa de vinho branco", "como não empapar", "tempo de preparo", "dá pra congelar". Compare a lista de sub-perguntas contra o conteúdo já publicado (próprio e do concorrente que ranqueia): toda sub-pergunta sem página/seção que responda é um buraco de cobertura — vira pauta nova ou seção a adicionar na página existente, priorizado como qualquer outra keyword da tabela (passo 7).

Como documentar as keywords decididas

Keyword	Intent	Balde	Volume/mês	Dificuldade	KEI	Prioridade
chef a domicílio sp	transacional	negócio	480	média	0,000342	P0
como fazer risoto	informacional	conteúdo	alto	alta	—	P1 (blog)

A coluna Intent classifica: informacional (tutorial, "como"), transacional (compra/contratação), navegacional (marca). Isso direciona o tipo de página e o tom do Copy.

Nota sobre densidade de keyword

Keyword research decide os termos; não autoriza repeti-los. Keyword stuffing (repetir à exaustão) é penalizado pelo Penguin desde 2012 — 2 a 3 ocorrências naturais por página bastam. O aviso vive aqui porque é onde a tentação nasce; o tuning de conteúdo é do Copy.

Handoff de Keyword Research

• → Copy (13/50): recebe a tabela de keywords (intent + balde) ANTES de escrever.
• → Frontend (04): keyword principal vai pra URL (slug) e pra <h1>/headings. A 14 só especifica qual termo.
• → PO (01): se o research revelar demanda por algo fora do escopo do produto, é decisão de negócio/roadmap — devolver pro PO. SEO mapeia a demanda, PO decide se persegue.

Off-Page / Link Building

On-page não é tudo. O peso que outros sites dão ao seu — via links — é fator central de ranking (PageRank). Fonte: "SEO Prático", cap. 9-10.

Fronteira de papel: boa parte de link building é execução de Marketing/Conteúdo (escrever guest post, fechar parceria). O papel da 14 aqui é o brief técnico: estratégia de aquisição, critérios de qualidade, anchor text correto, uso de nofollow, e validar que os links no código estão saudáveis. A 14 não sai negociando backlink — especifica o que um bom backlink precisa ter.

Princípio: qualidade > quantidade, relevância contextual

Volume de links não importa — relevância importa. O link tem que vir de quem é autoridade no seu assunto. Um site de culinária linkado por veículo de fitness no contexto certo ganha boost; linkado por um banco, quase nada. Comprar links de diretórios sem conteúdo é o que o Penguin (2012) pune.

Critérios que os buscadores avaliam (vão no brief):

• A página que linka tem relevância maior que a minha?
• Vários domínios diferentes linkam (mais valioso que o mesmo site de novo)?
• Os conteúdos das duas páginas têm relação temática?
• Qual o anchor text e a posição do link (conteúdo > rodapé/sidebar)?

Anchor text e posicionamento (brief técnico — responsabilidade da 14)

• Anchor natural, nunca "clique aqui". O texto do link deve ser a keyword no contexto.
• Diversifique o anchor. Repetição idêntica em massa parece artificial.
• Posição importa. Link no começo/centro do conteúdo > rodapé/sidebar.
• rel="nofollow" onde não há controle. Comentários, UGC, links não-endossados não passam autoridade. Redes sociais marcam links como nofollow — curtidas/seguidores não entram no ranking, embora valham como canal que gera links naturais depois.
• Links internos contam. Mesmas regras (natural, bem descrito).

Estratégias de aquisição natural (execução de Marketing/Conteúdo)

A 14 documenta que se aplicam e qual o brief; quem escreve/negocia é Marketing:

1. Marketing de conteúdo — conteúdo original/relevante que atrai links sozinho (brief = keywords de conteúdo + critério; execução = Copy 13/50).
2. Guest blogging — escrever pra site terceiro relevante com link de volta.
3. Comentários e fórum marketing — participar de comunidades do nicho agregando valor.
4. Troca de links, parcerias e promoções — patrocínio/brinde em troca de link (decisão de orçamento = PO 01).
5. Press releases — matéria via RP pra emplacar em portal (decisão de negócio = PO 01).

Checklist de Link Building (brief técnico)

• Estratégia de aquisição definida e atribuída (dono: Marketing vs. PO)
• Critério de qualidade do backlink documentado (domínio relevante, autoridade > a nossa)
• Meta de diversidade de domínios referenciadores
• Anchor text natural e variado, keyword no contexto — nunca "clique aqui"
• Links de autoridade no conteúdo principal (não rodapé/sidebar)
• rel="nofollow" em comentários, UGC e links não-endossados
• Links internos descritivos e sem quebra (404 interno derruba ranking)
• Conteúdo original (Penguin penaliza duplicação e diretórios de link)

Handoff de Off-Page

• → Marketing Copy (13/50): executa guest posts, marketing de conteúdo, outreach.
• → PO (01): decisões de orçamento (PR pago, patrocínio, agência) e priorização de parcerias.
• → Frontend (04): implementa anchor text, posicionamento, nofollow.

Meta Tags - Template Padrão

src/app/layout.tsx

import type { Metadata } from 'next';

export function generateMetadata({
  title,
  description,
  url,
  image,
}: {
  title: string;
  description: string;
  url: string;
  image?: string;
}): Metadata {
  const siteName = 'Nome do Projeto';
  const defaultImage = '/og-image.png';

  return {
    title: {
      default: title,
      template: `%s | ${siteName}`,
    },
    description,
    alternates: {
      canonical: url,
    },
    openGraph: {
      title,
      description,
      url,
      siteName,
      images: [
        {
          url: image || defaultImage,
          width: 1200,
          height: 630,
          alt: title,
        },
      ],
      locale: 'pt_BR',
      type: 'website',
    },
    twitter: {
      card: 'summary_large_image',
      title,
      description,
      images: [image || defaultImage],
    },
    robots: {
      index: true,
      follow: true,
      googleBot: {
        index: true,
        follow: true,
        'max-video-preview': -1,
        'max-image-preview': 'large',
        'max-snippet': -1,
      },
    },
  };
}

Schema Markup - JSON-LD

src/components/seo/WebsiteSchema.tsx

export function WebsiteSchema({ url, name }: { url: string; name: string }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'WebSite',
    name,
    url,
    potentialAction: {
      '@type': 'SearchAction',
      target: `${url}/search?q={search_term_string}`,
      'query-input': 'required name=search_term_string',
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

src/components/seo/OrganizationSchema.tsx

export function OrganizationSchema({
  name,
  url,
  logo,
  sameAs,
}: {
  name: string;
  url: string;
  logo: string;
  sameAs: string[];
}) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Organization',
    name,
    url,
    logo,
    sameAs,
    contactPoint: {
      '@type': 'ContactPoint',
      contactType: 'customer service',
      availableLanguage: ['Portuguese'],
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

src/components/seo/FAQSchema.tsx

interface FAQItem {
  question: string;
  answer: string;
}

export function FAQSchema({ items }: { items: FAQItem[] }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    mainEntity: items.map((item) => ({
      '@type': 'Question',
      name: item.question,
      acceptedAnswer: {
        '@type': 'Answer',
        text: item.answer,
      },
    })),
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Core Web Vitals - Metas Obrigatórias

Métrica        Alvo         Descrição
─────────────────────────────────────────────────────────────
LCP            < 2.5s       Largest Contentful Paint — tempo até o maior elemento visível
FID            < 100ms      First Input Delay — tempo de resposta à primeira interação
CLS            < 0.1        Cumulative Layout Shift — estabilidade visual da página
INP            < 200ms      Interaction to Next Paint — responsividade geral
TTFB           < 800ms      Time to First Byte — velocidade do servidor

Todas as métricas devem estar na zona verde do Google PageSpeed Insights.

Checkpoint: rodar PageSpeed Insights (ou Lighthouse local) → se qualquer métrica ficar fora da zona verde, aplicar a otimização correspondente (LCP alto → lazy load de imagem abaixo do fold; CLS alto → dimensões reservadas em imagem/ad; TTFB alto → cache/CDN) → rodar de novo. Repetir até as 5 métricas estarem verdes na mesma medição — não é aceitável "3 de 5 verde, os outros 2 são aceitáveis".

Otimizações Obrigatórias

next.config.js

next.config.js

const nextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
  experimental: {
    optimizeCss: true,
  },
  compress: true,
  poweredByHeader: false,
};

module.exports = nextConfig;

Imagens

Regras inegociáveis:

• Sempre usar next/image — nunca <img> nativo
• Prioridade de formato: AVIF > WebP > PNG
• Alt text obrigatório em TODAS as imagens — sem exceção
• Dimensões explícitas (width e height) em todas as imagens
• priority para imagens hero (above the fold)

src/components/ui/OptimizedImage.tsx

import Image from 'next/image';

interface OptimizedImageProps {
  src: string;
  alt: string;
  width: number;
  height: number;
  priority?: boolean;
  className?: string;
}

export function OptimizedImage({
  src,
  alt,
  width,
  height,
  priority = false,
  className,
}: OptimizedImageProps) {
  return (
    <Image
      src={src}
      alt={alt}
      width={width}
      height={height}
      priority={priority}
      loading={priority ? 'eager' : 'lazy'}
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
      className={className}
    />
  );
}

Fontes

• Sempre usar next/font (self-hosted, zero CLS)
• font-display: swap obrigatório

src/app/layout.tsx

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="pt-BR" className={inter.variable}>
      <body>{children}</body>
    </html>
  );
}

Lazy Loading e Performance

• Dynamic imports para tudo abaixo do fold
• loading="lazy" em imagens e iframes fora da viewport
• Defer em scripts de terceiros

src/app/page.tsx

import dynamic from 'next/dynamic';

const FAQ = dynamic(() => import('@/components/sections/FAQ'));
const Testimonials = dynamic(() => import('@/components/sections/Testimonials'));
const Footer = dynamic(() => import('@/components/layout/Footer'));

src/components/ThirdPartyScripts.tsx

import Script from 'next/script';

export function ThirdPartyScripts() {
  return (
    <>
      <Script
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"
        strategy="afterInteractive"
      />
      <Script id="gtag-init" strategy="afterInteractive">
        {`window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXX');`}
      </Script>
    </>
  );
}

HTML Semântico - Referência

Correto                    Errado
──────────────────────────────────────────
<header>                   <div class="header">
<nav>                      <div class="nav">
<main>                     <div class="main">
<section>                  <div class="section">
<article>                  <div class="article">
<aside>                    <div class="sidebar">
<footer>                   <div class="footer">
<h1> a <h6>                <div class="title">
<figure> + <figcaption>    <div class="image-wrapper">
<time datetime="">         <span class="date">
<address>                  <div class="contact">
<mark>                     <span class="highlight">

Regras:

• Uma única <h1> por página
• Hierarquia de headings sem pular níveis (h1 > h2 > h3)
• <main> uma única vez por página
• <nav> com aria-label quando houver mais de uma navegação

SEO Checklist

Técnico

• Sitemap.xml gerado e enviado ao Google Search Console
• robots.txt configurado corretamente
• Tags canonical em todas as páginas
• HTTPS ativo em todo o site
• Sem conteúdo duplicado
• URLs amigáveis (slug legível, sem IDs expostos)
• Redirects 301 para URLs antigas
• Página 404 customizada com navegação
• Carregamento < 3s em conexão 3G

On-Page

• H1 única e descritiva em cada página
• Title tag < 60 caracteres
• Meta description < 160 caracteres
• Alt text em todas as imagens
• Links internos entre páginas relacionadas
• Breadcrumbs implementados
• Conteúdo mínimo de 300 palavras por página

Acessibilidade (Impacta SEO)

• Contraste mínimo 4.5:1 (WCAG AA)
• Navegação completa via Tab
• ARIA labels em elementos interativos
• Skip to content implementado
• Labels em todos os campos de formulário
• Focus visível em todos os elementos interativos

Performance

• Core Web Vitals na zona verde
• Imagens otimizadas (AVIF/WebP via next/image)
• Fontes com next/font (zero CLS)
• Bundle splitting (dynamic imports)
• Preload de recursos críticos
• CDN configurado para assets estáticos

GEO/AEO

Ver seção dedicada ## GEO/AEO — Otimização para LLMs e Answer Engines abaixo, com checklist completo de citação por motores generativos (clear claims, quotable headings, FAQ/HowTo schema, E-E-A-T, tabelas, llms.txt).

GEO/AEO — Otimização para LLMs e Answer Engines

LLMs como ChatGPT, Claude, Perplexity e Google AI Overviews viraram a primeira camada de descoberta para muitos usuários — eles fazem a pergunta no chat antes de abrir o Google. GEO (Generative Engine Optimization) e AEO (Answer Engine Optimization) cobrem técnicas para tornar o conteúdo extraível, citável e referenciável por esses sistemas. Diferente de SEO clássico (que otimiza ranking em SERP), GEO/AEO otimiza para ser a fonte que o LLM cita textualmente na resposta gerada.

Conteúdo citável

LLMs extraem trechos curtos e atômicos. Estruture o conteúdo para facilitar essa extração:

• Clear atomic claims: 1 fato por sentença. Evite parágrafos com múltiplas afirmações concatenadas — o LLM precisa conseguir citar uma frase isolada sem perder contexto.
  • Ruim: "A Vitamina D é importante para os ossos e também tem papel no sistema imune, sendo que sua deficiência afeta 50% da população em climas frios."
  • Bom: "A Vitamina D regula a absorção de cálcio. Sua deficiência afeta 50% da população em climas frios (Holick, 2024)."
• Quotable H2/H3 como perguntas: headings em forma de pergunta direta batem com a query do usuário no LLM. "Como configurar SSL no Nginx" extrai melhor que "Configuração de SSL".
• Parágrafos curtos: máximo 3-4 frases. Blocos longos são descartados na extração.
• TL;DR no topo: 2-3 linhas resumindo o artigo logo após o H1. LLMs frequentemente citam o TL;DR como resposta direta.
• Listas numeradas e com bullets: estruturas enumeradas são extraídas com fidelidade muito maior que prosa corrida.

Structured data específico

Além do schema clássico (Website, Organization), priorize tipos que LLMs consomem para grounding:

• FAQPage schema (já tem template em FAQSchema.tsx — ver seção ## Schema Markup - JSON-LD acima): cada par pergunta/resposta vira candidato a citação direta em AI Overviews.
• FAQ pós-artigo baseada em pergunta real do leitor: adicionar um bloco de FAQ ao final de todo artigo, com perguntas extraídas de fontes reais (comentários, suporte, "as pessoas também perguntam" do Google, fan-out do keyword research acima) — não perguntas inventadas pra preencher espaço. Backlinko documentou 32% de lift de tráfego orgânico num experimento controlado com 21 posts ao adicionar esse bloco. Marcar com FAQPage schema.
• HowTo schema: para tutoriais e procedimentos. Cada step é extraído individualmente.
• Article schema com metadados completos: author (com @type: Person e url para bio), datePublished, dateModified (LLMs ranqueiam por frescor — conteúdo sem dateModified perde relevância em queries que pedem informação atual), publisher, headline, description.

const articleSchema = {
  '@context': 'https://schema.org',
  '@type': 'Article',
  headline: title,
  author: {
    '@type': 'Person',
    name: 'Nome do Autor',
    url: 'https://site.com/sobre/autor',
  },
  datePublished: '2025-01-15',
  dateModified: '2025-03-20',
  publisher: {
    '@type': 'Organization',
    name: 'Nome da Publicação',
    logo: { '@type': 'ImageObject', url: 'https://site.com/logo.png' },
  },
};

E-E-A-T para LLMs

Experience, Expertise, Authoritativeness, Trustworthiness. LLMs filtram fontes por sinais de autoridade explícitos:

• Bio do autor visível na página: nome, credenciais, link para perfil profissional. Não basta no schema — precisa estar no HTML renderizado.
• Fontes externas linkadas: sempre que citar dado, estudo ou stat, link para a fonte primária. LLMs verificam grounding via outbound links.
• Datas claras em todo conteúdo: <time datetime="2025-03-20">20 de março de 2025</time> visível no corpo, não só no schema.
• Contradições explícitas: não use "alguns dizem X" — atribua nominalmente. "Smith (2024) defende X, mas Jones (2025) contradiz com Y baseado em dados de Z." Isso aumenta a confiabilidade percebida e dá ao LLM material para citar com nuance.
• Sobre/About page robusta: com bio dos contribuidores, missão editorial, processo de fact-checking se aplicável.

Tabelas e listas

LLMs extraem tabelas com altíssima fidelidade — frequentemente reproduzem a tabela inteira na resposta. Use tabelas sempre que comparar:

• Planos/preços
• Features entre alternativas
• Antes/depois
• Especificações técnicas
• Prós/contras

Listas com bullets ou numeradas vencem prosa para qualquer enumeração. Se tem mais de 3 itens equivalentes, vire lista.

llms.txt