Filtros y facetas en PrestaShop: controlar URLs sin romper el catálogo

Respuesta breve

Controlar los filtros de una tienda PrestaShop consiste en decidir qué combinaciones merecen existir como URL y hacer que el resto no se genere ni se enlace, en lugar de dejar que se generen todas y tratar de contenerlas después con canonical o robots. El procedimiento es inventariar el espacio real de URLs que produce la navegación por facetas, clasificar cada tipo de combinación, aprobar solo las que tienen intención propia e inventario estable, y comprobar en la superficie pública —con la caché purgada— que la regla se aplica de verdad. Ningún control resuelve por sí solo un espacio combinatorio: la solución empieza por limitar la generación y el enlazado.

Puntos clave

• El problema no es de indexación sino de generación: cada filtro adicional multiplica las URLs disponibles.
• Canonical, meta robots, robots.txt y enlaces controlan cosas distintas y ninguno sustituye a los demás.
• Solo las combinaciones con intención propia y stock estable son candidatas a landing indexable, y aun así necesitan mantenimiento.
• Las ordenaciones y los parámetros técnicos no son facetas: no deben producir URLs indexables.
• Sin número de versión y lista de módulos, afirmar «cómo se comporta PrestaShop» no sirve de nada.
• Una configuración guardada no es una configuración aplicada: se lee en la superficie pública tras purgar.
• Se muestrea sobre combinaciones representativas antes de generalizar una regla al catálogo entero.

Decidir qué combinaciones existen

1. Inventario del espacioCuántas combinaciones genera hoy el catálogo.
2. ClasificarOrdenaciones y parámetros técnicos no son facetas.
3. Aprobar landingsSolo con intención propia y stock estable.
4. Elegir controlesCanonical, robots, noindex y enlaces: cada uno lo suyo.
5. Versión y módulosAnotados; sin ellos nada es repetible.
6. MuestrearCombinaciones representativas antes de generalizar.

El espacio combinatorio

Conviene entender el mecanismo antes de elegir remedios. Una categoría con cinco filtros de tres valores cada uno no produce quince URLs: produce todas las combinaciones posibles de valores seleccionados, y a eso se le multiplican las ordenaciones y las páginas de paginación. El crecimiento es combinatorio, no aditivo, y por eso una tienda mediana puede exponer un número de direcciones muy superior al de sus productos. A ese volumen se le aplica lo que explica el artículo sobre el presupuesto de rastreo en webs grandes.

Eso tiene dos consecuencias. La primera es que el remedio no puede ser marcar cada URL una por una: hay que reducir cuántas se generan y cuántas se enlazan. La segunda es que la mayoría de esas direcciones no tienen demanda, tienen poco o ningún producto y cambian según el inventario, de modo que ni siquiera son buenas candidatas a existir. El marco general lo da el artículo sobre decidir entre categorías, productos y facetas.

Inventario del espacio

Selecciona categorías representativas y combina un filtro, dos filtros, orden, paginación y resultados vacíos. Registra patrón, status, canonical, robots, enlace, contenido e inventario. Repite con y sin JavaScript.

La repetición con y sin JavaScript no es un detalle: en muchas implementaciones los enlaces de faceta se construyen en el cliente, de modo que lo que un rastreador encuentra puede ser mucho menos —o mucho más— de lo que ve una persona. Comprobar ambos estados es lo único que revela si el enlazado que se cree tener es el que existe.

Anota también cómo se codifica la selección, porque de ahí salen los duplicados menos visibles. Si el orden de los valores en la URL no está normalizado, dos rutas con la misma selección producen dos direcciones distintas con el mismo contenido; lo mismo ocurre con mayúsculas, acentos codificados de dos maneras o separadores intercambiables. Ese tipo de duplicado no se ve en el panel y sí en el inventario.

Clasificar facetas

• combinaciones con intención y stock estable;
• filtros útiles solo para experiencia;
• ordenaciones;
• parámetros técnicos;
• combinaciones vacías;
• estados que producen duplicados.

Solo el primer grupo es candidato a landing indexable, y aun así necesita contenido, enlaces y mantenimiento. La arquitectura eCommerce ofrece el marco neutral.

Tipos de faceta: si se genera, si se enlaza y si es indexable.

