SEO de filtros y variantes en una tienda online: qué indexar

SEO de filtros y variantes en una tienda online: qué indexar. Decide qué URLs abrir a Google, cómo tratar canónicas, tallas, colores y paginación.

El SEO de filtros consiste en decidir qué listas de productos merecen una página de búsqueda y cuáles solo sirven para navegar. En un ejemplo hipotético, diez colores, ocho tallas, seis marcas y cuatro ordenaciones producen 1.920 combinaciones brutas. Eso no significa que existan 1.920 URLs indexadas.

Una persona entra en una categoría, marca su talla y ordena por precio. La tienda hace exactamente lo que debe hacer: ayudarle a comprar. El problema aparece cuando cada movimiento abre una URL distinta y nadie ha decidido qué representa esa URL para Google. Una categoría puede acabar rodeada de versiones que se parecen mucho, resultados vacíos y combinaciones que cambian con cada reposición.

La solución necesita dos perspectivas. Quien lleva el negocio debe explicar qué selecciones tienen sentido comercial y cuáles puede sostener el catálogo. Quien desarrolla debe convertir esas decisiones en un comportamiento previsible: enlaces, respuestas HTTP, metadatos y selección de variantes. Ninguna de las dos partes puede resolverlo por separado con una casilla de un plugin.

Nuestra recomendación editorial es empezar por el catálogo y no por robots.txt. Selecciona las páginas que quieres conservar, comprueba cómo se encuentran los productos y después limita las rutas que sobran. Una prohibición demasiado amplia puede ahorrar solicitudes a costa de cerrar una categoría útil. Una canónica colocada en todas partes puede esconder que cada página enseña productos diferentes.

Esta guía se concentra en esa decisión técnica. Para la arquitectura general, los feeds o los datos de producto, consulta la guía de SEO para tiendas online. Aquí las preguntas son más acotadas: qué hacer con el color negro, qué ocurre con la talla agotada, qué debe devolver una página cinco que no existe y cómo verificar un cambio sin confundir una prueba técnica con resultados comerciales.

Los dos ejemplos desarrollados son hipotéticos y reproducibles. No describen clientes de YAG ni resultados obtenidos. Las recomendaciones de implementación son propuestas que deben contrastarse con la tienda concreta; las reglas atribuidas a Google llevan su fuente oficial.

1. Distingue una categoría comercial, un filtro y una variante

Una selección puede tener varias funciones

Una categoría comercial reúne productos para una necesidad que puedes nombrar con claridad. Un filtro reduce una lista según un atributo. Una variante identifica una opción comprable de un producto. Los tres pueden incluir la palabra "negro", pero no son lo mismo. "Zapatos negros" puede ser una selección comercial; marcar negro en un panel es una interacción; elegir el zapato negro de un modelo concreto es una opción de compra.

Antes de discutir etiquetas SEO, pide que alguien de la tienda complete esta frase para cada ruta: "Esta página sirve para que el cliente...". Si la respuesta es "vea los mismos artículos ordenados de otra forma", estás ante una vista. Si es "encuentre las botas impermeables que tenemos", quizá hay una página de categoría. Si es "reciba el modelo elegido en la talla que necesita", hay una variante que debe conservar su identidad durante la compra.

Creo que mezclar estas funciones es la causa más costosa de muchos diseños de filtros. No porque haya una penalización automática por mezclarlas, sino porque después resulta imposible escribir una regla sencilla. El programador recibe la instrucción de indexar colores, el editor crea un texto para negro y el panel genera negro combinado con cualquier talla, marca y precio. Nadie ha autorizado todas esas páginas.

La diferencia también afecta al mantenimiento. Una categoría editorial puede necesitar selección de productos, una descripción útil, navegación y seguimiento propio. Un filtro de sesión necesita rapidez y claridad. Una variante necesita atributos, precio, disponibilidad y correspondencia exacta con el pedido. Darle a una vista de sesión el mantenimiento de una categoría no hace mejor la tienda; multiplica trabajo que quizá no aporta nada.

Diseña un registro que entienda quien compra mercancía

Un registro inicial puede tener seis columnas: nombre de la selección, función, URL, responsable comercial, comportamiento esperado y prueba. No hace falta empezar con todas las URLs de la web. Elige una categoría representativa y recorre sus controles. Anota qué cambia cuando pulsas cada uno: la dirección, el título, los productos, la foto principal o la opción seleccionada en una ficha.

Una marca puede tener una colección propia porque vende líneas reconocibles y recibe búsquedas identificables. Otra marca puede funcionar como filtro dentro de una categoría pequeña. La decisión no depende de que ambas compartan el atributo técnico brand. Depende de qué oferta puedes presentar y de cómo la entiende el comprador. Mantener dos páginas que dan la misma respuesta requiere una razón comercial concreta.

Lo mismo ocurre con la talla. Una tienda especializada en tallas amplias puede tener una selección editorial duradera. En otra tienda, la talla cambia únicamente qué variantes se pueden añadir al carrito. No conviene convertir la segunda en la primera solo porque el sistema permite generar una URL. La disponibilidad de una función no demuestra que exista una oportunidad SEO.

Ese registro debe incluir lo que no cambia. Si elegir azul modifica la imagen pero mantiene el mismo modelo y la misma descripción, el equipo necesita saberlo. Si elegir una marca sustituye el conjunto completo de productos, también. La similitud se observa en la respuesta real de la página, no se deduce de la forma bonita o fea de su dirección.

Resuelve primero las contradicciones comerciales

Imagina que el menú tiene "Calzado negro" y el filtro genera una segunda lista negra con los mismos artículos. Decide cuál es la entrada pública que quieres mantener. Puede ser la categoría editorial; puede ser una colección que el propio sistema administra. Después documenta cómo se llega a ella desde el filtro. Crear una tercera URL porque el título queda mejor no resuelve la duplicación anterior.

Otro conflicto aparece cuando una categoría significa "disponible ahora" y el filtro de color incluye variantes agotadas. El comprador recibe una promesa que la lista no cumple. Antes de cambiar canónicas, revisa la consulta de catálogo. Debe quedar claro si una tarjeta se incluye porque tiene alguna variante negra, porque la variante negra se puede comprar o porque hay previsión de reposición.

Conviene acordar también qué entiende la tienda por producto. Para almacén puede ser una referencia; para marketing, una familia; para el comprador, una combinación de modelo y color. Utiliza esos nombres sin forzarlos a ser idénticos, pero registra la correspondencia. Cuando una auditoría cuenta productos y otra cuenta variantes, comparar ambos números sin ese acuerdo produce un diagnóstico equivocado.

