Google Storebot está comprando en tu tienda PrestaShop: lo que los comerciantes deben saber en 2026

Abre la cuadrícula Clientes → Carritos en el back office de PrestaShop y puede que encuentres algo alarmante: cientos de carritos sin nombre de cliente, sin dirección, sin transportista, solo un producto, una marca de tiempo y nada más. Día tras día, en un goteo constante, sin convertirse nunca en pedidos. Tu primera reacción puede ser pensar que algo está roto o que estás sufriendo un ataque. Ninguna de las dos cosas es cierta. En la mayoría de los casos, el responsable es un rastreador de Google llamado Storebot, y está haciendo exactamente aquello para lo que Google lo diseñó: comprar literalmente en tu tienda para comprobar que tus fichas de Google Shopping dicen la verdad.

Este artículo trata ese fenómeno concreto en PrestaShop. Qué es Storebot, cómo confirmar que es lo que está llenando tu tabla ps_cart (y no un bot que en realidad sí deberías bloquear), por qué bloquearlo es un error caro y qué hacer en su lugar. Lo hemos investigado de primera mano en varias tiendas PrestaShop activas en 2026, así que las rutas del back office, las estructuras de base de datos y los pasos de verificación que verás a continuación son reales, no explicaciones vagas.

Última actualización: junio de 2026.

Qué es realmente Storebot-Google

Storebot es un rastreador específico de Google, distinto del Googlebot que indexa páginas para la búsqueda orgánica. Su función es la verificación de comercio electrónico: carga una página de producto, lee el precio y la disponibilidad, y después prueba si un cliente real podría comprar el artículo añadiéndolo al carrito y avanzando hacia el pago. Renderiza JavaScript como un navegador real, algo importante en PrestaShop porque el tema predeterminado añade productos al carrito mediante AJAX.

Puedes reconocerlo por su agente de usuario, que contiene el token literal Storebot-Google:

Mozilla/5.0 (X11; Linux x86_64; Storebot-Google/1.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

En una visita típica carga la página de producto, lanza la solicitud de añadir al carrito (un POST gestionado por el CartController de PrestaShop. El controller_class es cart, independientemente de que tu URL localizada diga /cart, /panier o /warenkorb), comprueba que el total del carrito coincide con el precio de la página de producto, tantea los pasos de dirección y entrega para leer los gastos de envío y los impuestos, y luego se marcha sin hacer el pedido. Ese último paso es la razón por la que acabas con una montaña de carritos abandonados de una sola línea. Es verificación, no abandono en ningún sentido útil.

Por qué estos carritos tienen este aspecto en PrestaShop

La forma de estos carritos fantasma es específica y fácil de reconocer. Cuando los examinamos en tiendas en producción, todos los carritos de Storebot tenían la misma huella en ps_cart:

• id_customer = 0, ningún cliente conectado
• id_guest = 0, ninguna fila de sesión de invitado asociada
• id_carrier = 0 y id_address_delivery = 0, nunca llegaron a la selección de entrega
• secure_key = '', vacío

Hay una razón específica de PrestaShop por la que estos carritos llegan a crearse. CartController::updateCart lleva mucho tiempo comprobando $this->context->cookie->exists() antes de permitir que una acción de añadir al carrito modifique el carrito, una protección pensada precisamente para limitar este tipo de carrito fantasma (las ramas más recientes se apoyan más en una comprobación Connection::isBot()). En las tiendas que analizamos, el bot aun así pasaba porque una capa de caché de página completa (el add-to-cart dinámico por AJAX que utiliza) entregaba al bot una cookie sin id_guest. La propia fila de invitado normalmente solo se crea mediante un hook de estadísticas en la cabecera de la página; con caché de página completa, ese hook a menudo no se ejecuta, así que el front controller construye un carrito con id_guest = 0 y una clave segura vacía.

¿Y qué significa eso para ti? Dos cosas. Primero, la forma de invitado vacío es un efecto secundario de la caché, no una prueba de que sea un bot, lo que nos lleva directamente a la siguiente sección. Segundo, como no hay ninguna sesión de invitado asociada, la propia recuperación de carritos y la atribución de visitantes de PrestaShop se rompen silenciosamente para esas filas: no hay nadie a quien enviar un correo, nada que vincular a una sesión, y aun así siguen en tus tablas inflando todos los recuentos.

Primero, confirma que realmente es Storebot, no adivines

Este es el paso que omiten la mayoría de los consejos de “solo borra los carritos”, y es el que te protege de eliminar clientes reales. La forma de carrito con invitado vacío no es por sí sola un marcador fiable de bot. En una tienda PrestaShop con caché de página completa y una tabla ps_connections vacía, un comprador real sin cookies, por ejemplo, tráfico de anuncios de pago que llega con un gclid y sin cookie previa, produce un carrito huérfano idéntico. Si purgas solo por la forma, puedes borrar carritos abandonados reales y corromper tu propio embudo de recuperación.

Verifícalo contra el registro de acceso, no contra la tabla de carritos. Dos comprobaciones, en este orden:

• Agente de usuario + origen de IP. Busca las solicitudes que crearon los carritos en el registro de acceso real de tu servidor web (en nginx suele ser /var/log/nginx/access.log; ten en cuenta que los domlogs de Apache a menudo excluyen el tráfico proxy, así que comprueba el archivo correcto). Las solicitudes auténticas de Storebot proceden de rangos de Google, confirmamos visitas desde 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x y 192.178.11.x.
• DNS inverso confirmado hacia delante. No confíes solo en la IP ni en la cadena de UA, ambas pueden falsificarse. Ejecuta una consulta DNS inversa sobre la IP (las visitas reales de Google resuelven a *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), luego resuelve hacia delante ese nombre de host y confirma que devuelve la misma IP. Storebot-Google respeta robots.txt (consulta la última sección), y Google publica rangos de IP de rastreadores en su documentación oficial de IPs de rastreadores, revisa el archivo de la categoría de rastreador correspondiente para confirmar una IP verificada de Storebot, en lugar de asumir que una única lista lo cubre todo.

Si el UA afirma ser Storebot pero falla la confirmación inversa y directa de DNS, estás ante un impostor que se hace pasar por Google, y ese tráfico sí puedes tratarlo de otra manera. Los verificados debes mantenerlos.

Por qué bloquear Storebot es el error caro

La reacción tentadora, una regla de firewall, un Disallow en robots.txt, un 403 en la ruta del carrito para ese UA. Se vuelve en tu contra, y lo hace a través de un sistema que no controlas: Google Merchant Center.

• Bloquea el UA y tus productos pueden ser rechazados. La documentación de Google es explícita al indicar que permitir al rastreador acceder a tus páginas es “muy recomendable”. Si Storebot no puede verificar tu proceso de compra, tus artículos se arriesgan a rechazos por página de destino y discrepancias de precio, y desaparecen de los anuncios de Shopping y de las fichas gratuitas.
• Tampoco bloquees solo el POST del carrito. Permitir la lectura de páginas de producto pero bloquear el envío de añadir al carrito rompe exactamente aquello que Storebot existe para verificar, la coherencia del precio en el carrito, , que también es un motivo de rechazo.
• Nunca bloquees los rangos de IP en el firewall. Los rangos 66.249.* y 66.102.* se comparten con el Googlebot normal. Bloquéalos y también desindexarás tu tienda de la búsqueda orgánica, una pérdida mucho mayor que unas cuantas filas adicionales de carrito.

La forma honesta de verlo: la visita de Storebot es una auditoría gratuita que confirma que tus fichas son correctas, y las fichas correctas se muestran con más frecuencia. Te conviene que rastree. El problema que hay que resolver no es el rastreador. Son los residuos que deja atrás.

El coste real: los carritos de bot están falseando tus analíticas

Los carritos fantasma no son solo desorden. En silencio, contaminan las cifras con las que tomas decisiones:

• Tu tasa de abandono es ficción. Si Storebot crea siete carritos por hora y casi ninguno convierte, la tasa carrito-pedido del back office parece mucho peor que la realidad. Vimos periodos en los que los carritos de bot superaban a los carritos reales por varios a uno durante unos pocos días.
• Las tablas ps_cart y ps_cart_product crecen sin límite, y en alojamientos con recursos de base de datos modestos ese lastre acaba apareciendo en consultas lentas del carrito y de administración.
• Las automatizaciones de recuperación desperdician esfuerzo. Como estas filas no tienen un cliente real ni una sesión utilizable, cualquier proceso de recuperación de carritos o bien las omite (el mejor caso) o consume recursos intentando actuar sobre un contacto que no existe.

Decidir qué carritos son bots y cuáles son reales, antes de confiar en cualquier cifra de conversión, es la misma disciplina que sostiene toda medición de una tienda, saber qué contar y qué ignorar. Tratamos esa mentalidad en analítica para tiendas online: qué medir y qué ignorar, y la versión específica para GA4 de cómo filtrar este ruido en las métricas de GA4 que realmente importan.

Qué hacer en su lugar: conserva el rastreador, limpia los residuos

1. Asegúrate de que Storebot encuentra exactamente lo que prometía tu feed

La medida más eficaz es ofrecer al rastreador una verificación limpia, para que su visita pase la prueba y no dispare nada. Feed, datos estructurados, página de producto, carrito y checkout deben coincidir en precio (incluidos impuestos y moneda) y disponibilidad. En PrestaShop, eso significa que tu módulo de feed lee precios y stock en vivo, y que tus páginas de producto incluyen marcado schema.org/Product correcto con price, priceCurrency, availability y brand. Si envías fichas mediante la Merchant API, confirma que tu módulo de feed admite v1, la antigua Content API for Shopping se retirará en 2026, así que un módulo de feed obsoleto es una fuente latente de discrepancias.

2. Haz bien las páginas de productos sin stock

Google espera que una página de producto sin stock muestre claramente que no está disponible, impida la compra y que la disponibilidad coincida exactamente con tu feed y tus datos estructurados. Un botón de compra visiblemente desactivado (en gris, con el atributo HTML disabled) es una implementación aceptable, siempre que se mantenga coherente con tu feed y con la disponibilidad del schema. Muchos temas de PrestaShop, en cambio, ocultan por completo el botón de añadir al carrito cuando el stock llega a cero, revisa el product.tpl / la plantilla de producto de tu tema. Storebot lo comprueba directamente: no debería poder añadir un artículo sin stock, y sí debe poder añadir uno con stock.

3. Limpia los carritos de bot de forma programada, pero protege el borrado

La limpieza periódica es la solución práctica para la hinchazón de la base de datos, y los carritos son identificables: id_customer = 0, id_guest = 0 (o una fila de invitado que lleva un UA de Storebot), id_carrier = 0, id_address_delivery = 0, creados desde una IP verificada de Google. La parte protegida importa tanto como la coincidencia: antes de borrar, confirma que el carrito no tiene ningún pedido asociado, ningún cliente, ninguna dirección y (según la sección anterior) que fue creado por una IP de Storebot confirmada mediante DNS inverso y directo, nunca solo por su forma.

Una trampa muy concreta de PrestaShop si escribes tu propio SQL o cron de limpieza: PrestaShop escribe sus valores date_add usando el reloj de PHP, no el de MySQL. En un alojamiento donde la zona horaria de la base de datos difiere de la de PHP, un filtro de antigüedad construido sobre NOW() / DATE_SUB(NOW(), ...) puede interpretar todos los carritos como recién activos y no purgar nada en silencio (o purgar las filas equivocadas). Calcula el corte desde el reloj de la aplicación y elimina siempre las filas correspondientes de ps_cart_product junto con las filas de ps_cart para no dejar líneas de carrito huérfanas.

4. Mantén los carritos de bot fuera de tus informes y recuperaciones

Tu cifra real de abandono es la que se calcula solo a partir de carritos con un cliente real o una sesión de invitado identificada. Excluye los carritos anónimos de bots verificados de tu embudo de conversión, y asegúrate de que cualquier automatización de recuperación de carritos los filtra para que no actúe sobre filas que nunca fueron una persona. Esa misma separación te permite por fin informar de una tasa carrito-pedido real en lugar de una inflada por Storebot, el tipo de cifra limpia y orientada al propietario que debe formar parte de los informes avanzados de tu tienda.

5. Recorta el rastreo no comercial con robots.txt (no toques producto ni carrito)

Puedes reducir el rastreo desperdiciado sin poner en peligro la verificación dirigiendo a Storebot fuera de las URLs que no tienen valor comercial, nunca las páginas de producto ni la propia ruta del carrito:

User-agent: Storebot-Google, después Disallow: /*?order=, Disallow: /*?utm_ y finalmente Allow: / para que todo lo demás, incluidas las páginas de producto y la ruta del carrito, siga siendo rastreable.

Hacer todo esto sin desarrollador: Spam Cart Blocker

El flujo de verificar y luego purgar con seguridad que acabamos de describir es correcto, pero hacerlo a mano, análisis de logs, confirmación DNS inversa y directa, cron seguro frente a zonas horarias, borrados protegidos que nunca toquen un pedido real, exige mucho mantenimiento. Creamos Spam Cart Blocker para nuestras propias tiendas precisamente porque las alternativas disponibles lo hacían peligrosamente mal: los pocos módulos de este ámbito o bien bloquean los carritos de bot (lo que, como hemos explicado, puede acabar con tus productos suspendidos en Merchant Center) o hacen borrados bruscos basados en antigüedad sin saber si un carrito era de un bot o de un comprador real sin cookies.

¿Y qué hace por ti? Clasifica los carritos comprobando la identidad del rastreador con DNS inverso confirmado hacia delante, de modo que un Storebot verificado se reconoce y un impostor que falsifica el UA no, , luego etiqueta y purga por TTL los carritos de bot auténticos dejando intacto todo lo que tenga pedido, cliente, dirección o sesión real. Nunca bloquea a Google, así que tus fichas siguen a salvo. Repara la creación de invitados rota bajo caché de página completa para que la atribución real de carritos vuelva a funcionar. Y muestra la verdad en el back office: un desglose bot frente a humano de tus carritos y tu tasa real de carritos abandonados, además de inteligencia de carrito por visitante, todo configurado desde la administración, sin overrides del core, para que sobreviva a las actualizaciones. En resumen, convierte la investigación manual de este artículo en una opción que marcas una vez.

Preguntas frecuentes

¿Por qué se está llenando mi tabla de carritos de PrestaShop con carritos vacíos que nunca convierten?

En la mayoría de los casos es Storebot-Google, un rastreador específico de Google, distinto del Googlebot que indexa páginas, verificando que tus fichas de Google Shopping dicen la verdad. Carga una página de producto, añade el artículo al carrito para comprobar que el precio coincide, tantea el paso de entrega para leer envío e impuestos, y luego se marcha sin hacer el pedido. Cada visita deja un carrito de una sola línea con id_customer = 0, id_guest = 0, id_carrier = 0 y una clave segura vacía. Es verificación, no abandono.

¿Debería bloquear Storebot para detener los carritos fantasma?

No. Ese es el error caro. La documentación de Google es explícita al indicar que permitir al rastreador acceder a tus páginas es muy recomendable. Bloquea el agente de usuario, el POST del carrito o (lo peor de todo) los rangos de IP, y tus productos se arriesgan a rechazos por página de destino y discrepancias de precio en Merchant Center, además de desaparecer de los anuncios de Shopping y de las fichas gratuitas. Los rangos 66.249.* y 66.102.* se comparten con el Googlebot normal, así que un bloqueo de firewall también te desindexa de la búsqueda orgánica. Conserva el rastreador; limpia los residuos.

¿Cómo confirmo que un carrito lo creó el Storebot real y no un comprador real?

Verifícalo contra el registro de acceso, no contra la tabla de carritos, la forma de invitado vacío por sí sola no es un marcador fiable de bot, porque un comprador real sin cookies que llega con un gclid bajo caché de página completa produce un carrito huérfano idéntico. Comprueba el agente de usuario y la IP de origen en el registro de acceso de tu servidor web, y luego ejecuta una comprobación de DNS inverso confirmado hacia delante: la IP debería resolver a un nombre de host *.google.com / google-proxy-* que, al resolverse hacia delante, devuelva la misma IP. Si falla, es un impostor que se hace pasar por Google.

¿Cuál es la trampa específica de PrestaShop al escribir SQL de limpieza para carritos de bot?

La zona horaria. PrestaShop escribe date_add usando el reloj de PHP, no el de MySQL. En un alojamiento donde la zona horaria de la base de datos difiere de la de PHP, un filtro de antigüedad basado en DATE_SUB(NOW(), ...) puede evaluar mal todos los carritos y no purgar nada en silencio, o purgar las filas equivocadas. Calcula el corte desde el reloj de la aplicación, elimina siempre las filas correspondientes de ps_cart_product junto con las filas de ps_cart, y protege el borrado para que nunca toque un carrito con pedido, cliente o dirección.

¿Puedo recortar el rastreo de Storebot sin poner en peligro la verificación?

Sí, aléjalo solo de URLs no comerciales, nunca de las páginas de producto ni de la ruta del carrito. Un bloqueo seguro en robots.txt apunta a URLs con parámetros sin valor comercial:

User-agent: Storebot-Google
Disallow: /*?order=
Disallow: /*?utm_
Allow: /

Recuerda que Disallow detiene el rastreo de esas URLs, no la indexación de páginas enlazadas desde otros lugares. Es una herramienta de presupuesto de rastreo, no un control de indexación. Mantén las páginas de producto y la ruta del carrito totalmente rastreables para que la verificación siga pasando.

Hacerlo de forma segura sin desarrollador

El flujo de verificar y luego purgar anterior, análisis de logs, DNS inverso confirmado hacia delante, cron seguro frente a zonas horarias, borrados protegidos, exige mucho mantenimiento manual. Spam Cart Blocker clasifica los carritos comprobando la identidad del rastreador (de modo que un Storebot verificado se reconoce y un impostor que falsifica el UA no), purga por TTL los carritos de bot auténticos dejando intacto todo lo que tenga pedido, cliente o sesión real, nunca bloquea a Google y muestra tu tasa real de carritos abandonados en el back office. Si tu tienda ya está enterrada bajo carritos de bot, nuestro Cleanup Revolution se encarga de la limpieza programada de la base de datos, y Google Analytics GA4 mantiene honestas las cifras de conversión una vez filtrado el ruido del rastreador.

Mirando al futuro: Storebot es el principio, no el final

El rastreo de Storebot está aumentando, no desapareciendo, porque Google avanza hacia agentes de compra con IA que actúan en nombre del cliente, verificando precios, comprobando stock y, potencialmente, completando compras a través de tu checkout. Sea cual sea tu opinión sobre esa dirección, la implicación práctica para un comerciante PrestaShop es la misma que este artículo ha defendido de principio a fin: las tiendas cuyo feed, datos estructurados, páginas de producto y carrito cuentan una historia coherente son aquellas en las que un rastreador. Dirigido por humanos o por agentes, puede confiar. Las que tienen discrepancias de precio, botones de sin stock ocultos y una tabla ps_cart llena de basura sin examinar se filtran antes de que un comprador llegue a verlas.

Así que la conclusión no es “borra los carritos raros”. Es: confirma qué son, da la bienvenida a la verificación que mantiene tus fichas activas y limpia después de ella según las reglas de PrestaShop, borrados protegidos, cron correcto en zona horaria y analíticas que cuenten personas en lugar de rastreadores. Hazlo bien y Storebot dejará de ser un misterio en tu base de datos para convertirse en lo que siempre debió ser: una auditoría gratuita y continua que confirma que tu tienda está lista para vender.