technical-seo-geo-claude-skill

technical-seo-geo

Auditor automatizado para SEO técnico, HTML semántico, accesibilidad, metadatos, Open Graph, datos estructurados, sitemaps, robots.txt, canónicos, enlaces internos, Core Web Vitals, SEO para Next.js, SEO para comercio electrónico, GEO, AEO, visibilidad en LLM, optimización para búsqueda por IA y optimización de recuperación de información.

CONTRATO DE EJECUCIÓN NO NEGOCIABLE

Esta habilidad es un flujo de trabajo de auditoría en vivo, no una lista de verificación estática.

1. REQUISITO DE FUENTE EN VIVO / MÁS RECIENTE

Al inicio de cada auditoría, DEBE recuperar y verificar la guía más reciente y relevante de la web.

No asuma que los archivos .md incluidos están actualizados. Son solo el conocimiento base.

Para cada dominio de auditoría aplicable:

1. Abra las fuentes semilla en source-registry.md.
2. Verifique que la página sea accesible y esté actualizada.
3. Revise el changelog, las actualizaciones, las notas de la versión, "Novedades" o equivalente de la fuente, cuando esté disponible.
4. Siga los sub-enlaces relevantes de origen interno descubiertos dentro de la fuente.
5. Continúe siguiendo sub-enlaces relevantes de forma recursiva hasta que no haya referencias autorizadas adicionales relevantes que puedan cambiar la regla que se está auditando.
6. Prefiera la versión más nueva aplicable de una especificación o página de documentación.
7. Registre la URL de la fuente, la fecha/versión de la fuente cuando esté disponible, y qué regla respalda.
8. Si una fuente no está disponible, reintente y/o encuentre el reemplazo autorizado antes de continuar. Nunca la omita en silencio.

2. JERARQUÍA DE FUENTES

Utilice este orden de autoridad:

1. Google Search Central / estándares web de Google
2. W3C / WCAG / WAI / WHATWG
3. Schema.org
4. Documentación oficial de Next.js y documentación de versiones/changelog
5. MDN
6. OWASP
7. Documentación oficial de la biblioteca/framework relevante para la pila detectada
8. Fuentes de la industria de buena reputación
9. Artículos de investigación / fuentes experimentales GEO-AI

Una fuente de menor autoridad NO DEBE anular una fuente de mayor autoridad directamente aplicable.

Si las fuentes entran en conflicto:

• Prefiera la fuente autorizada más nueva.
• Registre el conflicto.
• Explique qué fuente ganó y por qué.
• Nunca elija una en silencio.

3. POLÍTICA DE NO OMISIÓN / NO DETENCIÓN ANTICIPADA

El agente NO DEBE:

• omitir una categoría de auditoría porque otra categoría ya encontró problemas;
• omitir la verificación de la fuente porque la referencia incluida parece suficiente;
• omitir un sub-enlace porque la página principal ya se leyó;
• detenerse después de encontrar algunos problemas críticos;
• reemplazar la verificación requerida con suposiciones;
• informar "no revisado" sin un bloqueador documentado y un intento de recuperación.

La auditoría se completa solo cuando cada categoría aplicable tiene un estado registrado:

• PASS (APROBADO)
• ISSUES_FOUND (PROBLEMAS ENCONTRADOS)
• NOT_APPLICABLE (NO APLICA) con evidencia
• BLOCKED_AFTER_RETRY (BLOQUEADO DESPUÉS DE REINTENTO) con evidencia de intentos y una fuente/ruta alternativa cuando sea posible

Una categoría no puede omitirse en silencio.

4. COMPUERTA DE FINALIZACIÓN

Antes de producir el informe final, ejecute una verificación de finalización contra el registro de ejecución obligatorio. El informe se genera solo a partir de los estados terminales del registro.

Compuertas requeridas:

• Se completó la actualización de la fuente más reciente para cada dominio aplicable.
• Los sub-enlaces relevantes se inspeccionaron de forma recursiva.
• Los conflictos de fuentes se resolvieron o documentaron explícitamente.
• Se completó la auditoría de SEO/indexabilidad.
• Se completó la auditoría de HTML semántico.
• Se completó la auditoría de accesibilidad.
• Se completó la auditoría de metadatos/Open Graph/canónicos.
• Se completó la auditoría de datos estructurados.
• Se completó la auditoría de sitemap/robots.
• Se completó la auditoría de enlaces internos, incluida la profundidad de rastreo y la detección de páginas huérfanas.
• Se completó la auditoría de rendimiento/Core Web Vitals.
• Se completó la auditoría de comercio electrónico cuando corresponda.
• Se completó la auditoría de GEO/AEO/búsqueda por IA.
• Se completó la auditoría de Next.js cuando se detecte Next.js.
• Se completaron las comprobaciones de seguridad/fortalecimiento relevantes cuando la aplicación expone funcionalidad web/servidor.
• Se ejecutaron comprobaciones de validación/compilación/linting/verificación de tipos/tiempo de ejecución cuando el entorno las admite.
• Cada hallazgo tiene evidencia.
• Cada hallazgo tiene gravedad y clasificación.
• El orden de corrección está completo.
• No queda ningún TODO, SKIP o afirmación no verificada sin resolver en la auditoría final, a menos que esté explícitamente marcado como bloqueado.

Si una compuerta falla, continúe trabajando. No finalice el informe simplemente porque ya se pueda escribir un informe plausible.

5. POLÍTICA DE RECUPERACIÓN / REINTENTO

Cuando una operación requerida falla:

1. Diagnostique el fallo.
2. Reintente usando la misma ruta confiable cuando sea apropiado.
3. Pruebe una fuente/ruta autorizada equivalente.
4. Continúe con el trabajo de auditoría independiente que no dependa del fallo.
5. Vuelva al elemento bloqueado.
6. Registre el estado final y la evidencia.

Un fallo web temporal no es permiso para usar conocimiento desactualizado sin divulgación.

6. GRAFO DE FUENTES / RASTREO DE SUB-ENLACES

Trate cada página de documentación autorizada como un nodo en un grafo de fuentes.

Para cada página de fuente abierta:

• inspeccione los enlaces a especificaciones, referencias de API, changelogs, guías de migración, actualizaciones, herramientas de validación y guías oficiales relacionadas;
• siga los enlaces relevantes que puedan cambiar materialmente la regla de implementación;
• evite navegación irrelevante, marketing, comentarios o páginas de productos no relacionados;
• desduplique URL y canonicalice variaciones obvias de URL;
• mantenga un registro de fuentes visitadas;
• no vuelva a visitar una URL a menos que su contenido/versión haya cambiado o una afirmación conflictiva requiera una nueva verificación.

El objetivo es la integridad de fuentes relevantes, no un límite arbitrario de profundidad de rastreo.

7. REGLA DE PRIMERA LA EVIDENCIA

No convierta una recomendación en un hallazgo sin evidencia.

Para cada hallazgo, capture:

• evidencia exacta de código/página/URL;
• fuente que respalde la regla;
• fecha/versión de la fuente cuando esté disponible;
• por qué la implementación actual viola o no cumple con la regla;
• corrección concreta.

Distinga claramente entre:

• defecto confirmado;
• riesgo;
• recomendación;
• práctica emergente;
• idea experimental.

7A. PRESUPUESTO DE CONTEXTO / CARGA DE REFERENCIAS BAJO DEMANDA

Los archivos de referencia incluidos son intencionalmente modulares. NO cargue cada archivo .md en el contexto al inicio de una ejecución.

Utilice este orden de carga:

1. Lea SKILL.md y source-registry.md.
2. Inspeccione el proyecto y determine qué dominios de auditoría son aplicables.
3. Cargue solo los archivos de referencia necesarios para el dominio que se está auditando actualmente.
4. Después de completar un dominio, mantenga su resultado en el registro de ejecución en lugar de retener el texto de referencia completo en el contexto activo.
5. Cargue módulos adicionales solo cuando un hallazgo, versión del framework, conflicto de fuente o detalle de implementación los requiera.

El runbook local del proyecto definido a continuación es la memoria operativa compacta para ejecuciones futuras. DEBE preferirse a copiar toda esta habilidad en el contexto del proyecto.

7B. RUNBOOK LOCAL DEL PROYECTO (DURADERO, NUNCA SE ELIMINA AUTOMÁTICAMENTE)

En el primer uso en un proyecto, cree un archivo compacto en .claude/technical-seo-geo-runbook.md solo si no existe ya.

Reglas para este archivo:

• Es documentación duradera del proyecto, no estado de ejecución.
• Nunca lo sobrescriba automáticamente después de la creación.
• Nunca lo elimine durante la limpieza del registro.
• Manténgalo corto (objetivo: <= 120 líneas).
• Contiene solo la secuencia de ejecución, decisiones específicas del proyecto y punteros, no documentación de referencia copiada.
• Actualícelo solo cuando una decisión de flujo de trabajo específica del proyecto cambie genuinamente, y preserve el contenido existente propiedad del proyecto.

El contenido inicial del runbook debe ser la secuencia de pasos compacta que se muestra en PROJECT-LOCAL-STEPS.md.

8. DETECTE LA PILA REAL

Antes de aplicar reglas específicas del framework:

• inspeccione package.json;
• detecte la versión de Next.js;
• detecte la versión de React;
• detecte TypeScript;
• detecte el modelo de enrutamiento;
• detecte bibliotecas de UI/accesibilidad;
• detecte bibliotecas de esquema/SEO;
• detecte herramientas de prueba/compilación.

Aplique las reglas más recientes adecuadas para las versiones detectadas. No fuerce reglas de Next.js en un proyecto que no sea Next.js.

8A. REGLA DE NO DETENCIÓN VOLUNTARIA

El agente NO DEBE terminar voluntariamente la ejecución porque la tarea es grande, ya se han encontrado muchos problemas, una herramienta falló o ya se puede producir un informe plausible. Continúe todo el trabajo independiente y regrese al trabajo bloqueado antes de la finalización. Si una restricción externa impide genuinamente la finalización, registre la restricción exacta, la cobertura completada, los intentos de recuperación y los elementos no verificados restantes en lugar de implicar la finalización.

9. REGISTRO DE EJECUCIÓN OBLIGATORIO (ANTI-OMISIÓN / ANTI-DETENCIÓN ANTICIPADA)

Cada ejecución DEBE mantener un registro de auditoría explícito en memoria o en un archivo de trabajo temporal. El registro es la máquina de estados de ejecución para la auditoría; un informe en prosa no es un sustituto.

Almacenamiento y limpieza del registro de ejecución (OBLIGATORIO)

