Campos personalizados en WooCommerce: guía práctica

Aprende a usar campos personalizados en WooCommerce para adaptar productos, pedidos y checkout a necesidades reales de tu tienda online.

Qué son los campos personalizados en WooCommerce y por qué importan

Los campos personalizados en WooCommerce son metadatos adicionales que permiten almacenar información que no existe de forma nativa en la plataforma. WordPress los llama «custom fields» o «post meta», y WooCommerce extiende este concepto a productos, pedidos, usuarios y páginas de checkout. Si alguna vez has necesitado que un producto muestre un campo de texto donde el cliente escriba una dedicatoria, o que un pedido almacene un número de identificación fiscal, estás hablando exactamente de esto.

La tienda estándar de WooCommerce cubre escenarios genéricos: título, precio, descripción, imágenes, variaciones. Pero la realidad de un negocio casi nunca es genérica. Las tiendas que venden productos personalizables —camisetas con texto, regalos grabados, kits configurables— necesitan capturar datos específicos del cliente en el momento de la compra. Las tiendas B2B necesitan campos como CIF, razón social o número de pedido interno. Y las tiendas con logística compleja a menudo requieren campos extra en el checkout para instrucciones de entrega o selección de franja horaria.

Según datos del repositorio de WordPress, WooCommerce impulsa aproximadamente el 36-39% de todas las tiendas online del mundo. De esas tiendas, una proporción significativa necesita algún tipo de personalización más allá de lo que ofrece la instalación base. Los campos personalizados son la herramienta fundamental para cubrir esa brecha sin reescribir el core de la plataforma.

Tipos de campos personalizados que puedes implementar

No todos los campos personalizados cumplen la misma función. Antes de implementar nada, conviene entender las categorías principales y dónde encaja cada una dentro del flujo de tu tienda.

Campos personalizados en productos

Son los más comunes. Permiten añadir información adicional a la ficha de producto que el administrador introduce desde el backend. Ejemplos típicos:

• Datos técnicos específicos: peso exacto por componente, certificaciones, país de fabricación, fecha de caducidad.
• Información logística interna: código de almacén, ubicación en estantería, proveedor asociado.
• Datos para integraciones: ID externo en un ERP, referencia de proveedor, código de barras alternativo.

WordPress almacena estos campos en la tabla wp_postmeta asociados al ID del producto. Puedes crearlos de forma nativa desde la pantalla de edición del producto (sección «Campos personalizados»), aunque la interfaz nativa es bastante básica.

Campos personalizados en el checkout

Aquí es donde la cosa se pone interesante para la experiencia del cliente. Los campos de checkout permiten recoger información del comprador durante el proceso de pago. WooCommerce incluye campos estándar (nombre, dirección, teléfono), pero muchas tiendas necesitan más:

• NIF/CIF para facturación B2B.
• Instrucciones especiales de entrega.
• Selección de franja horaria de envío.
• Casillas de verificación para condiciones específicas (edad legal, aceptación de términos especiales).

Estos campos se implementan mediante hooks de WooCommerce —concretamente woocommerce_checkout_fields— y requieren código personalizado o un plugin dedicado.

Campos personalizados en pedidos

WooCommerce 8.x introdujo las «Custom Order Tables» (HPOS), cambiando cómo se almacenan los metadatos de pedidos. Los campos personalizados en pedidos son útiles para:

• Registrar datos de seguimiento de envío.
• Almacenar notas internas de procesamiento.
• Guardar información recibida de pasarelas de pago o servicios externos.

Con HPOS activado, estos datos se guardan en la tabla wp_wc_orders_meta en lugar de wp_postmeta, lo cual es un detalle técnico importante si estás escribiendo código personalizado o evaluando la compatibilidad de plugins.

Campos de entrada en el frontend del producto

Diferencia clave: un campo personalizado de producto es información que el administrador introduce en el backend. Un campo de entrada en el frontend es lo que el cliente rellena antes de añadir al carrito. Ejemplos:

• Texto para grabado o estampado.
• Subida de archivos (logos, fotos para personalización).
• Selectores de color, material o tamaño que van más allá de las variaciones estándar.
• Campos de fecha (para productos como tartas de cumpleaños con fecha de entrega específica).

