CommunityPesquisa e Análise de Dadosgithub.com

technical-seo-geo

Um auditor automatizado para o Claude Code que realiza auditorias abrangentes de SEO Técnico, Acessibilidade, Dados Estruturados e Otimização Generativa de Mecanismos de Busca (GEO) em qualquer site, página ou base de código.

O que é technical-seo-geo?

Esta skill transforma o Claude Code em um auditor técnico de SEO, acessibilidade, dados estruturados e otimização generativa de mecanismos de busca (GEO) totalmente automatizado, voltado para desenvolvedores e profissionais de SEO. Ela realiza uma auditoria ao vivo, seguindo um contrato de execução rigoroso que exige a verificação das fontes mais recentes da web (como Google Search Central, W3C, Schema.org e documentação do Next.js) antes de aplicar qualquer regra. A skill é compatível com qualquer site, página ou base de código, detectando automaticamente a stack tecnológica (Next.js, React, TypeScript, etc.) e adaptando as auditorias conforme necessário. Ela cobre domínios como SEO/indexabilidade, HTML semântico, acessibilidade (WCAG), metadados/Open Graph, dados estruturados, sitemaps, robots.txt, canonicais, links internos, Core Web Vitals, SEO para e-commerce, GEO/AEO/visibilidade em LLMs e segurança básica. O principal diferencial é seu rigoroso fluxo de trabalho baseado em um 'ledger de auditoria' que impede a finalização prematura, exige evidências para cada descoberta e obriga a recuperação de falhas, garantindo auditorias completas e confiáveis.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add AhmedNnasser11/technical-seo-geo-claude-skill

Installed? Explore more Pesquisa e Análise de Dados skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que technical-seo-geo faz?

Auditor automatizado para SEO técnico, HTML semântico, acessibilidade, metadados, Open Graph, dados estruturados, sitemaps, robots.txt, canônicos, links internos, Core Web Vitals, SEO para Next.js, SEO para e-commerce, GEO, AEO, visibilidade em LLMs, otimização para busca em IA e otimização para recuperação de informações.

CONTRATO DE EXECUÇÃO INEGOCIÁVEL

Esta skill é um fluxo de trabalho de auditoria ao vivo, não uma lista de verificação estática.

1. REQUISITO DE FONTE AO VIVO / MAIS RECENTE

No início de cada auditoria, você DEVE recuperar e verificar as orientações mais recentes e relevantes da web.

Não presuma que os arquivos .md incluídos estão atualizados. Eles são apenas o conhecimento base.

Para cada domínio de auditoria aplicável:

  1. Abra as fontes iniciais em source-registry.md.
  2. Verifique se a página está acessível e atualizada.
  3. Verifique o changelog, atualizações, notas de versão, "O que há de novo" ou equivalente da fonte, quando disponível.
  4. Siga os sub-links oficiais relevantes de primeira parte descobertos dentro da fonte.
  5. Continue seguindo os sub-links relevantes recursivamente até que não haja referências autoritativas adicionais e relevantes que possam alterar a regra que está sendo auditada.
  6. Prefira a versão mais recente aplicável de uma especificação ou página de documentação.
  7. Registre a URL da fonte, a data/versão da fonte quando disponível, e qual regra ela suporta.
  8. Se uma fonte estiver indisponível, tente novamente e/ou encontre a substituição autoritativa antes de continuar. Nunca a ignore silenciosamente.

2. HIERARQUIA DE FONTES

Use esta ordem de autoridade:

  1. Google Search Central / padrões web do Google
  2. W3C / WCAG / WAI / WHATWG
  3. Schema.org
  4. Documentação oficial do Next.js e documentação de versão/changelog
  5. MDN
  6. OWASP
  7. Documentação oficial da biblioteca/framework relevante para a stack detectada
  8. Fontes reputadas da indústria
  9. Artigos de pesquisa / fontes experimentais GEO-AI

Uma fonte de autoridade inferior NÃO DEVE substituir uma fonte de autoridade superior diretamente aplicável.

Se as fontes entrarem em conflito:

  • Prefira a fonte autoritativa mais recente.
  • Registre o conflito.
  • Explique qual fonte venceu e por quê.
  • Nunca escolha uma silenciosamente.

3. POLÍTICA DE NÃO PULAR / NÃO PARAR ANTECIPADAMENTE

O agente NÃO DEVE:

  • pular uma categoria de auditoria porque outra categoria já encontrou problemas;
  • pular a verificação da fonte porque a referência incluída parece suficiente;
  • pular um sub-link porque a página pai já foi lida;
  • parar depois de encontrar alguns problemas críticos;
  • substituir a verificação necessária por suposições;
  • relatar "não verificado" sem um bloqueador documentado e uma tentativa de recuperação.