• NO mantenga una plantilla de registro por ejecución ni un archivo de estado de ejecución dentro del repositorio del proyecto del usuario.
• NO cree, sobrescriba ni elimine un archivo persistente del proyecto solo para realizar un seguimiento de la ejecución actual.
• Almacene el estado de ejecución solo en un directorio de ejecución temporal fuera del repositorio, por ejemplo $TMPDIR/technical-seo-geo/<run-id>/.
• El directorio temporal DEBE ser único por ejecución.
• Al finalizar normalmente, elimine el directorio de ejecución temporal.
• En caso de fallo/interrupción, una ejecución posterior DEBE limpiar los directorios de ejecución temporales technical-seo-geo/* obsoletos antes de iniciar una nueva ejecución.
• Nunca elimine archivos de proyecto del usuario, .git, context/, .claude/ ni ningún otro contenido persistente del proyecto como parte de la limpieza del registro.
• La antigua plantilla run-ledger-template.md incluida intencionalmente NO es necesaria y NO DEBE instalarse en el proyecto.

Esta separación es deliberada: el proyecto conserva solo instrucciones duraderas; el estado de ejecución transitorio nunca contamina el repositorio ni infla el contexto futuro.

El registro DEBE contener al menos:

| ID | Dominio | ¿Obligatorio? | Estado de la fuente | Estado de auditoría | Evidencia | Estado de recuperación | |---|---:|---|---|---|---| | D1 | Actualización de fuente en vivo | sí | pendiente/verificado/bloqueado | pendiente/aprobado/problemas/bloqueado | URL(s) | intentos | | D2 | Rastreo/indexabilidad | sí | ... | ... | ... | ... | | D3 | HTML semántico | sí | ... | ... | ... | ... | | D4 | Accesibilidad | sí | ... | ... | ... | ... | | D5 | Metadatos/redes sociales | sí | ... | ... | ... | ... | | D6 | Datos estructurados | sí | ... | ... | ... | ... | | D7 | Sitemap/robots/canónico | sí | ... | ... | ... | ... | | D8 | Enlaces internos | sí | ... | ... | ... | ... | | D9 | Rendimiento/CWV | sí | ... | ... | ... | ... | | D10 | Comercio electrónico | condicional | ... | ... | ... | ... | | D11 | GEO/AEO/búsqueda por IA | sí | ... | ... | ... | ... | | D12 | Next.js | condicional | ... | ... | ... | ... | | D13 | Seguridad/fortalecimiento | condicional | ... | ... | ... | ... | | D14 | Compuertas de validación | sí | ... | ... | ... | ... |

Reglas:

1. Un dominio comienza como pendiente y no puede considerarse completo sin un estado terminal explícito.
2. pendiente, en_progreso, TODO, SKIP, desconocido y en blanco son estados no terminales y prohíben la finalización.
3. Si el trabajo se interrumpe por un error, tiempo de espera, límite de velocidad, dependencia faltante o fallo de herramienta, marque el elemento afectado como BLOQUEADO_DESPUES_DE_REINTENTO solo después de agotar los intentos de recuperación; primero continúe todos los dominios independientes, luego reintente el elemento bloqueado nuevamente.
4. El agente NO DEBE marcar un dominio completo como APROBADO porque un subconjunto de verificaciones pasó.
5. Si un elemento no es aplicable, adjunte evidencia concreta de por qué no es aplicable.
6. Antes de la salida final, cada fila requerida del registro debe ser terminal y cada fila condicional debe estar marcada explícitamente como NO_APLICA o auditada.
7. El informe final DEBE generarse a partir del registro, no de la memoria o la intuición.

Invariante de finalización del registro

FINALIZABLE = todos(los elementos requeridos son terminales) Y todos los hallazgos tienen evidencia Y todas las actualizaciones de fuente obligatorias son terminales Y todas las validaciones aplicables tienen resultados explícitos.

Si FINALIZABLE = false, no produzca el informe de auditoría final. Continúe la ejecución o informe el bloqueador exacto solo después de que se hayan agotado todas las rutas de recuperación permitidas.

10. REGLA OBLIGATORIA DE CADUCIDAD / FRESCURA DE LA FUENTE EN VIVO

"Más reciente" significa la información autorizada más reciente que se pueda descubrir en tiempo de ejecución, no la información más reciente conocida por el modelo y no el markdown incluido más reciente.

Para cada familia de fuentes aplicable:

1. Abra la página semilla/actual.
2. Lea su información de última actualización/publicación/versión cuando esté disponible.
3. Inspeccione el registro de cambios oficial, la página de actualizaciones, las notas de la versión, el historial o el índice de versiones.
4. Siga los enlaces relevantes de origen interno de forma recursiva.
5. Vuelva a verificar la fuente actual después de seguir referencias más recientes cuando la página anterior apunte a ellas.
6. Registre la versión/fecha autorizada seleccionada en el registro.

Nunca codifique una versión actual del framework, umbral de Core Web Vitals, característica de datos estructurados, estado de accesibilidad o comportamiento de Google Search en la recomendación final sin verificación en tiempo de ejecución.

Precedencia de frescura de la fuente

Cuando varias páginas cubren la misma regla, elija en este orden:

1. Especificación normativa actual / documentación oficial para la versión detectada.
2. Notas de la versión oficial actual / registro de cambios / aviso de seguridad.
3. Guía de implementación oficial actual.
4. Documentación secundaria solo cuando las fuentes internas no cubran el problema.
5. Fuentes de la industria/marketing para prácticas complementarias o experimentales únicamente.

Un borrador más nuevo NO anula automáticamente una recomendación finalizada existente. Registre el estado del estándar (Recomendación, Borrador de trabajo, Obsoleto, etc.) y aplique la autoridad normativa adecuada.

11. VERIFICACIÓN RECURSIVA DE SUB-ENLACES — CON UNA CONDICIÓN DE PARADA REAL

El rastreo recursivo DEBE ser seguro en amplitud/profundidad y completo para enlaces autorizados relevantes.

Para cada nodo de fuente, inspeccione los enlaces cuyo destino podría cambiar una regla de auditoría, incluyendo:

• estándares/especificaciones;
• referencias de API;
• documentación versionada;
• guías de migración;
• registros de cambios y notas de la versión;
• avisos de seguridad;
• avisos de obsolescencia;
• requisitos/herramientas de validación;
• ejemplos oficiales que definen el comportamiento;
• documentación oficial de características de Google Search;
• documentación oficial de compatibilidad de framework/biblioteca.

Utilice un conjunto de visitados indexado por URL normalizada.