La documentación de Google sobre URLs de ecommerce recomienda URLs identificables para variantes y advierte de que los fragmentos no distinguen contenido al indexar. Esta regla no obliga a redactar una ficha SEO diferente para cada talla. La propuesta práctica es separar la identidad necesaria para comprar de la decisión editorial de crear una página de búsqueda autónoma.

El entregable de esta sección es un vocabulario compartido y una primera selección de rutas. Todavía no se bloquea nada. Si el equipo no puede explicar por qué existen dos direcciones, ese conflicto pasa a la lista de decisiones; no se oculta detrás de una etiqueta técnica.

2. Calcula la superficie de URLs sin inventar cuántas conoce Google

Ejemplo hipotético A: cuatro dimensiones y 1.920 combinaciones brutas

Supongamos una categoría de camisetas con diez valores de color, ocho tallas, seis marcas y cuatro formas de ordenar. El ejercicio exige elegir exactamente un valor de cada dimensión. El producto cartesiano es 10 × 8 × 6 × 4 = 1.920. Es un máximo bruto para ese conjunto de elecciones del ejemplo, no un recuento de páginas reales, productos, solicitudes ni URLs indexadas.

El cálculo se reproduce sin datos de ninguna tienda. Escribe los cuatro conjuntos en una hoja y combina un elemento de cada conjunto. Una fila podría ser negro, M, marca A y precio ascendente. Otra sería negro, M, marca A y precio descendente. Ambas pertenecen al ejercicio aunque muestren los mismos productos. Precisamente por eso contar combinaciones no equivale a contar respuestas distintas.

El modelo deja fuera opciones habituales: no seleccionar ninguna talla, elegir dos colores, aplicar un rango de precio, paginar o cambiar el orden de los parámetros. Tampoco considera incompatibilidades. Una marca puede no tener camisetas verdes; una talla puede no existir en un modelo. Si añades estas posibilidades, debes definir de nuevo el modelo. No sumes una cifra espectacular al artículo y la presentes como problema probado.

Mi preferencia es utilizar este cálculo para hacer visible una decisión de diseño. Si cuatro controles ya permiten muchas combinaciones, necesitas reglas de generación y mantenimiento. El cálculo sirve para preguntar qué hará el sistema, no para afirmar que Google ha gastado una cantidad de recursos concreta. Esa segunda afirmación exige datos observados.

Separa lo generable, lo enlazado y lo observado

Puedes distinguir cuatro inventarios. El primero contiene las direcciones que la aplicación admite. El segundo, las que aparece capaz de generar el escaparate. El tercero, las que se han solicitado y quedaron registradas. El cuarto, las que un buscador informa como conocidas o indexadas. Es posible que una dirección exista en uno de esos inventarios y no en los demás.

Una URL inventada manualmente puede responder aunque ningún enlace interno la utilice. Un enlace puede quedar visible en una plantilla sin que nadie lo haya solicitado. Un registro de acceso puede contener un bot de otra empresa, un monitor o un usuario, no Googlebot. Y un informe de indexación tiene su propia fecha y límites. El diagnóstico debe conservar esos matices.

Para una primera revisión pide una muestra concreta: una combinación de un filtro, otra de dos, una ordenación, una segunda página y una combinación imposible. Guarda las direcciones completas. No hagas una captura que esconda los parámetros y luego intentes reconstruirlos. La identidad de una ruta es parte de la evidencia, especialmente cuando el defecto está en duplicar un parámetro.

Después agrupa por función. Las solicitudes a sort se estudian con las ordenaciones; las de una talla en una ficha, con las variantes. Mezclarlas en una columna llamada "URLs con interrogación" no ayuda. Los parámetros no son un defecto por sí mismos. Una misma sintaxis puede transportar una paginación útil o un identificador de sesión innecesario para un enlace público.

Un inventario pequeño pero explicado suele ser más aprovechable que un rastreo enorme sin contexto. Si la herramienta se ha detenido al alcanzar su límite, registra ese límite. No extrapoles el último contador a todo el catálogo. Si no ha ejecutado la navegación con JavaScript, indica qué parte del escaparate queda fuera. La ausencia en una herramienta no prueba que una ruta no exista.

Localiza la fuente que multiplica direcciones

Antes de añadir restricciones, identifica quién construye la URL. Puede ser el tema, una extensión de filtros, un enlace del menú, una aplicación o un componente propio. Cambiar el lugar equivocado deja intacta la generación. Incluso puede crear nuevas versiones: una dirección antigua sigue enlazada y otra plantilla empieza a enlazar la nueva.

Repite la misma selección en órdenes distintos. Marca primero negro y después M; limpia; marca M y después negro. Compara direcciones y productos. Si las listas coinciden pero las direcciones varían, has encontrado una decisión de normalización que merece revisar. También prueba seleccionar, quitar y volver a seleccionar un valor. El estado final no debería acumular instrucciones de interacciones anteriores.

Comprueba si el panel anuncia valores que no tienen relación con la categoría. Un atributo global mal aplicado puede ofrecer tallas de calzado en camisetas o marcas sin ningún artículo en esa sección. Esta revisión pertenece tanto a la gestión de catálogo como al desarrollo. Bloquear las URLs de esos errores evita parte de la exposición, pero no corrige la navegación equivocada del comprador.

No conviertas la superficie máxima en una previsión de daños. Usa el inventario para priorizar: qué patrón se repite, qué páginas comerciales afecta, qué productos necesitan una ruta alternativa y qué prueba permite demostrar la corrección. La cifra de 1.920 queda como herramienta didáctica de este ejemplo, no como una estadística atribuida a YAG o a Google.

3. Elige qué filtros se convierten en páginas comerciales

Exige una respuesta diferente, no un título diferente

Una combinación merece consideración editorial si resuelve una necesidad reconocible y el catálogo puede responder a ella. Cambiar el H1 de "Camisetas" a "Camisetas negras" mientras se enseñan todos los colores no crea esa respuesta. Tampoco basta con añadir un párrafo que repite el atributo. La selección tiene que ser comprensible, correcta y suficientemente estable para mantenerla.

Proponemos evaluar cinco preguntas: qué busca el comprador, qué productos cumplen, cómo se diferencia de otra página, quién mantendrá la selección y qué ocurre cuando cambia el stock. No asignamos una puntuación universal. Una tienda pequeña de material profesional y un catálogo amplio de moda necesitan umbrales distintos. El equipo debe justificar sus elecciones con su oferta y con datos que pueda comprobar.

Las consultas de clientes, el buscador interno, Search Console y el análisis de resultados de búsqueda pueden aportar indicios. Cada fuente cuenta una cosa distinta. Una búsqueda interna muestra una necesidad de alguien que ya está en la tienda; no demuestra por sí sola demanda orgánica suficiente. Una consulta orgánica puede corresponder a una ficha o a una categoría. Revisa la intención antes de elegir una URL de destino.

