Tipos de taxonomías en WordPress: guía práctica

Descubre los tipos de taxonomías WordPress, cómo funcionan, cuándo usar cada una y criterios para diseñar una arquitectura de contenidos sólida.

Qué es una taxonomía en WordPress y por qué importa tanto

Antes de entrar en los tipos de taxonomías WordPress, conviene aclarar qué es realmente una taxonomía. En términos simples, una taxonomía es un sistema de clasificación. WordPress la usa para agrupar contenido relacionado, de forma que tanto los visitantes como los motores de búsqueda puedan navegar y entender la estructura del sitio.

Sin una taxonomía bien pensada, un sitio con 200 o 2.000 entradas se convierte en un cajón desastre. La taxonomía como disciplina existe desde el siglo XVIII, cuando Linneo clasificó los seres vivos. WordPress adoptó el concepto para organizar publicaciones, páginas y cualquier tipo de contenido personalizado (custom post type).

Lo que muchos desconocen es que WordPress no se limita a categorías y etiquetas. El sistema taxonómico es extensible por diseño, lo que permite crear clasificaciones a medida para prácticamente cualquier necesidad. Entender cómo funcionan las diferentes taxonomías —y cuándo usar cada una— es la base para construir una arquitectura de contenidos que escale sin problemas.

Taxonomías nativas de WordPress: categorías y etiquetas

WordPress incluye dos taxonomías registradas por defecto para las entradas (posts): categorías (category) y etiquetas (post_tag). Aunque parecen similares, su naturaleza es distinta y eso tiene consecuencias directas en la navegación, la URL y el SEO.

Categorías: clasificación jerárquica

Las categorías son jerárquicas. Esto significa que una categoría puede tener subcategorías (categorías hijas), creando una estructura de árbol. Por ejemplo:

• Desarrollo Web
  • WordPress
  • Shopify
• Diseño
  • UX/UI
  • Branding

WordPress obliga a que cada entrada tenga al menos una categoría asignada. Si no la asignas manualmente, se usa la categoría por defecto (normalmente «Sin categoría»). Esto garantiza que todo contenido tenga un punto de anclaje dentro de la estructura del sitio.

Desde el punto de vista técnico, cada categoría genera su propio archivo (archive page) con una URL tipo /category/wordpress/. Eso hace que las categorías funcionen como secciones del sitio, algo que los buscadores indexan y posicionan.

Etiquetas: clasificación plana

Las etiquetas son no jerárquicas. No tienen padres ni hijas; son términos sueltos que agrupan entradas de forma transversal. Si las categorías son los capítulos de un libro, las etiquetas son las entradas del índice temático al final.

Una entrada sobre «Cómo optimizar imágenes en WordPress» podría tener la categoría «WordPress» y las etiquetas «rendimiento», «imágenes», «optimización». Las etiquetas permiten conexiones cruzadas entre categorías diferentes.

El problema habitual: muchos sitios crean cientos de etiquetas que solo se usan una vez. Eso genera páginas de archivo vacías o con una sola entrada, lo que diluye la autoridad del sitio y confunde a los rastreadores. La regla práctica es que una etiqueta debería agrupar al menos tres contenidos para justificar su existencia.

Taxonomías ocultas: formatos y tipos de enlace

WordPress registra internamente otras taxonomías que la mayoría de usuarios no ve en el panel de administración. Son lo que se conoce como taxonomías internas o privadas.

post_format

Los formatos de entrada (post formats) son una taxonomía registrada con register_taxonomy() igual que las categorías, pero marcada como interna. Permite clasificar entradas como «galería», «vídeo», «cita», «audio», etc. Pocos temas actuales los implementan, pero técnicamente siguen ahí en el núcleo de WordPress.

nav_menu

Los menús de navegación también usan una taxonomía interna. Cada menú que creas en «Apariencia > Menús» es un término dentro de la taxonomía nav_menu. WordPress lo gestiona de forma transparente, pero entender que un menú es técnicamente una taxonomía ayuda a comprender la flexibilidad del sistema.

link_category

Herencia de versiones antiguas de WordPress que incluían un gestor de enlaces. Está obsoleta pero sigue registrada en el código fuente. Es un ejemplo de cómo las taxonomías evolucionan con la plataforma.