Tipo	Se genera	Se enlaza	Indexable
combinación aprobada	sí	sí, desde la categoría	sí, con contenido propio
filtro de experiencia	sí	solo en la interfaz	no
ordenación	sí	solo en la interfaz	no
parámetro técnico	sí	no	no
combinación vacía	evitar generarla	no	no

Cuándo aprobar una faceta como landing

Promover una combinación a página indexable es una decisión editorial con coste de mantenimiento, no un ajuste técnico. Los criterios que conviene exigir a la vez son cuatro: que exista demanda expresada con esas palabras y no solo una hipótesis; que el inventario sostenga la página de forma estable, sin quedarse vacía cada temporada; que se pueda escribir algo propio que la categoría general no diga; y que haya un sitio natural desde donde enlazarla.

Si falta cualquiera de los cuatro, la combinación se queda como filtro de experiencia. La señal de que se aprobaron demasiadas es fácil de reconocer meses después: páginas con dos productos, textos idénticos salvo una palabra y nadie que recuerde por qué existen. El caso de las páginas que se vacían tiene además su propio tratamiento, desarrollado en el artículo sobre productos agotados o descatalogados.

Elegir controles

Canonical expresa preferencia; meta robots controla indexación; robots afecta rastreo; los enlaces determinan descubrimiento. Ninguno resuelve por sí solo un espacio infinito. La solución puede requerir limitar la generación, cambiar enlaces y mantener una allowlist de combinaciones aprobadas.

El error de combinación más común es bloquear en robots.txt unas URLs que llevan noindex: al impedir el rastreo, la directiva deja de leerse y las direcciones pueden permanecer en el índice sin descripción. Si se quiere sacar del índice un conjunto ya indexado, primero se permite rastrear con noindex y solo cuando ha surtido efecto se plantea el bloqueo.

El control más eficaz y el que menos se usa es el enlazado. Una combinación que no se enlaza desde ninguna parte apenas se descubre, con independencia de que técnicamente responda. Convertir los controles de filtro en elementos que no generan enlaces rastreables —manteniendo la funcionalidad y el acceso por teclado— reduce el espacio descubierto mucho más que cualquier etiqueta añadida a posteriori.

El control más eficaz y el que menos se usa es el enlazado.

Riesgo de versión y módulos

No atribuyas un comportamiento a “PrestaShop” sin versión. Un módulo puede reemplazar URLs o canonicals; un override puede conservar lógica antigua. Inventaría componentes, revisa changelog y prueba upgrade.

La navegación por facetas la implementa un módulo, y el módulo decide cómo se construyen las URLs, qué canonical emite y qué ocurre con las combinaciones sin resultados. Dos tiendas con la misma versión del núcleo pueden comportarse de forma distinta por eso. Antes de escribir cualquier regla conviene anotar versión del núcleo, versión del módulo de facetas, tema y overrides activos.

Los overrides merecen atención especial porque sobreviven a las actualizaciones y aplican lógica que ya no coincide con la del módulo. Un canonical que se genera en un override antiguo puede ignorar la configuración del panel sin que nada lo indique. Cuando el comportamiento observado contradice a la configuración, el override es el primer sitio donde mirar.

Caché y lectura posterior

Una configuración guardada puede no llegar a la página si existen caché de aplicación, servidor o CDN. Purga la ruta exacta, lee origen y superficie pública y guarda evidencias. La página de SEO PrestaShop explica esta matriz.

La secuencia que evita la mayoría de los diagnósticos erróneos es siempre la misma: se guarda el cambio, se purga la ruta concreta —no solo la caché general—, se lee desde el origen y después desde la URL pública, y se comparan. Si origen y superficie pública difieren, el problema es de caché; si coinciden y ninguna refleja el cambio, el problema es de configuración o de override.

Guarda la evidencia de cada lectura con su fecha: código de estado, canonical, meta robots y las primeras líneas del contenido. Sin ese registro, quien revise el caso después repetirá el trabajo, y en una tienda con varias capas de caché no es barato.

Muestrear antes de generalizar

Selecciona combinaciones representativas: una faceta útil, otra sin demanda validada, múltiples filtros, ordenación, paginación y valores sin resultados. Para cada muestra registra status, canonical, robots, enlaces entrantes, presencia en sitemap y contenido visible. El objetivo es comprobar la regla real, no asumirla desde el panel.