Creo que las mejores candidatas suelen poder defenderse sin empezar hablando de palabras clave: "Vendemos esta selección durante todo el año y la gente pregunta por ella". Después hay que verificar la demanda y la competencia. El razonamiento inverso, crear cada cruce porque una herramienta muestra un término relacionado, tiende a producir categorías que el negocio no puede sostener.

Tabla de decisión para un catálogo real

Esta tabla es una propuesta de trabajo, no una receta automática ni una lista de resultados garantizados. "Evaluar" significa revisar la respuesta de esa página, no activar indexación por defecto.

La fila de agotado y la de vacío no son intercambiables. Una ficha puede describir un artículo existente que volverá a venderse. Una combinación "marca A + color verde + talla X" puede no haber tenido ningún resultado jamás. Si el sistema les da el mismo tratamiento porque ambos muestran cero botones de compra, pierde información útil para el usuario y para el mantenimiento.

Construye una lista de admisión editorial

Una lista de admisión recoge las selecciones aprobadas como páginas comerciales. Por ejemplo, puede permitir categoría y marca en unas familias, pero no talla y rango de precio. Cada excepción tiene propietario y motivo. No necesita empezar como un sistema complejo: un registro versionado, revisado por negocio y desarrollo, puede evitar que un cambio de catálogo abra rutas sin control.

Cuando una combinación pasa esa revisión, decide su dirección estable y su relación con el panel. Si la página comercial está en /camisetas/negras/, el filtro negro debe tener un comportamiento compatible con ella. Si se conserva una ruta con parámetros como página principal, todos los enlaces relevantes deben utilizar esa forma acordada. La limpieza visual de la URL no sustituye esa coherencia.

También decide cómo retirar una selección. Puede haber una campaña temporal, una marca que deja de distribuirse o una línea que se sustituye por otra. Registra qué evidencia obliga a revisarla y quién toma la decisión. Evita que una variación diaria de stock cambie constantemente la política editorial; el comprador necesita direcciones previsibles y el equipo necesita reglas que pueda probar.

Una página candidata todavía no es una página aprobada. Si falta comprobar el catálogo o la demanda, queda pendiente de ese dato, mientras los filtros siguen cumpliendo su función de navegación. Este límite evita presentar una decisión de SEO como si fuera una certeza técnica y permite trabajar con el servicio de diseño y desarrollo de tiendas online sin crear categorías que luego habrá que deshacer.

4. Usa canonical, noindex y robots.txt para objetivos distintos

Define el verbo antes de elegir la herramienta

Hay tres intenciones que conviene escribir literalmente: preferir una versión, excluir una página del índice o limitar el rastreo. Se parecen en el informe final porque todas pueden reducir la presencia de ciertas URLs, pero el recorrido técnico es diferente. Si el encargo dice solo "que Google no vea esto", falta concretar cuál de las tres intenciones corresponde.

Google presenta rel="canonical" como una señal de preferencia entre páginas duplicadas o muy similares. No garantiza que el buscador elija la URL declarada, y robots.txt no es un método de canonicalización. También desaconseja usar noindex para resolver la selección de una canónica dentro del mismo sitio. La documentación de canonicalización explica estas diferencias.

Aplicado a una tienda, la pregunta editorial es si dos direcciones representan la misma respuesta. Un orden distinto puede seguir enseñando una lista equivalente; una segunda página con otros productos no es la misma lista. En una categoría negra pueden cambiar todos los artículos respecto a la categoría general. No asumas equivalencia porque las plantillas comparten el mismo encabezado o porque quieres que solo aparezca una URL.

Mi recomendación es que el equipo escriba el destino canónico en la tabla de pruebas y explique la equivalencia. "Porque así lo hace el plugin" describe una configuración, no justifica la elección. Una canónica hacia una categoría que no contiene los artículos seleccionados merece revisión, aunque sea una solución frecuente en una plantilla.

El conflicto entre noindex y bloqueo de rastreo

Google necesita acceder a una página para leer una instrucción noindex; si robots.txt le impide entrar, no puede ver esa instrucción. El documento oficial sobre noindex distingue la regla de indexación de un bloqueo de acceso. Por eso aplicar ambas cosas a la vez no demuestra que una URL conocida vaya a desaparecer del índice.

Imagina una familia de filtros ya conocida por Google. El objetivo es excluirla y después reducir su rastreo. El equipo debe preparar una secuencia que considere ese estado previo, comprobar que la instrucción se recibe y revisar el informe correspondiente antes de tratar el bloqueo como cierre. No hay un plazo universal que permita dar esa transición por realizada tras unas horas. Un bloqueo posterior tampoco garantiza que la URL permanezca fuera del índice: impide volver a leer el noindex y la dirección puede seguir descubriéndose mediante enlaces. Si mantenerla excluida es el requisito, conserva una vía para que el buscador reciba la instrucción y revisa el resultado observado.

Otra familia todavía no necesita formar parte de búsqueda y se genera sin aportar páginas comerciales. Ahí puede resultar razonable estudiar controles de rastreo desde el diseño. La guía de navegación facetada de Google contempla robots.txt o estados mediante fragmentos para filtros que no necesitan indexarse, y señala que canonical o nofollow son menos eficaces para controlar ese espacio de rastreo. Los fragmentos aquí representan navegación prescindible para indexación; no deben confundirse con variantes o paginación que se necesite descubrir.

El diagnóstico debe anotar el objetivo elegido, el estado previo y la prueba de cada transición. Escribir "noindex aplicado" no significa "desindexación observada". Escribir "bloqueado" no significa "eliminado". Esta precisión evita cambiar de criterio a diario cuando dos herramientas muestran datos recogidos en fechas diferentes.

Prueba una regla antes de extenderla

No pegues un patrón general para todas las interrogaciones de la tienda. Puede coincidir con el parámetro de página, con una selección de variante o con una ruta utilizada por otra función. Prepara ejemplos que deban coincidir y ejemplos que no. La categoría principal, la página dos y una ficha comprable forman parte del conjunto de protección, no del conjunto que quieres cerrar.

Para cada patrón registra una prueba positiva y otra negativa. Una prueba positiva confirma que bloquea el filtro concreto. Una negativa comprueba que no bloquea una página comercial vecina. Si únicamente ensayas la primera, puedes conseguir el efecto deseado y romper otra ruta sin advertirlo. La prueba no tiene que ser complicada; sí debe utilizar URLs reales de esa instalación.

Revisa también las señales que recibe la misma página en distintas capas. El HTML puede contener una canónica y el servidor otra cabecera. Una extensión puede producir una etiqueta robots y el tema otra incompatible. Guarda la respuesta completa de la muestra para comparar, sin publicar datos de sesiones privadas. El objetivo es una decisión coherente que se pueda repetir.