Conocer estas taxonomías ocultas no es un ejercicio académico: cuando desarrollas plugins o temas personalizados, necesitas saber qué nombres de taxonomía están reservados para evitar conflictos.

Taxonomías personalizadas: el verdadero potencial

Aquí es donde los diferentes tipos de taxonomías en WordPress muestran todo su potencial. La función register_taxonomy() permite crear taxonomías completamente nuevas, asociadas a cualquier tipo de contenido.

Cuándo necesitas una taxonomía personalizada

La pregunta clave es: «¿Necesito filtrar o agrupar este contenido de una forma que las categorías y etiquetas no cubren?». Algunos ejemplos reales:

• Portfolio de proyectos: taxonomía «Tipo de proyecto» (web corporativa, e-commerce, landing page) y «Tecnología» (WordPress, React, Shopify).
• Directorio de recetas: taxonomías «Ingrediente principal», «Tipo de cocina», «Dificultad», «Tiempo de preparación».
• Catálogo de productos (sin WooCommerce): taxonomías «Material», «Color», «Temporada».
• Base de conocimiento: taxonomías «Nivel de dificultad», «Producto relacionado», «Departamento».

Cada una de estas taxonomías genera sus propias páginas de archivo, puede mostrarse como filtro en el front-end y es consultable vía WP_Query o la API REST.

Jerárquica vs. no jerárquica: criterios de decisión

Al registrar una taxonomía personalizada, el parámetro hierarchical determina su comportamiento:

• hierarchical = true: se comporta como las categorías. Interfaz de checkboxes en el editor, soporte para términos padre/hijo. Ideal cuando la clasificación tiene niveles lógicos (por ejemplo, «Ubicación» > «País» > «Ciudad»).
• hierarchical = false: se comporta como las etiquetas. Campo de texto libre con autocompletado. Ideal para clasificaciones planas y abiertas donde no hay niveles (por ejemplo, «Habilidad», «Ingrediente»).

El error más común es elegir jerárquica por defecto «porque parece más ordenada». Si los términos no tienen una relación padre-hijo real, una taxonomía plana es más eficiente y fácil de mantener. La decisión afecta directamente a la experiencia del editor que gestiona el contenido a diario.

Parámetros clave al registrar una taxonomía

Más allá de hierarchical, hay parámetros que muchos desarrolladores dejan en sus valores por defecto sin pensar en las consecuencias:

• public: ¿Debe ser visible en el front-end y generar archivos? Si es una taxonomía de uso interno (por ejemplo, para clasificar contenido en el admin sin que el visitante la vea), establece public = false.
• show_in_rest: Necesario si quieres que la taxonomía funcione con el editor de bloques (Gutenberg) y con la API REST de WordPress. Sin este parámetro activado, la taxonomía solo aparecerá en el editor clásico.
• rewrite: Controla la estructura de URL de los archivos. Puedes personalizar el slug, desactivar la paginación o modificar el comportamiento del permalink.
• show_admin_column: Añade una columna con los términos asignados en la tabla de listado del post type. Pequeño detalle que mejora enormemente la experiencia editorial.

Taxonomías en WooCommerce: un caso especial

WooCommerce registra varias taxonomías propias para gestionar los productos. Es uno de los mejores ejemplos de cómo las taxonomías personalizadas resuelven necesidades complejas en un contexto real.

• product_cat: Categorías de producto. Jerárquica. La estructura clásica del catálogo.
• product_tag: Etiquetas de producto. Plana.
• pa_* (product attributes): Cada atributo global (color, talla, material) se registra como una taxonomía independiente con el prefijo pa_. Esto permite filtrar productos por atributos en el front-end y, más importante aún, es la base del sistema de variaciones de producto.
• product_visibility: Taxonomía interna que controla si un producto es destacado, si está excluido de las búsquedas o del catálogo.
• product_shipping_class: Clases de envío, usadas para asignar tarifas diferentes según el tipo de producto.

Cuando se planifica una tienda online, el diseño de las taxonomías de producto es una de las decisiones con más impacto a largo plazo. Un catálogo con 5.000 productos y taxonomías mal estructuradas se vuelve inmanejable, tanto para el equipo editorial como para el cliente final que intenta encontrar lo que busca.

Criterios para diseñar taxonomías correctamente

