Tienes 1.200 productos y Search Console te dice que Google conoce 340.000 URLs. Hace seis meses alguien puso un canonical en todas las URLs de filtros apuntando a la categoría, se dio el tema por cerrado y hoy sigues viendo el mismo número subiendo mes a mes. Las páginas nuevas tardan semanas en indexarse y nadie entiende por qué.
Lo que pasó es que se usó una herramienta correcta para un problema que no le corresponde. El canonical consolida señales entre URLs parecidas, y eso lo hace bien. Lo que no hace es impedir que Google rastree, ni reducir el número de URLs que existen, ni evitar que tu servidor genere 340.000 páginas inútiles.
Y no lo digo yo. La documentación de Google sobre navegación facetada coloca el canonical como opción y añade que es “generalmente menos eficaz a largo plazo” que bloquear el rastreo. Está escrito, en su guía oficial, y aun así media industria sigue vendiendo el canonical como la solución.
Esta guía va de lo otro: qué hace cada mecanismo de verdad, cómo decidir qué facetas merecen existir para un buscador, cómo diseñar las URLs para que el problema no aparezca, y cómo montar una política que no dependa de que alguien se acuerde de poner una etiqueta. Con las citas oficiales delante y desmontando de paso dos técnicas que se están recomendando mucho este año y que no aguantan el escrutinio.
1. El problema no es la duplicidad, es el espacio infinito
Casi todas las guías empiezan por el contenido duplicado. Es lo menos grave de lo que pasa aquí.
Piensa en una categoría con cinco facetas: color (8 valores), talla (7), marca (15), precio (5 rangos) y material (6). Solo con combinaciones de dos facetas ya tienes más de 3.000 URLs. Con tres, pasas de 100.000. Y eso en una sola categoría, sin contar ordenaciones ni paginación.
La documentación de Google lo describe con una frase que explica el fondo del asunto: las URLs que genera la navegación facetada parecen nuevas y los rastreadores no pueden saber si van a ser útiles sin rastrearlas primero.
Ahí está todo. No es que Google no entienda que son duplicados: es que para saberlo tiene que pedirlas. Cada una. Una por una.
Google añade el efecto: que se rastreen esas URLs supone más uso de recursos en tu servidor y, potencialmente, un descubrimiento más lento de las URLs nuevas de tu sitio.
Los tres daños, por orden de importancia real:
Rastreo desviado. Google dedica peticiones a combinaciones que nadie busca en lugar de a tus productos nuevos. En catálogos grandes esto se nota en semanas de retraso en la indexación.
Índice inflado. Miles de URLs casi idénticas compitiendo entre sí y ninguna especialmente fuerte.
Coste de servidor. Cada petición a una faceta hace que tu backend consulte la base de datos, filtre inventario y monte una página que nadie va a ver. En Black Friday, con el rastreo alto y el tráfico alto a la vez, esto tumba tiendas.
Fíjate en que ninguno de los tres se arregla poniendo una etiqueta dentro del HTML de una página que el bot ya ha tenido que pedir.
2. Qué hace el canonical (y qué no)
Lo que es
El rel="canonical" es una señal fuerte, no una orden. La documentación de Google lo dice tal cual: es “una señal fuerte de que la URL especificada debería convertirse en la canónica”. Señal, no directiva. Google la pondera junto al resto y decide.
Google ordena los métodos de canonicalización por fuerza:
- Redirecciones: señal fuerte de que el destino debe ser la canónica.
rel="canonical": señal fuerte de la URL especificada.- Inclusión en sitemap: señal débil.
Cuando el canonical apunta a una página que no se parece lo suficiente a la que lo declara, Google lo ignora y elige otra canónica. Es lo que pasa cuando canonicalizas /zapatillas/?color=rojo&talla=42 hacia /zapatillas/: son páginas con inventario distinto, y si Google no se lo cree, se queda con la URL filtrada.
Lo que no es
No controla el rastreo. Esta es la clave del artículo. El canonical va dentro del HTML. Para leerlo, Googlebot tiene que hacer la petición completa, tu servidor tiene que generar la página y devolverla. El ahorro de rastreo llega, si llega, mucho después y de forma indirecta.
La propia guía de navegación facetada de Google reconoce que el canonical puede, con el tiempo, reducir el volumen de rastreo de las versiones no canónicas, y a continuación aclara que es generalmente menos eficaz a largo plazo que impedir el rastreo con robots.txt o con fragmentos de URL.
No reduce el espacio de URLs. Las 340.000 combinaciones siguen existiendo, siguen enlazadas desde tu propia navegación y siguen siendo descubribles.
No es un cortacircuitos. En un espacio potencialmente infinito, una etiqueta que solo se lee después de generar la página no puede ser el mecanismo de contención.
El coste que nadie calcula
Haz el cálculo con tus números. Si Googlebot pide 50.000 URLs de filtros al mes y cada una le cuesta a tu servidor 400 ms de CPU y tres consultas a base de datos, son cinco horas y media de servidor mensuales dedicadas a generar páginas cuyo único contenido útil es una etiqueta que dice “esta página no importa”.
Eso con el canonical funcionando perfectamente.
3. Qué hace cada mecanismo
Esta es la tabla que resuelve la mitad de las discusiones.
Cada mecanismo resuelve un problema distinto. Ninguno resuelve el de otro.
| Mecanismo | ¿Evita el rastreo? | ¿Saca del índice? | ¿Consolida señales? | Qué dice Google |
|---|---|---|---|---|
rel="canonical" | No | No directamente | Sí | Señal fuerte, no directiva. “Generalmente menos eficaz a largo plazo” para facetas |
robots.txt | Sí | No garantizado | No | Recomendado para facetas que no deben indexarse. “No lo uses para canonicalizar” |
noindex | No | Sí | No | ”No uses noindex” para presupuesto de rastreo: Google pide la página igual y luego la descarta |
nofollow | Parcial | No | No | Puede ser útil, pero exige ponerlo en todos los enlaces hacia esa URL |
Fragmento # | Sí | Sí (no existe como URL) | No aplica | Google no admite fragmentos de URL en rastreo e indexación |
404 / 410 | No la primera vez | Sí | No | Recomendado cuando una combinación de filtros no devuelve resultados |
Tres matices que hay que leer despacio.
El noindex no ahorra rastreo. La guía de presupuesto de rastreo de Google es explícita: no uses noindex, porque Google seguirá pidiendo la página y luego la descartará al ver la etiqueta, desperdiciando tiempo de rastreo. Sirve para limpiar el índice, no para proteger el rastreo.
El robots.txt no garantiza la desindexación. Google avisa de que puede indexar URLs bloqueadas en robots.txt sin su contenido, si las conoce por otras vías. Por eso su consejo es no usar robots.txt como método de canonicalización.
El nofollow exige exhaustividad. Google señala que para que funcione tiene que estar en todos los enlaces que apuntan a esa URL, lo que en un ecommerce con navegación, breadcrumbs, enlaces contextuales y sitemap HTML es bastante frágil.
De ahí sale la regla que resume todo: cada mecanismo resuelve un problema distinto, y ninguno resuelve el de otro. Si esperas que el canonical te ahorre rastreo, estás usando un destornillador de martillo.
4. Los cinco errores canónicos
Los que aparecen una y otra vez en auditorías.
4.1. Canonical y noindex a la vez
En la misma página: noindex diciendo “no me indexes” y canonical diciendo “consolida mis señales en esta otra”. Son instrucciones contradictorias, y además existe el riesgo de que el noindex acabe interpretado sobre la URL canónica.
Google recomienda expresamente no usar noindex para elegir canónica dentro de un mismo sitio, porque bloquea la página de la Búsqueda por completo.
Elige uno. Si la página no debe indexarse, noindex y quita el canonical hacia otra. Si debe consolidar, canonical y fuera el noindex.
4.2. Canonical apuntando a una URL bloqueada en robots.txt
Si canonicalizas hacia una página que Google no puede rastrear, no puede confirmar que se parezcan y la señal se cae. Este error aparece mucho cuando alguien bloquea /*? entero en robots.txt sin revisar qué canonicals había puestos.
4.3. Canonical desde una faceta que sí tiene demanda propia
“Zapatillas de running” tiene búsquedas propias, resultados propios y compradores propios. Si esa faceta la canonicalizas hacia “Zapatillas” a secas, estás renunciando voluntariamente a una consulta comercial por aplicar una regla general sin mirar.
Es el error más caro de la lista, porque no genera ningún aviso en ninguna herramienta.
4.4. Canonicals encadenados o incoherentes
?color=rojo&talla=42 canonicaliza a ?color=rojo, que canonicaliza a la categoría. O peor: la misma combinación con los parámetros en distinto orden apunta a canónicas distintas. Google acaba ignorando el conjunto.
4.5. Facetas en el sitemap
El sitemap es una señal de canonicalización, débil pero señal. Si metes ahí URLs de filtros que a la vez canonicalizas hacia otro sitio, estás mandando dos mensajes opuestos. En el sitemap van solo las URLs que quieres indexar, y ninguna más.
5. La decisión que va antes que cualquier etiqueta
Ninguna configuración técnica te salva de no haber decidido qué filtros merecen existir para un buscador. Esa decisión es de negocio y se toma mirando demanda de búsqueda e inventario, no mirando el código.
La matriz
Las tres pruebas tienen que salir bien. Con dos de tres, apárcala.
| Tipo de estado | Ejemplo | ¿Demanda de búsqueda? | Tratamiento |
|---|---|---|---|
| Categoría y subcategoría | /zapatillas/running/ | Alta | URL limpia, indexable, en el sitemap, enlazada desde el menú |
| Faceta con demanda propia | /zapatillas/running/nike/ | Media o alta | URL limpia, indexable, tratada como landing con su texto y su title |
| Faceta secundaria | ?color=rojo | Baja | Rastreo bloqueado o fragmento. Nada en el sitemap |
| Combinación de dos o más | ?color=rojo&talla=42 | Ninguna | Bloqueado. Sin excepciones salvo demanda demostrada |
| Ordenación | ?orden=precio-asc | Ninguna | Bloqueado o fragmento |
| Vista y paginación de estado | ?vista=lista, ?por_pagina=48 | Ninguna | Bloqueado o fragmento |
| Paginación real | /zapatillas/pagina-2/ | Ninguna, pero necesaria | Rastreable, autocanónica, fuera del sitemap |
| Técnicos y de sesión | ?utm_source=, ?sid= | Ninguna | Bloqueado |
Cómo se decide si una faceta tiene demanda
Tres comprobaciones, en este orden:
- Volumen. ¿Existe la consulta con su volumen propio en tu herramienta de keywords? “Zapatillas running Nike” sí. “Zapatillas running rojas talla 42” no.
- SERP. Busca la consulta en Google. Si el top 10 son páginas de listado de tiendas, la faceta merece landing. Si son fichas de producto sueltas, no.
- Inventario. ¿Tienes suficientes productos para que la página tenga sentido dentro de seis meses? Una faceta con tres productos hoy y cero el mes que viene es una futura página vacía.
Las tres tienen que salir bien. Con dos de tres, apárcala.
Y un límite práctico que ahorra discusiones: una sola faceta por URL indexable. En cuanto permites la combinación de dos, has abierto la puerta al espacio infinito y ya no hay política que lo cierre.
6. Diseño de URLs: donde se gana de verdad
Si las facetas con valor viven en rutas limpias y el resto vive en parámetros, el control se vuelve trivial. Si todo va mezclado en parámetros, cada regla que escribas será un parche.
Facetas con valor, en el path:
/zapatillas/running/
/zapatillas/running/nike/
Todo lo demás, en parámetros de consulta:
/zapatillas/running/?color=rojo&talla=42&orden=precio-asc
Con esa separación, tu robots.txt es una línea y no una lista de excepciones.
Reglas que dicta la documentación oficial
Usa & como separador. Google recomienda el ampersand estándar en lugar de comas, punto y coma o corchetes, porque esas alternativas son más difíciles de detectar para los rastreadores.
Mantén el orden lógico fijo. Si codificas filtros en la ruta, el orden de los filtros debe ser siempre el mismo, y hay que impedir filtros duplicados.
Normaliza el orden de los parámetros. ?color=rojo&talla=42 y ?talla=42&color=rojo son dos URLs distintas con el mismo contenido. Si tu front permite generar ambas, has duplicado tu espacio de filtros gratis. Fija un orden alfabético en el servidor y redirige a la forma normalizada.
Fragmentos para estados puramente navegacionales
Para ordenaciones, vistas y filtros de interfaz, el fragmento resuelve el problema de raíz:
/zapatillas/running/#orden=precio-asc
Google no admite los fragmentos de URL en rastreo e indexación. Para el bot, esa URL es /zapatillas/running/ y no hay más que hablar. El usuario mantiene su estado, puede compartir el enlace y volver atrás.
Es la solución más limpia que existe para la mitad de los parámetros de un ecommerce, y casi nadie la usa porque exige tocar el front en lugar de poner una etiqueta.
7. El 200 vacío: el error que degrada todo lo demás
Un usuario combina cuatro filtros, no hay ningún producto y tu servidor devuelve un 200 con una página que dice “No se han encontrado resultados”.
Google clasifica eso como soft 404: código de éxito con contenido que sugiere error o página vacía. Multiplicado por miles de combinaciones sin stock, es un patrón de baja calidad extendido por todo el dominio.
La guía de navegación facetada de Google da la instrucción exacta: devuelve un código de estado HTTP 404 cuando una combinación de filtros no devuelva resultados. Y añade que no redirijas a una página de error genérica, sino que sirvas el error bajo la URL donde se encontró.
Lo mismo vale para URLs de paginación que no existen: /zapatillas/pagina-47/ en una categoría con nueve páginas debe devolver 404, no una página vacía con 200.
Esto es de las cosas más fáciles de arreglar y de las que más se descuidan, porque no aparece en ningún informe hasta que ya tienes miles.
8. Nofollow y ofuscación: dos técnicas que hay que mirar con lupa
Aquí toca desmontar dos recomendaciones que están circulando mucho este año.
Qué hace el nofollow en realidad
Se repite que poner nofollow en los enlaces de filtros “canaliza” la autoridad hacia el resto. Eso dejó de ser cierto en 2009.
Matt Cutts lo explicó en junio de 2009: antes del cambio, los enlaces con nofollow no contaban en el denominador y los demás recibían más. Después del cambio, cuentan todos, así que los enlaces normales reciben proporcionalmente menos. El PageRank que iba al enlace con nofollow no se reparte entre los otros: se pierde.
Así que sí, hay fuga. Pero conviene leer también lo que dijo Cutts a continuación: que nadie se dio cuenta del cambio, lo que indica que el impacto real no era tan grande.
Y desde marzo de 2020 el nofollow es una indicación, no una orden. La documentación actual dice que los enlaces con estos atributos “generalmente no se seguirán” y que las páginas enlazadas pueden encontrarse por otras vías y ser rastreadas igualmente.
Conclusión práctica: el nofollow en facetas no es un desastre ni una solución. Google lo lista como opción que “puede ser beneficiosa”, con el aviso de que hay que ponerlo en todos los enlaces hacia esa URL para que sirva de algo. Como mecanismo único, es frágil.
La ofuscación de enlaces con Base64
La técnica consiste en convertir los enlaces de filtros en elementos que no son enlaces (un <span> o un <button> con la URL codificada) para que el bot no los descubra y el PageRank no se escape.
Se está recomendando bastante como técnica avanzada. Antes de montarla, dos cosas.
Lo que hay de Google sobre esto, y lo que no. Circula una cita de John Mueller respondiendo específicamente a la ofuscación con Base64. No he encontrado ninguna fuente que la sostenga, así que no la doy por buena ni la uses tú. Lo que sí existe es una respuesta suya de julio de 2026 sobre ofuscación de enlaces en general, donde resta importancia al asunto y recomienda no complicarse. No es exactamente este caso, y conviene no venderlo como si lo fuera.
Lo que cuesta. Es una técnica que exige mantenimiento permanente, complica la accesibilidad, rompe la navegación sin JavaScript y te deja dependiendo de que nadie del equipo de front la deshaga sin saberlo en el siguiente rediseño.
Mi lectura, y aquí ya opino: si tienes un espacio de filtros descontrolado, la ofuscación es esfuerzo puesto en el sitio equivocado. Antes de esconder enlaces del bot, arregla lo que los genera. Diseño de URL, robots.txt y fragmentos resuelven el mismo problema, están documentados, no dependen de JavaScript y se los puedes explicar a un cliente sin que parezca magia negra.
Si aun así quieres probarlo, que sea en una parte acotada y después de haber hecho lo básico. No como estrategia principal.
9. La herramienta de parámetros ya no existe
Vas a seguir encontrando guías que te dicen que configures el comportamiento de tus parámetros en Search Console. Ahórrate el clic.
Google retiró la herramienta de parámetros de URL el 26 de abril de 2022. El motivo que dio: solo en torno al 1 % de las configuraciones especificadas en la herramienta resultaban útiles para el rastreo. Su mensaje fue que no hace falta hacer nada para indicar la función de los parámetros, porque los rastreadores aprenden a gestionarlos automáticamente.
Confiar en ese aprendizaje automático para un espacio de filtros de seis cifras es optimista. Lo que queda son las herramientas de siempre: arquitectura de URL, robots.txt, fragmentos y códigos de estado correctos.
Si una guía te manda a esa herramienta, tiene más de cuatro años y probablemente todo lo demás también.
10. Las facetas y los bots de IA
Un ángulo que casi nadie está conectando.
El estudio de Vercel y MERJ de diciembre de 2024 mostró que los grandes rastreadores de IA no ejecutan JavaScript: GPTBot, ClaudeBot, PerplexityBot y otros se quedan con el HTML de respuesta. Descargan archivos JavaScript sin ejecutarlos.
Eso tiene dos consecuencias para tus facetas.
Si tus filtros con valor se cargan por AJAX, esos bots no ven nada, por el mismo motivo por el que ChatGPT no ve una web en React. Tu landing de “zapatillas running Nike” no existe para ellos, y ese es justo el tipo de página que alimenta las respuestas generativas sobre productos.
Si tus filtros sin valor están enlazados en el HTML, esos bots los rastrean con criterios más rudimentarios que Googlebot para gestionar parámetros. Se meten en el espacio facetado y lo recorren, gastando su presupuesto en combinaciones inútiles en lugar de en tus categorías.
Google lleva años afinando la gestión de espacios de parámetros. Los rastreadores de IA llevan meses. Un espacio facetado que Google gestiona con relativa dignidad puede ser una trampa para ellos.
La solución es la misma que ya has leído, lo cual es una buena noticia: facetas con valor en HTML plano y con URL propia, el resto fuera del alcance del rastreo.
11. Diagnóstico: cómo saber que tu canonical no está sirviendo
Cinco comprobaciones.
1. La proporción. Cuenta las URLs que Google conoce (Search Console, informe de indexación de páginas, sumando indexadas y no indexadas) y divídelo entre tu número real de productos y categorías. Si te sale una proporción de 10 a 1 o más, tienes espacio facetado descontrolado.
2. Estadísticas de rastreo. En Search Console, ve a Configuración → Estadísticas de rastreo y mira la distribución por tipo de respuesta y por finalidad. Si el grueso de las peticiones va a URLs con parámetros y la finalidad “actualización” domina sobre “descubrimiento”, Google está gastando su tiempo en repasar filtros.
3. Rastreo comparado. Lanza Screaming Frog o Sitebulb sobre tu web y compara el número de URLs encontradas con tu catálogo real. Filtra por URLs con parámetros y revisa la columna de canonical: si hay canonicals autorreferenciales en URLs de filtros, tienes miles de páginas declarándose importantes a sí mismas.
4. Coherencia. Sobre esa misma exportación, comprueba que ninguna URL de filtro esté a la vez en el sitemap, que no haya combinaciones de noindex con canonical hacia otra URL, y que no existan canonicals hacia URLs bloqueadas en robots.txt.
5. Logs. Si tienes acceso, es la prueba definitiva y tiene artículo propio con los comandos. Filtra las peticiones de Googlebot del último mes, agrupa por patrón de URL y calcula el porcentaje que se va en parámetros. He visto cuentas donde ese porcentaje pasaba del 70 %.
Si las cinco te salen mal y llevas seis meses con canonicals puestos, ya tienes la respuesta a si el canonical estaba resolviendo el problema.
12. Gobernanza: que no dependa de que alguien se acuerde
Las etiquetas se caen en el siguiente rediseño. Una política documentada, no.
El documento de política de facetas
Una página, cuatro apartados:
Clasificación de estados. Cada faceta de tu web clasificada en una de estas cuatro categorías:
- Curada: tiene demanda propia, URL limpia, indexable, con contenido propio.
- Navegacional: útil para el usuario, sin valor de búsqueda. Fragmento o parámetro bloqueado.
- Inválida: combinación sin resultados. Devuelve 404.
- Retirada: existió y ya no. Devuelve 410 o redirige si hay un destino equivalente.
Gramática de URL. Qué va en el path y qué en parámetros, en qué orden, con qué separador y con qué normalización.
Reglas por mecanismo. Qué se bloquea en robots.txt, qué lleva canonical y hacia dónde, qué entra en el sitemap, qué devuelve qué código.
Responsables. Quién aprueba que una faceta pase a curada, quién la implementa y quién revisa que la política se cumple después de cada despliegue.
Quién tiene que firmarlo
Esto es una de las salidas de una auditoría de arquitectura web e indexación. No es un documento de SEO: es un acuerdo entre catálogo, producto, desarrollo y SEO, porque cada uno controla una pieza: quién define los atributos, quién decide la interfaz de filtros, quién genera las URLs y quién responde del resultado en búsqueda.
Sin ese acuerdo, cada nueva faceta que añada el equipo de producto reabre el problema, y dentro de un año estarás repitiendo esta auditoría.
13. Un aviso para webs multilingües
Si tienes hreflang, las facetas se complican de una forma que casi ninguna guía menciona.
Las anotaciones de hreflang tienen que ser recíprocas y autorreferenciales: cada versión lista a todas las demás y también a sí misma, y si dos páginas no se apuntan mutuamente, Google ignora las etiquetas.
Ahora júntalo con un canonical agresivo en facetas. Si tu versión en francés de /chaussures/running/nike/ declara hreflang hacia la española /zapatillas/running/nike/, pero esa española lleva un canonical hacia /zapatillas/running/, estás mandando señales que se contradicen: hreflang dice que esa URL es la equivalente, y el canonical dice que esa URL no es la buena.
La regla de trabajo: las facetas curadas llevan hreflang y son autocanónicas; las facetas bloqueadas no llevan hreflang de ninguna manera. Y el conjunto de facetas curadas debe ser el mismo en todos los idiomas, porque si en español tienes landing de marca y en francés no, el grupo de hreflang no cierra.
Esto obliga a que la política de facetas se decida a nivel global y no mercado por mercado, que es justo como se suele decidir.
14. Checklist
Diagnóstico
- Proporción entre URLs conocidas por Google y URLs reales calculada
- Estadísticas de rastreo revisadas por tipo de URL
- Rastreo con crawler comparado contra el catálogo real
- Porcentaje de peticiones de Googlebot que se van en parámetros (logs)
Política
- Cada faceta clasificada como curada, navegacional, inválida o retirada
- Criterio de demanda documentado (volumen, SERP e inventario)
- Límite de una sola faceta por URL indexable
- Documento firmado por catálogo, producto, desarrollo y SEO
URLs
- Facetas curadas en el path, resto en parámetros
- Separador
&estándar - Orden de parámetros normalizado en servidor
- Estados navegacionales resueltos con fragmento
#
Mecanismos
- Robots.txt bloquea los patrones de parámetros sin valor
- Ningún canonical apunta a una URL bloqueada en robots.txt
- Ninguna página combina
noindexcon canonical hacia otra URL - Facetas curadas con canonical autorreferencial
- Sitemap solo con URLs indexables, sin ninguna faceta bloqueada
- Combinaciones sin resultados devuelven 404, no un 200 vacío
- Paginación inexistente devuelve 404
Multilingüe
- Facetas curadas idénticas en todos los idiomas
- Hreflang solo entre facetas curadas, recíproco y autorreferencial
- Ninguna faceta bloqueada con hreflang declarado
15. Preguntas frecuentes
¿El canonical sirve para algo en facetas?
Sí, para lo suyo: consolidar señales entre URLs que ya existen y que se parecen mucho. Lo que no hace es evitar el rastreo ni reducir el número de URLs. La guía de navegación facetada de Google lo cita como opción y añade que es generalmente menos eficaz a largo plazo que impedir el rastreo con robots.txt o con fragmentos.
¿Bloqueo los filtros en robots.txt y ya está?
Es lo que Google recomienda como método principal cuando esas URLs no deben indexarse, pero con dos cautelas. Google puede indexar una URL bloqueada sin su contenido si la conoce por otras vías. Y si bloqueas una URL que ya está indexada, Google no podrá leer el noindex para sacarla. En ese caso el orden es: primero noindex y esperar a que salgan, después bloquear.
¿Uso noindex para ahorrar presupuesto de rastreo?
No. La documentación de Google sobre presupuesto de rastreo dice literalmente que no lo uses para eso, porque Google seguirá pidiendo la página y la descartará al ver la etiqueta, gastando tiempo de rastreo igualmente. El noindex limpia el índice, no protege el rastreo.
¿Sigue existiendo la herramienta de parámetros de Search Console?
No. Google la retiró el 26 de abril de 2022 porque solo alrededor del 1 % de las configuraciones resultaban útiles. El control hoy se hace con arquitectura de URL, robots.txt, fragmentos y códigos de estado.
¿Qué hago con las combinaciones de filtros que no devuelven productos?
Devolver un 404 en esa misma URL. Es lo que indica la guía de navegación facetada de Google, y evita que se acumulen miles de soft 404 por servir un 200 con una página vacía.
¿El nofollow en los enlaces de filtros canaliza la autoridad hacia el resto?
No. Desde 2009, el PageRank que va a un enlace con nofollow no se reparte entre los demás enlaces de la página: se pierde. Y desde marzo de 2020 el nofollow es una indicación, no una orden, así que la página puede ser rastreada igualmente por otras vías. Google lo lista como opción posible para facetas, con el aviso de que hay que ponerlo en todos los enlaces hacia esa URL.
¿Merece la pena ofuscar los enlaces de filtros con Base64?
No hay ninguna declaración de Google sobre este caso concreto, y la cita de John Mueller sobre Base64 que circula por ahí no aparece en ninguna fuente verificable. Lo más cercano es una respuesta suya de julio de 2026 sobre ofuscación de enlaces en general, en la que resta importancia al asunto. Antes de montar una técnica que exige mantenimiento permanente y complica la accesibilidad, conviene agotar lo documentado: diseño de URL, robots.txt y fragmentos.
¿Y los fragmentos con almohadilla?
Son de las opciones más limpias para estados puramente navegacionales como ordenaciones y vistas, porque Google no admite los fragmentos de URL en rastreo e indexación. Para el bot, esa URL es la página base. Requiere tocar el front, que es por lo que casi nadie los usa.
¿Cuántas facetas puedo dejar indexables?
Las que superen a la vez las tres pruebas de volumen de búsqueda, tipo de SERP e inventario suficiente. Y una regla que ahorra problemas: una sola faceta por URL. En cuanto permites combinaciones de dos, vuelves a abrir el espacio infinito.
¿Esto afecta también a los buscadores con IA?
Sí, y con más motivo. Los grandes rastreadores de IA no ejecutan JavaScript, así que las facetas cargadas por AJAX les son invisibles, y gestionan los espacios de parámetros con menos criterio que Googlebot, con lo que es más fácil que se pierdan en ellos.
16. Qué hacer con todo esto
El orden de trabajo es este, y es el inverso al que se suele seguir. Primero decide qué facetas merecen existir para un buscador, con la prueba de volumen, SERP e inventario. Después mueve esas a rutas limpias y manda todo lo demás a parámetros. Luego bloquea esos parámetros e implementa los fragmentos para los estados navegacionales. Y solo al final, cuando el espacio ya está acotado, pon canonicals donde de verdad aporten.
Si empiezas por el canonical, que es lo que hace casi todo el mundo, acabas donde empezaba este artículo: con 340.000 URLs y una etiqueta muy bien puesta en cada una de ellas.
Dos cosas que puedes comprobar esta misma tarde: la proporción entre URLs que Google conoce y productos que tienes, y si tus combinaciones de filtros sin resultados devuelven 200 o 404. Con esas dos ya sabes si tienes un problema y de qué tamaño.
Cuándo te compensa pedir ayuda
Hazlo tú si tienes un catálogo mediano, pocas facetas y control sobre las plantillas. La política se puede escribir en una tarde y la implementación es de horas.
Busca ayuda cuando el número de URLs conocidas por Google se te haya ido de las manos, cuando haya varios idiomas con hreflang de por medio, cuando el buscador interno o el filtrado los gestione un servicio externo que no controlas, o cuando lleves tiempo publicando categorías nuevas y tarden semanas en indexarse. Ese último síntoma casi siempre es esto.
El siguiente paso
En Consultoría SEO Sevilla trabajamos la arquitectura del catálogo completa: qué facetas se publican, cómo se construyen las URLs, cómo se reparte el enlazado interno y cómo se controla el rastreo, con las tareas priorizadas y escritas para que tu equipo de desarrollo las pueda ejecutar sin traducciones.
Si tienes la sensación de que Google está gastando su tiempo en tus filtros en lugar de en tus productos, mira en qué consiste la auditoría SEO para ecommerce o escríbenos y le echamos un vistazo.
Y para seguir por aquí: menús en JavaScript: por qué Google puede no estar viendo tu navegación y análisis de logs: qué hace Googlebot de verdad en tu servidor.