Cuando el equipo resuelva esta sección, debería poder responder: "Esta familia se trata así porque cumple esta función; se protege esta otra familia; se verificará con estas muestras". Si solo queda el nombre de una herramienta, aún falta convertir el criterio en una implementación acotada.

5. Normaliza parámetros y evita estados que el catálogo no puede responder

Una dirección debe describir el estado final

La normalización consiste aquí en dar una forma acordada a estados equivalentes. Dos personas pueden llegar a la selección negra y talla M siguiendo recorridos distintos. La dirección que comparten debería representar esa selección, no conservar una narración de sus clics. Esta es una propuesta de diseño para que soporte, catálogo y desarrollo puedan reproducir el mismo problema.

Define el orden de los atributos, la escritura de sus valores y el tratamiento de las selecciones vacías. Separa una elección omitida de una elección inválida. Una talla que el usuario no ha marcado no es lo mismo que una talla inexistente introducida en la dirección. Si el servidor las trata como equivalentes, documenta por qué; si el sistema necesita rechazarlas, incluye esa respuesta en los tests.

Google recomienda consistencia en las URLs facetadas, evitar filtros duplicados y responder con HTTP 404 ante cruces sin resultados, incoherentes o páginas inexistentes. No propone redirigir todos esos casos a una página común de error. Estas pautas aparecen en la guía oficial de navegación facetada. El resto de esta sección desarrolla un procedimiento editorial y de pruebas propio para trasladarlas a un catálogo.

No hace falta que quien compra mercancía sepa escribir una expresión regular. Sí necesita explicar qué valores son posibles. En material eléctrico, diámetro y longitud pueden pertenecer a unidades diferentes; en ropa, S y una talla numérica pueden ser esquemas alternativos. El sistema no debería permitir cruces que mezclan categorías incompatibles solo porque todos los atributos están guardados como texto.

Define equivalencias sin borrar elecciones

Supón que el catálogo contiene "negro", "Negro" y "negro mate". Puede haber un error de escritura en los dos primeros y una diferencia de producto en el tercero. Agrupar todo automáticamente sería cómodo, pero podría ocultar una característica que el comprador necesita. La normalización de datos exige una decisión de catálogo antes de cambiar la dirección pública.

Lo mismo ocurre con marcas y fabricantes. Un nombre comercial, una marca abreviada y una empresa matriz pueden convivir sin ser intercambiables para el usuario. Decide qué etiqueta muestra la tienda y conserva el vínculo con el dato de origen. Así puedes corregir un filtro sin cambiar accidentalmente la clasificación de las fichas o la información que llega a otros sistemas.

Creo que una equivalencia debe poder explicarse con un ejemplo de pedido. Si alguien compra el producto A y el sistema lo agrupa con B, ¿esa agrupación habría cambiado lo que esperaba recibir? Si la respuesta es sí, no estás ante una simple limpieza de nombres. Quizá necesitas un filtro de familia y otro de acabado, o categorías distintas. Resolverlo con una redirección sería trasladar el conflicto a otra capa.

Una vez acordados los valores, prueba la reversibilidad de la interacción. Selecciona negro y M, quita M, vuelve a añadir M, cambia a L y limpia todos los filtros. La lista y la dirección deben seguir el estado visible. Si la dirección conserva M después de que el control muestre L, el enlace compartido puede abrir una selección distinta de la que vio el comprador.

Ensaya entradas inválidas de forma acotada

La batería de pruebas propuesta incluye valores desconocidos, parámetros repetidos, atributos incompatibles y números de página fuera de rango. No es un test de carga ni una exploración agresiva. Se ejecuta sobre una muestra pequeña y autorizada, preferiblemente en un entorno de pruebas con catálogo representativo. El objetivo es observar respuestas, no forzar recursos del servidor.

Para cada entrada guarda la dirección solicitada, el estado HTTP, el mensaje visible y la alternativa ofrecida. Una página de error puede conservar navegación y ayudar a volver a la categoría; no tiene por qué ser un callejón sin salida. La respuesta técnica y la ayuda al comprador pueden coexistir. Lo que debe evitarse es afirmar que existe una lista válida cuando no hay una respuesta para esa selección.

No confundas validación con seguridad. Que el sistema rechace una talla imposible demuestra esa regla concreta, no una auditoría completa de la aplicación. Tampoco deduzcas que una combinación está vacía porque la primera respuesta tardó o falló. Puede haber una incidencia temporal. Repite la muestra controlada y consulta el comportamiento del catálogo antes de convertir un error de servidor en una decisión editorial.

Incluye las dependencias en el registro. Un filtro puede funcionar con la caché recién vaciada y fallar después de una actualización de stock. Otro puede mostrar valores antiguos porque una aplicación conserva su índice. El test necesita una situación inicial conocida: qué productos y variantes deberían aparecer, cuándo se actualizó el dato y qué componente ejecuta la consulta.

El resultado útil no es una lista de cientos de direcciones raras. Es una especificación de estados: válido con resultados, válido sin la respuesta esperada, incompatible, inexistente o error temporal. Cada estado debe tener dueño y prueba. Esa especificación sirve también para atención al cliente cuando alguien envía un enlace que la tienda no puede reproducir.

6. Diseña variantes que lleguen correctamente al pedido

La URL debe conservar lo que el comprador eligió

Una variante es una opción que cambia lo que se puede comprar: talla, color, capacidad, acabado u otro atributo. La prueba de negocio es sencilla de expresar. Abre un enlace, confirma la selección, añade el producto al carrito y comprueba que el pedido conserva esa selección. La prueba requiere un entorno seguro o un flujo que no cobre ni formalice una compra real sin autorización.

Pongamos una mochila negra con capacidad de treinta litros. Si el enlace abre la familia de mochilas pero la ficha preselecciona una azul de veinte litros, el enlace no representa correctamente la opción. El defecto afecta a campañas, mensajes de soporte y navegación, aunque la página cargue y el título esté bien escrito. Es más urgente corregirlo que discutir una variación estilística del slug.

La guía de URLs para ecommerce de Google distingue variantes identificadas mediante rutas o parámetros y recuerda que los fragmentos no sirven para diferenciar contenido indexado. A partir de esa base, nuestra propuesta es probar la identidad comprable por separado de la política de indexación. Una URL de variante funcional no exige convertir cada combinación en una página editorial distinta.

La imagen forma parte de la prueba. No basta con que un selector tenga la palabra "negro" si la foto, el texto de disponibilidad o el precio corresponde a otra opción. Captura el estado de ficha y carrito sin datos personales. Pide a una persona ajena al desarrollo que indique qué cree que va a recibir; esa lectura ayuda a encontrar contradicciones que el equipo acostumbrado a la plantilla deja pasar.

Decide si el color pertenece a la familia o a un producto separado

