Verificar correções de SEO

Reverifique problemas ou URLs selecionados após uma atualização do site. Cada problema recebe a marcação resolvido, persistente, alterado ou não verificável, considerando só as páginas afetadas.

O que faz

Reverificação direcionada

Escolha o que verificar pelo ID do problema, pela URL afetada, por um arquivo de URLs ou por uma visualização de verificação salva. O SpiderHead busca de novo somente essas páginas, com a política de HTTP, robots e renderização registrada na linha de base. Verificações de todo o site não são executadas outra vez.

  • Uma seleção comporta no máximo 500 alvos de rastreamento e 5.000 problemas.
  • Uma seleção acima desses limites falha. Nunca é feita amostragem.
  • O --after usa uma auditoria ou um scan posterior já existente, então nenhuma requisição é enviada.

Vereditos limitados

Uma reverificação parcial não pode declarar o site inteiro corrigido. Verificações de todo o site e verificações não medidas voltam como não verificáveis. Um rastreamento posterior inválido não resolve problemas, e reanalisar o mesmo scan não é uma evidência nova.

  • Cada veredito traz um motivo e a evidência.
  • Os resultados são gravados em um novo arquivo JSON e Markdown, imutável.
  • Páginas ausentes continuam como não verificáveis.

Registro de correções

Para trabalhos mais longos, um registro de correções vinculado a um projeto acompanha cada caso pelos estados do ciclo de vida. Uma tarefa avança com base em evidência de reverificação, então uma tarefa marcada como concluída não é confundida com um site corrigido. As reverificações ficam restritas aos casos pendentes exatos.

  • O remediation-ingest carrega uma auditoria salva como linha de base.
  • O remediation-recheck verifica os casos pendentes sem rastrear o site.
  • O remediation-report mostra as evidências de antes e depois, offline.

Três passos, um rastreamento salvo

  1. Comece por uma linha de base

    Aponte o verify-fixes para o audit.json ou para o scan SQLite que você já tem e, em seguida, escolha os IDs dos problemas ou as URLs afetadas.

  2. Reverifique só as páginas afetadas

    O comando busca de novo as URLs selecionadas com a política de HTTP, robots e renderização registrada na linha de base. Verificações de todo o site não são executadas outra vez.

  3. Leia o veredito de cada problema

    Cada problema recebe a marcação resolvido, persistente, alterado ou não verificável, com motivo e evidência, em um novo arquivo JSON ou Markdown imutável.

Verificações deste recurso

VerificaçãoO que significaGravidadeEvidência
BROKEN_PAGE_4XXA página retorna status 4xx; a reverificação pode mostrar o problema corrigido quando a URL passar a retornar 2xxCriticalCódigo de status antes e depois, por URL
SERVER_ERROR_5XXA página retorna status 5xx; só é considerado resolvido quando a reverificação recebe 2xxCriticalCódigo de status antes e depois, por URL
TITLE_MISSINGA página não tem a tag title; a correção aparece como resolvida na mesma URLCriticalLinhas de problemas da linha de base e da reverificação para a URL
H1_MISSINGA página não tem título H1ImportantLinhas de problemas da linha de base e da reverificação para a URL
CANONICAL_MISSINGA página não tem a tag canonicalImportantLinhas de problemas da linha de base e da reverificação para a URL
REDIRECT_CHAINO redirecionamento passa por dois ou mais saltos antes da URL finalImportantStatus de cada salto na reverificação
BAD_REDIRECT_TYPEUsa 302, 303 ou 307 onde se espera um redirecionamento permanente 301TipStatus de cada salto na reverificação

Um comando

bash
seohead verify-fixes --baseline ./report/audit.json --urls https://example.com/old-page --out-dir ./verification-1

Instale primeiro: guia de instalação. Todo comando também funciona como ferramenta MCP para agentes de IA.

O que você precisa

  • Uma linha de base: um audit.json salvo ou um scan SQLite
  • Uma seleção: IDs de problemas, URLs, um arquivo de URLs ou uma visualização salva
  • Uma nova pasta de saída (--out-dir) para os arquivos de verificação
  • Opcional: a configuração original do rastreador, se a linha de base ocultou credenciais (--config)

Limites

  • Sem --after, o comando envia requisições de leitura para as URLs que você selecionar.
  • Só as páginas selecionadas são verificadas. O site não é rastreado de novo.
  • Um scan posterior usado com --after precisa ser diferente da linha de base e ter sido feito depois dela.
  • Verificações de todo o site não podem ser confirmadas por uma reverificação parcial.

Perguntas

Isso altera alguma coisa no meu site?
Não. Ele só envia requisições de leitura para as URLs que você selecionar. O resultado é um novo arquivo de verificação na pasta que você indicar com --out-dir.
Resolvido significa que o site inteiro foi corrigido?
Não. A verificação cobre só as páginas afetadas que você selecionou. Verificações de todo o site e verificações não medidas não podem virar corrigidas em uma reverificação parcial; elas voltam como não verificáveis.
Preciso rastrear de novo antes?
Você precisa de uma linha de base: um audit.json salvo ou um scan SQLite. Para verificar sem requisições de rede, passe --after com uma auditoria posterior já existente, e o comando funciona offline.
Quantos problemas posso verificar em uma execução?
Até 500 alvos de rastreamento e 5.000 problemas. Seleções maiores falham em vez de ser reduzidas por amostragem, então divida-as.
Qual é a diferença para o compare-crawls?
O compare-crawls compara dois arquivos salvos e não busca nada. O verify-fixes busca de novo as páginas que você selecionar e dá um veredito por problema. Use o compare-crawls para uma visão geral da atualização e o verify-fixes para fechar tarefas específicas.
Posso usar com um assistente de IA?
Sim. A mesma operação está disponível no servidor MCP local como seo_verify_fixes, com os mesmos argumentos da CLI.

Teste no seu próprio site