A auditoria está completa somente quando cada categoria aplicável tem um status registrado:

  • PASS
  • ISSUES_FOUND
  • NOT_APPLICABLE com evidência
  • BLOCKED_AFTER_RETRY com evidência das tentativas e uma fonte/caminho alternativo, quando possível

Uma categoria não pode ser omitida silenciosamente.

4. PORTÃO DE CONCLUSÃO

Antes de produzir o relatório final, execute uma verificação de conclusão contra o registro de execução obrigatório. O relatório é gerado apenas a partir dos estados finais do registro.

Portões necessários:

  • Atualização da fonte mais recente concluída para cada domínio aplicável.
  • Sub-links relevantes foram inspecionados recursivamente.
  • Conflitos de fonte foram resolvidos ou documentados explicitamente.
  • Auditoria de SEO/indexabilidade concluída.
  • Auditoria de HTML semântico concluída.
  • Auditoria de acessibilidade concluída.
  • Auditoria de metadados/Open Graph/canônicos concluída.
  • Auditoria de dados estruturados concluída.
  • Auditoria de sitemap/robots concluída.
  • Auditoria de links internos concluída, incluindo profundidade de rastreamento e detecção de órfãos.
  • Auditoria de desempenho/Core Web Vitals concluída.
  • Auditoria de e-commerce concluída quando aplicável.
  • Auditoria GEO/AEO/busca em IA concluída.
  • Auditoria Next.js concluída quando o Next.js é detectado.
  • Verificações relevantes de segurança/endurecimento concluídas quando a aplicação expõe funcionalidades web/servidor.
  • Verificações de validação/build/lint/typecheck/execução foram executadas quando o ambiente as suporta.
  • Cada descoberta tem evidência.
  • Cada descoberta tem gravidade e classificação.
  • A ordem de remediação está completa.
  • Nenhum TODO, SKIP ou reivindicação não verificada permanece na auditoria final, a menos que explicitamente marcado como bloqueado.

Se um portão falhar, continue trabalhando. Não finalize o relatório meramente porque um relatório plausível já pode ser escrito.

5. POLÍTICA DE RECUPERAÇÃO / TENTATIVA NOVAMENTE

Quando uma operação necessária falha:

  1. Diagnostique a falha.
  2. Tente novamente usando o mesmo caminho confiável, quando apropriado.
  3. Tente uma fonte/caminho autoritativo equivalente.
  4. Continue com o trabalho de auditoria independente que não depende da falha.
  5. Volte ao item bloqueado.
  6. Registre o status final e a evidência.

Uma falha temporária na web não é permissão para usar conhecimento desatualizado sem divulgação.

6. GRAFO DE FONTES / RASTREAMENTO DE SUB-LINKS

Trate cada página de documentação autoritativa como um nó em um grafo de fontes.

Para cada página de fonte aberta:

  • inspecione links para especificações, referências de API, changelogs, guias de migração, atualizações, ferramentas de validação e orientações oficiais relacionadas;
  • siga links relevantes que possam alterar materialmente a regra de implementação;
  • evite navegação irrelevante, marketing, comentários ou páginas de produtos não relacionadas;
  • desduplique URLs e canonalize variantes óbvias de URL;
  • mantenha um registro de fontes visitadas;
  • não revisite uma URL a menos que seu conteúdo/versão tenha mudado ou uma reivindicação conflitante exija uma nova verificação.

O objetivo é a completeza de fonte relevante, não um limite arbitrário de profundidade de rastreamento.

7. REGRA DA EVIDÊNCIA PRIMEIRO

Não converta uma recomendação em uma descoberta sem evidência.

Para cada descoberta, capture:

  • evidência exata de código/página/URL;
  • fonte que suporta a regra;
  • data/versão da fonte quando disponível;
  • por que a implementação atual viola ou perde a regra;
  • remediação concreta.

Distinga claramente entre:

  • defeito confirmado;
  • risco;
  • recomendação;
  • prática emergente;
  • ideia experimental.

7A. ORÇAMENTO DE CONTEXTO / CARREGAMENTO DE REFERÊNCIA SOB DEMANDA

Os arquivos de referência incluídos são intencionalmente modulares. NÃO carregue cada arquivo .md no contexto no início de uma execução.

Use esta ordem de carregamento:

  1. Leia SKILL.md e source-registry.md.
  2. Inspecione o projeto e determine quais domínios de auditoria são aplicáveis.
  3. Carregue apenas o(s) arquivo(s) de referência necessário(s) para o domínio atualmente sendo auditado.
  4. Após um domínio ser concluído, mantenha seu resultado no registro de execução em vez de reter o texto completo da referência no contexto ativo.
  5. Carregue módulos adicionais apenas quando uma descoberta, versão do framework, conflito de fonte ou detalhe de implementação os exigir.

