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:
- Abra as fontes iniciais em
source-registry.md. - Verifique se a página está acessível e atualizada.
- Verifique o changelog, atualizações, notas de versão, "O que há de novo" ou equivalente da fonte, quando disponível.
- Siga os sub-links oficiais relevantes de primeira parte descobertos dentro da fonte.
- 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.
- Prefira a versão mais recente aplicável de uma especificação ou página de documentação.
- Registre a URL da fonte, a data/versão da fonte quando disponível, e qual regra ela suporta.
- 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:
- Google Search Central / padrões web do Google
- W3C / WCAG / WAI / WHATWG
- Schema.org
- Documentação oficial do Next.js e documentação de versão/changelog
- MDN
- OWASP
- Documentação oficial da biblioteca/framework relevante para a stack detectada
- Fontes reputadas da indústria
- 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:
PASSISSUES_FOUNDNOT_APPLICABLEcom evidênciaBLOCKED_AFTER_RETRYcom 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,SKIPou 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:
- Diagnostique a falha.
- Tente novamente usando o mesmo caminho confiável, quando apropriado.
- Tente uma fonte/caminho autoritativo equivalente.
- Continue com o trabalho de auditoria independente que não depende da falha.
- Volte ao item bloqueado.
- 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:
- Leia
SKILL.mdesource-registry.md. - Inspecione o projeto e determine quais domínios de auditoria são aplicáveis.
- Carregue apenas o(s) arquivo(s) de referência necessário(s) para o domínio atualmente sendo auditado.
- 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.
- 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.mdincluí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:
| ID | Domínio | Obrigatório? | Status da fonte | Status da auditoria | Evidência | Status de recuperação |
|---|---|---|---|---|---|---|
| D1 | Atualização de fonte ao vivo | sim | pendente/verificada/bloqueada | pendente/passou/problemas/bloqueado | URL(s) | tentativas |
| D2 | Rastreamento/indexabilidade | sim | ... | ... | ... | ... |
| D3 | HTML semântico | sim | ... | ... | ... | ... |
| D4 | Acessibilidade | sim | ... | ... | ... | ... |
| D5 | Metadados/social | sim | ... | ... | ... | ... |
| D6 | Dados estruturados | sim | ... | ... | ... | ... |
| D7 | Sitemap/robots/canônicos | sim | ... | ... | ... | ... |
| D8 | Links internos | sim | ... | ... | ... | ... |
| D9 | Desempenho/CWV | sim | ... | ... | ... | ... |
| D10 | E-commerce | condicional | ... | ... | ... | ... |
| D11 | GEO/AEO/busca em IA | sim | ... | ... | ... | ... |
| D12 | Next.js | condicional | ... | ... | ... | ... |
| D13 | Segurança/endurecimento | condicional | ... | ... | ... | ... |
| D14 | Portões de validação | sim | ... | ... | ... | ... |
Regras:
- Um domínio começa como
pendentee não pode ser considerado completo sem um status terminal explícito. pendente,em_andamento,TODO,SKIP,desconhecidoe em branco são estados não terminais e proíbem a finalização.- 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_TENTATIVAsomente após as tentativas de recuperação serem esgotadas; continue todos os domínios independentes primeiro, depois tente o item bloqueado novamente. - O agente NÃO DEVE marcar um domínio inteiro como
PASSOUporque um subconjunto de verificações passou. - Se um item não for aplicável, anexe evidência concreta do porquê não é aplicável.
- 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ÁVELou auditada. - 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:
- Abra a página inicial/atual.
- Leia suas informações de última atualização/publicação/versão quando disponível.
- Inspecione o changelog oficial, página de atualizações, notas de versão, histórico ou índice de versões.
- Siga links oficiais recursivamente.
- Re-verifique a fonte atual após seguir referências mais recentes quando a página mais antiga aponta para elas.
- 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:
- Especificação normativa atual / documentação oficial para a versão detectada.
- Notas de versão/changelog/aviso de segurança oficial atual.
- Guia de implementação oficial atual.
- Documentação secundária somente quando as fontes de primeira parte não cobrirem o problema.
- 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.