GSC Diagnostics — Quick wins, canibalización y anomalías

Tres diagnósticos sobre datos reales de Search Console que hoy no cubre ningún otro skill instalado: mineria-de-impresiones clasifica y prescribe contenido para una página ya elegida; seo-gsc-drops compara dos períodos por caída de clics. Este skill responde tres preguntas distintas sobre el sitio completo o una sección de él: dónde hay ganancias rápidas por CTR, qué queries se están robando tráfico entre páginas propias, y qué días no encajan con el resto de la serie.

Origen: metodología replicada a partir de la evaluación del MCP thatseoagent/mcp (2026-09-08) — se descartó instalar el servidor de terceros y se construyó esta lógica sobre el acceso a GSC que ya existe en este entorno (service account / token OAuth local), en vez de depender de software externo sin track record.

Autenticación

Nunca pedir credenciales nuevas. Usar el acceso ya establecido:

• Sesion local (interactiva): token en ~/gsc_token.pkl (scope webmasters.readonly), generado por gsc_auth.py. Si expiro o no existe, ejecutar gsc_auth.py para regenerarlo: abre navegador y requiere aprobacion interactiva del usuario. La ruta se puede sobrescribir con la variable de entorno GSC_TOKEN_PATH.
• Agente cloud / automatizado: service account con rol de lectura en Search Console. La ruta de su JSON key y las propiedades a las que tiene acceso se documentan en el CLAUDE.md del entorno. Una service account solo ve las propiedades donde se la agrego explicitamente como usuario, asi que para cualquier dominio fuera de esa lista hay que usar el token local.

El script scripts/gsc_diagnostics.py intenta primero el token local; si no existe y se le pasa --service-account, usa la service account.

Paso 0 — Validar el sitio y el rango de fechas