O manual de execução local do projeto definido abaixo é a memória operacional compacta para execuções futuras. Ele DEVE ser preferido em vez de copiar toda esta skill no contexto do projeto.

7B. MANUAL DE EXECUÇÃO LOCAL DO PROJETO (DURÁVEL, NUNCA AUTO-EXCLUÍDO)

No primeiro uso em um projeto, crie um arquivo compacto em .claude/technical-seo-geo-runbook.md somente se ele ainda não existir.

Regras para este arquivo:

  • É documentação durável do projeto, não estado de execução.
  • Nunca o sobrescreva automaticamente após a criação.
  • Nunca o exclua durante a limpeza do registro.
  • Mantenha-o curto (meta: <= 120 linhas).
  • Ele contém apenas a sequência de execução, decisões específicas do projeto e ponteiros — não documentação de referência copiada.
  • Atualize-o apenas quando uma decisão de fluxo de trabalho específica do projeto for genuinamente alterada e preserve o conteúdo existente de propriedade do projeto.

O conteúdo inicial do manual deve ser a sequência compacta de etapas mostrada em PROJECT-LOCAL-STEPS.md.

8. DETECTE A STACK REAL

Antes de aplicar regras específicas do framework:

  • inspecione package.json;
  • detecte a versão do Next.js;
  • detecte a versão do React;
  • detecte TypeScript;
  • detecte o modelo de roteamento;
  • detecte bibliotecas de UI/acessibilidade;
  • detecte bibliotecas de schema/SEO;
  • detecte ferramentas de teste/build.

Aplique as regras mais recentes apropriadas para as versões detectadas. Não force regras do Next.js em um projeto que não é Next.js.

8A. REGRA DE NÃO PARADA VOLUNTÁRIA

O agente NÃO DEVE encerrar voluntariamente a execução porque a tarefa é grande, muitos problemas já foram encontrados, uma ferramenta falhou ou um relatório plausível já pode ser produzido. Continue todo o trabalho independente e retorne ao trabalho bloqueado antes da finalização. Se uma restrição externa impedir a conclusão, registre a restrição exata, a cobertura concluída, as tentativas de recuperação e os itens não verificados restantes, em vez de implicar conclusão.

9. REGISTRO DE EXECUÇÃO OBRIGATÓRIO (ANTI-PULAR / ANTI-PARAR ANTECIPADAMENTE)

Cada execução DEVE manter um registro de auditoria explícito na memória ou em um arquivo de trabalho temporário. O registro é a máquina de estado de execução para a auditoria; um relatório em prosa não é um substituto.

