GEO Score Checker
Ciência, matemática e uso real em cliente piloto

Visibility OS baseado em literatura acadêmica 2025-2026. 8 dimensões stage-aware, 4 LLMs em paralelo (gpt-4o-mini, claude-haiku-4-5, gemini-2.5-pro, sonar), fila assíncrona no Supabase, preference learning. Inferência estatística com Cohen/Fleiss kappa e bootstrap BCa. Aplicado ao vivo no rebrand Stone em 15-mai-2026.

Números fidedignos · 27 de maio de 2026

Cada KPI é rastreável: 8 dimensões em score-calculator.ts, modelos LLM em llm-probes.ts, 10 heurísticas seed em preference-engine.ts, cliente Stone documentado em geo-stone/audits/www-stone-com-br/.

Maio 2026 · da entrega técnica ao uso em cliente real

Da semana 18 à 21, o checker passou de ferramenta interna para instrumento ao vivo num cliente pagante. Cada cartão é printável para uso direto em slides executivos.

Casos reais usando o checker

Por que esta ferramenta existe

A literatura 2025-2026 sobre Generative Engine Optimization (GEO) derrubou três premissas que ainda moldavam praticamente toda ferramenta de SEO/GEO do mercado:

1. Score é série temporal, não número único. Cada estágio da pipeline do motor generativo (retrieval → reranking → generation) precisa ser medido separadamente. Otimizações na geração podem degradar o retrieval — o checker precisa ser stage-aware. (SAGEO Arena, arXiv:2602.12187)
2. Cada engine é uma realidade informacional distinta. A mesma query retorna fontes, estilos e níveis de hedging diferentes entre ChatGPT, Claude, Gemini e Perplexity. A métrica primária passa a ser a divergência entre engines (answer bubble). (Answer Bubbles, arXiv:2603.16138)
3. O alvo real não é ranking, é Exposure + Faithful Credit + Causal Impact. Não basta aparecer — a IA precisa citar corretamente, e precisamos saber se uma mudança no site causou o ganho. (CC-GSEO-Bench, arXiv:2509.05607)

O GEO Score Checker v2.0 foi desenhado de trás para frente a partir dessas três leis. Todo ponto do score é rastreável a um paper ou métrica validada publicamente, e a janela de uso real começou com cliente pagante (Stone) em maio de 2026.

A ciência por trás do score

Cada dimensão é derivada de um paper peer-reviewed ou preprint com forte tração acadêmica. Abaixo, a fundação teórica de cada uma.

A matemática — formulário completo

Zero cap artificial. Zero booleano binário onde pode haver gradiente. Todos os pontos das 8 dimensões somam exatamente 100. A v2.2 (08-abr-2026) acrescentou inferência estatística rigorosa via inference.ts.

Score triangular (title, meta description)

O título precisa estar entre 30 e 65 caracteres (ideal). Abaixo de 30 ou acima de 90 vale 0. Entre os limites, valor decai linearmente. Isso dá crédito parcial em vez de on/off.

triangularScore(x, min=0, idealMin=30, idealMax=65, max=90):
  if x ≤ min or x ≥ max:       return 0
  if idealMin ≤ x ≤ idealMax:  return 1
  if x < idealMin:             return (x - min) / (idealMin - min)
  if x > idealMax:             return (max - x) / (max - idealMax)

// Title de 28 chars → 5 × triangular(28) = 5 × 0.933 = 4.67 pts
// Title de 50 chars → 5 × triangular(50) = 5 × 1.000 = 5.00 pts
// Title de 80 chars → 5 × triangular(80) = 5 × 0.400 = 2.00 pts

Response Time (TTFB) — piecewise gradient

Crawlers de IA abandonam requisições lentas. A curva privilegia rapidez extrema (≤500ms) e penaliza exponencialmente acima de 1500ms.

responseTimeFactor(ms):
  if ms ≤ 500:    return 1.00
  if ms ≤ 1500:   return 1 - 0.5 × ((ms - 500) / 1000)   // 1.00 → 0.50
  if ms ≤ 3000:   return 0.5 × (1 - (ms - 1500) / 1500)  // 0.50 → 0.00
  else:           return 0

Cohen / Fleiss kappa — concordância corrigida por chance (novo em v2.2)

O pairwise agreement bruto inflaciona quando 3 engines dizem "yes" e 1 diz "no" (média ~0,83 parece "alto"). Fleiss kappa penaliza isso porque corrige o esperado por chance. Cada campo livre (name, category, proposition) vira shingle canônico antes de virar rótulo nominal.

