¿Cuándo necesitamos custom post types en lugar de páginas y posts?

Cuando un tipo de contenido tiene sus propios atributos, su propio template o su propia audiencia. Reportes, eventos, cursos y casos de uso no se comportan en nada como una página, y forzarlos dentro de páginas significa que no vas a poder filtrarlos, cruzarlos ni darle al equipo editorial una pantalla consistente para completar. El error opuesto es igual de común: un post type creado para algo que siempre fue apenas una categoría. Si la única diferencia real es la etiqueta, lo que necesitás es una taxonomía.

¿Por qué definir los tipos de contenido en código en lugar de usar un plugin como CPT UI?

Porque una estructura que vive solo en la base de datos es una estructura que nadie puede revisar y nadie puede revertir. CPT UI y otras herramientas visuales similares sirven para prototipar, pero no están versionadas, así que son difíciles de mantener e imposibles de desplegar de forma predecible. Registrar los post types a mano da el máximo control a costa de mucho código repetitivo. Extended CPTs, nuestro estándar, ofrece una sintaxis clara más control de orden, etiquetas y visibilidad en el admin, todo en archivos versionados. Los campos siguen la misma lógica. Componemos los grupos de campos de ACF en código, así un cambio estructural llega como un pull request y no como un clic sin documentar en producción.

¿Necesitamos ACF Pro, y cuándo un campo personalizado es la respuesta equivocada?

ACF Pro es nuestro estándar para datos estructurados y editables por el cliente, compuesto en código con ACF Composer sobre un stack Sage o con ACF Builder en el resto de los casos. Meta Box es una alternativa creíble, con un ecosistema más chico. Un campo es la respuesta equivocada cuando lo que estás guardando es en realidad una clasificación. Si en algún momento fueras a querer listar todo lo que comparte ese valor, filtrar por él o darle un archivo, es una taxonomía. Los campos usados como pseudotaxonomías vuelven difícil de consultar el modelo más adelante.

¿Cómo manejan el filtrado y la búsqueda sobre miles de ítems?

FacetWP es la opción por defecto. Funciona de forma nativa con campos de ACF y taxonomías, corre sobre AJAX sin trabajo extra y cubre filtros, búsqueda, ordenamiento y paginación como un solo sistema. Para casos de alto volumen o poco habituales bajamos a WP_Query, la REST API o endpoints afinados para esa consulta puntual. Lo que los equipos subestiman: en una biblioteca grande, el filtrado y la paginación asincrónicos hay que diseñarlos desde el principio, porque agregarlos cuando los templates ya existen significa reescribirlos. Nuestra capacidad de búsqueda avanzada profundiza en esto.

¿Cuántos tipos de contenido son demasiados?

No hay un número, pero hay una prueba: cada tipo tiene que ganarse su propia pantalla de edición y su propio template. El modelo de Commvault incluye Use Cases y un Resource Center. El de Everest Group incluye Reports y Analysts, con más de 5.000 reportes y acceso por rol en una sola instancia de WordPress. Lo que sale mal es predecible: tipos de contenido creados sin un propósito claro, relaciones omitidas entre contenidos que las necesitan, navegación hardcodeada contra páginas en lugar de construida a partir de la estructura, e implementación arrancada antes de haber modelado el contenido.

¿Cómo sabemos que el modelo es correcto antes de que lo construyan?

Porque la etapa de definición produce algo que podés revisar: cada tipo de contenido, un mapa de sus atributos y relaciones, y las asignaciones de taxonomías, documentado de forma visual y no enterrado en un ticket. Después QA contrasta el modelo con la realidad. Los campos obligatorios y condicionales se comportan bien, la edición y la vista previa funcionan desde el admin, y los filtros cargan lo bastante rápido con tus volúmenes reales de datos. El inventario que alimenta todo esto sale de la fase de descubrimiento.

Arquitectura de contenido

Arquitectura de contenido WordPress Enterprise, modelada antes de construirla

Custom post types, taxonomías y campos editables definidos en código versionado, para que tu equipo editorial sepa dónde va cada contenido y tus desarrolladores no estén parchando la estructura dentro de dos años.

Inicio
Capacidades
Arquitectura de contenido

Qué modelamos

La estructura se decide en el descubrimiento y después se escribe en el repositorio

Cuando todo es una página o un post, el contenido se vuelve difícil de organizar, imposible de cruzar y propenso a la inconsistencia. Siete decisiones lo evitan.

Un inventario antes de una implementación

Se lista cada tipo de contenido, se mapean sus atributos, se dibujan sus relaciones y se asignan sus taxonomías a los tipos que las usan. Los campos que edita tu equipo quedan separados de los campos que calcula el sistema.

Tipos de contenido definidos en código versionado

Registramos post types y taxonomías con Extended CPTs en archivos versionados, nunca desde la interfaz de un plugin. La estructura viaja entre entornos junto con tus releases y es revisable como cualquier otro código.

Taxonomías que sostienen estructura real

Las taxonomías impulsan la navegación, el filtrado y el cruce entre tipos. Cuando una clasificación le sirve a tu equipo pero no significa nada para quien visita el sitio, la registramos como no pública, así la estructura interna nunca llega a tus URLs ni a tu sitemap.

Campos agrupados para quien los completa

ACF Pro es el estándar, compuesto en código con ACF Composer sobre un stack Sage y con ACF Builder en el resto de los casos. Los grupos se organizan por unidad lógica, con pestañas, repetidores y lógica condicional, y quedan documentados.

Quién puede editar qué, resuelto junto con el modelo

Los permisos son parte de la estructura, no de un ticket posterior. Cada tipo de contenido declara qué roles pueden crearlo y editarlo, y validamos esas capacidades, junto con la exportación y la importación, antes de que el modelo llegue a tu equipo editorial.

Relaciones modeladas, no improvisadas

Noticias con eventos, recursos con casos de uso, etiquetas compartidas en un catálogo de cursos: las conexiones se diseñan junto con los tipos. Usamos campos relacionales con moderación, y nunca un campo donde la respuesta correcta es una taxonomía.

Filtrado que aguanta el volumen

Para listar y filtrar miles de ítems implementamos FacetWP, nativo de ACF y de las taxonomías y con AJAX por defecto. Donde el rendimiento lo exige, WP_Query, la REST API o endpoints hechos a medida, con paginación asincrónica diseñada desde el inicio.

La capa de edición

La estructura es la mitad. El equipo editorial se encuentra con el modelo a través de los bloques.

Un modelo de contenido que tu equipo no puede operar es apenas un esquema. El 40Q Atomic Block System es la forma en que esa estructura se convierte en algo con lo que marketing puede publicar.

Una librería de bloques, no un page builder

Entre veinte y cuarenta bloques, aprobados de antemano y construidos alrededor de tus tipos de contenido, con Tailwind como framework de CSS. Los page builders le entregan todo al equipo editorial y devuelven inconsistencia y páginas lentas.

Design tokens compartidos entre Figma y el código

Los colores, las escalas tipográficas y los espaciados existen como tokens, y theme.json sigue al design system de Figma en lugar de alejarse de él. Los controles de espaciado y estilo se exponen con límites explícitos, así el equipo editorial tiene opciones reales dentro de un margen que no puede romper.

Patrones, documentación y capacitación

Los patrones y templates de página le dan a marketing un punto de partida en lugar de un lienzo en blanco. Cada bloque se prueba de forma aislada, se verifica su navegación por teclado y su comportamiento con lectores de pantalla, y se entrega con guías escritas y recorridos grabados.