Informes - distribuidordeherramientases-wq/seo-taxonomy GitHub Wiki

Informes

Pestañas visibles

  1. Informes
  2. Panel
  3. Contenido
  4. Anomalías
  5. Analista

Los informes se generan bajo demanda y pueden exportarse a JSON.

Entre los informes actuales están:

  • Google · Visibilidad orgánica
  • Posicionamiento y búsqueda con IA
  • Rendimiento de Posts
  • Rendimiento de Landing Pages

Manual operativo

Ruta: TaxoCommerce SEO → Informes

Analista conserva su informe completo, pero se accede desde SEO Taxonomy → Mercado → Dónde estamos; ya no aparece como pestaña directa de Informes. El enlace seo-reports&tab=analista sigue vigente.

Pestañas

  • Informes
  • Panel
  • Contenido
  • Anomalías

Informes

Las tarjetas disponibles tienen:

  • Crear informe [Proceso]: genera el informe elegido.
  • Cerrar informe [Consulta]: cierra su vista.

Panel y Contenido

Reúnen, según las fuentes disponibles:

  • Google · Visibilidad orgánica.
  • Últimos 28 días disponibles.
  • Rendimiento de Posts.
  • Rendimiento de Landing Pages.
  • Señales externas.

Las tarjetas y gráficos son de lectura; no modifican contenido.

Anomalías

Incluye controles de estructura y contenido como:

  • Estructura Completa de Categorías.
  • FAQs sin elemento relacionado.
  • Clusters sin hubs primarios.
  • Hubs primarios sin cluster.
  • Hubs secundarios sin hub primario.
  • Hubs primarios en múltiples clusters.
  • Landings sin hub secundario.
  • Landings sin categoría de producto asociada.
  • Posts editoriales sin categoría de producto relacionada (post_to_category).
  • Posts sin Vocabulary semántico activo.
  • Categorías sin asignación estructural.
  • Categorías de producto con 0 productos.
  • Categorías duplicadas en múltiples Hubs Secundarios.

Acciones visibles:

  • Descargar JSON [Exporta]: descarga un paquete correctivo con los posts/landings detectados, su contenido, categorías WordPress, relaciones con product_cat y Vocabulary.
  • Importar JSON [Guarda]: aplica correcciones únicamente sobre IDs existentes; no crea ni borra contenidos, categorías o términos de Vocabulary.
  • Recalcular contadores [Proceso].
  • Borrar FAQs de categorías desaparecidas [Elimina].
  • Borrar FAQs de productos desaparecidos [Elimina].
  • Seleccionar todas las eliminables [Consulta].
  • Eliminar categorías seleccionadas [Elimina][Producción].

Para poder eliminar una categoría con 0 productos, el sistema exige además que no tenga relaciones funcionales protegidas y que disponga de un único Hub secundario publicado. Antes del borrado se valida el destino y, al completarse, se crea/actualiza automáticamente un redirect 301 hacia ese Hub; los datos SEO propios se limpian mediante Data Layer.

Una anomalía es una señal; revisar siempre el objeto antes de ejecutar una eliminación.

Analista

Periodo

  • selector Periodo.
  • Cambiar periodo [Consulta].

Bloques de análisis

La pantalla presenta, entre otros:

  • Cómo avanzan nuestras posiciones.
  • Movimiento de keywords.
  • Cómo se posiciona el catálogo.
  • Lectura rápida.
  • Evolución en Google.
  • Arquitectura que Analista tiene en cuenta.
  • Palabras clave vigiladas.
  • Nosotros frente a competidores.
  • Palabras clave que debemos disputar.
  • Demanda exterior · Google Trends.
  • Señales de clientes que no debemos perder.

Configurar comparación

Permite definir competidores y palabras que se quieren vigilar.

Guardar comparación [Guarda].

Analista carga los bloques bajo demanda para evitar calcular todos los informes cada vez que se abre la página.

Plan de acción validado · Analista 3.8.1

El bloque Plan de acción sigue siendo bajo demanda: abrir Informes > Analista no calcula esta cola. Al pulsar Plan de acción se genera únicamente ese informe.

Antes de mostrar una instrucción, Analista 3.8.1 valida:

  1. Consulta ↔ entidad: marca, modelo/variante, SKU/MPN cuando están disponibles, intención, categoría y URL.
  2. Destino: una instrucción de edición necesita una URL local/canónica resuelta. Si no existe, la salida es INVESTIGAR COBERTURA.
  3. Volumen de evidencia: impresiones, clics, número de consultas y base del periodo anterior. Las muestras pequeñas no se convierten en quick wins solo por posición.
  4. Preparación comercial: stock/disponibilidad, precio y, cuando existen, proveedor y margen/comisión.
  5. Cobertura editorial existente: categoría/producto y posts publicados de Dependiente, Ingeniero y Comparador. Se prefiere actualizar/enlazar antes que crear otra URL.
  6. Metadatos efectivos: Analista distingue postmeta explícito de title/meta gestionados por plugin SEO o fallback de plantilla, para no generar falsos positivos de “meta inexistente”.

Los estados del plan son:

  • HACER AHORA: destino y asociación validados, evidencia suficiente y confianza compatible con ejecución. Máximo 10; el sistema no rellena el cupo.
  • HACER DESPUÉS: trabajo válido, pero menos urgente; en 3.8.2 también puede contener una oportunidad SEO válida temporalmente bloqueada por una dependencia comercial explícita.
  • INVESTIGAR: conflicto de modelo, entidad no demostrada o destino sin resolver. Los bloqueos puramente comerciales ya no se clasifican aquí.
  • VIGILAR: señal coherente pero todavía inmadura.
  • ESPERAR DATOS: muestra demasiado pequeña o crecimiento sobre base insuficiente.
  • SIN ACCIÓN: compatibilidad histórica para señales sin valor de trabajo.

Cada tarjeta muestra consulta exacta, URL atribuida, tipo/confianza de match, impresiones, clics, CTR, posición, variación absoluta, base anterior, confianza, preparación comercial, responsable recomendado y dependencias.

Los valores Autoridad / Visitas / Ventas son scores internos de priorización. No son métricas de autoridad de Google.

Umbrales configurables

En Analista → Comparación, el formulario de configuración incluye los umbrales internos de evidencia y matching. Son criterios operativos del proyecto, no reglas SEO universales:

  • máximo de impresiones considerado muestra pequeña;
  • impresiones consideradas fiables;
  • volumen alto;
  • base previa mínima para interpretar porcentajes;
  • match parcial mínimo;
  • match exacto mínimo.

Seguridad y responsabilidades

Analista diagnostica y deriva. No publica, no crea posts/URLs ni modifica categorías o productos automáticamente.

  • Auditor conserva la gestión de anomalías/tareas.
  • Editora revisa cambios de contenido.
  • Catálogo/proveedores valida surtido, disponibilidad, proveedor, precio y margen.
  • SEO/taxonomía resuelve asociaciones, destinos y enlazado.
  • Ingeniero / Solucionador / Comparador aportan cobertura o evidencia; Analista no duplica sus workers.

En Fuentes se muestran las pruebas de aceptación de 3.8.1/3.8.2/3.8.3 y un diagnóstico separado de Action Scheduler para detectar colas vencidas que puedan afectar a la frescura de datos.

Corrección del Plan de acción · Analista 3.8.2

3.8.2 mantiene intactos los demás módulos de Analista y modifica únicamente la generación/explicación de tareas del Plan de acción.

Cambios:

  • antes de devolver INVESTIGAR, intenta resolver la consulta contra la taxonomía product_cat y el índice local de entidades ya conocido por Analista;
  • un candidato automático solo se acepta si vuelve a superar la validación de entidad, URL e identificadores; las consultas con modelo no se degradan a categorías genéricas;
  • INVESTIGAR queda reservado a conflictos de modelo, entidad no demostrada o destino sin resolver;
  • una oportunidad SEO válida con datos comerciales incompletos pasa a HACER DESPUÉS con gate BLOCKED_COMMERCIAL, no a INVESTIGAR;
  • una muestra insuficiente pasa a ESPERAR DATOS;
  • el score de oportunidad permanece estable cuando existe una dependencia: los gates modifican ejecutabilidad/confianza, no la puntuación;
  • cada bloqueo incluye blocker_type, investigation_steps, valor actual, condición de desbloqueo, responsable y bucket_if_unblocked;
  • si se resuelve una dependencia comercial y el bucket base era HACER AHORA, la siguiente ejecución puede devolver la tarea a HACER AHORA sin subir artificialmente el score;
  • el informe muestra un diagnóstico agregado de asociaciones auto-resueltas, bloqueos de entidad, bloqueos comerciales, evidencia insuficiente y tareas de score alto retenidas por un gate.