fleissKappa(ratings): // N × K matriz de votos por categoria
  Pbar = (1/N) × Σ_i [ (Σ_j n_ij² - n) / (n × (n - 1)) ]
  Pe   = Σ_j ( (Σ_i n_ij) / (N × n) )²
  κ    = (Pbar - Pe) / (1 - Pe)

// Interpretação Landis-Koch:
//  < 0.00  pobre        |  0.41-0.60  moderado
//  0.00-0.20 leve       |  0.61-0.80  substancial
//  0.21-0.40 razoável   |  0.81-1.00  quase perfeito

// score-calculator anexa kappa ao detail do item exibido:
//  "Engines contam uma história consistente sobre sua marca.
//   Fleiss kappa = 0.687 (substancial)."

Bootstrap BCa — intervalo de confiança 95% (novo em v2.2)

Bias-Corrected and Accelerated bootstrap (Efron 1987) dá IC mais honesto que o percentile clássico. computeFinalScoreWithCI aceita B≥5 réplicas estocásticas e devolve { point, ci: { ciLower, ciUpper, biasZ0, acceleration } }. Permite relatar Score = 74 [69, 78] em vez de cravado.

bootstrapBcaCI(samples, statisticFn, confidence=0.95, B=1000):
  theta_hat = statisticFn(samples)
  boot     = [statisticFn(resample(samples)) for _ in range(B)]
  z0       = Φ⁻¹( (#{b: boot[b] < theta_hat}) / B )           // bias correction
  // jackknife para aceleração
  jack     = [statisticFn(samples \ {i}) for i in range(n)]
  jbar     = mean(jack)
  a        = Σ(jbar - jack)³ / (6 × (Σ(jbar - jack)²)^(3/2))   // acceleration
  α        = (1 - confidence) / 2
  α₁       = Φ( z0 + (z0 + Φ⁻¹(α))    / (1 - a × (z0 + Φ⁻¹(α))) )
  α₂       = Φ( z0 + (z0 + Φ⁻¹(1-α))  / (1 - a × (z0 + Φ⁻¹(1-α))) )
  return percentile(boot, [α₁, α₂])

Dice similarity — string sem dependência externa

normalize(s) = lowercase + remove diacritics + remove punctuation
bigrams("openai") = {"op", "pe", "en", "na", "ai"}
diceSimilarity(a, b) = 2 × |bigrams(a) ∩ bigrams(b)| / (|a|-1 + |b|-1)

// similarity("OpenAI", "Open AI")     ≈ 0.73
// similarity("Brasil GEO", "BrasilGEO") ≈ 0.89

Calibração estatística — bridge com Papers

Os pesos atuais (15·15·20·15·10·10·10·5) são axiomáticos. O projeto Papers gera o dataset empírico que permite estimar pesos calibrados via regressão logística cujo target é a taxa real de citação observada nos 4 LLMs.

Pipeline de calibração:

Score Checker  ──[D1..D8]──┐
                            ├──> score_calibration_inputs (SQLite no papers/)
Papers (citations)──[k/n]──┘
                                │
                                v
                  scripts/calibrate_score.py
                                │
                                v
        logit(P(cited|site)) = β0 + Σ β_d · D_d
                                │
                                v
              w*_d = 100 · max(0, β_d) / Σ max(0, β_k)

// Modo simulado N=200:
//   pseudo R² (McFadden): 0.1742
//   5-fold CV AUROC: 0.8146 ± 0.0253
//   5-fold CV Brier: 0.0370 ± 0.0039
//   Spearman(score_atual, score_calibrado): 0.9495

Priorização de recomendações

impact = gap × (dimension.maxScore / 20)

// Esforço heurístico por palavras-chave
if /robots|sitemap|llms\.txt|canonical|title|meta/:   effort = 2
else if /schema|json-ld|og:|h1|h2|ssr/:                 effort = 4
else if /entidade|wikidata|autoridade|press/:           effort = 7
else:                                                    effort = 5

priority = impact / max(effort, 1)
recommendations.sortBy(priority DESC).slice(0, 12)

Modelos LLM em produção · pricing canônico

Atualizado em 27 de maio de 2026. Preço por 1 milhão de tokens. Gemini foi atualizado de 2.5-flash para 2.5-pro em 18-abr-2026 para elevar a qualidade do structured output. Cada probe espelha custo+tokens em finops_calls (Supabase) para FinOps unificado.

Arquitetura e stack

Fluxo assíncrono end-to-end

Usuário → POST /api/geo-check { domain, mode: "async" }
  ↓
  [rota route.ts]
    1. Normaliza + valida domínio
    2. Checa SSRF (resolve DNS, bloqueia IPs privados)
    3. Checa cache 24h em geo_analysis_jobs
    4. Checa FinOps gate (budget diário US$ 5)
    5. Insere job { status: "queued" } no Supabase
    6. Retorna { job: { id, status: "queued" } }
  ↓
Frontend → GET /api/geo-check/[jobId] a cada 2,5s (polling)
  ↓
  [Vercel Cron * * * * *]
    → POST /api/geo-check/worker
      1. claimNextJob via UPDATE atômico (lock otimista)
         SET status='running', locked_at=NOW(), locked_by='vercel-cron-...'
         WHERE status='queued' AND id=<first FIFO>
      2. Dead-lock recovery: libera jobs 'running' há >5min
      3. Fase estática: collectStaticSignals(domain)  → phase='static', 30%
      4. Fase compreensão: runAllProbes em Promise.all → 4 fetches paralelos
         (OpenAI gpt-4o-mini, Anthropic claude-haiku-4-5,
          Google gemini-2.5-pro, Perplexity sonar)
         → aggregateComprehension(evals, staticSignals)
         → trackProbeCall espelha em finops_calls (fire-and-forget)
         → phase='comprehension', 60%, cost_delta_usd=0.035
      5. Fase entity: Wikidata + Google KG cross-check  → phase='entity', 90%
      6. Fase semantic (PRO): geo-probes 4×3 geos        → phase='semantic', 95%
      7. calculateAllDimensions → score-calculator.ts
      8. enrichWithPreferences (Fase 5 — preferences_learned)
      9. completeJob(id, { final_score, dimensions, recommendations })
  ↓
Frontend detecta status='done' → renderiza score

Stack

Fases do roadmap

Sete entregas em ordem cronológica. Cada fase aprofunda uma dimensão diferente do score e mantém compatibilidade backwards. Clique no número da fase no menu sticky acima para saltar.

O que pode ser automatizado × o que exige você

Transparência total. Tarefas que dependem de dashboards externos, chaves e decisões estratégicas precisam de sua mão; tudo mais eu executo aqui no Claude Code.

Garantias de congruência — como sabemos que estamos medindo certo

Medir compreensão por IA é difícil porque LLMs são não-determinísticos por padrão. A v2.2 elevou a régua: agora temos Cohen/Fleiss kappa, bootstrap BCa e pipeline de calibração contra dataset empírico do Papers.

FinOps — defesa em profundidade contra estouro de orçamento

5 camadas independentes de proteção contra runaway de custos LLM. Se uma falhar, a próxima ainda contém o estouro. A camada 6 (tracking transparente) ganhou tabela cross-projeto finops_calls em 07-abr.

Próximos passos imediatos

5 das 6 fases estão em produção e a Fase 5.5 (inferência estatística) acrescentou rigor empírico. As tarefas abaixo destravam Causal Impact e endurecem a operação com cliente Stone.

1. Aplicar fixes da auditoria NAIA Stone (Brasil GEO + Stone, 2-3 semanas) — componente reaproveitável de schema (Organization + WebSite + BreadcrumbList) cobre 64 URLs do stone.com.br. Meta: levar score competitivo de ~45 → ≥60 até fim de junho.
2. Re-rodar cohort STN-* pós-rebrand semanalmente (automatizável) — Stone D+12 (já), D+19, D+26, D+33, D+40. Cada snapshot alimenta o histórico que destrava Causal Impact e permite reportar delta com IC 95% via bootstrap BCa.
3. Acumular 3 snapshots dos 5 domínios do smoke test (automatizável, ~3 dias) — re-rodar anthropic.com, vercel.com, magazineluiza.com.br, stripe.com, brasilgeo.ai a cada 48h. Após 3 snapshots por domínio, Causal Impact (5 pts) destrava.
4. Implementar CausalImpact (BSTS) em inference.ts (1-2 dias) — Bayesian structural time-series para atribuir delta de score à intervenção (ex: novo Schema.org no site). Bridge com Papers já está pronta; falta só a primitiva TS.
5. Configurar Spend Management no Vercel (manual, 3 min) — Settings → Usage → alerta US$ 30, hard pause US$ 50. Última camada da defesa em profundidade contra runaway.
6. Configurar usage cap mensal nas 4 dashboards LLM (manual, 10 min) — cap recomendado US$ 50/mês cada.
7. Publicar verbete da Brasil GEO no Wikidata (manual) — melhora o próprio score da marca como exemplo vivo da metodologia. Prova social: agência GEO que opera segundo a própria régua.

Rode no seu domínio agora

Análise rápida (estática) entrega resultado em 6 segundos. Análise profunda consulta os 4 LLMs em paralelo e devolve em ~60 segundos com mention rate, faithful credit, bubble divergence + Fleiss kappa reais.

Roadmap mantido por Alexandre Caramaschi, CEO da Brasil GEO. Atualizado em 27 de maio de 2026.