Saber que existen distintos tipos de taxonomías en WordPress es solo el primer paso. El verdadero reto está en diseñar un sistema taxonómico coherente para un proyecto concreto. Estos son los criterios que marcan la diferencia entre una arquitectura sólida y un desastre de categorías.

1. Empieza por el contenido, no por la herramienta

Antes de tocar código o instalar un plugin, haz un inventario del contenido que va a existir. ¿Cuántos tipos de contenido habrá? ¿Cómo quiere el usuario final navegar por ellos? ¿Qué filtros tienen sentido? Las taxonomías deben responder a necesidades reales de navegación y búsqueda, no a la estructura mental del desarrollador.

2. Evita la redundancia entre taxonomías

Si una categoría ya clasifica el contenido por «tema» y luego creas una taxonomía personalizada «asunto» que hace lo mismo, estás creando confusión para los editores y contenido duplicado para los buscadores. Cada taxonomía debe aportar una dimensión de clasificación diferente.

3. Planifica la escalabilidad

Una taxonomía con 5 términos hoy puede tener 500 en dos años. ¿El sistema sigue funcionando? Las taxonomías jerárquicas con muchos niveles de profundidad (más de tres) se vuelven difíciles de gestionar. Las taxonomías planas con cientos de términos necesitan un buen autocompletado y búsqueda interna.

4. Piensa en el SEO desde el diseño

Cada taxonomía pública genera URLs indexables. Eso puede ser una ventaja (páginas de categoría bien posicionadas) o un problema (thin content si los archivos tienen pocas entradas). Define desde el principio qué taxonomías quieres que los buscadores indexen y cuáles no, usando meta robots o el plugin de SEO que utilices.

5. Documenta las reglas de uso

Si hay un equipo editorial, necesitas un documento que explique: qué taxonomías existen, para qué sirve cada una, cuántos términos se pueden asignar a una entrada, y quién puede crear términos nuevos. Sin estas reglas, las taxonomías degeneran en pocos meses.

Errores frecuentes al trabajar con taxonomías

Después de años trabajando con WordPress, estos son los problemas que veo repetirse en proyecto tras proyecto:

• Usar categorías como etiquetas: Crear una categoría para cada palabra clave en lugar de usar etiquetas o una taxonomía plana personalizada. El resultado es un árbol de categorías con 200 entradas donde ninguna tiene más de dos posts.
• No configurar show_in_rest: La taxonomía funciona en el editor clásico pero desaparece en Gutenberg. El editor se confunde, no asigna la taxonomía, y el contenido se publica sin clasificar.
• Slugs conflictivos: Registrar una taxonomía con un slug que ya usa un custom post type o una taxonomía nativa. WordPress no muestra error; simplemente rompe los permalinks de forma silenciosa.
• Olvidar las templates: Crear una taxonomía pública sin diseñar la template de archivo correspondiente. El visitante accede a /tipo-proyecto/ecommerce/ y ve una lista genérica sin diseño ni contexto.
• Taxonomías sin contenido asociado: Registrar taxonomías «por si acaso» que luego nadie usa. Cada taxonomía vacía es ruido en el admin y potencial contenido vacío en el front-end.

Taxonomías y custom post types: la relación clave

Las taxonomías no existen en el vacío. Siempre están asociadas a uno o varios tipos de contenido. WordPress por defecto asocia categorías y etiquetas al post type «post», pero al crear taxonomías personalizadas puedes asociarlas a cualquier post type, incluidos los personalizados.

La decisión de qué taxonomía se asocia a qué post type tiene implicaciones profundas:

• Una taxonomía compartida entre post types permite agrupar contenido de distinta naturaleza bajo el mismo término. Por ejemplo, una taxonomía «Industria» asociada tanto a «Casos de estudio» como a «Artículos de blog» crea conexiones transversales útiles para el usuario.
• Una taxonomía exclusiva de un post type mantiene la separación limpia. Los atributos de producto (pa_color) solo tienen sentido en el contexto de productos WooCommerce; asociarlos a las entradas del blog no tendría lógica.

La clave es que la relación entre post types y taxonomías refleje la lógica del negocio, no la comodidad técnica del momento.

Plugins vs. código para gestionar taxonomías

