Rudra Analyzer

Metodologia

Como testamos e pontuamos sites

Esta página explica exatamente o que nossas verificações analisam, de onde vêm as evidências, como cada pontuação é calculada, como mantemos os testes seguros e onde estão os limites. Ela descreve as verificações de página única por trás das ferramentas gratuitas e da auditoria de site, além das verificações extras que uma varredura do site adiciona.

O que cada verificação analisa

Uma auditoria completa executa sete verificações. Cada uma tem um nome simples, usado em todos os nossos relatórios, e um nome técnico que descreve o que ela realmente testa.

SEO

Nome técnico
SEO on-page e técnico
O que verifica
Título e meta descrição (tamanho, texto genérico, palavras repetidas), H1 e ordem dos títulos, URL canonical e o status do destino, regras de robots meta e X-Robots-Tag, meta refresh, tags Open Graph e Twitter card (incluindo se a og:image carrega), html lang, viewport, texto alternativo das imagens, dados estruturados JSON-LD (erros de leitura, tipos duplicados, URLs inválidas, propriedades essenciais ausentes nos tipos comuns), hreflang, favicon, contagem de palavras, texto dos links e formato das URLs, além de robots.txt, até três sitemaps declarados, llms.txt, cadeias de redirecionamento e HTTPS.
Como é pontuada
Começa em 100. Título ausente −25, meta descrição ausente −15, H1 ausente −15, noindex −30 e descontos menores (2–15 pontos) para o restante. As verificações mais recentes juntas podem tirar no máximo 45 pontos, e os novos resultados informativos não custam nada.
Testada com
Python requests + BeautifulSoup (lê o HTML que o servidor envia; o JavaScript não é executado), além de uma requisição HEAD para um destino canonical diferente e outra para a og:image
Experimente a ferramenta Verificador de SEO

Velocidade

Nome técnico
Desempenho da página (Lighthouse)
O que verifica
A categoria de desempenho do Lighthouse: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index e Time to Interactive, cada um comparado com seu limite publicado (por exemplo, LCP 2,5 s / 4 s, CLS 0,1 / 0,25, TBT 200 / 600 ms), além de até 15 auditorias reprovadas com os arquivos responsáveis. Se o Lighthouse não puder ser executado, uma verificação rápida informa a resposta do servidor, o tamanho do HTML, a compressão, os arquivos que bloqueiam a renderização, os cabeçalhos de cache e o tamanho e formato das imagens.
Como é pontuada
A própria pontuação de desempenho de 0–100 do Lighthouse, sem alterações. Uma auditoria com pontuação abaixo de 0,5 é marcada como crítica e abaixo de 0,9 como aviso. A verificação rápida, por sua vez, começa em 100 e lista seus descontos; ela é identificada como verificação rápida, nunca como pontuação do Lighthouse.
Testada com
Google Lighthouse no Chrome headless, configurações padrão (celular), uma execução; alternativa: 1 GET e no máximo 25 requisições HEAD
Experimente a ferramenta Verificador de velocidade do site

Experiência no celular

Nome técnico
Layout responsivo
O que verifica
A meta tag viewport (presente, width=device-width, zoom não bloqueado) e o transbordamento horizontal nos tamanhos de celular (375×667), tablet (768×1024) e desktop (1440×900), indicando os elementos que ficam para fora, com capturas de tela da visualização no celular e de qualquer tamanho com problema.
Como é pontuada
Começa em 100. Tag viewport ausente −20, viewport sem width=device-width −10, viewport que bloqueia o zoom −5, −15 para cada tamanho em que a página fica mais larga que a tela, −10 se algum tamanho teve problemas de carregamento.
Testada com
Playwright com Chromium
Experimente a ferramenta Verificador de celular

Acessibilidade

