Robots.txt para eCommerce: reglas y plantillas 2026

Si vendes online, tu robots.txt es como el portero del edificio: no decide qué “vive” dentro (eso lo hace la indexación), pero sí decide quién puede entrar a mirar. Y en un eCommerce, dejar la puerta abierta suele significar que Google se pasa el día rastreando variantes infinitas (filtros, paginación, parámetros, ordenaciones) mientras tarda más en descubrir productos nuevos o cambios de stock.

En esta guía (actualizada a 4 de marzo de 2026) tienes reglas seguras, plantilla robots.txt por plataforma (Shopify, WooCommerce y PrestaShop), y una estrategia práctica para bloquear parámetros URL sin cargarte el SEO. Si quieres que lo dejemos implementado y automatizado (con validación y monitorización), puedes ver nuestra consultoría SEO orientada a eCommerce.

1. Qué SÍ y qué NO debes bloquear en un eCommerce

El error más frecuente con robots.txt ecommerce es usarlo como “papelera”: bloquear todo lo que parece duplicado… y terminar bloqueando recursos, rutas o plantillas que Google necesita para entender el sitio. Recuerda dos principios:

• Robots.txt controla rastreo, no indexación. Si una URL está enlazada externamente o internamente, puede indexarse aunque esté bloqueada (apareciendo como “URL bloqueada por robots.txt” con poca información). Para desindexar, usa noindex, canonicals, o control de enlaces internos.
• No bloquees lo que necesitas que Google renderice. Bloquear CSS/JS o endpoints que afectan a la renderización puede hacer que Google “vea” una página incompleta y afecte a calidad percibida, layout y señales.

Qué SÍ suele ser buena idea bloquear (según plataforma y arquitectura):

• Búsqueda interna (p. ej. /search, ?s=). En eCommerce genera combinaciones infinitas y suele aportar poco valor.
• Carrito, checkout y área de cuenta (privado/no indexable, además de evitar rastreo inútil).
• Parámetros técnicos o de tracking (utm, gclid, fbclid, etc.) a través de otras estrategias (canonicals y limpieza de enlaces). En robots.txt se puede bloquear por patrón en algunas plataformas, pero no siempre es la mejor primera opción.
• URLs de sesión, vistas previas, rutas de admin, endpoints internos.
• Facetas/filtros si generan miles de combinaciones y no hay una estrategia de indexación selectiva (más abajo explico la forma “sin riesgos”).

Qué NO deberías bloquear en la mayoría de eCommerce modernos:

• CSS y JS necesarios para renderizar (o rutas donde sirves assets). Hoy Google renderiza mucho, y bloquear recursos suele ser contraproducente.
• Categorías y productos (obvio, pero ocurre cuando se bloquea por patrones demasiado agresivos).
• Imágenes si te interesa Google Images/Discover (en eCommerce aporta tráfico transaccional). Si necesitas controlar consumo, mejor optimizar en rendimiento web y CDN antes que bloquear rastreo.
• APIs o endpoints que el renderizado use para cargar contenido principal (depende del stack).

Una regla práctica: bloquea “acciones” (carrito, login, buscar) y controla “variantes” (filtros, ordenaciones, paginación) con una mezcla de robots.txt + canonicals + noindex + enlaces internos. Si quieres un enfoque operativo, en nuestro método lo tratamos como un proyecto de control de demanda de rastreo: qué rastrear, con qué prioridad, y cómo medirlo.

Errores comunes (evítalos):

• Bloquear /collections/ o /category/ por confusión al intentar bloquear filtros.
• Bloquear /wp-content/ o assets y romper renderizado o recursos críticos.
• Creer que “Disallow = no index” y terminar con URLs indexadas sin contenido (mal snippet, mala calidad).
• Bloquear facetas sin antes revisar si hay facetas que sí convierten y merecen indexarse (por ejemplo “zapatillas running mujer” como filtro clave).

2. Plantillas robots.txt por plataforma (Shopify/Woo/PS)

Aquí tienes una plantilla robots.txt por plataforma con reglas típicas y seguras. Importante: toma esto como base. La configuración ideal depende de tu estructura real (rutas, idioma, apps, módulos, facetas) y de si quieres indexar ciertas páginas filtradas.

Shopify (robots.txt.liquid)

Desde hace tiempo Shopify permite editar robots.txt.liquid. Shopify ya incluye reglas por defecto; lo correcto suele ser ajustar, no reinventar. En general, conviene bloquear búsqueda interna y algunas rutas de sistema, pero no tocar rutas de producto/colección.

User-agent: *
Disallow: /search
Disallow: /cart
Disallow: /checkout
Disallow: /account
Disallow: /orders
Disallow: /carts
Disallow: /wallets
Disallow: /apps

# Si usas parámetros agresivos de filtros creados por apps, evalúa caso a caso
# Disallow: /*?*sort_by=
# Disallow: /*?*filter.

