Referência honesta
Metodologia
Cada número desta página é lido do código-fonte da Sonar, ou de um arquivo de evidência datado, quando a página é gerada. Nenhum é digitado à mão, e cada seção cita os arquivos de onde vêm seus números.
Cada número desta página é calculado quando ela carrega, a partir do código que executa o Sonar e dos testes registrados, então não pode se afastar do que o produto faz.
O que medimos, por mecanismo
O SEO vem dos seus próprios dados do Google Search Console e é determinístico: os mesmos dados geram a mesma pontuação. Os últimos 28 dias são comparados com os 28 dias anteriores. O intervalo (80%) mostra a variação de uma semana para outra em blocos de 7 dias, porque os dados do Search Console são um censo, não uma amostra.
A prontidão AEO vem de verificações determinísticas do HTML e das respostas HTTP das suas páginas, sem modelo de linguagem e sem rubrica. Cada verificação reprovada traz uma evidência que você pode contestar.
A participação de citações GEO é a frequência com que um mecanismo de IA lista o seu domínio entre as fontes para um conjunto fixo de prompts. Cada um dos 6 mecanismos, e cada idioma, é relatado separadamente e nunca entra em média com os outros.
As três pontuações nunca são fundidas em um único número. O tipo de dado que as guarda não tem campo para uma pontuação combinada, e um teste falha se alguém adicionar um.
Tamanho e cadência do painel
- Prompts
- 30 (20 de categoria, 10 de marca)
- Mecanismos de IA
- 6
- Idiomas
- 2, sempre idiomas diferentes
- Execuções por prompt
- 2
- Respostas por mecanismo e idioma
- 60
- Cadência
- Semanal
O idioma de uma pergunta e a escolha dos prompts movem as citações de IA muito mais do que repetir a mesma pergunta. 2 execuções por prompt é o mínimo que ainda estima o ruído entre execuções; rodar todos os dias multiplicaria o custo sem estreitar o intervalo. A contrapartida é explícita: uma mudança nas citações nunca é detectada em menos de uma semana.
60 respostas por mecanismo e idioma geram intervalos largos, muitas vezes largos demais para separar duas participações próximas. A Sonar mostra essa largura em vez de escondê-la.
Como os intervalos são calculados
Os intervalos vêm de um bootstrap de clusters. A unidade reamostrada é um cluster de prompts, sorteado com reposição junto com todas as suas execuções. Prompts do mesmo tema sobem e descem juntos; tratar cada resposta como independente faria os intervalos parecerem mais estreitos do que são.
Cada intervalo usa 2.000 réplicas de bootstrap no nível de 95%, com o método de percentis “expanded”. Ele foi escolhido porque, em simulação, sua cobertura foi a mais próxima da nominal entre os métodos testados.
Um número GEO só recebe o rótulo de medido quando cada prompt rodou pelo menos 2 vezes e há mais de um cluster de prompts para reamostrar. Caso contrário, recebe o rótulo de indicativo, com o tamanho da amostra, e um único cluster recebe o intervalo mais largo possível.
As sementes aleatórias são derivadas do mecanismo e do idioma, então os mesmos dados sempre reproduzem o mesmo intervalo.
Desenho do holdout: por que antes/depois não é prova
O tráfego muda por motivos que nada têm a ver com uma alteração: sazonalidade, feriados, atualizações dos buscadores, o lançamento de um concorrente. Uma comparação antes/depois mistura tudo isso no resultado. Por isso, cada afirmação de impacto da Sonar compara as páginas alteradas com um holdout de páginas semelhantes que nunca foram tocadas, nos mesmos dias.
Pelo menos 10% das URLs, e pelo menos 10% dos clusters de prompts, ficam no holdout. A participação é decidida por um hash com chave, não por ranking, então adicionar páginas nunca embaralha os membros existentes. Membros do holdout nunca são removidos nem aposentados.
As páginas são aleatorizadas por cluster de consultas de busca, não uma a uma: páginas que compartilham as principais consultas são alocadas juntas, então uma mudança em uma página não consegue tirar cliques de uma página de controle. Um experimento só abre quando o maior cluster concentra no máximo 30% dos cliques e pelo menos 10 clusters têm cliques.
O estimador é de diferenças em diferenças, com um modelo sazonal semanal e bootstrap de blocos móveis (blocos de 7 dias, 2.000 réplicas). Um piso de Poisson impede que sites com pouco tráfego recebam intervalos falsamente estreitos. Ele precisa de 70 dias de histórico antes da mudança e de uma leitura de 28 dias depois.
GOOD exige probabilidade de ganho de pelo menos 95% e um limite sequencial ultrapassado; BAD exige probabilidade de dano de pelo menos 90%; NEUTRAL exige que pelo menos 80% da probabilidade fique dentro de ±3%, o menor ganho que vale a pena manter. O limite sequencial gasta um orçamento de erro de 5% em cada direção, então checar todos os dias não infla os alarmes falsos. Todo o resto continua RUNNING ou termina UNDERPOWERED, exibido em cinza e nunca em verde.
Sem holdout, o relatório de impacto se recusa a ser exibido. Ele não é substituído por um número de antes/depois.
Resultados dos testes A/A
Um teste A/A não altera nada, então cada veredito GOOD ou BAD que ele produz é um alarme falso. Todo o pipeline de vereditos, o mesmo código que julga experimentos reais, rodou em sites simulados cuja divisão entre braços e cujo ruído foram calibrados com base em um site real.
0 veredito falso em 100 execuções A/A, em 5 níveis de tráfego.
| Cliques por dia | A/A: GOOD ou BAD falsos | Ganho real de 20% detectado como GOOD | Queda real de 10% detectada como BAD | MDE medido |
|---|---|---|---|---|
| 1,2 | 0 de 20 | 0 de 20 | 0 de 20 | 117% |
| 8,4 | 0 de 20 | 0 de 20 | 0 de 20 | 49% |
| 22 | 0 de 20 | 3 de 20 | 1 de 20 | 30% |
| 50 | 0 de 20 | 4 de 20 | 3 de 20 | 21% |
| 150 | 0 de 20 | 14 de 20 | 2 de 20 | 13% |
A tabela também mostra a parte incômoda: com pouco tráfego, até um ganho real raramente é detectado, porque um veredito GOOD exige mais certeza do que a fórmula clássica do MDE supõe. É por isso que a Sonar mostra o seu MDE antes de um experimento começar, e por isso o que ela vende depende do poder medido.
São simulações, registradas em 24 de setembro de 2026. Um teste A/A sobre uma série de tráfego real precisa de 98 dias de dados finais, e o site de laboratório tinha 69 na época. Há dados finais suficientes desde 20 de outubro de 2026, mas o resultado sobre a série real ainda não foi publicado, então a tabela acima continua simulada.
Efeito mínimo detectável por nível de tráfego
O efeito mínimo detectável (MDE) é o menor ganho que um experimento consegue distinguir do ruído, com nível de significância bilateral de 5% e poder de 80%. A Sonar o calcula para o seu site antes de qualquer experimento começar.
Uma afirmação de impacto só é vendida quando o MDE medido é de no máximo 12%. Entre 12% e 25%, os resultados aparecem como indicativos. Acima de 25%, nenhuma afirmação de impacto é feita.
| Cliques por dia | MDE de planejamento | O que a Sonar pode afirmar |
|---|---|---|
| 1,2 | 322% | Sem afirmação de impacto |
| 8,4 | 122% | Sem afirmação de impacto |
| 22 | 75% | Sem afirmação de impacto |
| 50 | 50% | Sem afirmação de impacto |
| 150 | 29% | Sem afirmação de impacto |
| 200 | 25% | Apenas indicativo |
| 866 | 12% | Afirmação de impacto |
Os números de planejamento supõem dias independentes, uma sobredispersão conservadora e o holdout mínimo. O número que vale é medido nos seus próprios dados com o bootstrap de blocos. Nas execuções A/A acima ele saiu menor que o número de planejamento, mas em outro site pode sair maior.
Calculadora de MDE
A mesma função da tabela acima, com sobredispersão 4. Mude os valores para ver quanto tráfego um experimento legível precisa.
O que nos recusamos a afirmar
Alguns números venderiam melhor. A Sonar não os mostra.
- Uma única pontuação de visibilidade combinada. SEO, AEO e GEO continuam sendo três números separados.
- Impacto a partir de uma comparação antes/depois. Gráficos de antes/depois levam o rótulo “não é prova de impacto”.
- Um número GEO sem o seu intervalo, ou o rótulo de medido em dados que são apenas indicativos.
- Uma afirmação de impacto para um site cujo MDE está acima de 25%.
- Uma tendência que atravessa uma troca de versão do modelo de IA. Uma nova versão do modelo começa uma nova série.
- Resultados agregados de outros clientes antes que pelo menos 3 clientes diferentes e 3 clusters independentes contribuam.
- Avaliações, resenhas, preços ou depoimentos que não existem.
Circuito de segurança
A Sonar escreve em sites no ar, então cada escrita é limitada, verificada e reversível.
- Verificação no ar
- 2 minutos depois de publicar, a Sonar busca a página no ar e verifica se cada mudança está mesmo sendo servida. Se não estiver, a Sonar verifica mais uma vez após 28 minutos. Uma verificação que falha é registrada e relatada, nunca escondida.
- Reversão
- Cada mudança é guardada com o estado anterior e pode ser revertida pelo app. Os experimentos se ampliam em anéis de 10% 30% 100% das páginas elegíveis, e um veredito BAD reverte a mudança.
- Interruptor de emergência
- Um botão interrompe toda gravação de um workspace inteiro ou de um único site e pausa as mudanças de edge já no ar, para que o site volte às páginas originais. É verificado antes de cada gravação.
- Limites de ritmo
- Os limites contam janelas móveis, não dias do calendário, então o trabalho não pode ser acumulado perto da meia-noite.
- Novos artigos no site de um cliente: no máximo 3 a cada 24 horas móveis
- Correções técnicas por site por dia, por padrão: no máximo 3
- Rascunhos de conteúdo por site por dia, por padrão: no máximo 1
- Páginas do holdout
- Nunca são editadas. O executor para se uma mudança fosse tocar uma delas.
Conexões e o que cada uma pode mudar
A forma como o Sonar aplica correções depende de como o seu site está conectado. A tabela é gerada a partir do que cada conexão realmente suporta hoje.
| Alavanca | Edge (Cloudflare) | WordPress | GitHub | Shopify | Webflow | Contentful | Sanity | Strapi | Wix | Squarespace | HubSpot |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Títulos de página e meta descrições | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim |
| Blocos de resposta, FAQ e tabelas comparativasB-01 · B-18 · B-14 | Sim | Em parte | Sim | Sim | Não | Não | Não | Não | Não | Não | Não |
| Dados estruturados de FAQA-21 | Sim | Sim | Sim | Sim | Não | Não | Não | Não | Não | Não | Não |
| Páginas novasB-15 | Sim | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Atualização de seções em artigos existentesB-10 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| robots.txt, llms.txt e chave do IndexNowA-01 | Sim | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Correções técnicas (alt de imagem, tags sociais, hreflang, redirecionamentos)A-06 · A-08 · A-16 · B-19 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Tags canonicalA-07 | Sim | Não | Não | Não | Não | Em parte | Em parte | Em parte | Sim | Não | Sim |
| Correções em nível de templateB-31 · B-30 · A-07 · A-16 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Páginas de coleçãoB-15 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Títulos e descrições localizados em loteB-22 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Links relacionados entre páginasB-21 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Sitemaps de imagem e vídeo, links de entidadeH-10 · A-16 · H-15 · D-01 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Consolidação (noindex em páginas fracas)B-11 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Velocidade (cache HTML, preload)A-26 · A-13 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Prontidão para agentes (markdown, feeds, políticas)F-11 · F-16 · F-17 | Sim | Não | Não | Não | Não | Não | Não | Não | Não | Não | Não |
| Disponível por completo | 16 de 16 | 4 de 16 | 3 de 16 | 3 de 16 | 1 de 16 | 1 de 16 | 1 de 16 | 1 de 16 | 2 de 16 | 1 de 16 | 2 de 16 |
- Borda (Cloudflare): o conjunto mais amplo de correções, aplicadas na frente do seu site. Funciona para qualquer domínio: aponte um hostname para o Sonar com um CNAME no provedor de DNS que você usa.
- WordPress: o plugin do Sonar mais uma senha de aplicativo. Títulos, descrições, seções de perguntas frequentes e páginas novas.
- GitHub: o Sonar abre pull requests no seu repositório, para sites gerados a partir de arquivos.
- Shopify: um app personalizado na sua loja. Meta tags e blocos na página.
- Webflow: um token de API. Apenas títulos e descrições de página.
- Contentful, Sanity, Strapi (mapeamento de campos por tipo de conteúdo), Wix, Squarespace e HubSpot: um token de API. Títulos e descrições, e canonical quando a API tem o campo; o resto vai para o modo de exportação.
O que você precisa
- Google Search Console: adicione a conta de serviço do Sonar exibida no assistente de configuração como usuário restrito da sua propriedade.
- Bing Webmaster Tools: peça ao proprietário do Sonar para adicionar o seu site à conta do Bing do time.
- Conexão de borda: acesso às configurações de DNS para adicionar um registro CNAME (qualquer provedor de DNS). Se você não puder mudar o DNS, use WordPress, Shopify, Webflow ou GitHub.
- Um app autenticador para o segundo fator, necessário para conectar um site.
- Pelo menos dois idiomas de conteúdo para o negócio, se você quiser o painel de citações GEO.