WooCommerce override Elementor archive template: fix

Si armaste un template de archive en Elementor y al entrar a la tienda te aparece otra cosa, no estás loco. El problema del WooCommerce override Elementor archive template pasa porque la jerarquía de plantillas de WooCommerce tiene prioridad sobre el Theme Builder cuando el tema no declara soporte de la forma correcta. La solución pasa por registrar las locations de Elementor en tu child theme y ajustar bien las display conditions.

El conflicto entre WooCommerce y el Theme Builder de Elementor es un choque de jerarquías de plantillas: WooCommerce carga archive-product.php desde su propia carpeta de templates, mientras Elementor intenta inyectar su diseño a través de las locations declaradas por el tema. Si esa declaración falta, gana WooCommerce y tu template queda ignorado.

¿Por qué WooCommerce sobrescribe el template de archive de Elementor?

Ponele que creás un template tipo «Archive» en Elementor Pro, le ponés como condición «Productos / Todos los archivos», lo publicás contento, y al entrar a /tienda seguís viendo el layout viejo del tema. ¿Qué pasó? WooCommerce levantó archive-product.php antes de que Elementor pudiera meter mano. Más contexto en cómo lo explicamos en nuestra guía de Elementor.

WordPress carga las plantillas por orden de especificidad. WooCommerce se engancha en ese proceso con su propio set de templates y, salvo que el tema le diga explícitamente «che, dejá que acá manda Elementor», la plantilla del plugin gana. Esto está documentado en el issue #9874 del repositorio de Elementor, donde varios usuarios reportaron que el Theme Builder ignoraba los overrides para ciertos archives de producto.

El tema es que Elementor no reemplaza el sistema de templates de WordPress. Lo intercepta. Y para interceptar necesita que el tema declare sus «locations» (header, footer, single, archive). Si trabajás con un tema que no las registra, el archive de WooCommerce queda fuera del alcance de Elementor.

Diferencia entre override de template y taxonomía personalizada compartida

Son dos cosas distintas que la gente mezcla todo el tiempo.

• Override de template: es cuando querés cambiar el diseño de una página (el archive de la tienda, por ejemplo) y otro sistema te lo pisa. Es un problema de quién renderiza el HTML.
• Taxonomía compartida: es cuando querés que una misma taxonomía (ponele «marca» o «tema») agrupe tanto productos de WooCommerce como entradas del blog. Es un problema de cómo registrás y relacionás los datos.

El override lo resolvés en la capa de templates. La taxonomía compartida la resolvés en la capa de registro de datos (register_taxonomy). Una no depende de la otra, aunque suelen aparecer juntas cuando armás un sitio que es blog y tienda al mismo tiempo.

Jerarquía de templates: WordPress, WooCommerce y Elementor Theme Builder

Para entender el conflicto, conviene ver el flujo real de carga. WordPress busca la plantilla más específica disponible; WooCommerce inyecta las suyas para sus post types; Elementor las reemplaza si tiene la location registrada. Sobre eso hablamos en nuestra guía sobre cómo monetizar temas de Elementor.

Capa	Qué template usa	Prioridad
WordPress core	archive.php / index.php	Base (la más baja)
WooCommerce	archive-product.php, taxonomy-product_cat.php	Pisa al core para sus post types
Tema (child theme)	Override en /woocommerce/	Pisa al plugin
Elementor Theme Builder	Template «Archive» con display conditions	Solo si la location está registrada

Lo interesante es que Elementor no está al tope por defecto. Necesita el permiso del tema. Por eso Hello Elementor, el tema oficial, ya trae todo declarado y casi nunca da este dolor de cabeza. Si usás un tema pesado de terceros, ahí empiezan los líos.

¿Cómo crear un archive personalizado sin que WooCommerce lo sobrescriba?

Acá viene lo bueno. Tenés tres caminos, de menos a más invasivo.

• Usar Hello Elementor (o un tema compatible): el camino más limpio. El tema ya registra las locations y declara el soporte de WooCommerce, así que tu template de archive simplemente funciona.
• Declarar el soporte en tu child theme: si tenés un tema propio, agregá el soporte a WooCommerce y registrá las locations de Elementor en el hook elementor/theme/register_locations. La guía oficial de cómo agregar soporte WooCommerce muestra exactamente qué declarar.
• Configurar bien las display conditions: a veces el template existe pero la condición es demasiado genérica o demasiado específica. Revisá que apunte a «Products Archive» y no quede tapado por otro template con condición más fuerte.

La idea central: en tu functions.php del child theme, registrás la location de archive de Elementor para que el plugin se la «robe» a WooCommerce. Sin esa declaración, no hay forma. Y ojo, esto es código que toca el render del sitio entero, así que probalo primero en un entorno local antes de subirlo. Si después querés pasar el sitio a producción, un hosting WordPress como el de Donweb te lo levanta sin que tengas que pelear con configuraciones de servidor.