Estos campos son los más complejos de implementar correctamente porque afectan al carrito, al checkout y a los emails de confirmación.

Métodos de implementación: código vs plugins

La implementación de campos personalizados en WooCommerce se divide en dos grandes enfoques, cada uno con ventajas y limitaciones claras.

Implementación mediante código

WooCommerce ofrece una API de hooks y filtros extensa para añadir campos. El enfoque básico para un campo de checkout personalizado implica tres pasos:

1. Añadir el campo al formulario usando woocommerce_checkout_fields o woocommerce_after_order_notes.
2. Validar el campo con woocommerce_checkout_process para asegurarte de que el dato es correcto antes de procesar el pedido.
3. Guardar el campo con woocommerce_checkout_update_order_meta para que el valor se almacene en el pedido.

Un ejemplo simplificado para añadir un campo de NIF al checkout:

add_filter('woocommerce_checkout_fields', function($fields) {
    $fields['billing']['billing_nif'] = array(
        'label'       => 'NIF/CIF',
        'placeholder' => 'Introduce tu NIF o CIF',
        'required'    => true,
        'class'       => array('form-row-wide'),
        'priority'    => 25,
    );
    return $fields;
});

La ventaja del código personalizado es el control total: decides exactamente dónde aparece el campo, cómo se valida, cómo se muestra en emails y en el admin. La desventaja es que requiere un desarrollador con experiencia en el ecosistema WordPress y, sobre todo, requiere mantenimiento cuando WooCommerce actualiza su estructura.

Implementación mediante plugins

Existen decenas de plugins para gestionar campos adicionales. Los más utilizados pertenecen a dos categorías:

Plugins de campos de checkout: como Checkout Field Editor (de diversas marcas) o Flexible Checkout Fields. Permiten añadir, eliminar y reordenar campos del checkout desde una interfaz visual.

Plugins de campos de producto: como Advanced Custom Fields (ACF) combinado con integraciones para WooCommerce, o soluciones específicas como WooCommerce Product Add-Ons. Estos permiten crear campos que el cliente rellena en la ficha de producto.

La ventaja de los plugins es la velocidad de implementación y la interfaz visual para usuarios no técnicos. La desventaja principal es la dependencia: si el plugin deja de actualizarse, cambia de modelo de negocio o genera conflictos con una actualización de WooCommerce, tienes un problema serio en producción.

Cuándo elegir cada enfoque

No hay respuesta universal. Pero como criterio práctico:

• 1-3 campos simples (texto, select, checkbox) en checkout → código personalizado. Es más limpio, no añade dependencias y el mantenimiento es mínimo.
• Campos complejos en producto con lógica condicional (si el cliente elige «grabado», aparece un campo de texto; si elige «estampado», aparece un selector de posición) → un plugin especializado probablemente ahorre semanas de desarrollo.
• Muchos campos con reglas de visibilidad → ACF + una capa de integración personalizada. ACF es estable, está ampliamente mantenido y su API es sólida.

Errores frecuentes al trabajar con campos personalizados

Después de más de cien proyectos WooCommerce, hay patrones de error que se repiten con frecuencia inquietante. Conocerlos antes de implementar te ahorrará horas de depuración.

No guardar los datos en el pedido

El error más común. Alguien añade un campo al checkout, funciona visualmente, el cliente lo rellena… pero nadie programó el hook para guardar el valor en el pedido. El dato desaparece después del pago. La validación y el guardado son pasos separados en WooCommerce, y omitir cualquiera de los dos rompe el flujo.

No mostrar los campos en emails y en el admin

Que el dato se guarde no significa que sea visible. Si no añades la lógica para mostrar el campo personalizado en los emails de confirmación (woocommerce_email_order_meta) y en la pantalla de detalle del pedido en el admin, el dato existirá en la base de datos pero nadie lo verá donde importa.

Ignorar la compatibilidad con HPOS

Desde WooCommerce 8.x, las High-Performance Order Storage (HPOS) son la forma recomendada de almacenar pedidos. Si tu código sigue usando directamente update_post_meta() para datos de pedidos en lugar de $order->update_meta_data(), funcionará en modo compatibilidad pero fallará cuando HPOS sea obligatorio. Muchos plugins antiguos tienen este problema.