Ejemplo comercial: una categoría puede tener demanda SEO suficiente pero quedar temporalmente en HACER DESPUÉS porque faltan stock_categoria, precio_categoria, proveedor o margen/comisión. Analista toma una muestra acotada de productos de la categoría para intentar validar esos datos sin cargar todo el catálogo. GA4 se muestra como señal de medición separada; su ausencia por sí sola no bloquea una oportunidad SEO si la oferta comercial ya está acreditada. La tarjeta enumera exactamente los campos bloqueantes y qué debe ocurrir para desbloquearla.

Coherencia de tarea · Analista 3.8.3

3.8.3 es una corrección puntual del Plan de acción. No cambia otros informes ni servicios.

La tarjeta se construye desde una única decisión task_decision, que contiene:

  • Estado de la señal: aceleración, descenso, mejora/pérdida de posición, muestra insuficiente o señal estable.
  • Prioridad de trabajo: HACER AHORA, HACER DESPUÉS, INVESTIGAR, VIGILAR, ESPERAR DATOS o SIN ACCIÓN.
  • Tipo de intervención: la acción primaria de trabajo.
  • Bloqueo: entidad/destino, evidencia, dependencia comercial o sin bloqueo.

Una tarea solo puede quedar en HACER AHORA cuando su acción primaria es ejecutable y tiene verbo, objeto, destino, responsable, URL validada y gate READY. Si la única instrucción es observar, esperar, investigar o mantener la línea base, se reclasifica automáticamente.

El bloque Qué hacer muestra una sola acción primaria. Las comprobaciones de INVESTIGAR permanecen en un bloque separado e indican duda pendiente, valor actual, fuente donde verificar, criterio de salida y responsable.

El límite de diez HACER AHORA actualiza también task_decision; por tanto contador, sección, etiqueta, gate y JSON leen el mismo bucket final.

La identidad de seguimiento usa una clave estable por consulta/tema. Resolver una dependencia no crea una tarea nueva: se conserva la trazabilidad y se migra el identificador anterior cuando existe.

La medición se vincula a la intervención concreta y siempre conserva la línea base de impresiones, clics, posición y periodo. Los resultados se interpretan como asociación temporal, no como causalidad automática.

Las pruebas T01–T06 verifican: Cámaras sin acción ejecutable, contrato de HACER AHORA, separación de etiquetas, coherencia de contadores/JSON, trazabilidad al resolver bloqueos y regresiones de evidencia/URL/modelo/tarea ejecutada/oportunidad ejecutable.

Propietario de intención y anti-canibalización · Analista 3.9.0

Analista 3.9.0 modifica la lógica del Plan de acción, no añade un nuevo formulario ni un nuevo botón. Los controles de Periodo, Comparación y generación del Plan siguen siendo los mismos; cambia la forma en la que Analista decide el destino de cada oportunidad.

Antes de proponer trabajo editorial, Analista revisa la cobertura local en:

  • categoría de producto;
  • hub secundario;
  • hub primario;
  • cluster;
  • landing;
  • post;
  • página editorial.

Las páginas corporativas y funcionales no se consideran destino editorial.

El Plan de acción puede devolver ahora estas decisiones editoriales:

  • MEJORAR_CATEGORIA / IMPULSAR_CATEGORIA: la intención debe concentrarse en una categoría ya existente.
  • MEJORAR_HUB / IMPULSAR_HUB: la oportunidad pertenece a un hub ya existente.
  • MEJORAR_CLUSTER / IMPULSAR_CLUSTER: la cobertura amplia corresponde al cluster existente.
  • MEJORAR_LANDING / POTENCIAR_LANDING: existe una landing que debe absorber la demanda.
  • MEJORAR_POST / IMPULSAR_POST: existe un post apropiado y no conviene abrir otra URL.
  • CREAR_POST: no existe cobertura suficiente y la intención es informativa y concreta.
  • CREAR_LANDING: no existe propietario local suficiente y la demanda cruza varias familias/categorías, por lo que se propone una landing transversal.
  • INVESTIGAR_COBERTURA: la demanda es comercial/transaccional, pero no está demostrado si falta categoría, surtido o landing; no se propone una URL hasta resolverlo.

