Un producto tiene una página que se posiciona y una ficha de datos que alguien consulta. Cuando las dos viven en el mismo registro, el registro carga con dos trabajos distintos. Como página necesita URL, maquetación y metadatos de búsqueda. Como dato necesita campos ordenados, relaciones con otros datos y un único valor por atributo. Mezclar ambos trabajos produce campos duplicados y tipos de contenido que nadie sabe a qué público sirven.
Síntomas de un registro con dos trabajos
- Un mismo atributo aparece en el editor de la página y en una tabla de especificaciones.
- Un cambio de dato obliga a editar la maquetación.
- El marcado estructurado y el texto visible dicen cosas distintas.
- Un tipo de contenido agrupa elementos con ciclos de vida opuestos, unos con URL y otros sin ella.
- Un catálogo compartido, como una lista de radios o de certificaciones, se reescribe dentro de cada página.
Dos de estos síntomas bastan para plantear la separación.
Definición del patrón
La página pública es el registro que tiene URL. Contiene el contenido que se lee, la maquetación y los metadatos de búsqueda. La entidad de datos es un registro headlessGlosarioHeadlessModalidad de ejecución de un software, navegador (como Chromium, Firefox o WebKit) o arquitectura de sistema sin interfaz gráfica de usuario (GUI). En el ámbito de la automatización y la navegación agéntica por IA, un navegador headless ejecuta el motor de renderizado y JavaScript en segundo plano (vía herramientas como Playwright o Puppeteer), exponiendo directamente el DOM y el Árbol de Accesibilidad para inspección, scraping estructurado y ejecución de acciones programáticas sin cargar elementos visuales en pantalla.Ver término completo →, sin URL ni plantilla propia, que guarda los atributos estructurados. Un puntero guardado en la página identifica su entidad. Los catálogos de referencia son entidades compartidas, y varias fichas apuntan a la misma.
Cada elemento del diagrama tiene una responsabilidad. La página responde a una visita. La entidad responde a una consulta. El catálogo responde a la pregunta de qué existe en el mundo y se reutiliza.
Cómo modelarlo
- Listar los tipos y marcar cuáles tienen URL. Un tipo con URL lleva SEO y maquetación. Uno sin URL es un almacén.
- Separar atributos de presentación y atributos de dato. El titular, el texto comercial y la imagen principal son de la página. Las medidas, las capacidades, las opciones y los recursos descargables son de la entidad.
- Crear el puntero en la página, no en la entidad. La página sabe qué ficha usa. La ficha no necesita conocer a su página, porque la dirección de la dependencia sigue a la dirección de la lectura.
- Extraer a catálogos lo que se repite. Si un mismo elemento aparece en varias fichas, deja de ser un campo de texto y pasa a ser una entidad con identidad propia.
- Decidir la dirección inversa. Un catálogo puede ignorar qué fichas lo usan y calcularlo al recorrer las fichas. Evita guardar relaciones por duplicado y vale mientras el volumen sea pequeño.
- Registrar las relaciones en un único mapa. Cada relación por identificador entra primero en un documento de referencia, y de ahí se implementa.
- Dejar un respaldo. Si una página no tiene entidad enlazada, el código lee los datos de la propia página. Así la migración puede hacerse de una en una.
Una sola copia que lee todo el mundo
La separación solo tiene sentido si el dato técnico deja de existir en la página. Si ambos registros conservan los mismos campos, se paga la complejidad de dos tipos sin obtener ninguna ventaja.
Todos los consumidores leen de un único punto. Un helper recibe la página, resuelve el puntero y devuelve el identificador de la fuente, o el de la propia página si no hay entidad. Lo usan los widgets que pintan tablas y los que muestran certificaciones. Lo usa también el generador de JSON-LDGlosarioJSON-LDFormato de datos estructurados basado en JSON que describe el contenido de una página con el vocabulario de Schema.org.
Se inserta en un bloque <script type="application/ld+json"> del HTML. Buscadores y asistentes de IA lo leen para identificar entidades como un producto, un artículo o una ruta de navegación sin interpretar el diseño de la página.Ver término completo →, y ahí está el error más común. Los datos visibles se corrigen y el marcado estructurado, que leía otra copia, sigue sirviendo el valor viejo a buscadores y agentes de IA.
El orden de aplicación importa. Primero se despliega el código que lee de la entidad. Después se hace una copia de seguridad, se escriben los datos en la entidad y se borran las copias de la página. Si se borran antes, el marcado estructurado queda vacío entre un paso y otro. Cada consumidor se comprueba al final contra la página publicada.
Queda un riesgo residual. Si el editor de la página sigue mostrando los campos técnicos, alguien volverá a rellenarlos. La defensa es ocultarlos cuando hay ficha enlazada y, mientras tanto, una regla escrita de que los datos solo se escriben en la entidad.
Compartir también compromete
Una entidad compartida es el punto donde un error se multiplica. Tres precauciones.
| Riesgo | Efecto | Precaución |
|---|---|---|
| Buscar un elemento por título y atributo | Un script encuentra el elemento de otra ficha y lo sobrescribe | Títulos únicos por entidad y búsqueda por identificador |
| Editar un elemento compartido | Cambia en todas las fichas que lo usan | Revisar a qué fichas afecta antes de guardar |
| Fusionar elementos casi iguales | Se pierde el matiz de cada uso | Un elemento propio cuando el matiz importa |
Antes de cualquier escritura masiva se hace una copia de contenido. Con entidades compartidas, una escritura equivocada se reparte por varias páginas a la vez.
Cuándo no separar
- ✕El dato es corto. Tres o cuatro atributos caben en la propia página sin riesgo de duplicado.
- ✕Nada se reutiliza. Si ningún otro elemento comparte los datos, el puntero solo añade un salto.
- ✕Una persona lo mantiene todo. La separación ayuda cuando varios consumidores o equipos leen el dato.
- ✕El volumen es mínimo. Con un puñado de registros, un campo estructurado dentro de la página basta.
- ✓Varios consumidores. Maquetación, marcado estructurado, resúmenes para IA y descargas leen el mismo dato.
- ✓Elementos compartidos. Radios, sondas o certificaciones aparecen en varias fichas.
- ✓Ciclos distintos. La página cambia por campañas y el dato cambia con la documentación técnica.
Del caso al principio
El patrón se aplicó a un catálogo de productos con fichas técnicas que antes vivían duplicadas en la página. El caso, con el modelo real, el error del marcado estructurado y la sobrescritura de un elemento compartido, está en product_device y product_spec en WordPress.
La síntesis es que el puntero resuelve la separación y la lectura única resuelve la duplicación. Una vez que todos los consumidores pasan por el mismo helper, mover o corregir un dato se hace en un sitio. Lo mismo vale para la fuente única que se trata en fuente única de verdad entre editor y código, y los identificadores de cada entidad pertenecen a su instalación, como explica el patrón de monorepo multi-marca. Sobre el marcado estructurado en sí hay un desarrollo en llms.txt y JSON-LD.