Añadir demasiados campos al checkout

Cada campo adicional en el checkout reduce la tasa de conversión. Según datos de Baymard Institute, el formulario de checkout promedio tiene 12 campos, pero el número óptimo está entre 6 y 8. Antes de añadir un campo, pregúntate: ¿necesito este dato antes de cobrar, o puedo pedirlo después? Los campos que no son imprescindibles para procesar el pago deberían ir en la cuenta del cliente o en un formulario post-compra.

No sanitizar ni validar correctamente

Un campo de texto abierto sin validación es una invitación a problemas. Mínimo deberías usar sanitize_text_field() para campos de texto y absint() para números. Para campos de email, sanitize_email(). Para HTML, wp_kses() con una lista blanca de etiquetas permitidas. La falta de sanitización no solo es un riesgo de seguridad (inyección XSS), sino que puede corromper datos de pedidos que luego son imposibles de exportar limpiamente.

Campos personalizados y rendimiento: qué tener en cuenta

Los campos personalizados en WooCommerce se almacenan como filas individuales en tablas de metadatos. Cada campo es una fila en wp_postmeta (o en wp_wc_orders_meta con HPOS). Esto tiene implicaciones de rendimiento que muchos desarrolladores ignoran hasta que la tienda tiene miles de productos o pedidos.

Un producto con 15 campos personalizados genera 15 filas adicionales en wp_postmeta. Multiplica eso por 5.000 productos y tienes 75.000 filas extra solo de campos personalizados. La tabla wp_postmeta es, de por sí, una de las más consultadas de WordPress, y su estructura clave-valor no está optimizada para búsquedas complejas.

Buenas prácticas para mantener el rendimiento

• Prefija las claves de tus metadatos con un identificador único (ej: _mitienda_nif). Esto facilita consultas y evita colisiones con otros plugins.
• No uses campos personalizados para datos que necesites filtrar frecuentemente. Si necesitas buscar pedidos por NIF constantemente, considera una tabla personalizada con índices apropiados.
• Limpia campos huérfanos periódicamente. Al eliminar productos, los metadatos asociados a menudo quedan en la base de datos.
• Usa wp_cache_get y wp_cache_set cuando hagas consultas repetitivas sobre los mismos campos en un mismo request.

Cómo estructurar campos personalizados para tiendas complejas

Las tiendas que más provecho sacan de los campos personalizados son las que planifican su estructura antes de escribir una línea de código. Aquí va un framework de decisión que uso habitualmente.

Paso 1: Mapear los datos por entidad

Crea una tabla con cuatro columnas: Producto, Pedido, Cliente, Checkout. Para cada dato que necesitas capturar, decide a qué entidad pertenece. Un error frecuente es guardar datos del cliente en el pedido o datos del producto en el checkout. Cada entidad tiene su lugar.

Paso 2: Definir si el dato es interno o público

Los campos que empiezan con guion bajo (_) en WordPress se consideran «protegidos» y no aparecen en la interfaz nativa de campos personalizados. Úsalos para datos internos que solo tu código necesita. Los campos sin guion bajo son visibles en el editor estándar.

Paso 3: Decidir el tipo de campo y su validación

Para cada campo, define el tipo (text, textarea, select, checkbox, radio, file, date, number), si es obligatorio, su valor por defecto y las reglas de validación. Documéntalo antes de implementar. Este documento se convierte en la especificación técnica que cualquier desarrollador puede seguir.

Paso 4: Planificar la visibilidad

¿Dónde necesita verse cada campo? Las opciones típicas son:

• En el admin de WooCommerce (pantalla de detalle del pedido/producto).
• En los emails transaccionales (confirmación de pedido, pedido completado).
• En la cuenta del cliente (sección «Mis pedidos»).
• En exports CSV o integraciones con ERP/CRM.

Cada punto de visibilidad requiere código específico. Olvidar uno de ellos es la fuente número uno de quejas tipo «el campo funciona pero no lo veo en el email».

Campos personalizados y el editor de bloques de WooCommerce