¿Puedo usar la misma taxonomía en productos y posts con Elementor?

Sí, se puede. Y es más simple de lo que parece, aunque requiere configuración.

Cuando registrás la taxonomía con register_taxonomy(), en el primer argumento pasás el nombre y en el tercero le indicás un array con los dos post types: ['product', 'post']. Con eso, una sola taxonomía agrupa entradas del blog y productos de la tienda. WooCommerce documenta sus taxonomías y post types instalados, así que conviene mirar ahí para no pisar slugs existentes como product_cat.

El detalle que casi todos olvidan: tenés que poner 'show_in_rest' => true. Sin eso, Elementor y el editor de bloques no ven la taxonomía, y te quedás sin poder usarla en las display conditions del Theme Builder. Si preferís no tocar código, Custom Post Type UI o Advanced Custom Fields te dejan registrar la taxonomía compartida desde el panel, con la opción de REST incluida.

Errores comunes al configurar taxonomías compartidas en WooCommerce

• Olvidar show_in_rest: la taxonomía queda invisible para Gutenberg y Elementor. Corrección: agregá 'show_in_rest' => true al registrar.
• Conflicto de slugs: usar un slug que ya ocupa WooCommerce (como product_cat) rompe el filtrado. Corrección: elegí un slug propio y único.
• No incluir los dos post types: registrás la taxonomía solo para product y después no aparece en las entradas. Corrección: pasá el array completo en register_taxonomy().
• Display condition mal armada: el template de Elementor existe pero la condición apunta a la taxonomía equivocada. Corrección: revisá que la condición coincida exacto con el slug registrado.

Soluciones según tu versión de Elementor y WooCommerce

No todas las versiones se comportan igual. El builder de archives de producto necesita un piso de versiones para funcionar. En sobre cómo Elementor impacta tu SEO profundizamos sobre esto.

Combinación	Soporte de archive WooCommerce	Recomendación
Elementor Pro < 2.1	No	Actualizá: el Theme Builder no maneja archives de producto
Elementor Pro 2.1+ con WooCommerce 3.4+	Sí	Combinación mínima estable
Elementor Pro reciente con WooCommerce HPOS activo	Sí	Verificá compatibilidad de plugins de terceros con HPOS

Si estás abajo del mínimo, actualizá antes de tocar cualquier otra cosa. Muchos de los reportes del issue #9874 venían de instalaciones desactualizadas donde el widget de archive ni existía.

Preguntas Frecuentes

¿Por qué WooCommerce ignora mi template de archive en Elementor?

Porque WooCommerce carga su propia plantilla archive-product.php con más prioridad que el Theme Builder cuando el tema no registra las locations de Elementor. La solución es usar un tema compatible como Hello Elementor o declarar el soporte en tu child theme.

¿Cómo compartir una taxonomía personalizada entre productos y posts?

Registrás la taxonomía con register_taxonomy() pasando los dos post types en un array: ['product', 'post']. Sumá 'show_in_rest' => true para que el editor y Elementor la reconozcan. Para más detalles técnicos, mirá alternativas como Bricks que podrías considerar.

¿Cuál es la jerarquía de templates entre WooCommerce y Elementor?

WordPress carga el template más específico, WooCommerce pisa al core para sus post types, y Elementor reemplaza esas plantillas solo si el tema registra sus locations. Sin esa declaración, gana siempre WooCommerce.

¿Qué versión mínima necesito para editar archives de WooCommerce con Elementor?

Elementor Pro 2.1 o superior junto con WooCommerce 3.4 o superior. Por debajo de esas versiones, el Theme Builder no incluye el soporte para archives de producto.

¿Necesito Elementor Pro para esto o alcanza la versión gratuita?

Necesitás Elementor Pro. El Theme Builder, que es donde se crean los templates de archive con display conditions, es una función exclusiva de la versión paga. La gratuita no edita plantillas de WooCommerce.

Conclusión

El choque entre WooCommerce y Elementor no es un bug raro: es una cuestión de jerarquías de templates mal alineadas. Si tu archive de tienda no respeta el diseño de Elementor, lo más probable es que tu tema no esté declarando las locations o que estés abajo del mínimo de versiones (Elementor Pro 2.1 con WooCommerce 3.4).

Empezá por lo simple: confirmá versiones, probá con Hello Elementor en un entorno de prueba, y recién después metete con el código del child theme. Para la taxonomía compartida, acordate del show_in_rest, que es el olvido que más tiempo hace perder. Con eso resuelto, tenés blog y tienda usando la misma estructura sin pelearte con el render.

Fuentes

• Elementor – Cómo crear un template de archive de WooCommerce
• GitHub – Issue #9874 del repositorio de Elementor
• Elementor Developers – Agregar soporte WooCommerce al tema
• WooCommerce – Taxonomías y post types instalados