En este artículo
  1. El mito inicial: En WordPress casi todo es un Post
  2. Las 4 capas fundamentales para modelar tus datos
  3. Lo que SÍ y lo que NO al definir la arquitectura de datos
  4. Mantenibilidad y visión Senior

Pensar la arquitectura de datos de un sitio en WordPress antes de escribir una sola línea de código o instalar el primer plugin es la línea divisoria entre un desarrollo profesional y un desastre anunciado.

Cuando trabajás con frameworks modernos en el frontend, como React o Next.js, estás acostumbrado a pensar en componentes, props y flujos de datos estructurados. En WordPress, la flexibilidad del CMS suele ser una trampa para los perfiles junior o mid: como el sistema te permite meter casi cualquier cosa en cualquier lado, el impulso inicial suele ser resolver la maquetación a fuerza de editores visuales y campos sueltos.

El resultado de ese enfoque es un sitio donde los datos quedan “atrapados” dentro del HTML, la base de datos se degrada, las búsquedas se vuelven lentas y la mantenibilidad colapsa al primer cambio que pide el cliente.

Para construir proyectos escalables, limpios y con buen rendimiento, necesitás entender cómo piensa WordPress por dentro y aprender a modelar la información antes de construir.

El mito inicial: En WordPress casi todo es un Post

Para dominar la arquitectura de datos en WordPress, lo primero que tenés que entender es la estructura de su base de datos relacional. Por debajo, WordPress sostiene casi todo el sitio sobre una única tabla principal: wp_posts.

Un artículo de blog es un post. Una página estática es un post. Un producto de WooCommerce es un post. Un archivo adjunto multimedia (JPG, PDF) es un post. Y cualquier entidad personalizada que crees mediante código o plugins (un Custom Post Type) también va a parar a wp_posts.

Esto tiene una ventaja enorme: WordPress ya resolvió la lógica de almacenamiento, estados de publicación (borrador, publicado, privado), slugs para URLs, fechas y autorías. Pero también representa un peligro: si no entendés cómo clasificar y enriquecer esa tabla, terminás saturando la base de datos con consultas ineficientes.

Las 4 capas fundamentales para modelar tus datos

Cuando te enfrentás a un nuevo proyecto (un sitio inmobiliario, una plataforma de cursos, un directorio o un sitio corporativo), tenés que descomponer la información en cuatro estructuras nativas:

1. Entidades Principales: Custom Post Types (CPTs)

Son los objetos o “sustantivos” principales de tu negocio. Si el sitio fuera una base de datos relacional pura, los CPTs serían tus tablas principales.

  • Cuándo usarlos: Cuando el contenido tiene su propio ciclo de vida, necesita sus propias URLs (permalinks individuales), vistas de listado/archivo y una estructura clara.
  • Ejemplos: Propiedad, Curso, Evento, Receta, Vehículo.

2. Clasificación y Contexto: Taxonomías

Las taxonomías definen cómo se agrupan, relacionan y filtran los Custom Post Types.

  • Cuándo usarlas: Para relaciones de tipo “pertenece a” o “clasificado como”.
  • Regla de oro de arquitectura: Si un dato se va a usar para filtrar, buscar o agrupar contenidos en el sitio, siempre debe ser una Taxonomía, nunca un campo de texto plano (Post Meta). Buscar o filtrar por taxonomías aprovecha los índices optimizados de la tabla wp_terms; buscar por metadatos requiere recorrer millones de filas en wp_postmeta haciendo SQL JOINs pesados.
  • Ejemplos: Tipo de propiedad (Casa, Depto), Modalidad (Presencial, Online), Cultura culinaria (Italiana, Mexicana).

3. Atributos Específicos: Post Meta (Custom Fields / ACF)

Son los datos escalares o detalles puntuales que enriquecen a una entidad específica, pero que no necesitan agrupar a otros posts entre sí.

  • Cuándo usarlos: Para guardar atributos descriptivos o cuantitativos.
  • Ejemplos: Precio, Número de dormitorios, Metros cuadrados, Fecha límite de inscripción, Dossier PDF descargable.

4. Entidades Globales y Personas: Users y Options

  • wp_users: Reservado para personas, roles y permisos (autores, clientes, instructores). Si tu “Profesor” o “Agente inmobiliario” solo necesita mostrar un nombre y foto sin acceso al panel, podés evaluarlo como CPT o Taxonomía; pero si necesita credenciales y perfil, debe ser un usuario.
  • wp_options: Guarda la configuración global del sitio. Advertencia: No uses la tabla de opciones para almacenar contenido dinámico o listas crecientes; esta tabla se carga en la memoria del servidor (autoload) en cada petición y puede arruinar el TTFB (Time to First Byte) del servidor.

Lo que SÍ y lo que NO al definir la arquitectura de datos

Para evaluar si tu modelo de datos es técnicamente sólido, aplicá este filtro antes de maquetar:

Lo que SÍ debes hacer

  • Modelá en papel o Figma antes de tocar la base de datos: Diseñá el esquema E-R (Entidad-Relación) identificando qué es un CPT, qué es una taxonomía y qué es un metadato.
  • Separá el contenido de la presentación: El backend solo debe almacenar datos estructurados atómicos (números, strings limpios, IDs). La responsabilidad de cómo se ven esos datos en pantalla es del tema, del maquetador o del frontend desacoplado.
  • Aprovechá la preparación para headless/APIs: Si estructurás bien tus CPTs, taxonomías y campos meta desde el inicio, el sitio queda automáticamente listo para exponer sus datos mediante la REST API nativa de WordPress o GraphQL si en el futuro migrás el frontend a Astro, Next.js o React.

Lo que NO debes hacer

  • Guardar datos estructurados dentro del editor visual: Si escribís el precio de un departamento o la fecha de un evento dentro de un párrafo en el editor de bloques o Elementor, ese dato queda “sordo” para el sistema. No vas a poder hacer ordenamientos por menor/mayor precio, filtros por fecha ni exportación limpia de datos.
  • Abusar de la tabla wp_postmeta: Guardar cientos de campos personalizados en un único post puede generar cuellos de botella en proyectos grandes. Si tu CPT supera los 30-40 metadatos por entrada o maneja millones de registros, evaluá la creación de Custom Database Tables (tablas SQL personalizadas).
  • Crear CPTs para cosas que son atributos de usuario: Si querés mostrar los cursos que compró un alumno, no crees un post especial de “Relación Alumno-Curso” si podés resolverlo mediante metas de usuario o tablas de relación optimizadas.

Mantenibilidad y visión Senior

La diferencia entre un maquetador de páginas y un Email o Frontend Developer con mentalidad de arquitectura es el control sobre el ciclo de vida del software.

Cuando definís una arquitectura de datos sólida en WordPress:

  1. El cliente o el equipo de contenidos no rompe el diseño: Solo llena campos de texto, selectores y formularios estructurados en el panel de administración.
  2. El código del frontend permanece limpio: Solo se encarga de consultar los datos y renderizar componentes reutilizables.
  3. El sitio escala sin rehacerse desde cero: Agregar nuevas funcionalidades, cambiar el diseño completo o migrar a una arquitectura headless se vuelve una tarea trivial, porque la base de conocimiento de la empresa vive en datos estructurados e independientes de la capa visual.