El sistema vigila lo que se busca y se conversa en el universo de Nacar, propone qué contenido crear, ayuda a producirlo en tres idiomas y, una vez aprobado por una persona, lo convierte en página, post de LinkedIn e Instagram y actualización de la capa que leen los motores de IA. Propone, no publica: cada pieza pasa por alguien de Nacar antes de salir.
Todo lo que ocurre entre capas queda escrito en Supabase con estado y fecha, así que cualquier persona de Nacar puede ver qué se detectó, qué se propuso, qué se aprobó y qué salió. Las dos compuertas en rojo son personas: sin su clic, nada se publica.
En una pantalla. El detalle de cada capa, el ciclo de vida de una pieza, el modelo de datos y la semana tipo están en la sección siguiente.
Search Console dice qué busca la gente que ya llega a Nacar; un proveedor de datos de búsqueda dice qué busca la que todavía no llega; Instagram y la Biblioteca de anuncios dicen de qué se habla; los RSS y sitemaps de estudios pares dicen qué publica el sector.
Y cada semana se lanzan las mismas 30 preguntas a ChatGPT, Claude y Perplexity para ver si Nacar aparece y quién aparece en su lugar. Es fuente de temas y métrica a la vez.
Agrupa los términos en temas, los puntúa (demanda × relevancia para Nacar × hueco × frescura) y redacta para los mejores una propuesta de una pantalla: título, ángulo, por qué ahora, evidencia, formato, idioma origen y brief.
Nadie escribe todavía un artículo. Una propuesta se acepta o descarta en treinta segundos, y el motivo del descarte ajusta la puntuación siguiente.
El borrador nace en el idioma origen y de él se derivan los otros dos. Cada versión sabe de qué revisión viene: si se corrige el original, las derivadas se marcan desfasadas y se regeneran con un clic. Una aprobación editorial por tema, no tres.
Cada pieza nace con su pack GEO: meta tags, JSON-LD, bloque de preguntas y respuestas, datos citables con fuente, resumen para llms.txt y enlaces internos.
Al aprobar: la página sale en las tres URL con hreflang, y la capa GEO del sitio entero se regenera (llms.txt, grafo JSON-LD, sitemap, IndexNow). Segundos.
Los posts de LinkedIn e Instagram se derivan y entran en la segunda compuerta: una pantalla, todas las variantes, una aprobación. Salen por API o quedan listos para programar, según la liberación de cada plataforma.
Visitas de crawlers de IA por página. Share of voice en los motores (en cuántas de las 30 preguntas aparece Nacar). Impresiones y clics por página e idioma. Sesiones referidas desde ChatGPT, Perplexity y similares.
Lo que el sistema controla es la infraestructura de descubrimiento y su medición. La cita en una respuesta de IA es consecuencia, no entregable.
Martes, diez minutos: aceptar o descartar propuestas. Jueves, veinte: editar y aprobar la pieza. Viernes, diez: aprobar los posts en una pantalla. El resto ocurre solo.
Con nueve aprobaciones por tema el sistema se atasca en el segundo mes; con dos, se sostiene. Está diseñado para dos.
Lo que la sección anterior resume en seis celdas, aquí con el detalle que hace falta para discutirlo: qué fuente alimenta cada capa, qué decide el sistema y qué decide una persona, por qué estados pasa una pieza, qué tablas lo sostienen y cómo se reparte una semana.
Ninguna fuente sola basta. Search Console dice qué busca la gente que ya llega a Nacar; la demanda de búsqueda dice qué busca la gente que todavía no llega; Meta dice de qué se habla; el sector dice qué publican los pares; y el sondeo de motores dice qué responden ChatGPT o Perplexity cuando alguien pregunta por diseño en Barcelona, y si Nacar aparece o no. Cada fuente escribe filas en la tabla señales con el mismo formato: término, idioma, volumen, tendencia, fecha, origen.
Consultas reales por página e idioma, con impresiones y clics. Es la única fuente que dice qué se busca y no encuentra en el sitio: consultas con muchas impresiones y ningún clic, o sin página que responda.
Volumen mensual y tendencia por término, a partir de un conjunto semilla del universo Nacar (diseño industrial, packaging, branding, sostenibilidad, sectores cliente). Google Trends no tiene API oficial; se usa un proveedor de datos de palabras clave (DataForSEO o Keyword Planner) que sí la tiene.
Qué se publica bajo los hashtags del sector (API oficial, hasta 30 hashtags por semana) y qué promueven los competidores en la Biblioteca de anuncios, pública en la UE. Meta no dice qué se busca; dice de qué se habla. Se trata como señal de temperatura, no de demanda.
Publicaciones del sector (Experimenta, Gràffica, Dezeen, designboom) y el diff semanal de los sitemaps de estudios comparables: qué páginas nuevas han publicado. Barato, y muy revelador de hacia dónde se mueve el discurso.
Cada semana se lanza el mismo conjunto de 30 preguntas a ChatGPT, Claude y Perplexity («¿qué estudios de diseño industrial destacan en Barcelona?», «¿cómo se diseña un packaging reciclable?»). Se registra si Nacar aparece, en qué posición y quién aparece en su lugar. Es a la vez fuente de temas y métrica de resultado.
Barcelona Design Week, Salone, premios, ferias de packaging. Se cargan a mano una vez al año y suben la puntuación de los temas relacionados en las semanas previas. Es la única fuente manual, y por diseño.
El Cerebro convierte cientos de filas de señales en tres a cinco propuestas semanales que una persona puede leer en diez minutos. Lo hace en tres pasos, y el tercero es el que importa.
Cada término se convierte en un vector (pgvector, dentro de Supabase) y se agrupa con sus vecinos: «packaging reciclable», «envase sostenible» y «diseño de envases eco» son un tema, no tres. Las señales de Meta y del sector se pegan al tema más cercano.
Cada tema recibe una puntuación: demanda (volumen y tendencia) × relevancia (cercanía a los servicios y sectores de Nacar, definidos una vez) × hueco (no hay página que responda, o los motores de IA no citan a Nacar) × frescura (fechas del calendario, picos recientes). Un tema con mucha demanda pero ya cubierto puntúa bajo; un tema modesto donde Nacar tiene autoridad y nadie lo cubre puntúa alto.
Claude escribe, para cada tema alto, una propuesta de una pantalla: título, ángulo, por qué ahora, qué evidencia lo sostiene (las señales, enlazadas), formato sugerido, idioma origen y un brief de cinco líneas. La propuesta va al panel con estado propuesta. Nadie escribe todavía un artículo.
Cuando una persona acepta una propuesta, el Taller genera el borrador completo en el idioma origen y, de él, deriva las versiones en los otros dos. La regla es que la traducción es derivación, no creación paralela: cada versión sabe de qué versión y de qué revisión viene. Si alguien corrige el original, el panel marca las derivadas como desfasadas y las regenera con un clic. Eso mantiene una sola aprobación editorial por tema, no tres.
No se añade después: el borrador y su capa de descubrimiento se generan juntos. El pack incluye título y descripción para buscadores, JSON-LD (Article, FAQPage, about con las entidades que trata), un bloque de preguntas y respuestas, dos o tres datos citables con fuente, el resumen de dos líneas que irá a llms.txt, y los enlaces internos hacia servicios y proyectos de Nacar relacionados.
Los motores generativos citan lo que pueden extraer limpio: definiciones, cifras con fuente, respuestas directas. El pack existe para que cada página tenga eso.
El panel muestra el original y las derivadas lado a lado, con el pack GEO desplegable. La persona edita el texto, añade un proyecto real de Nacar como ejemplo, corrige el tono, y aprueba. Un clic cambia el estado a aprobada y dispara la Distribución.
Para el catalán se recomienda una revisión de una persona nativa antes de aprobar: es el idioma donde la traducción automática más se nota, y el que más dice de un estudio de Barcelona.
Al aprobarse una pieza, dos cosas ocurren al instante y sin intervención: la página se publica en el blog y la capa GEO del sitio se regenera. Una tercera cosa se prepara pero no sale: los posts derivados para LinkedIn e Instagram entran en la segunda compuerta.
La página se publica en las tres URL (una por idioma) con hreflang recíproco, JSON-LD traducido, dateModified real y los enlaces internos del pack. Vercel regenera solo las páginas afectadas. Tiempo desde el clic hasta estar en línea: segundos.
Se reescriben llms.txt y llms-full.txt con el índice de páginas y sus resúmenes, se actualiza el grafo JSON-LD de la organización (qué temas trata, qué páginas lo prueban), se regenera el sitemap por idioma y se notifica a los índices mediante IndexNow. El sitio entero queda un poco más citable con cada pieza, no solo la pieza.
De la pieza aprobada se derivan un post de LinkedIn (ES y EN) y uno de Instagram con imagen generada por plantilla del design system, nunca arte generada por IA. Todo aparece en una sola pantalla del panel; una aprobación cubre todos los canales. Al aprobar, se publica por API o queda listo para copiar y programar, según la liberación de cada plataforma.
«Ser encontrado por los motores de IA» no es un deseo sino cuatro números que el panel muestra cada semana. Lo que el sistema controla es la infraestructura de descubrimiento y su medición; la cita concreta en una respuesta de ChatGPT es consecuencia, no entregable.
Cuántas veces por semana GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot y Google-Extended leen el sitio, y qué páginas.
Fuente: log de Vercel → tabla crawler_hitsPorcentaje de las 30 preguntas del sondeo en las que Nacar aparece citada, y contra quién. Es la métrica de resultado del proyecto.
Fuente: sondeo semanal → tabla sondeosPor página e idioma. Muestra si las piezas nuevas capturan la demanda que las motivó.
Fuente: Search Console APISesiones que llegan desde chatgpt.com, perplexity.ai, copilot y similares. Pequeño hoy; es la curva que interesa ver crecer.
Fuente: GA4Cada domingo el sistema redacta un informe de una página con estas cuatro cifras, qué se publicó, qué se propuso y no se aceptó, y qué huecos siguen abiertos en los motores. Ese informe realimenta la Escucha: un hueco persistente sube la puntuación del tema la semana siguiente.
Todo contenido es una fila que avanza por estados. El panel no es más que una vista de esta tabla filtrada por estado, y cada transición guarda quién la hizo y cuándo.
Siete tablas en Supabase. Deliberadamente pocas: cada capa lee de la anterior y escribe en la suya, y el panel es solo vistas sobre esto.
| Tabla | Qué guarda | Quién escribe |
|---|---|---|
| señales | Una fila por término observado: origen, idioma, volumen, tendencia, fecha, dato bruto. | Escucha (cron semanal) |
| temas | Grupos de señales con vector, puntuación desglosada, evidencia enlazada y estado. | Cerebro |
| propuestas | Título, ángulo, por qué ahora, brief, idioma origen, estado, motivo de descarte. | Cerebro; persona (estado) |
| contenidos | Una fila por idioma y versión: cuerpo, pack GEO, de qué contenido y revisión deriva, estado. | Taller; persona (edición y estado) |
| distribuciones | Una fila por canal y pieza: carga útil, estado, fecha, identificador externo si se publicó por API. | Distribución; persona (compuerta 2) |
| crawler_hits | Agente, ruta, fecha, por cada lectura de un bot de IA. | Middleware del sitio |
| sondeos | Pregunta, motor, si Nacar aparece, posición, quién más aparece, fecha. | Medición (cron semanal) |
El sistema está pensado para que una persona de Nacar dedique unos cuarenta minutos a la semana, en dos momentos. Los días marcados en rojo son suyos; el resto ocurre solo.
Ninguna imagen se genera con IA. Nacar diseña en Figma tres o cuatro plantillas de post con sus variables (color, tipografía, espaciado, logotipo); el sistema las reproduce como código y las rellena con el texto aprobado. Cada pieza sale siempre en la marca, en los tres formatos, sin abrir Figma.
Cuatro semanas y media. El orden no es arbitrario: primero lo que no depende de nadie (la base del sitio), después lo que depende de accesos (la Escucha), y al final lo que depende de que Nacar haya visto propuestas reales (el Taller y la Distribución). Los puntos son los checks de la sección siguiente.
Seis puntos de revisión. Cuatro son presenciales y obligatorios: son las reuniones donde se decide algo que después no se puede deshacer barato. Entre checks, cada viernes hay un vídeo de cinco minutos con el avance; no es una reunión, es ritmo.
Se recibe el design system y el Figma, se cierran los accesos y se toman las decisiones que definen el sistema: idioma origen, quién aprueba en cada compuerta, qué servicios y sectores marcan la relevancia, y las 30 preguntas que haremos a los motores de IA cada semana. Sale con acta el mismo día.
Home y plantillas institucionales en los tres idiomas sobre el design system, en un enlace de prueba. Nacar valida la fidelidad al Figma y comenta directamente sobre las páginas. Sin decisión nueva: es una comprobación de que la base es la correcta antes de construir encima.
El Cerebro presenta sus primeras propuestas con evidencia real y Nacar las acepta o descarta en directo, diciendo por qué. Es el check más importante del proyecto: aquí se calibra si el sistema propone lo que Nacar quiere ser, y el tono en que lo escribe. Todo lo que viene después se construye sobre esta calibración.
Revisión de los proyectos migrados a las plantillas y de los textos institucionales en los tres idiomas. Solo tiene sentido si el acervo se entregó en la semana 2; si no, se funde con C4.
Una pieza real de principio a fin, en la sala: propuesta, borrador en tres idiomas, aprobación, blog y capa GEO en línea, posts derivados, segunda aprobación. Se revisan las plantillas de social sobre el design system y se forma a las personas de las dos compuertas en el panel. Al salir, Nacar sabe operar el sistema sin el desarrollador.
Puesta en producción en el dominio, panel de medición con las cuatro cifras, entrega de cuentas, claves y documentación de operación. Acta de cierre con lo entregado, lo que queda en fase 2 y la cadencia de las semanas siguientes.