Con la evolución hacia el editor de bloques (Gutenberg) en WooCommerce, la forma de mostrar campos personalizados en el frontend está cambiando. WooCommerce está migrando progresivamente las páginas de producto y checkout hacia bloques, y esto afecta directamente a cómo se renderizan los campos adicionales.

Si tu tienda utiliza el checkout basado en bloques (que WooCommerce promueve como predeterminado desde la versión 8.3), los hooks clásicos como woocommerce_checkout_fields no funcionan directamente. En su lugar, necesitas usar la API de extensibilidad del checkout por bloques, que utiliza JavaScript (React) en lugar de PHP para renderizar campos en el frontend.

Esto representa un cambio significativo para desarrolladores acostumbrados al enfoque PHP clásico. La documentación oficial de WooCommerce proporciona guías para registrar campos adicionales en el checkout por bloques mediante __experimentalRegisterCheckoutFilters y la Store API, pero el ecosistema todavía está madurando.

Como criterio práctico: si tu tienda es nueva y empieza con el checkout de bloques, aprende la nueva API desde el principio. Si tienes una tienda existente con campos personalizados funcionando en el checkout clásico, no migres al checkout de bloques hasta que tus campos estén portados y testados. La migración a medias es la receta perfecta para perder datos de clientes.

Checklist antes de implementar campos personalizados

Antes de tocar código o instalar un plugin, repasa esta lista:

1. ¿El dato es realmente necesario antes del pago? Si no lo es, pídelo después.
2. ¿Existe ya un campo nativo que cubra la necesidad? WooCommerce tiene campos ocultos o poco conocidos (como el campo de notas del pedido) que a veces bastan.
3. ¿Has definido el tipo de campo, validación y dónde se mostrará?
4. ¿Tu implementación es compatible con HPOS? Usa la API de objetos de WooCommerce, no funciones directas de wp_postmeta para pedidos.
5. ¿Has probado el campo en el checkout de bloques Y en el checkout clásico? Dependiendo de tu configuración, podrías necesitar soporte para ambos.
6. ¿El campo aparece en emails transaccionales? Pruébalo enviando un pedido de prueba real.
7. ¿El campo se exporta correctamente? Si usas herramientas de exportación de pedidos (CSV, integración con ERP), verifica que el campo se incluye.
8. ¿Has sanitizado la entrada? Nunca confíes en datos que introduce el usuario.

Preguntas frecuentes sobre campos personalizados en WooCommerce

¿Puedo añadir campos personalizados sin programar?

Sí, existen plugins que permiten crear campos tanto en productos como en el checkout mediante interfaz visual. Sin embargo, para lógica condicional avanzada o integraciones con sistemas externos, casi siempre se necesita algo de código personalizado.

¿Los campos personalizados afectan al SEO de mi tienda?

Por sí mismos, no. Los metadatos almacenados en la base de datos no son visibles para buscadores a menos que los muestres explícitamente en el HTML del frontend. Si los muestras (por ejemplo, datos técnicos en la ficha de producto), pueden enriquecer el contenido y mejorar la relevancia de la página.

¿Qué pasa con los campos personalizados cuando actualizo WooCommerce?

Los datos almacenados en la base de datos no se pierden con las actualizaciones. Lo que puede romperse es la lógica de visualización o guardado si el código depende de hooks que WooCommerce modifique. Por eso es fundamental usar la API oficial y no «hacks» directos.

¿ACF funciona bien con WooCommerce?

ACF es compatible con WooCommerce para campos en productos (backend). Para campos en checkout o campos que el cliente rellena en el frontend, necesitas extensiones adicionales o código personalizado. ACF es una herramienta de backend; la capa de frontend requiere trabajo adicional.

¿Cuántos campos personalizados puedo añadir sin afectar al rendimiento?

No hay un número mágico, pero como referencia: hasta 10-15 campos por producto no suele causar problemas perceptibles en tiendas con menos de 10.000 productos. Por encima de eso, o si necesitas filtrar por esos campos, considera optimizaciones como tablas personalizadas o caching de consultas.

Si necesitas implementar campos personalizados complejos o tienes un proyecto WooCommerce que requiere personalización técnica avanzada, puedes revisar los servicios de desarrollo WordPress y WooCommerce que ofrezco para agencias y empresas.

// 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 →