Existen dos caminos para crear taxonomías personalizadas: plugins de interfaz gráfica (como CPT UI, Pods o ACF) o código directo con register_taxonomy() en el archivo functions.php o en un plugin propio.

Plugins con interfaz gráfica:

• Ventaja: rapidez para prototipar, accesible para perfiles no técnicos.
• Desventaja: dependencia del plugin. Si se desactiva, las taxonomías desaparecen (los datos persisten en la base de datos, pero el registro de la taxonomía se pierde).

Código directo:

• Ventaja: control total, sin dependencias externas, más fácil de versionar con Git.
• Desventaja: requiere conocimientos de PHP y comprensión de la documentación oficial de WordPress para evitar errores.

Para proyectos profesionales y de largo plazo, el código directo suele ser la opción más robusta. Los plugins de interfaz gráfica son excelentes para explorar y validar ideas, pero en producción añaden una capa de dependencia que puede ser problemática.

Checklist: diseño de taxonomías para un proyecto WordPress

Antes de registrar una sola taxonomía, responde estas preguntas:

1. ¿Qué tipos de contenido va a tener el sitio? Enuméralos.
2. ¿Cómo va a navegar el usuario por ese contenido? Dibuja los flujos.
3. ¿Qué filtros necesita el front-end? Cada filtro suele corresponder a una taxonomía.
4. ¿Las categorías nativas cubren alguna de esas necesidades? No dupliques.
5. Para cada taxonomía nueva: ¿es jerárquica o plana? Justifícalo.
6. ¿Cuántos términos tendrá cada taxonomía a 12 meses vista? ¿Y a 36?
7. ¿Qué taxonomías deben ser públicas (indexables) y cuáles internas?
8. ¿Necesitas que funcionen con Gutenberg y la API REST? Activa show_in_rest.
9. ¿Hay un equipo editorial? Documenta las reglas de uso de cada taxonomía.
10. ¿Has verificado que los slugs no colisionan con post types o taxonomías existentes?

Este checklist evita el 90% de los problemas que surgen cuando un proyecto crece y las taxonomías iniciales se quedan cortas o generan conflictos.

Preguntas frecuentes sobre taxonomías en WordPress

¿Cuántas taxonomías personalizadas puedo crear?

No hay límite técnico impuesto por WordPress. Puedes crear tantas como necesites. El límite real es la usabilidad: demasiadas taxonomías confunden al editor y complican el mantenimiento. En la práctica, la mayoría de proyectos funcionan bien con entre 2 y 6 taxonomías por post type.

¿Las taxonomías afectan al rendimiento del sitio?

Por sí solas, no de forma significativa. WordPress almacena las taxonomías en la tabla wp_term_taxonomy y las relaciones en wp_term_relationships, que están indexadas. El problema de rendimiento aparece cuando haces consultas complejas que filtran por múltiples taxonomías simultáneamente en catálogos muy grandes (decenas de miles de entradas). En esos casos, la optimización de la base de datos y el caching son fundamentales.

¿Puedo convertir una categoría en taxonomía personalizada?

Técnicamente sí, pero implica migrar los términos y sus relaciones de una taxonomía a otra. Plugins como «Taxonomy Switcher» facilitan el proceso, aunque siempre conviene hacer un backup completo antes de cualquier migración de este tipo.

¿Qué diferencia hay entre una taxonomía y un campo personalizado?

Una taxonomía clasifica y agrupa contenido: genera archivos, permite filtrar y buscar. Un campo personalizado (meta) almacena datos específicos de una entrada individual: un precio, una fecha, una URL. Si necesitas agrupar contenido por un criterio, usa una taxonomía. Si necesitas almacenar un dato único de cada entrada, usa un campo personalizado.

¿Las taxonomías personalizadas se pierden al cambiar de tema?

Depende de dónde estén registradas. Si están en el functions.php del tema, sí se pierden al cambiar de tema. Si están en un plugin independiente (un mu-plugin o un plugin personalizado), persisten independientemente del tema activo. Por eso la recomendación general es registrar las taxonomías en un plugin, nunca en el tema.

Si estás planificando un proyecto WordPress que requiere una arquitectura de contenidos sólida —con taxonomías personalizadas, custom post types y una estructura pensada para escalar—, puedes ver cómo trabajo este tipo de proyectos en mi página de servicios.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →