Dashboards simples para monitorear tu cadena de contenido
Cómo seguir ideas, borradores, traducciones, builds y publicaciones sin convertir tu operación editorial en un panel demasiado complejo.
Una cadena de contenido no se rompe de una sola vez. Empieza a romperse en silencio.
Una idea queda parada sin responsable. Un borrador nace sin fuentes. Una traducción se genera, pero no se revisa. Un post se publica en portugués, pero las versiones en inglés y español quedan olvidadas. Un deploy falla, nadie lo ve, y el sitio sigue pareciendo normal hasta que alguien nota que la última publicación no entró.
Por eso los dashboards simples importan. No para crear otra pantalla bonita, sino para ver cuellos de botella antes de que se conviertan en deuda operativa.
Qué es salud editorial
Salud editorial no es publicar todos los días. Tampoco es tener una lista enorme de ideas.
Para mí, una cadena saludable es aquella en la que cada ítem tiene estado claro, próximo paso visible y bajo riesgo de quedar olvidado.
Esto vale tanto para un blog personal como para una red de sitios. La diferencia es que, en una red, el error escala más rápido. Si el proceso depende de memoria, pestañas abiertas y mensajes sueltos, funciona mientras el volumen es pequeño. Después se convierte en ruido.
Una operación saludable responde preguntas simples:
- ¿cuántas ideas esperan triage?
- ¿cuántos textos están en revisión?
- ¿qué posts ya tienen versión PT, pero todavía no tienen EN y ES?
- ¿qué builds fallaron?
- ¿qué fuentes necesitan revisión?
- ¿qué contenidos están listos, pero todavía no fueron publicados?
Si no puedo responder eso en pocos minutos, el problema no es falta de productividad. Es falta de visibilidad.
Métricas que importan
El error común es empezar por el dashboard ideal. Gráficos, filtros, colores, rankings y pantallas complejas. Casi siempre es demasiado pronto.
Yo empezaría con métricas operativas, no de vanidad.
Las primeras serían:
- Ideas por status: sugerida, aprobada, en producción, en revisión, publicada, rechazada.
- Tiempo detenido por etapa: cuántos días un ítem está sin cambio de status.
- Cobertura por idioma: PT publicado, EN pendiente, ES pendiente.
- Fallas de automatización: ejecuciones con error en n8n.
- Fallas de build/deploy: commits que no llegaron al sitio.
- Posts sin fuentes suficientes: contenido técnico sin referencia mínima.
- Posts sin relación interna: páginas huérfanas dentro del propio blog.
Estas métricas no sirven para impresionar. Sirven para decidir la próxima acción.
Un buen dashboard editorial debe apuntar trabajo, no solo mostrar números.
Un panel simple
En la arquitectura de este laboratorio, el panel más pragmático empieza en Baserow.
Ya puede guardar ideas, status, idioma, prioridad, origen, palabras clave, URL final y observaciones. Con algunas views bien diseñadas, Baserow se convierte en un cockpit editorial simple:
- una view para triage;
- una view para textos en revisión;
- una view para traducciones pendientes;
- una view para publicaciones listas;
- una view para errores o bloqueos;
- una view por proyecto o dominio.
n8n entra como motor. Puede actualizar status, registrar logs, guardar fecha de la última ejecución, salvar la respuesta de GitHub API y marcar si el deploy fue disparado.
Astro sigue como capa pública. No necesita saber del desorden operativo. Recibe archivos válidos y genera páginas estáticas.
Esa separación es importante: el panel muestra la operación; el sitio público entrega contenido.
Alertas antes que dashboards bonitos
Antes de gastar energía en el diseño del dashboard, yo crearía alertas simples.
Algunos ejemplos:
- idea aprobada hace más de 7 días sin borrador;
- post PT publicado sin traducción después de 5 días;
- workflow de n8n con error;
- build de Cloudflare Pages con falla;
- post técnico sin fuente;
- contenido marcado como listo, pero todavía con
draft: true; - canonical duplicado o ausente.
La alerta correcta reduce la necesidad de mirar el panel todo el tiempo.
Dashboard es bueno para revisión periódica. Alerta es buena para excepción. Mezclar los dos suele generar ansiedad operativa: la persona pasa a monitorear una pantalla en vez de mejorar el proceso.
Rutina de revisión
Un dashboard solo funciona si existe una rutina detrás.
Mi sugerencia para una operación enxuta sería:
- lunes: revisar ideas nuevas y aprobar prioridades;
- miércoles: revisar textos en producción y traducciones pendientes;
- viernes: revisar publicaciones, enlaces internos, fuentes y fallas;
- una vez al mes: limpiar ideas rechazadas y revisar pilares editoriales.
Nada de esto necesita ser complejo. El objetivo es impedir que la cadena se convierta en un depósito de intenciones.
Al final, un buen dashboard no es el que muestra todo. Es el que muestra lo suficiente para tomar la próxima decisión con claridad.
Para un Systems Builder, esa es la diferencia entre solo producir contenido y construir una operación editorial que aguanta crecer.