Armazenamento e limpeza do registro de execução (OBRIGATÓRIO)

  • NÃO mantenha um modelo de registro por execução ou arquivo de estado de execução dentro do repositório do projeto do usuário.
  • NÃO crie, sobrescreva ou exclua um arquivo de projeto persistente meramente para rastrear a execução atual.
  • Armazene o estado de execução apenas em um diretório de execução temporário fora do repositório, por exemplo $TMPDIR/technical-seo-geo/<run-id>/.
  • O diretório temporário DEVE ser único por execução.
  • Na conclusão normal, exclua o diretório de execução temporário.
  • Em uma falha/interrupção, uma execução subsequente DEVE limpar os diretórios de execução temporários technical-seo-geo/* obsoletos antes de iniciar uma nova execução.
  • Nunca exclua arquivos de projeto do usuário, .git, context/, .claude/ ou qualquer outro conteúdo de projeto persistente como parte da limpeza do registro.
  • O antigo run-ledger-template.md incluído é intencionalmente NÃO necessário e NÃO DEVE ser instalado no projeto.

Esta separação é deliberada: o projeto mantém apenas instruções duráveis; o estado de execução transitório nunca polui o repositório ou infla o contexto futuro.

O registro DEVE conter pelo menos:

IDDomínioObrigatório?Status da fonteStatus da auditoriaEvidênciaStatus de recuperação
D1Atualização de fonte ao vivosimpendente/verificada/bloqueadapendente/passou/problemas/bloqueadoURL(s)tentativas
D2Rastreamento/indexabilidadesim............
D3HTML semânticosim............
D4Acessibilidadesim............
D5Metadados/socialsim............
D6Dados estruturadossim............
D7Sitemap/robots/canônicossim............
D8Links internossim............
D9Desempenho/CWVsim............
D10E-commercecondicional............
D11GEO/AEO/busca em IAsim............
D12Next.jscondicional............
D13Segurança/endurecimentocondicional............
D14Portões de validaçãosim............

Regras:

  1. Um domínio começa como pendente e não pode ser considerado completo sem um status terminal explícito.
  2. pendente, em_andamento, TODO, SKIP, desconhecido e em branco são estados não terminais e proíbem a finalização.
  3. Se o trabalho for interrompido por um erro, tempo limite, limite de taxa, dependência ausente ou falha de ferramenta, marque o item afetado como BLOQUEADO_APÓS_TENTATIVA somente após as tentativas de recuperação serem esgotadas; continue todos os domínios independentes primeiro, depois tente o item bloqueado novamente.
  4. O agente NÃO DEVE marcar um domínio inteiro como PASSOU porque um subconjunto de verificações passou.
  5. Se um item não for aplicável, anexe evidência concreta do porquê não é aplicável.
  6. Antes da saída final, toda linha de registro necessária deve ser terminal e toda linha condicional deve ser explicitamente marcada como NÃO_APLICÁVEL ou auditada.
  7. O relatório final DEVE ser gerado a partir do registro, não da memória ou intuição.

Invariante de conclusão do registro

FINALIZÁVEL = todos(os itens necessários são terminais) E todas(as descobertas têm evidência) E todas(as atualizações de fonte obrigatórias são terminais) E todas(as validações aplicáveis têm resultados explícitos).

Se FINALIZÁVEL = falso, não produza o relatório de auditoria final. Continue a execução ou relate o bloqueador exato somente depois que todos os caminhos de recuperação permitidos forem esgotados.

10. REGRA DE VALIDADE / FRESCURA DA FONTE AO VIVO OBRIGATÓRIA

"Mais recente" significa a informação autoritativa mais recente descoberta em tempo de execução, não a informação mais recente conhecida pelo modelo e não o markdown incluído mais recente.

Para cada família de fonte aplicável:

  1. Abra a página inicial/atual.
  2. Leia suas informações de última atualização/publicação/versão quando disponível.
  3. Inspecione o changelog oficial, página de atualizações, notas de versão, histórico ou índice de versões.
  4. Siga links oficiais recursivamente.
  5. Re-verifique a fonte atual após seguir referências mais recentes quando a página mais antiga aponta para elas.
  6. Registre a versão/data autoritativa selecionada no registro.

Nunca codifique uma versão atual do framework, limite do Core Web Vitals, recurso de dados estruturados, status de acessibilidade ou comportamento de pesquisa do Google na recomendação final sem verificação em tempo de execução.

Precedência de frescura da fonte

Quando várias páginas cobrem a mesma regra, escolha nesta ordem:

  1. Especificação normativa atual / documentação oficial para a versão detectada.
  2. Notas de versão/changelog/aviso de segurança oficial atual.
  3. Guia de implementação oficial atual.
  4. Documentação secundária somente quando as fontes de primeira parte não cobrirem o problema.
  5. Fontes da indústria/marketing para práticas suplementares ou experimentais apenas.

Um rascunho mais recente NÃO substitui automaticamente uma recomendação finalizada existente. Registre o status do padrão (Recomendação, Rascunho de Trabalho, Obsoleto, etc.) e aplique a autoridade normativa apropriada.

11. VERIFICAÇÃO RECURSIVA DE SUB-LINKS — COM UMA CONDIÇÃO REAL DE PARADA

O rastreamento recursivo DEVE ser seguro em amplitude/profundidade e completo para links autoritativos relevantes.

Para cada nó de fonte, inspecione links cujo destino possa alterar uma regra de auditoria, incluindo:

  • padrões/especificações;
  • referências de API;
  • documentação versionada;
  • guias de migração;
  • changelogs e notas de versão;
  • avisos de segurança;
  • avisos de obsolescência;
  • ferramentas/requisitos de validação;
  • exemplos oficiais que definem comportamento;
  • documentação oficial de recursos de pesquisa do Google;
  • documentação oficial de compatibilidade de bibliotecas/frameworks.

Use um conjunto de visitados indexado por URL normalizada. Não revisite uma URL a menos que seu conteúdo/versão tenha mudado ou uma reivindicação conflitante exija uma nova verificação. O objetivo não é rastrear toda a documentação da web, mas sim garantir que cada regra aplicável na auditoria seja baseada na fonte mais autoritativa e atualizada disponível. Quando uma fonte de alta autoridade aponta para uma página mais específica ou mais recente (por exemplo, uma especificação W3C aponta para uma errata ou uma nova versão), siga esse link e atualize a fonte base da regra, se apropriado. Registre a decisão de parar quando todas as fontes autoritativas diretas forem verificadas e nenhum link não seguido possa alterar materialmente o resultado da auditoria para aquele domínio específico.

Habilidades Relacionadas