Nome técnico
Testes WCAG automatizados
O que verifica
O conjunto de regras padrão do axe-core — regras WCAG 2.x de nível A e AA e boas práticas — aplicado à página renderizada. São listados até 25 tipos de violação, cada um com o número de elementos afetados e até cinco exemplos (seletor, trecho de HTML, o que corrigir). As regras que o axe-core não consegue decidir aparecem como “requer revisão manual”, e as regras aprovadas também são listadas.
Como é pontuada
Começa em 100 e perde pontos por regra com falha, conforme o impacto: crítico −15, sério −10, moderado −5, leve −2.
Testada com
Uma cópia incluída do axe-core injetada no Chromium via Playwright
Experimente a ferramenta Verificador de acessibilidade

Segurança do site

Nome técnico
Segurança do transporte, valores de cabeçalhos, cookies e exposição
O que verifica
HTTPS após redirecionamentos e se http:// redireciona permanentemente para HTTPS; o certificado TLS (confiança, nome do host, versão do protocolo, emissor, validade); valores dos cabeçalhos de segurança — max-age do HSTS (pelo menos 180 dias) e sintaxe, diretivas de CSP incluindo 'unsafe-inline', 'unsafe-eval', fontes de script amplas, nonces e hashes, object-src e base-uri, X-Frame-Options ou CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy; atributos dos cookies (Secure, HttpOnly, SameSite, Domain) apenas pelo nome; CORS com uma origem de teste inofensiva; conteúdo misto; security.txt; cabeçalhos que revelam versões e source maps públicos; tecnologias e superfície visível, como formulários de login e referências a APIs; manipuladores de eventos inline e scripts sem Subresource Integrity, sinalizados para revisão manual.
Como é pontuada
Começa em 100. Sem HTTPS −40, certificado inválido ou expirado −40, falha na conexão TLS −30, CORS que confia em qualquer origem com credenciais −25, sem HSTS −15, sem CSP −12, sem redirecionamento de http→https −10, sem proteção contra clickjacking −8, conteúdo misto ativo −8, CSP Report-Only −8, sem X-Content-Type-Options −6, scripts 'unsafe-inline' −6, cookies sem Secure −6, HSTS fraco −5 e descontos menores para outros valores fracos. Muitos resultados informativos, como a ausência de security.txt, não custam nada.
Testada com
Python requests (somente GET e HEAD) + o módulo ssl da biblioteca padrão
Experimente a ferramenta Verificador de segurança do site

Links e erros de página

Nome técnico
Teste funcional básico e revisão de formulários
O que verifica
Carrega a página em um navegador, registra erros de console do JavaScript, exceções não tratadas e os seus próprios scripts, estilos, imagens e fontes que não carregam, testa até 12 links únicos para o mesmo site (navegação primeiro) e até 5 links para outros sites, e revisa a marcação de cada formulário: HTTPS, GET com senhas, rótulos, tipos de campo, autocomplete, ações externas, um token visível no estilo CSRF e um botão de envio. Os formulários nunca são enviados, clicados, focados ou preenchidos.
Como é pontuada
Começa em 100. Cada link interno quebrado −10 (no máximo −40), cada erro de JavaScript não tratado −10 (no máximo −30), cada erro de console −5 (no máximo −20), cada arquivo próprio que falha −4 (no máximo −20), um formulário de senha em HTTP, envio para http:// ou uso de GET −10 cada, um placeholder como único rótulo −3. Links externos quebrados e as demais observações sobre formulários são informativos.
Testada com
Playwright com Chromium; os links são verificados com HEAD, com GET como alternativa
Experimente a ferramenta Verificador de links quebrados

Servidor e disponibilidade

Nome técnico
Disponibilidade e tempo de resposta
O que verifica
A própria página e caminhos comuns (robots.txt, sitemap.xml, /health, /healthz, /api, /api/health, openapi.json, swagger.json, manifest.json e security.txt) em busca de erros de servidor e do tempo médio de resposta. Um 404 nesses caminhos opcionais não é penalizado.
Como é pontuada
Começa em 100. Página inacessível ou 5xx −50, página 4xx −20, −15 para cada outro caminho que retorne 5xx (no máximo −30), tempo médio de resposta acima de 800 ms −8 ou acima de 1.500 ms −15.
Testada com
Python requests
Experimente a ferramenta Auditoria de site

Como as evidências são coletadas

Um resultado só aparece quando uma verificação realmente viu o que descreve — um valor de cabeçalho, um elemento, uma resposta. Cada resultado registra de onde veio a evidência:

Resposta HTTP
Códigos de status, redirecionamentos e cabeçalhos de resposta de uma requisição normal à sua página.
HTML
O código-fonte da página que seu servidor envia, antes de qualquer JavaScript ser executado.
Página renderizada e execução no navegador
A página depois de carregar no Chromium: os elementos renderizados, os erros de JavaScript e os arquivos que não carregaram.
Lighthouse
Métricas de laboratório e auditorias de uma execução do Lighthouse.
axe-core
Resultados das regras de acessibilidade para a página renderizada.
Dados da varredura
Em varreduras de site: as páginas, links, títulos e canonicals armazenados durante a varredura — sem requisições extras.
robots.txt e sitemap
As regras do seu robots.txt e as URLs listadas nos seus sitemaps XML.
Conexão TLS
O certificado e a versão do protocolo que seu servidor apresenta.

Privacidade: as evidências nunca contêm valores de cookies, tokens, senhas, cabeçalhos Authorization, chaves de API ou qualquer coisa digitada em formulários. Os cookies são informados apenas pelo nome e pelos atributos, os campos de formulário apenas pelo nome e pelo rótulo, e parâmetros de query string que parecem tokens são removidos das URLs.

Níveis de confiança

Cada resultado informa o quanto temos certeza, para que você saiba o que resolver imediatamente e o que conferir antes.

Alta

Observado diretamente: um valor de cabeçalho, um código de status, um elemento que não passou em uma regra. Você mesmo pode confirmar em segundos.

Média

Um sinal forte que depende do contexto — por exemplo, um cookie que parece ser de sessão pelo nome, ou uma página listada no sitemap para a qual nenhuma página verificada aponta.

Baixa

Uma heurística que precisa da revisão de uma pessoa, como um formulário sem token CSRF visível ou manipuladores de eventos inline. Esses casos são descritos como “possível” ou “revisão manual” e nunca são apresentados como vulnerabilidades confirmadas.

Verificações realizadas e “Não testado”

Os relatórios listam todas as regras que avaliamos, incluindo as aprovadas, para que você veja o que foi coberto e não apenas o que deu errado. Uma lista curta de problemas significa uma coisa quando quarenta verificações foram aprovadas e outra quando apenas cinco puderam ser executadas.

“Não testado” significa que uma verificação não se aplicava ou não era seguro executá-la — por exemplo, a verificação do atributo Secure do cookie em uma página que não é servida por HTTPS, ou um link para um endereço privado. “Ignorado” significa que ela não pôde ser executada, geralmente porque nossa própria requisição falhou ou esgotou o tempo; a área é então marcada como parcial e o resumo informa quais verificações estão faltando. Um tempo esgotado ou um erro de DNS do nosso lado é “não foi possível verificar”, nunca uma falha do seu site.

Verificações ignoradas e não testadas não custam pontos. Se uma área inteira não pôde ser executada — o mecanismo estava indisponível ou falhou do nosso lado —, ela fica fora da pontuação geral em vez de ser contada como zero.

Segurança: como os testes de segurança seguem não destrutivos