No existe una única política editorial válida para todos los catálogos. Dos acabados pueden compartir un modelo y diferir únicamente en apariencia. En otro producto, el acabado cambia compatibilidad, material o uso. El negocio debe decidir qué compra la persona antes de que desarrollo elija qué rutas separa. La política de variantes sigue esa decisión, no al revés.

Un documento corto puede recoger cuándo se crea una familia, cuándo se separa una ficha y qué atributos identifica cada variante. Añade ejemplos del catálogo real. "Todo color es variante" puede fallar con una edición que tiene características propias; "todo SKU es página" puede multiplicar fichas de tallas casi idénticas. Las excepciones necesitan una razón que cualquiera pueda revisar.

Nuestra posición editorial es evitar textos fabricados para simular diferencias que el producto no tiene. Si una talla solo cambia dimensiones, describe esas dimensiones donde el comprador las espera y conserva una guía útil. Reescribir la introducción de cada talla con sinónimos no mejora la información. El tiempo editorial suele estar mejor empleado en una tabla de medidas que responda dudas de compra.

Prueba también opciones incompletas. Una URL que selecciona color pero no talla puede ser un estado legítimo. La ficha debe avisar de lo que falta antes de añadir al carrito. No elijas una talla arbitraria para conseguir que la prueba técnica pase. La comodidad de un botón activo no justifica enviar al usuario una variante que no ha escogido.

Agotado temporal, descatalogado y opción inexistente

Estos estados requieren mensajes diferentes. "Agotado temporalmente" presupone que la opción existe y el negocio decide mantenerla. "Descatalogado" describe una retirada. "La combinación no existe" corresponde a una elección imposible. Registra la fuente de ese dato: inventario, proveedor, decisión de surtido o regla de compatibilidad. Un contador a cero no explica todos los estados por sí solo.

Si hay reposición prevista, comunica únicamente lo que la tienda puede sostener. No inventes fechas para justificar mantener una ficha. Si se permite reserva, el comprador debe entender sus condiciones; si no, el botón debe dejarlo claro. Una alternativa no debe aparecer como sustitución automática si cambia talla, compatibilidad o precio sin una elección consciente del usuario.

En variantes inexistentes prueba qué hace la ficha al abrir la dirección directamente. Algunas interfaces muestran la familia y olvidan silenciosamente el parámetro inválido. Eso puede parecer amable, pero el enlace ya no describe la selección. La decisión de respuesta debe acordarse con el equipo y probarse frente a los estados válidos. No copies la política de una lista filtrada sin comprobar cómo representa esa aplicación las variantes.

Para evitar falsas conclusiones, el informe debe separar continuidad de ficha, disponibilidad de variante y accesibilidad del enlace. Puedes mantener una ficha útil y tener un defecto en la selección de talla. Puedes tener enlaces correctos y datos de stock atrasados. Declarar "variantes revisadas" sin esas capas impide saber qué quedó realmente comprobado.

El cierre de esta sección es funcional: cada muestra abre la opción prevista, presenta información coherente y conserva los atributos hasta el carrito. La revisión SEO va junto a ese recorrido, pero no lo sustituye. El comprador debe poder completar su elección antes de que una tienda pretenda optimizar cómo se presenta esa elección en búsqueda.

7. Protege paginación y descubrimiento cuando limitas filtros

Sigue un producto que no está en la primera página

La revisión de filtros debe proteger el camino que permite encontrar todo el catálogo que quieres vender. Elige una ficha que aparezca al final de una categoría y sigue su ruta desde el menú. No la busques por su nombre: esa prueba mediría otro mecanismo. Guarda los enlaces que has utilizado y comprueba qué ocurre al abrir cada dirección en una ventana nueva.

En un ejemplo de prueba puedes usar una categoría con varias páginas y un producto de la última. El número concreto depende de la tienda; no necesitas inventar un catálogo para justificar el test. La pregunta es si ese producto tiene un recorrido verificable sin activar una búsqueda interna ni depender de una sesión anterior del navegador.

Google recomienda URLs propias y canónicas propias para páginas de una serie, con enlaces que permitan continuar el recorrido. También explica que el rastreador no pulsa botones de "cargar más" como lo hace una persona. Estas pautas están en la documentación oficial de paginación. Una interfaz puede conservar ese botón para el usuario y ofrecer un recorrido enlazable equivalente.

Creo que la prueba del producto final es especialmente útil cuando se quiere aplicar un bloqueo amplio. Si el sistema utiliza un parámetro tanto para filtrar como para paginar, una regla aparentemente razonable puede cerrar el camino de continuidad. El control positivo es el filtro que quieres limitar; el control negativo debe ser esa página siguiente que sigue siendo necesaria.

Comprueba qué representa cada número de página

Abre la segunda página directamente y compara las tarjetas con la primera. Debe corresponder al estado documentado, no repetir la portada de la categoría por una inicialización del navegador. Comprueba también que al recargar se conserva la selección y que el encabezado no contradice el contenido. Una dirección visible en la barra no demuestra que el servidor la haya resuelto como esperas.

Después cambia un filtro desde una página avanzada. El sistema puede necesitar volver al inicio del nuevo conjunto, porque esa selección tiene menos resultados. Documenta ese comportamiento. Si conserva un número que ya no existe, el usuario puede recibir un vacío que parece falta de stock aunque haya productos en otra página. La interacción y la validez de la dirección se deben probar juntas.

No se debe extrapolar la canónica de una ordenación a toda la paginación. El informe necesita ejemplos de contenido. Si la primera página muestra unos productos y la segunda otros, el equipo debe explicar esa diferencia antes de decidir destinos. Resolverlo todo con una única preferencia puede hacer desaparecer del análisis el contenido que necesitabas descubrir.

Revisa también el tamaño de página. Si el comprador puede elegir cuántos productos ve, hay otra dimensión de estado. Decide si esa preferencia se comparte, se conserva únicamente en la sesión o genera direcciones públicas. Inclúyela en las pruebas de equivalencia. No es obligatorio que todas las opciones de interfaz formen parte del inventario editorial.

Trata el final de la serie como un límite real

Una tienda necesita distinguir una página válida de otra fuera de rango. Introduce un número posterior al final conocido de una categoría pequeña de prueba. Observa si devuelve error, repite la última página o vuelve silenciosamente a la primera. Repetir contenido bajo números arbitrarios crea estados que nadie necesita para comprar y complica la lectura del inventario.

La muestra debe ser reproducible. Anota cuántas páginas tiene esa categoría en el momento del test y qué modificación de stock podría cambiar el final. Si la prueba se ejecuta después de añadir productos, una dirección antes inválida puede pasar a ser válida. Eso no es una regresión automáticamente; es un cambio en la situación inicial. Compara reglas, no solo capturas antiguas.