Cada tarea incorpora coverage_decision, que deja trazado si la recomendación parte de una entidad existente o de un posible hueco nuevo.

Regla anti-canibalización

Antes de recomendar una URL nueva, Analista intenta localizar un propietario existente suficientemente afín. Para demanda comercial se prioriza, de forma orientativa:

Categoría → Hub secundario → Hub primario → Cluster → Landing → Post.

Si una entidad existente puede absorber la intención, el Plan de acción debe proponer mejorar/impulsar esa entidad en lugar de repartir autoridad entre URLs paralelas.

Una propuesta CREAR_POST o CREAR_LANDING queda como propuesta editorial y no como publicación automática. Debe validarse que ninguna URL existente pueda absorber la intención sin canibalización.

Controles de interfaz

Analista 3.9.0 no incorpora botones, casillas, selectores ni campos nuevos. La novedad se refleja en las etiquetas, acciones y explicación de las tarjetas del Plan de acción y en el JSON exportado. Por tanto, no cambia el procedimiento de uso: generar el Plan de acción, revisar la decisión, la entidad/URL y el bloqueo antes de ejecutar trabajo editorial.

Informe competitivo profundo

Dentro de Analista → Comparación, después de guardar competidores y palabras vigiladas, aparece el bloque Informe competitivo profundo.

Competidores configurados [Consulta]: número de dominios guardados en la comparación. El informe profundo analiza como máximo 8 competidores por ejecución.

Keywords vigiladas [Consulta]: número de palabras/intenciones configuradas. Si no hay ninguna, Analista toma automáticamente una muestra limitada de consultas accionables de Search Console del dominio propio.

Último informe [Consulta]: fecha del último informe competitivo persistido.

Generar informe competitivo [Proceso][API]: ejecuta de forma explícita el informe. Abrir la pantalla no consume consultas externas. La ejecución puede usar la conexión compartida SerpApi → ScraperAPI para muestrear Google Search y realiza un rastreo público acotado de cada dominio.

El informe separa estrictamente:

  • dominio propio: puede usar Search Console, GA4 y Bing, además de la evidencia pública;
  • competidores: sólo utiliza evidencia pública observable y el muestreo SERP;
  • Google Trends: se usa como contexto de demanda temática, nunca como tráfico estimado de un dominio.

Dimensiones comparadas:

  • SERP;
  • Arquitectura;
  • Producto;
  • Enlazado;
  • Confianza;
  • UX;
  • Técnico observable.

Cada dimensión muestra una puntuación sobre 5 y un porcentaje de confianza de evidencia. Si faltan datos, se muestra N/D; la ausencia de datos no se transforma en cero ni penaliza artificialmente el índice.

El muestreo público revisa, de forma limitada:

  • homepage;
  • robots.txt;
  • sitemap declarado en robots;
  • una URL representativa encontrada en las SERP, cuando existe;
  • title, meta description, canonical, H1, schema, enlaces internos y señales comerciales observables;
  • señales de ficha como precio, stock, SKU/EAN, reviews, envío, devoluciones, garantía, especificaciones y compatibilidad, cuando la URL representativa parece una ficha de producto.

Exportar JSON [Exporta]: descarga el último informe completo, incluyendo matriz competitiva, keywords muestreadas, contexto propio, fortalezas, brechas, plan priorizado y límites de evidencia.

Límites

  • Search Console, GA4 y Bing sólo describen el sitio conectado.
  • La visibilidad de los competidores es un muestreo sobre las keywords analizadas, no una estimación de tráfico total.
  • Google Trends no se interpreta como tráfico de dominio.
  • El rastreo competitivo es una muestra pública y no sustituye Screaming Frog/Sitebulb.
  • Core Web Vitals homogéneos y autoridad/backlinks requieren fuentes adicionales; si no están disponibles quedan como N/D.