Sitemap: https://TU-DOMINIO.com/sitemap.xml

Notas Shopify 2026: muchas apps de filtros generan parámetros (p. ej. filter.v.option=) o rutas. Antes de bloquear por patrón, revisa si Shopify ya canoniza y si tus páginas filtradas tienen potencial SEO. Si necesitas un plan de “indexación selectiva” de facetas, es más estable trabajar con canonicals, noindex en facetas no objetivo y una arquitectura de colecciones “SEO” creadas ad hoc.

WooCommerce (WordPress)

WooCommerce hereda el ecosistema WordPress: hay rutas previsibles (admin, feeds, parámetros de búsqueda). Aquí el riesgo típico es bloquear demasiado y romper recursos o impedir rastreo útil.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /?s=
Disallow: /search/

# Parámetros típicos de ordenación / capas (depende del tema y plugins)
# Disallow: /*?orderby=
# Disallow: /*?min_price=
# Disallow: /*?max_price=
# Disallow: /*?filter_

Sitemap: https://TU-DOMINIO.com/sitemap_index.xml

Notas Woo 2026: muchos sitios con filtros usan parámetros tipo ?filter_color= o taxonomías en ruta. Si usas plugins SEO (Yoast/Rank Math), el sitemap suele estar en sitemap_index.xml. Asegúrate de no bloquear rutas donde se sirven assets (por ejemplo /wp-content/ no debería bloquearse salvo casos muy controlados).

PrestaShop

PrestaShop varía por versión y módulos, pero hay patrones comunes: páginas de carrito/checkout, login, búsquedas y parámetros. La recomendación es mantenerlo simple y no intentar “tapar” todos los duplicados desde robots.