En scroll infinito comprueba la recuperación del estado del usuario. Abre un producto, vuelve a la categoría y revisa si regresa al lugar esperado o al principio de la lista. Esta es una prueba de experiencia de compra, distinta de la de descubrimiento. Ambas importan, pero un defecto en una no permite inferir que la otra esté resuelta o rota.

También conviene comprobar el acceso con teclado a los controles de continuación y el anuncio de cambios de resultados. El comprador puede perder la referencia cuando el panel añade tarjetas sin explicar qué ha ocurrido. El trabajo de filtros no queda terminado con una lista que simplemente contiene productos; necesita permitir que las personas entiendan y recorran esa lista.

El resultado de esta sección es una ruta protegida hacia las fichas del catálogo y un comportamiento definido para el final de las listas. Si limitar filtros rompe esa ruta, el cambio se corrige antes de extenderlo. Un sitemap puede ayudar a comunicar URLs, pero no convierte una navegación defectuosa en una experiencia de compra correcta.

8. Aplica el criterio en WooCommerce o Shopify sin fiarte del nombre de la plataforma

WooCommerce: revisa catálogo, tema y extensión como capas distintas

En WooCommerce empieza por identificar qué componente genera los filtros y cuál controla los metadatos. No presupongas que ambos son la misma extensión. El tema puede dibujar el panel, otra herramienta consultar los productos y una tercera producir canónicas. Una decisión de SEO necesita localizar el dueño de cada comportamiento antes de cambiar configuración.

La documentación de productos variables de WooCommerce explica que una familia puede utilizar atributos y variaciones, y que el inventario puede administrarse a nivel de producto, de variación o de forma mixta. Esa capacidad obliga a comprobar cómo está configurada tu instalación; no demuestra que una talla o un color tenga stock propio en todas las tiendas.

El procedimiento propuesto comienza con una ficha representativa. Abre sus atributos y compara lo que ve el comprador con lo que ha configurado el equipo. No modifiques valores durante esta comprobación si otras personas están trabajando en catálogo. Registra el estado y pide una muestra de pruebas separada cuando necesites cambiar disponibilidad o crear una combinación inválida.

Después inspecciona una categoría con filtros. Comprueba si la selección consulta productos padres, variantes o una mezcla. Una tarjeta puede aparecer porque el modelo tiene negro en alguna opción, aunque la talla seleccionada solo esté disponible en azul. Ese resultado puede deberse a la consulta o al diseño del filtro. No se corrige redactando una descripción de "camisetas negras talla M".

Mi recomendación para WooCommerce es reducir primero las contradicciones entre datos y interfaz. Si el origen de atributos tiene duplicados, la extensión de filtros heredará ese problema. Si el inventario está mezclado sin un criterio comercial, la lista puede ofrecer opciones equivocadas. Solo después tiene sentido definir la política de direcciones que representa esa lista.

Shopify: filtros de navegación y colecciones comerciales

La ayuda oficial de Shopify sobre Search & Discovery describe filtros basados en opciones de producto y en datos como metafields. También permite agrupar valores. No conviene convertir una etiqueta mostrada en el panel en prueba de una estructura SEO completa: el tema y el catálogo concreto siguen determinando qué ve el comprador y qué direcciones se generan.

En una tienda de Shopify, prepara el mismo inventario funcional: colección base, filtro sencillo, combinación, ordenación y variante. Comprueba qué componente controla cada muestra. Si una aplicación externa sustituye la búsqueda o el panel, registra ese hecho. No apliques un procedimiento pensado para el escaparate estándar sin verificar el resultado que esa aplicación entrega.

Una colección comercial seleccionada puede servir como entrada duradera mientras el panel permite filtrar con más detalle. La propuesta editorial es decidir explícitamente qué colecciones tienen esa función y mantener su oferta. Si cada campaña crea una nueva colección con los mismos artículos y ninguna se retira o diferencia, la tienda puede acumular entradas que compiten por la misma respuesta.

Los nombres de metafields y opciones deben ser comprensibles para quien mantiene productos. Un filtro elegante alimentado por datos incompletos ofrece una lista poco fiable. Revisa una muestra de artículos que deberían entrar y otra que debería quedar fuera. Incluye las variantes cuando el criterio dependa de ellas. La comprobación de exclusión suele descubrir errores que la de inclusión no muestra.

Una aplicación nueva no sustituye la decisión

Antes de instalar otra herramienta, escribe qué falta en la actual. Puede ser ordenar los parámetros, devolver un estado correcto, enlazar una página siguiente o elegir una canónica por plantilla. Son carencias distintas. Comparar aplicaciones sin esa especificación convierte el trabajo en una búsqueda de funciones que quizá la tienda no necesita.

La evaluación debe incluir una muestra real de catálogo y un recorrido móvil. Pide al proveedor o al equipo que muestre cómo se comparte una selección y qué ocurre con una combinación imposible. Revisa metadatos y respuestas, además del panel visible. Una demostración con tres productos perfectamente preparados no reproduce el comportamiento de un catálogo que cambia.

No añadimos cifras de límites ni afirmaciones sobre versiones porque la decisión debe tomarse con la documentación y la configuración vigentes de la instalación. Tampoco prometemos que una plataforma permita cualquier control de servidor. Si una limitación impide aplicar una regla, se registra y se estudia una alternativa disponible, manteniendo las páginas comerciales protegidas.

La comparativa útil entre WooCommerce y Shopify para este problema no es "cuál tiene mejor SEO". Es qué parte controlas, quién la mantiene y cómo verificarás el resultado. Una solución manual sin dueño puede deteriorarse; una solución automatizada puede automatizar una mala clasificación. En ambos casos, el contrato de comportamiento y la muestra de pruebas son más útiles que una promesa genérica de la herramienta.

9. Corrige una familia de URLs y verifica antes de ampliar

Ejemplo hipotético B: una tienda de componentes con filtros de compatibilidad

Imaginemos una tienda que vende accesorios para máquinas de café. Tiene filtros por fabricante, modelo compatible, material y precio. La tienda quiere una página comercial para un fabricante concreto, mientras que los cruces de modelo y rango de precio se utilizan para encontrar referencias. Este es un supuesto didáctico, no un cliente ni una intervención de YAG.

El defecto del ejercicio es que el filtro permite combinar un modelo del fabricante A con el fabricante B y muestra una lista vacía como si fuera una categoría normal. Al mismo tiempo, ordenar por precio genera una nueva dirección y la segunda página contiene accesorios diferentes. La política propuesta separa cuatro familias: selección comercial aprobada, cruce de compatibilidad, ordenación y paginación.

Primero se revisa la relación entre fabricantes y modelos. El equipo comercial prepara una muestra de compatibilidad, con una referencia que debe aparecer y otra que no. Desarrollo reproduce ambas. Si la consulta está mal, se corrige antes que las etiquetas; una página de búsqueda bien configurada que recomienda una pieza incompatible sigue siendo una mala tienda.

