Por qué los filtros de categoría (faceted navigation) te consumen el crawl budget
Cualquier combinación de filtros en una página de categoría — talla, color, precio, marca — puede generar su propia URL. En un catálogo pequeño, unas cuantas decenas de combinaciones no importan. En un catálogo con miles de productos y cinco o seis filtros disponibles a la vez, el número de URL posibles se dispara, y la mayoría no tiene ningún valor de búsqueda propio — son los mismos productos, solo reordenados. La documentación de Google sobre la navegación por facetas describe exactamente este patrón como una de las causas más frecuentes de quejas relacionadas con el rastreo: el buscador pierde tiempo rastreando de nuevo variaciones casi idénticas, en lugar de descubrir páginas nuevas o actualizadas.
La consecuencia práctica no es una «penalización», sino algo menos visible: las páginas que de verdad importan — categorías nuevas, productos nuevos — se descubren y reindexan más despacio, porque el presupuesto de rastreo del sitio se va a otra parte.
- 01Excluye las combinaciones de filtros de los enlaces internos rastreables conecta la navegación por filtros mediante JavaScript o parámetros bloqueados, no mediante href normales e indexables.
- 02Mantén un patrón de URL limpio para cada filtro los parámetros inconsistentes (orden distinto, mayúsculas/minúsculas) crean duplicados adicionales sin ningún beneficio.
- 03No bloquees a ciegas todo desde robots.txt un bloqueo demasiado agresivo puede ocultar también combinaciones de filtros con volumen de búsqueda real, como «zapatos talla 40».
Canonical correcto para las variantes de producto (talla, color, envase)
Un problema distinto al de los filtros es el producto con variantes — la misma camisa en tres colores, el mismo detergente en dos formatos. Aquí el error típico es el inverso: o cada variante tiene su propia URL sin ningún vínculo canónico entre ellas, o todas las variantes se fuerzan hacia una única URL «canónica», incluso cuando la gente busca exactamente «bolso negro», no solo «bolso». Según la documentación de Google sobre la consolidación de URLs duplicadas, las señales más fuertes para elegir una página canónica son, en orden, la redirección, después la etiqueta rel=canonical, después la inclusión en el sitemap — y las señales se pueden combinar para un resultado más claro.
La regla práctica: si una variante tiene demanda de búsqueda propia y contenido lo bastante diferente (foto, descripción, precio), merece la pena indexarla por separado, con su propio canonical hacia sí misma. Si las variantes son intercambiables desde la perspectiva del comprador, un canonical hacia la variante principal evita diluir la señal entre páginas casi idénticas. WooCommerce trata las variantes como subobjetos de un producto padre; Shopify puede exponerlas como URLs separadas — comprueba qué hace por defecto tu plataforma antes de suponer que ya está bien configurado.
La descripción de las páginas de categoría: qué contenido ayuda de verdad
Una página de categoría sin ningún texto único — solo una cuadrícula de productos — resulta, desde la perspectiva de un buscador, difícil de diferenciar de decenas de otras páginas similares del mercado. No hace falta un ensayo por encima de los productos; hace falta un par de frases que expliquen, con las palabras reales del comprador, qué encuentra en esa página y en qué se diferencia de la categoría vecina. La documentación de WooCommerce sobre la organización de productos y la sección de arquitectura del sitio de la guía de SEO de Shopify van en la misma dirección: la estructura de categorías debería reflejar cómo piensa el cliente, no cómo está organizado el almacén interno.
Una prueba sencilla: si puedes mover el texto de una página de categoría a otra sin ningún cambio, el texto no dice nada específico. Menciona en concreto qué diferencia a la categoría — material, ocasión de uso, rango de precio habitual — no adjetivos genéricos como «calidad premium», que no ayudan ni al lector ni al buscador a distinguir una página de otra.
Los datos estructurados Product, Offer y AggregateRating, rellenados correctamente
Los datos estructurados de tipo producto son la forma de decirle explícitamente a un buscador qué precio tiene un producto, si está en stock y qué valoración tiene, en lugar de dejar que esa información se deduzca del texto. Según la documentación de Google sobre datos estructurados de tipo producto, los resultados enriquecidos para productos solo se admiten en páginas centradas en un único producto (o en las variantes de ese mismo producto) — no en páginas de listado o de categoría genérica.
Los tres bloques que más importan son el nombre y la imagen del producto, la oferta (Offer, con precio, moneda y disponibilidad actualizados correctamente) y, si existen reseñas reales, la valoración agregada (AggregateRating). El error técnico más frecuente no es la ausencia total de la schema, sino su desincronización: el precio mostrado visualmente en la página difiere del que aparece en la schema, o la disponibilidad sigue en «in stock» después de que el producto se haya agotado. Una valoración inventada o inflada artificialmente es un problema distinto, de confianza, no solo técnico — no rellenes AggregateRating si no tienes reseñas reales detrás.
Los datos estructurados no crean confianza de la nada — solo transmiten con más claridad una información que, de todos modos, debe ser correcta y estar actualizada en la página.
Core Web Vitals en la página de producto: qué se mide, qué se optimiza
La página de producto (PDP) es, normalmente, la página más cargada de una tienda — galería de imágenes, selector de variantes, reseñas, productos recomendados. Según la documentación de Google sobre Core Web Vitals, las tres métricas que se siguen son el tiempo de carga del elemento visible más grande (LCP, por debajo de 2,5 segundos), el tiempo de respuesta a la interacción (INP, por debajo de 200 milisegundos) y la estabilidad visual de la página durante la carga (CLS, por debajo de 0,1).
En una ficha de producto, el LCP es casi siempre la imagen principal — comprímela, sírvela en un formato moderno (WebP o AVIF) y no la cargues de forma diferida (lazy load), porque es lo primero que debe ver el visitante. El CLS suele aparecer por banners de promoción que se cargan tarde y empujan el contenido, o por selectores de talla que cambian de tamaño después de cargar. El INP sufre más cuando el botón «añadir al carrito» espera a scripts de terceros pesados — chat, recomendaciones, tracking — que bloquean el hilo principal de ejecución.
- 01Imágenes secundarias de la galería a diferencia de la imagen principal, estas pueden cargarse de forma diferida (lazy load) sin afectar al LCP.
- 02Texto alternativo descriptivo, no una ristra de palabras clave «chaqueta impermeable hombre, gris, talla L» es útil; repetir la misma palabra clave cinco veces en el texto alternativo no ayuda y puede tratarse como spam.
- 03Dimensiones explícitas para cada imagen la falta de los atributos width/height es la causa típica de CLS en las imágenes que se cargan más tarde.
Por qué el blog debe enlazar hacia categorías, no solo hacia la página principal
Un artículo de blog que compara «las mejores bolsas para portátil para el trayecto diario» y no enlaza, desde el texto, hacia la categoría real de bolsas para portátil desperdicia precisamente el tipo de enlace interno que más importa para un catálogo grande: uno que transmite autoridad y contexto temático directamente hacia una página que puede vender. El enlace hacia la página principal no hace eso — la página principal ya es, por lo general, la página mejor enlazada del sitio.
En la práctica, cada artículo nuevo del blog debería identificar dos o tres categorías o productos relevantes del catálogo y enlazar hacia ellos con texto de anclaje descriptivo, no genérico («ver aquí»). En un catálogo grande, esto es también un mecanismo de descubrimiento: las categorías enterradas en lo profundo de la estructura acaban rastreándose de nuevo con más frecuencia si reciben enlaces frescos desde contenido nuevo, no solo desde el menú de navegación estático.
Producto agotado o retirado de la venta: 410, redirección o página conservada
Las dos situaciones se tratan de forma distinta, y la confusión entre ellas produce la mayoría de las decisiones equivocadas. Un producto agotado temporalmente, que va a volver al stock, debería permanecer en su página, con la disponibilidad actualizada correctamente en la schema de producto (out of stock o preventa), no eliminado del sitio. Borrar la página por una rotura de stock temporal tira precisamente esa URL que ya tenía historial y, posiblemente, posicionamiento ganado.
Un producto retirado definitivamente de la venta es otra discusión. Si existe un sustituto claro — misma categoría, modelo actualizado — una redirección hacia ese producto es la señal de consolidación más fuerte que puedes dar, según la jerarquía de señales de la documentación de Google sobre URLs canónicas. Si no existe ningún sustituto real, forzar una redirección hacia una página sin relación (a menudo la página principal, por reflejo) crea una mala experiencia y una señal confusa; una página clara de «producto no disponible definitivamente», con recomendaciones reales de productos similares, es más útil que cualquier redirección forzada.
Qué suele romperse en una migración de plataforma
Muchos de los problemas anteriores se vuelven visibles de golpe en el momento de una migración — de una plataforma a otra, o solo de un patrón de URL a otro. La estructura de categorías cambia, las variantes de producto adquieren otro patrón de URL, la schema de producto puede faltar por completo en el tema nuevo hasta que se configura de nuevo, y sin un mapeo completo de redirecciones, todo el historial de enlaces y posicionamiento acumulado en las URL antiguas se pierde de golpe, no poco a poco.
El tema es lo bastante amplio como para merecer un tratamiento aparte — el plan de redirecciones, el mapeo de URLs y las lecciones de un replatforming real están detallados en la guía dedicada a migrar una tienda online sin perder el SEO acumulado. Si quieres que la lista se aplique a tu tienda, consulta SEO para tiendas online.
Fuentes y lecturas.
- 01Google Search Central — Crawling December: Faceted navigation
- 02Google Search Central — Consolidación de URLs duplicadas (rel=canonical)
- 03Google Search Central — Intro to Product Structured Data
- 04Google Search Central — Understanding Core Web Vitals
- 05Shopify Help Center — Improving search engine optimization (SEO)
- 06WooCommerce Docs — Products
Preguntas frecuentes
¿Qué es la faceted navigation y por qué afecta al SEO de una tienda online?
Es el mecanismo de filtrado en páginas de categoría (talla, color, precio), que puede generar un número muy alto de combinaciones de URL. Cada combinación consume presupuesto de rastreo del sitio, lo que significa que las páginas importantes — productos y categorías nuevas — se descubren y reindexan más despacio.
¿Tengo que poner rel=canonical en cada variante de producto?
No automáticamente. Si una variante (color, talla) tiene demanda de búsqueda propia y contenido lo bastante diferente, indexarla por separado, con canonical hacia sí misma, puede ser correcto. Si las variantes son prácticamente intercambiables, un canonical hacia la variante principal evita diluir la señal entre páginas casi idénticas.
¿Hacen falta reseñas reales para usar AggregateRating en la schema de producto?
Sí. AggregateRating debe reflejar reseñas reales, presentes en la página. Rellenarlo con valores inventados o inflados artificialmente es un problema de confianza, no solo una cuestión técnica, y puede afectar a la elegibilidad para los resultados enriquecidos.
¿Qué hago con un producto agotado para no perder el posicionamiento ya ganado?
Si el agotamiento es temporal, mantienes la página y actualizas la disponibilidad en la schema de producto, sin borrarla. Si el producto se retira definitivamente de la venta y existe un sustituto claro, una redirección hacia ese producto consolida la señal mejor que borrar la página.
Veamos qué se puede automatizar en tu empresa.
Una sesión gratuita de 30 minutos: te decimos qué se puede automatizar, cuánto se tarda y cuánto cuesta, con precio fijo tras el discovery.