Después rastrea una frontera acotada y observa si aparecen combinaciones inesperadas. Si el número de URLs crece con la profundidad, detén la prueba antes de sobrecargar el entorno. Cualquier regla propuesta debe incluir excepciones aprobadas y un procedimiento para retirar una faceta sin dejar enlaces rotos.

La frontera acotada importa en una tienda: un rastreo sin límite de profundidad sobre un espacio combinatorio puede generar carga suficiente para degradar el servicio. Fija un tope de URLs y de profundidad, ejecuta fuera de las horas de más venta y detén la prueba en cuanto el crecimiento confirme la hipótesis; no hace falta enumerar el espacio entero para saber que es demasiado grande.

En cuatro láminas

ejemplo: filtros: color (5) · talla (6) · marca (8) / URLs posibles: 5 × 6 × 8 = 240 / con ordenación (3): 720 / con paginación: miles / / # cada filtro nuevo multiplica; / # el problema es de generación, no de indexación

0 ordenaciones indexables. Las ordenaciones y los parámetros técnicos no son facetas: no deben producir URLs indexables.

shell: $ curl -s "https://tienda.example/zapatos/?color=rojo" \ / | grep -i 'robots\|canonical' / <meta name="robots" content="noindex, follow"> / <link rel="canonical" href="…/zapatos/"> / / # tras purgar la ruta EXACTA: / # una configuración guardada no es una aplicada

Errores frecuentes

• Intentar contener con canonical un espacio que sigue generándose y enlazándose sin límite.
• Bloquear en robots.txt URLs que llevan noindex, impidiendo que la directiva llegue a leerse.
• Aprobar landings de faceta sin demanda comprobada, sin inventario estable ni contenido propio.
• No normalizar el orden ni la codificación de los valores en la URL y multiplicar duplicados invisibles.
• Afirmar cómo se comporta «PrestaShop» sin anotar versión de núcleo, módulo, tema y overrides.
• Buscar en el panel la causa de un comportamiento que impone un override antiguo.
• Leer la superficie pública sin purgar la ruta exacta y concluir que el cambio no se guardó.
• Lanzar un rastreo sin límite de profundidad sobre el espacio de facetas y cargar el servidor.

Preguntas habituales

¿Contengo las facetas con canonical?

No se puede contener con canonical un espacio que se sigue generando y enlazando: las URLs se solicitan igual y siguen recibiendo enlaces desde la navegación. El problema es de generación, no de indexación. Primero se decide qué combinaciones existen; después se etiqueta lo que queda.

¿Qué facetas merecen ser indexables?

Solo las que tienen intención propia y un inventario estable detrás, y aun así con contenido propio que justifique la página. Una combinación cuyo resultado cambia cada día, o que se cruza con otras tres, produce una URL que no se puede sostener ni mantener.

¿Puedo bloquear en robots.txt lo que lleva noindex?

Es contradictorio: el bloqueo impide descargar la página, así que la directiva noindex no llega a leerse nunca. Es de los errores más repetidos en catálogos, y sobrevive años porque las dos medidas parecen reforzarse.

¿Por qué mi cambio de configuración no se ve?

Una configuración guardada no es una configuración aplicada. Se lee en la superficie pública, purgando la ruta exacta, y a veces lo que manda no es el panel sino un override antiguo del tema o de un módulo. Sin anotar versión de núcleo, módulo, tema y overrides, ninguna afirmación sobre el comportamiento es repetible.

Próximo paso

Empieza por dos categorías representativas y levanta el inventario de su espacio: un filtro, dos filtros, una ordenación, una página de paginación y una combinación sin resultados, con y sin JavaScript, anotando estado, canonical, meta robots, enlaces entrantes y presencia en sitemap. Esa tabla, que se completa en una tarde, suele bastar para ver si el problema es de generación, de enlazado o de etiquetado.

Con ella delante, clasifica los tipos de combinación y decide cuáles quieres que existan. La lista de aprobadas será mucho más corta de lo esperado, y ese es el resultado útil: a partir de ahí se trabaja limitando la generación y el enlazado del resto, se comprueba cada cambio en la superficie pública con la caché purgada, y se anota la versión de núcleo y módulo bajo la que se validó la regla, para que la próxima actualización no la invalide en silencio.

Fuentes

• Google Search Central, consolidar URLs duplicadas — documentación oficial.
• Google Search Central, introducción a robots.txt — documentación oficial.
• Google Search Central, gestión del presupuesto de rastreo en sitios grandes — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo para prestashop es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo para prestashop