Después se define una URL comercial estable para el fabricante y se decide cómo enlazarla desde el menú. No se convierte cada modelo automáticamente en una landing. El negocio tendría que justificar cuáles merecen una selección mantenida. Las demás elecciones pueden continuar en el panel para resolver la búsqueda dentro de la tienda.

La primera entrega del ejercicio afecta únicamente al cruce imposible y a una categoría de prueba. El equipo compara el comportamiento anterior y el nuevo con las mismas referencias. Si el cambio bloquea también la segunda página, la entrega falla, aunque haya solucionado el vacío. La cobertura tiene un numerador y un denominador: estados comprobados frente a estados que el contrato exige proteger.

Prepara una transición con salida de emergencia

Una implantación debería registrar el patrón afectado, las muestras, la configuración anterior y la forma de volver atrás. También necesita un responsable que pueda reconocer un fallo comercial. Si el cambio reduce solicitudes pero oculta accesorios compatibles, no basta con que quien desarrolló confirme que la regla funciona tal como se escribió.

Nuestra recomendación es cambiar una familia homogénea cada vez. No porque una tienda solo pueda realizar cambios pequeños, sino porque una prueba mezclada dificulta saber qué causó un resultado. Normalizar direcciones, limpiar atributos y cambiar la política de indexación a la vez exige un seguimiento más complejo. Si no hay una razón operativa para hacerlo junto, separa las comprobaciones.

Antes de producción, ensaya el cambio con datos representativos. Guarda una selección con resultados, otra vacía, una variante, una ordenación y una página de continuidad. Comprueba también una colección comercial que no pertenezca al patrón. Esa última muestra protege frente a una regla demasiado amplia. Si el sistema tiene idiomas o mercados diferentes, incluye los que el cambio pueda afectar.

No se debe usar el entorno de pruebas para inferir resultados de Google. Ese entorno demuestra el comportamiento de la implementación con su configuración. La web pública puede añadir caché, redirecciones, otras aplicaciones o cabeceras distintas. La transición requiere comprobación pública después del cambio autorizado y seguimiento posterior del buscador, cada cosa con su fecha.

Evita alternar políticas por una lectura aislada

Un día una herramienta puede seguir mostrando una URL conocida y otro día un rastreo local ya no alcanzarla. No son pruebas contradictorias necesariamente. Tienen distinta fuente, fecha y alcance. El equipo debe conservar el objetivo de la intervención mientras comprueba esas diferencias, en lugar de alternar entre abrir y cerrar la familia cada vez que cambia un contador.

En el ejemplo hipotético no declaramos tráfico recuperado, ahorro de rastreo ni ventas incrementadas. Para poder hacerlo harían falta datos anteriores y posteriores, un periodo de observación justificado y una comparación que tenga en cuenta cambios de catálogo o campañas. Una batería de tests correcta prueba comportamiento, no causalidad comercial.

El criterio de cierre propuesto es más concreto: los cruces incompatibles se reconocen; la selección comercial sigue accesible; la paginación permite llegar a las referencias; los enlaces de variante conservan la opción; las señales técnicas coinciden con la política. Si una de esas capas no se ha revisado, la entrega se informa como parcial y se ejecuta la siguiente comprobación segura.

Tras esa primera familia, el registro permite extender la solución a otras categorías que compartan realmente el comportamiento. Una categoría de consumibles con atributos diferentes puede necesitar otra decisión. Copiar la regla porque ambas usan el mismo panel es una extrapolación, no una verificación. La reutilización es útil cuando se mantienen los supuestos que acabas de demostrar.

10. Mide cobertura, experiencia de compra y evolución por separado

Una matriz de QA pequeña que pueda repetirse

La siguiente matriz es una propuesta de validación. No certifica ninguna tienda: sirve para convertir una política en pruebas que un equipo pueda ejecutar, repetir y explicar. La evidencia debe incluir fecha, URL exacta y estado esperado. Si solo guardas una captura del panel, otra persona no podrá comprobar qué parámetros o cabeceras produjeron ese resultado.

Ejecuta la muestra en escritorio y móvil. En el móvil prueba el panel cerrado, abierto, con una selección y después de limpiar. El comportamiento responsive puede esconder un botón, truncar una talla o impedir cerrar el panel. Un HTML correcto no demuestra que esa interacción sea utilizable. El test debe llegar al resultado que necesita el comprador.

Creo que la cobertura debe expresarse con estados, no solo con páginas abiertas. Puedes visitar diez URLs y no probar ninguna variante en carrito. Puedes comprobar dos páginas y cubrir un recorrido completo. El denominador se fija con lo que el cambio afecta: categorías, filtros, variantes, errores y continuidad. El numerador incluye únicamente pruebas realizadas y documentadas.

Rastreo observado no es mejora de negocio

Después de la comprobación funcional, observa cómo cambian las solicitudes de las familias afectadas. Utiliza registros o herramientas disponibles con permisos adecuados. Identifica qué agente hizo cada solicitud antes de llamarla Googlebot. Un contador agregado de accesos puede incluir compradores, comprobadores y otros bots. No conviertas ese agregado en una métrica del buscador.

En Search Console, guarda la fecha de la evidencia y las URLs concretas que revisas. Compara la canónica declarada con la elegida cuando dispongas de esa información. No concluyas sobre todo el catálogo a partir de una sola inspección. Tampoco conviertas un estado pendiente de actualización en un fallo del cambio sin revisar si el buscador ya recibió la nueva respuesta.

El análisis comercial sigue otro ritmo. Una colección puede estar técnicamente disponible y no recibir visitas. Puede recibirlas y no convertir porque faltan productos, las condiciones no encajan o la selección es confusa. Estos hechos requieren datos de uso y compra, no una segunda lectura del HTML. El informe debe distinguir preparación técnica, exposición orgánica y resultado comercial.

No recomendamos fijar una mejora porcentual universal antes de conocer la tienda. Primero establece el punto de partida, el alcance del cambio y las señales que puedes medir de forma fiable. Si hay una campaña, una temporada o una reposición relevante durante la observación, registra ese contexto. Atribuir cada cambio de ventas a una canónica sería una afirmación que el test no sostiene.

Un cierre que sirva para mantenimiento

El documento final de una intervención puede ser breve: decisión por familia, muestras verificadas, límites no ensayados, responsable y disparadores de revisión. Entre esos disparadores están cambiar el tema, añadir una aplicación de filtros, introducir un atributo nuevo o alterar la gestión de stock. No hay que repetir toda la auditoría con cada producto, pero sí revisar los supuestos que una modificación puede romper.