User-agent: *
Disallow: /carrito
Disallow: /pedido
Disallow: /order
Disallow: /mi-cuenta
Disallow: /autenticacion
Disallow: /login
Disallow: /busqueda
Disallow: /*?controller=

# Si tu módulo de filtros genera parámetros, evalúa bloquearlos solo si no vas a indexarlos
# Disallow: /*?q=
# Disallow: /*&page=

Sitemap: https://TU-DOMINIO.com/index.php?controller=sitemap

Notas PrestaShop 2026: según friendly URLs y módulos, algunas rutas cambian. Comprueba el sitemap real y el idioma (p. ej. /es/, /fr/) antes de copiar/pegar. Si tu tienda es multidioma, revisa que el sitemap declarado corresponda al índice correcto.

Si quieres que revisemos tu robots.txt y además lo conectemos con monitorización (cambios de plantilla, nuevas facetas, apps que generan parámetros), en SEOAGIL solemos integrarlo con procesos de auditoría técnica y automatización.

3. Parámetros, filtros y paginación: estrategia sin riesgos

El punto delicado del robots.txt ecommerce no es bloquear carrito o login: es decidir qué hacer con parámetros URL, filtros por atributos y paginación. Si lo haces mal, puedes:

• impedir que Google descubra productos (si la paginación o el listado depende de parámetros),
• generar indexación masiva de duplicados (si lo dejas todo abierto),
• o provocar “soft 404” y mala calidad de indexación.

Estrategia recomendada (2026) para bloquear parámetros URL sin romper SEO:

1. Define qué facetas deben ser indexables (solo un subconjunto). Ejemplo: “zapatillas trail” (categoría) + “mujer” (faceta) puede merecer una landing indexable si hay demanda y catálogo suficiente. El resto, no.
2. Para facetas NO indexables: usa canonical hacia la categoría madre + (si aplica) noindex,follow. Evita depender solo de robots.txt, porque robots bloquea el rastreo y puede impedir que Google vea el canonical/noindex.
3. Para facetas SÍ indexables: crea landings estables (idealmente URLs limpias) y enlázalas desde navegación o bloques SEO; incluye contenido único y controla el facetado para evitar combinaciones infinitas.
4. Para parámetros de tracking: evita generarlos en enlaces internos; canoniza hacia la URL limpia. Si proliferan por campañas, no hace falta bloquearlos en robots si el canonical está bien y el sitio no enlaza esos parámetros internamente.
5. Para paginación: no bloquees ?page= a ciegas. Primero confirma si tu plataforma usa paginación con parámetros o con ruta (/page/2). La paginación suele ser necesaria para descubrir productos profundos. Mejor controlar indexación vía canonical y enlaces internos que bloquear el rastreo.

Cuándo sí tiene sentido bloquear patrones de parámetros en robots.txt: cuando sabes que son variantes infinitas que no aportan nada y además generan mucho consumo de rastreo (ej.: combinaciones de ordenación + filtros + vista). Aun así, hazlo de forma gradual y medible.

Ejemplos de patrones habituales (usa solo los que existan en tu web):

• Ordenación: orderby, sort, sort_by.
• Rango de precios: min_price, max_price.
• Filtros por atributo: filter_, q= (algunos módulos), o parámetros tipo filter.v. en Shopify.
• Vistas/plantillas: view=, output=.

Mini-caso práctico (típico): una categoría con 40.000 URLs rastreadas por filtros, pero solo 200 páginas útiles (categorías y productos). La solución más estable suele ser: (1) enlazado interno limpio, (2) canonicals y noindex en facetas no objetivo, (3) bloquear solo los parámetros más tóxicos (ordenación + combinadores) y (4) revisar sitemaps para que solo incluyan URLs indexables.

Si quieres automatizar la detección de parámetros que explotan (por logs, GSC o crawling recurrente) y generar reglas y alertas, es un tipo de proyecto que encaja con nuestra consultoría SEO para eCommerce y automatización.

4. Conclusión: checklist final y validación en Search Console

Un robots.txt correcto es el que reduce ruido sin bloquear valor. Antes de publicar cambios, aplica una checklist y valida en Search Console para evitar sustos (caídas por bloqueo accidental, sitemaps inconsistentes, o rastreo desperdiciado).

Checklist práctica (antes de desplegar):

• Inventario de plantillas: lista tus tipos de URL (home, categorías, productos, blog, búsqueda, carrito, cuenta, filtros, paginación).
• Decisión por tipo: para cada tipo, define “indexable / no indexable” y “rastreo necesario / no necesario”.
• Recursos: confirma que no bloqueas CSS/JS críticos ni endpoints necesarios para render.
• Sitemaps: el sitemap debe incluir solo URLs que quieres indexar (y que sean 200 OK).
• Facetas: define si habrá facetas indexables (pocas, controladas) y el resto con canonical/noindex.
• Parámetros: elimina parámetros en enlaces internos cuando sea posible; evita que navegación genere UTM internos.
• Pruebas: valida con un entorno de staging o un despliegue controlado.

Validación en Google Search Console (pasos):

1. Inspección de URL: prueba una categoría y un producto clave. Confirma que “Rastreo permitido” es Sí y que Google puede recuperar la página.
2. Prueba de robots.txt: si tu propiedad lo permite, verifica reglas y patrones para varias URLs representativas (categoría con filtros, búsqueda, carrito).
3. Informe de páginas: revisa “Bloqueada por robots.txt”. Si aparecen URLs valiosas, corrige inmediatamente.
4. Rastreo (estadísticas): tras el cambio, observa durante días/semanas si baja el volumen de rastreo en URLs inútiles y mejora el descubrimiento de URLs nuevas.
5. Sitemaps: reenvía sitemap si has cambiado qué URLs deben estar dentro.

Errores comunes en esta fase:

• Subir robots.txt y olvidarse del sitemap: el rastreo baja, pero Google sigue viendo URLs no deseadas desde el sitemap antiguo.
• Bloquear paginación que el crawler necesita para descubrir productos profundos.
• Bloquear facetas y perder control del canonical/noindex (porque Google ya no puede rastrear esas páginas para ver las señales).
• No medir: cambiar reglas sin observar impacto en rastreo, indexación e ingresos orgánicos.

Bien implementado, robots.txt te ayuda a que Google “invierta” su tiempo donde importa: categorías que convierten, productos disponibles y contenido útil. Si quieres una revisión técnica completa (robots, sitemaps, facetas, CWV y tracking), puedes ver nuestro enfoque en desarrollo web y optimización SEO.

Preguntas frecuentes

¿Bloquear en robots.txt elimina una URL del índice de Google?

No necesariamente. Robots.txt impide el rastreo, pero una URL puede permanecer indexada si Google la conoce por enlaces o por histórico. Para desindexar, usa noindex (si es rastreable), canonicals correctos o elimina la URL (404/410) según el caso.

¿Debo bloquear filtros y facetas en un eCommerce?

Depende. La mejor práctica es indexación selectiva: unas pocas facetas estratégicas (con demanda y catálogo) pueden ser landings SEO; el resto debería controlarse con canonical/noindex y una navegación que no genere combinaciones infinitas. Bloquear todo en robots.txt suele ser demasiado agresivo.

¿Qué pasa si bloqueo /checkout o /cart?

Normalmente es seguro y recomendable para evitar rastreo inútil. No afecta a la compra (los usuarios no dependen de Googlebot), pero sí evita que Google pierda tiempo en páginas sin valor SEO.

¿Es obligatorio incluir el Sitemap en robots.txt?

No es obligatorio, pero es una buena práctica. Declararlo ayuda a que los bots encuentren el sitemap más rápido, especialmente si tienes múltiples sitemaps o un índice.

¿Cómo sé si estoy desperdiciando crawl budget por parámetros?

Revisa en Search Console los informes de rastreo e indexación (URLs descubiertas, rastreadas y excluidas) y, si puedes, analiza logs del servidor. Señales típicas: muchas URLs con parámetros en “Rastreada: actualmente sin indexar”, “Duplicada” o picos de rastreo en patrones de filtros/ordenación.