Toda verificação é passiva e somente leitura. Na prática, isso significa:

  • Nossas próprias requisições usam apenas GET ou HEAD — nunca POST, PUT, PATCH ou DELETE. Quando uma página é aberta em um navegador, os scripts dela são executados como seriam para qualquer visitante.
  • A verificação de CORS é um único GET com uma Origin inofensiva de um domínio que não pode existir (https://rudra-audit.invalid), sem cookies nem credenciais.
  • Só é solicitada uma lista curta e fixa de arquivos conhecidos — como robots.txt, sitemap.xml, /.well-known/security.txt, llms.txt, humans.txt e o manifest ao qual sua página aponta, além dos caminhos de health e de descrição de API que a verificação do servidor lista acima. Não adivinhamos nem enumeramos outros caminhos, e os source maps só são verificados quando um dos seus próprios scripts os menciona.
  • Os formulários nunca são enviados, clicados, focados ou preenchidos, e nenhum payload de ataque é enviado.
  • Nunca fazemos login, enviamos credenciais nem testamos senhas.
  • Requisições para endereços de rede privados e internos — localhost, 10.x, 192.168.x, serviços de metadados de nuvem e similares — são bloqueadas antes de serem enviadas, incluindo as etapas de redirecionamento e, nas verificações com o navegador Playwright, todas as requisições que a página faz enquanto carrega.

Pontuação

Cada área começa em 100 e perde pontos pelos problemas encontrados; a velocidade usa a própria pontuação do Lighthouse. O relatório lista cada desconto ao lado do resultado que o causou, para que você veja exatamente para onde foram os pontos.

O mesmo problema nunca é descontado duas vezes: três cookies sem Secure são um único resultado com um único desconto. Quando o número de ocorrências importa, como em links quebrados ou erros de JavaScript, o desconto cresce com a quantidade até um limite informado. Os resultados informativos mais recentes não custam nada; algumas verificações antigas de baixa prioridade mantêm um pequeno desconto, por exemplo a ausência de Referrer-Policy (−4) ou uma regra de acessibilidade menor (−2).

Uma varredura do site adiciona verificações de SEO entre páginas — títulos e descrições duplicados, problemas de canonical, links para redirecionamentos, URLs do sitemap que retornam erros, links de retorno de hreflang ausentes e conteúdo idêntico — que as verificações de página única não conseguem ver. Juntas, elas podem tirar no máximo 5 pontos da pontuação de SEO, e problemas já pontuados em cada página não são contados de novo.

Como a pontuação geral é calculada

A pontuação geral é a média das pontuações das categorias, arredondada para um número inteiro. Só contam as categorias que produziram um resultado. Se um mecanismo não estiver disponível em nosso servidor, ou uma verificação falhar do nosso lado, essa categoria fica fora da média em vez de ser contada como zero ou estimada. Quando o Lighthouse não está disponível, a velocidade é avaliada pela verificação rápida.

Se uma verificação é executada mas não consegue terminar, por exemplo porque a página não carrega a tempo, ela recebe 0 e conta, porque esse é um problema real que um visitante também encontraria.

As pontuações aparecem com um status simples: 90–100 é “Bom”, 50–89 “Precisa de atenção” e 0–49 “Ruim”. O status sempre aparece escrito ao lado da cor.

As ferramentas que usamos

Usamos ferramentas abertas e consolidadas em vez de inventar nossas próprias medições.

  • Google Lighthouse

    Mede o desempenho de carregamento em um navegador Chrome real. Usamos sua pontuação de desempenho e suas auditorias sem alterações, e identificamos cada métrica como uma medição de laboratório de uma única execução.

  • Playwright e Chromium

    Carrega as páginas em um mecanismo de navegador real para as verificações de layout no celular, links, formulários e erros, e acessibilidade, e faz capturas de tela. Requisições para endereços de rede privados são bloqueadas dentro do navegador.

  • axe-core

    O mecanismo de regras de acessibilidade de código aberto da Deque, muito usado para testes WCAG automatizados.

  • requests e BeautifulSoup

    Busca as páginas e lê o HTML delas para as verificações de SEO, segurança e servidor, usando apenas requisições GET e HEAD.

  • Módulo ssl do Python

    Abre uma conexão TLS para ler e validar seu certificado com base nas autoridades certificadoras confiáveis padrão.

O que as verificações automáticas não conseguem dizer

  • Se o seu conteúdo é útil, preciso ou persuasivo, nem como ele vai se posicionar em relação aos concorrentes.
  • Questões de acessibilidade que exigem uma pessoa: se o texto alternativo é significativo, se a ordem do teclado faz sentido ou se o conteúdo é compreensível.
  • Se o seu site tem vulnerabilidades, software desatualizado, senhas fracas ou malware. A verificação de segurança lê sua configuração; não é um teste de invasão.
  • O quão rápido seu site é para seus visitantes reais. O Lighthouse faz um teste de laboratório; os dados de visitantes reais podem ser diferentes.
  • Qualquer coisa atrás de um login, paywall ou formulário: só vemos páginas que carregam publicamente.
  • Problemas em outras páginas. Cada verificação de página única analisa apenas o endereço que você digita.

Por que os resultados podem variar entre execuções

A velocidade é o que mais muda. Cada execução do Lighthouse é um novo carregamento da página, e as condições de rede, a carga do servidor, o cache, os anúncios e os scripts de terceiros mudam de um carregamento para outro. Alguns pontos de diferença entre execuções são normais.

As verificações feitas no navegador também podem variar se a página carrega conteúdo em ordem aleatória, mostra banners ou experimentos diferentes ou às vezes bloqueia visitantes automatizados. Os resultados de SEO e segurança só mudam quando a configuração da sua página ou do seu servidor muda.

Limitações conhecidas por área

Velocidade

Um teste de laboratório de um único carregamento, usando a simulação padrão do Lighthouse de um celular intermediário em uma conexão limitada. Ele não consegue medir o Interaction to Next Paint (INP), que depende de interações reais; o Total Blocking Time é o sinal de laboratório mais próximo.

Acessibilidade

As regras automáticas encontram apenas parte dos problemas que uma página pode ter. Passar não significa que a página atende às WCAG; ainda é preciso testar manualmente com teclado e leitor de tela.

Segurança

Lê a configuração que um navegador recebe: valores de cabeçalhos, atributos dos cookies da própria resposta da página, CORS, TLS e o HTML. Não é um teste de invasão — sem exploração, sem login, sem páginas autenticadas, sem revisão de código do servidor e sem busca de vulnerabilidades no seu software ou nas suas dependências.

Links e formulários

Testa até 12 links para o mesmo site e 5 para outros sites por página. Alguns servidores retornam erros para visitantes automatizados mesmo quando a página funciona para pessoas, por isso respostas externas 401, 403, 405 e 429 são tratadas como inconclusivas. Os formulários nunca são enviados, então a validação do lado do servidor e a proteção contra CSRF não podem ser testadas.

SEO

Lê o HTML que seu servidor envia, não a página depois que o JavaScript é executado. Não mede posições nos resultados de busca, tráfego, palavras-chave ou backlinks, e dados estruturados completos não garantem resultados avançados.

Como a IA é usada nos relatórios

Quando ativado, um modelo de IA (o Claude, da Anthropic) reescreve os resultados reais de uma varredura em uma lista curta e priorizada de próximos passos. Ele recebe o endereço analisado, as pontuações das categorias e os problemas que nossos scanners detectaram.

Ele é instruído a explicar e priorizar apenas esses resultados. Ele não cria problemas, não altera pontuações e não afirma ter medido algo que não foi medido. Quando a IA não está configurada, ou a solicitação falha, usamos um resumo padrão montado a partir das áreas com menor pontuação; o relatório mostra qual dos dois você está lendo.

As pontuações e os problemas sempre vêm dos scanners descritos acima, nunca da IA.

O que acontece com seus dados

As análises são temporárias. Cada varredura, varredura de site e teste de layout (com seus resultados, relatórios e capturas de tela) é excluído automaticamente 24 horas após a última atividade.

Nossa política de privacidade explica o que mais armazenamos, como os dados da conta, e por quanto tempo.

Ler a política de privacidade

Experimente as verificações

Todas as ferramentas desta página podem ser testadas gratuitamente em uma página do seu site, e nossos guias explicam como corrigir o que elas encontrarem.

Ver as ferramentas gratuitasFazer uma auditoria completa do siteLer os guias