Guarda los tests junto al componente responsable cuando sea posible. Si un cambio posterior vuelve a generar parámetros repetidos o borra la selección al abrir una URL, el equipo puede detectar la regresión. Un informe que solo dice "optimización completada" no protege nada. Un ejemplo concreto de entrada y salida permite comprobar si el sistema sigue haciendo lo acordado.

Los errores más evitables son aprobar categorías sin oferta, tratar todo parámetro como duplicado, ignorar el carrito y confundir un bloqueo con una retirada del índice. El antídoto es práctico: escribir qué representa cada familia y comprobarlo. Esta disciplina requiere más atención al principio, pero reduce discusiones basadas en capturas que muestran capas distintas del mismo problema.

Para una revisión con foco en negocio, el siguiente paso es un diagnóstico del catálogo y sus rutas comerciales, no una promesa de posiciones. Puedes plantearlo desde el servicio de SEO para empresas y tiendas en Madrid o desde el de creación de tiendas online. La pregunta inicial debería ser qué páginas venden una selección reconocible y qué controles solo ayudan a encontrarla.

Preguntas frecuentes

¿Hay que indexar todos los filtros de una tienda online?

No. La propuesta es aprobar páginas comerciales concretas y conservar el resto de los filtros como herramientas de navegación. Antes de aprobar una combinación, comprueba qué ofrece, a quién responde y quién la mantiene. La existencia de una URL no demuestra oportunidad comercial. Si falta demanda verificada o el catálogo cambia demasiado para sostenerla, puede seguir siendo útil para el comprador sin entrar en la lista editorial. Evita abrir todos los cruces como primer paso y decidir después cuáles sobran: tendrás que gestionar direcciones que quizá nunca necesitaste.

¿Canonical impide que Google rastree los filtros?

No. Para la implementación debes separar la preferencia entre versiones del objetivo de reducir solicitudes. La prueba práctica consiste en observar qué direcciones genera y enlaza el escaparate, y qué instrucciones recibe cada una. Si el problema dominante es un panel que crea estados equivalentes sin límite acordado, añadir una etiqueta no corrige esa generación. Registra la función de la familia, el destino previsto y la prueba. Si no puedes justificar la equivalencia de contenido, revisa el criterio antes de extender la canónica.

¿Puedo combinar noindex y bloqueo en robots.txt?

No lo hagas esperando que ambos actúen simultáneamente sobre la misma lectura de página. El procedimiento necesita un objetivo y una secuencia comprobada, especialmente para URLs ya conocidas. Antes de tocar reglas, inventaría la familia, protege las rutas comerciales y decide qué evidencia demostrará la transición. Un cambio de configuración es un paso de implementación; el estado observado en el buscador es otra capa. Si ambas fuentes tienen fechas diferentes, conserva esa diferencia en el informe en vez de cambiar la política cada día.

¿Cada talla debe tener una página SEO independiente?

No necesariamente. Pregunta primero qué representa la talla para el catálogo y para la compra. Una opción dentro de un modelo puede necesitar un enlace que la preserve, mientras que una especialización de surtido puede merecer una selección comercial. No fabriques párrafos casi iguales para cada medida. Una guía de tallas correcta, atributos comprensibles y un carrito que conserva la selección aportan información más defendible. La comprobación empieza abriendo el enlace de la opción y termina confirmando lo que el comprador cree que va a recibir.

¿La página dos de una categoría debe apuntar a la primera como canónica?

No si su función es continuar con otros productos. Para revisarla, compara las tarjetas y sigue una ficha que solo aparezca en esa parte de la lista. Abre la dirección directamente, recarga y comprueba la continuidad. La decisión técnica debe respetar esa función, no tratar toda la categoría como una única respuesta. Si un bloqueo de filtros alcanza la paginación, el cambio debe corregirse. Incluye siempre una página avanzada como muestra de protección cuando pruebes restricciones sobre parámetros.

¿Qué respuesta corresponde a una combinación de filtros vacía?

Google recomienda una respuesta HTTP 404 para una combinación de filtros vacía, sin redirigirla a una página genérica de error. Compruébala en la respuesta del servidor, después de confirmar que el vacío corresponde al catálogo y no a un fallo temporal. Prueba también una combinación válida, para evitar que la regla cierre ambas. No apliques automáticamente el tratamiento del vacío a una ficha agotada: registra si el producto existe, si se mantiene y qué información útil sigue ofreciendo. Son estados distintos aunque ninguno muestre un botón de compra activo.

¿WooCommerce o Shopify resuelven este problema automáticamente?

No puedes darlo por resuelto sin inspeccionar la instalación. Prepara una muestra que incluya categoría, filtro, ordenación, página siguiente y variante. Identifica qué parte corresponde al tema, al catálogo o a una aplicación, y comprueba el comportamiento público. Una función disponible en documentación no demuestra cómo está configurada tu tienda. Si falta un control, documenta la limitación antes de instalar otra herramienta. Así podrás evaluar alternativas contra una necesidad concreta y no contra una promesa genérica de "SEO automático".

¿Cómo sé si la corrección ha funcionado?

Empieza por las pruebas definidas en el contrato: selección correcta, navegación usable, identidad de variante, respuestas y señales coherentes. Después revisa lo observado en rastreo e indexación con su fecha. Solo más tarde analiza exposición y resultado comercial con datos adecuados. Informa de cada capa por separado. Si has comprobado las URLs pero no la compra, la validación es parcial. Si la técnica pasa y no hay datos de ventas, puedes afirmar preparación técnica, no crecimiento de ingresos ni una mejora de ranking atribuible al cambio.

Cuando el problema no está en el filtro

Si dos categorías atienden la misma búsqueda, revisa el diagnóstico de canibalización SEO antes de cerrar URLs. Si ya has decidido cambiar direcciones, utiliza el mapa de redirecciones para una migración para conservar destinos equivalentes.

Fuentes primarias y criterio editorial

Documentación consultada el 1 de octubre de 2026. Las reglas técnicas atribuidas a Google y las capacidades de plataforma citadas proceden de estas páginas. Las tablas de decisión, el producto cartesiano, los ejemplos hipotéticos y el procedimiento de QA son elaboración editorial de esta guía; no son métricas de clientes ni una certificación de una tienda concreta.

• Google: gestión del rastreo de URLs de navegación facetada.
• Google: especificación de una URL canónica.
• Google: uso de noindex para impedir indexación.
• Google: estructura de URLs en ecommerce.
• Google: paginación y carga incremental.
• WooCommerce: productos variables.
• Shopify: filtros de Search & Discovery.

Esta guía no sustituye una auditoría de tu tienda ni demuestra resultados de tráfico, posiciones o ventas. Contrasta las decisiones con tu catálogo, tu arquitectura y el comportamiento público real antes de aplicarlas.