Cómo corregir errores de la fuente de datos de Google Merchant: productos rechazados y cómo solucionarlos

Configuras Google Merchant Center, subes tu fuente de datos de PrestaShop y, de repente, medio catálogo aparece marcado. Triángulos rojos en la pestaña Productos, un aviso de "Cuenta suspendida" que no estaba la semana pasada y artículos que deberían aparecer en Shopping mostrados como Rechazados. Lo frustrante es que los rechazos rara vez cuentan toda la historia con claridad: Google nombra un síntoma ("Valor no coincidente: precio") y te deja averiguar qué ajuste de PrestaShop lo ha provocado realmente.

Última actualización: junio de 2026.

Esta guía trata específicamente de diagnosticar y resolver rechazos: leer el error, rastrearlo hasta el ajuste exacto de PrestaShop o el atributo de la fuente de datos que lo activó, y corregirlo para que el producto vuelva a aprobarse. Es el complemento de resolución de problemas del trabajo más amplio con fuentes de datos: si tus productos ya están aprobados y quieres que rindan mejor (títulos, taxonomía, etiquetas personalizadas), esa es otra tarea que cubrimos en nuestra guía de optimización de la fuente de datos de Merchant Center. Aquí nos ceñimos estrictamente a esto: está en rojo, por qué, y cómo ponerlo en verde.

Primero, interpreta bien el rechazo

Antes de tocar un solo ajuste, separa dos cosas que Merchant Center mezcla deliberadamente. Un problema a nivel de artículo rechaza un producto o unos pocos: corriges los datos y vuelve a aprobarse en la siguiente lectura de la fuente de datos. Un problema a nivel de cuenta (tergiversación, política, una cuenta suspendida) puede dejar todos los productos fuera de línea de una vez y exige otra respuesta. La forma más rápida de distinguirlos es la vista de Diagnóstico, no el icono rojo de cada producto.

En el Merchant Center actual, abre Productos → Diagnóstico (o Requiere atención en Merchant Center Next). Agrupa los rechazos por problema y te indica, para cada uno, si está a nivel de Cuenta, Artículo o Fuente de datos, cuántos productos están afectados, artículos de ejemplo y, cuando Google lo proporciona, el plazo antes de que el problema empiece a costarte dinero. Trabaja esa lista de arriba abajo por número de productos afectados: una corrección a nivel de fuente de datos suele limpiar decenas de artículos de una vez, mientras que perseguir productos individuales es una tarea interminable. ¿Qué ganas con eso? Dedicas el tiempo de corrección al único ajuste que vuelve a aprobar cuarenta productos en lugar de editar cuarenta productos a mano.

Discrepancia de precio: el rechazo más común en PrestaShop

Error: "Valor no coincidente (rastreo de página): precio [price]" o "Artículo rechazado por infracción de política: discrepancia de precio."

Google rastrea la página de producto publicada y compara el precio visible con el precio de tu fuente de datos. Si difieren más que una tolerancia mínima, el artículo se rechaza porque el comprador vería una cifra distinta a la prometida por el anuncio. En PrestaShop esto casi siempre se debe a una de cuatro causas, y requieren soluciones distintas; por eso conviene identificar cuál es antes de cambiar nada.

Una forma rápida de confirmar que el culpable son los impuestos: abre el producto rechazado en una ventana de incógnito, anota el precio mostrado y luego abre tu archivo de fuente de datos y busca el <g:price> de ese producto. Si la proporción entre ambos es tu tipo de IVA (1.19, 1.21, 1.23...), tienes una discrepancia de modo fiscal, no un problema de datos desactualizados; y cambiar el modo fiscal de la fuente de datos corrige todo el lote.

Como referencia, así debería verse un artículo con descuento en una fuente de datos XML: envía el precio normal como g:price (con impuestos incluidos, para coincidir con la página B2C que rastrea Google) y el precio rebajado como g:sale_price, ambos en la moneda que muestra la página; nunca solo el precio completo si la página muestra el precio de oferta.

<item>
  <g:id>1234</g:id>
  <g:price>49.99 EUR</g:price>
  <g:sale_price>39.99 EUR</g:sale_price>
  <g:availability>in_stock</g:availability>
  <g:brand>Acme</g:brand>
  <g:gtin>4006381333931</g:gtin>
</item>

Y para un producto que legítimamente no tiene código de barras, hecho a mano, personalizado o de tu propia marca privada, dile a Google que deje de esperar un GTIN en lugar de inventarte uno, lo que activaría "Identificador incorrecto":

<item>
  <g:id>5678</g:id>
  <g:brand>Your Label</g:brand>
  <g:identifier_exists>false</g:identifier_exists>
</item>

Datos de la fuente de datos desactualizados: la causa detrás de la mitad de los rechazos "aleatorios"

Error: discrepancias intermitentes de precio o disponibilidad que "se arreglan solas" y luego vuelven.

Si tu fuente de datos es un archivo que generaste una vez y subiste, es una fotografía de tu catálogo en ese momento. Cada cambio de precio, modificación de stock u oferta que hagas después va desincronizando la fuente de datos respecto a las páginas en vivo que rastrea Google; y los rechazos resultantes parecen aleatorios porque siguen tu actividad de edición, no un único ajuste roto. La solución es hacer que la fuente de datos se regenere según un calendario.

En PrestaShop, la forma limpia es una tarea cron que llame a tu controlador de fuente de datos (o a la URL de "generar" de tu módulo de exportación) de forma programada. El módulo oficial de Tareas cron de PrestaShop (el módulo cronjobs, gratuito en PrestaShop Addons, gestionado desde Módulos) puede llamar a la URL a diario; si tu alojamiento web te ofrece cron real del sistema, apúntalo a la misma URL. Ajusta la frecuencia a la frecuencia con la que cambias precios: diario es el mínimo, cada hora si haces ventas flash frecuentes. ¿Y qué? Los precios y el stock de la fuente de datos siempre reflejan la página que Google está a punto de rastrear, lo que cierra por completo el bucle de rechazos repetidos más común. (La arquitectura más amplia de generación de la fuente de datos, qué método de exportación, rendimiento en catálogos grandes, se cubre en la guía de optimización de la fuente de datos.)

Discrepancia de disponibilidad

Error: "Mismatched value (page crawl): availability" o "Product unavailable."

Google leyó in stock en tu fuente de datos, pero la página publicada decía que estaba agotado, o al revés. En PrestaShop esto casi siempre es la interacción entre la cantidad en stock de un producto y su comportamiento "Al agotarse el stock" (configurado por producto en la pestaña Stock, con el valor global por defecto en Parámetros de la tienda → Ajustes de producto). Si un producto tiene cantidad cero pero está configurado como "Permitir pedidos", la página todavía lo vende; por tanto, tu fuente de datos debe informar in stock, no out of stock. Asegúrate de que la fuente de datos lea tanto la cantidad como la política para productos sin stock, no solo la cantidad, o los productos con pedidos pendientes permitidos se marcarán erróneamente como no disponibles.

Infracciones en imágenes

Error: "Imagen demasiado pequeña", "Superposición promocional en la imagen" o "Imagen no rastreable".

• Imagen demasiado pequeña. El mínimo es 100×100 px (250×250 para ropa), y 800×800+ es una recomendación práctica de calidad que merece la pena cumplir. PrestaShop genera muchas copias redimensionadas de cada imagen (los tipos de imagen con nombre en Diseño → Ajustes de imágenes: home_default, large_default, cart_default y otros). Tu fuente de datos debe referenciar la URL del tipo large, no una miniatura; una fuente de datos que apunta a home_default activará "imagen demasiado pequeña" en todos los productos.
• Superposición promocional. Cualquier texto, insignia, marca de agua o logotipo incrustado en la imagen, "OFERTA", "-30%", "ENVÍO GRATIS", provoca un rechazo. Si has integrado llamadas promocionales en las fotos de producto, esa es la causa; la imagen del producto debe mostrar solo el producto sobre un fondo limpio.
• No rastreable. Googlebot no puede obtener la URL. Comprueba tres cosas por orden: que robots.txt no bloquee /img/, que ninguna protección contra hotlinking ni regla de WAF bloquee el user-agent del rastreador de imágenes de Google, y que la URL de la imagen no devuelva 404. Pega la URL exacta de <g:image_link> en una ventana de incógnito: si no puedes cargarla sin iniciar sesión, Google tampoco puede.

Identificadores ausentes (GTIN / MPN / marca)

Error: "Falta el valor: GTIN", "Identificador incorrecto" o "Rendimiento limitado por falta de identificadores".

Google cruza tus productos con su catálogo usando identificadores. Para la mayoría de los productos de marca y fabricación industrial, quiere marca + GTIN (el código de barras EAN/UPC). El campo de código de barras de PrestaShop, etiquetado como GTIN (código EAN, JAN, ITF o UPC/UCC) en el bloque Referencias de la pestaña Detalles del producto (las combinaciones tienen su propio código de barras, algo importante si vendes variantes), se mapea directamente al atributo gtin de Google. El atributo Marca se obtiene del Fabricante de PrestaShop asignado al producto.

• Productos de marca con códigos de barras: rellena el campo de código de barras GTIN/EAN-13 en PrestaShop y asigna un fabricante. Este es también el cambio individual con mayor impacto en la visibilidad: los productos con GTIN válidos se emparejan con más búsquedas.
• Productos que legítimamente no tienen código de barras (hechos a mano, personalizados, de tu propia marca privada): establece identifier_exists = false en la fuente de datos para que Google deje de esperar un GTIN. No inventes un código de barras: un GTIN incorrecto es peor que no tener ninguno y activa "Identificador incorrecto".
• "Identificador incorrecto": normalmente es un código de barras mal formado o con un dígito de control no válido que alguien escribió en el campo. Valida el EAN-13/GTIN en lugar de adivinar.

Envío no configurado para el país de destino

Error: "Falta información de envío" o "Sin coste de envío para [country]".

Google necesita un coste de envío que pueda mostrar antes de la pantalla de pago. Puedes proporcionarlo por producto mediante el atributo shipping de la fuente de datos, pero la ruta más limpia para una tienda PrestaShop es a nivel de cuenta: configúralo una vez en Merchant Center en Envíos y devoluciones, haciendo que coincida con las tarifas de tus transportistas de PrestaShop (Transporte → Transportistas). Dos detalles específicos de PrestaShop que suelen pasar factura:

• Envío gratuito no significa "sin envío". Si ofreces entrega gratuita, configura explícitamente un servicio de envío con coste 0. Para Google, un campo de envío vacío significa "envío no disponible", lo que rechaza el artículo.
• Cada país objetivo necesita una tarifa. Si apuntas a Alemania y Francia, pero el envío de Merchant Center solo cubre Francia, los productos alemanes se rechazan. Esto refleja tus zonas de transportista en PrestaShop: si un transportista no atiende una zona a la que estás anunciando, Google ve la brecha.

Políticas y tergiversación: las amenazas a nivel de cuenta

Error: "Infracción de política", "Tergiversación" o el temido "Cuenta suspendida".

Estos son los graves porque pueden tumbar toda la cuenta, no un solo producto. Rara vez son un problema de atributo de la fuente de datos: tienen que ver con las señales de confianza de tu tienda, que Google comprueba en el sitio publicado. La lista de comprobación específica para PrestaShop:

• Política de devoluciones/reembolsos visible y completa. Créala como una página CMS (Diseño → Páginas) y enlázala desde el pie de página. Una política escondida o ausente es un desencadenante frecuente de suspensión.
• Datos de contacto accesibles. Tu tienda debe mostrar una forma real de contactar contigo. El controlador Contacto de PrestaShop y una dirección/teléfono rellenados en Parámetros de la tienda → Contacto cubren esto; no dejes los datos de demostración.
• HTTPS en todas partes, sin contenido mixto. Activa Parámetros de la tienda → General → Activar SSL para forzar HTTPS en todo el sitio. Una pantalla de pago en HTTPS que carga una imagen http:// cuenta como contenido mixto y puede interpretarse como insegura.
• Títulos que coincidan con lo que vendes realmente. "Funda para Samsung Galaxy S24" es honesto; "Samsung Galaxy S24" para una funda de terceros es tergiversación. Si tus títulos de PrestaShop empiezan por una marca que no fabricas, corrige el nombre del producto, no la fuente de datos.

Si tu cuenta está suspendida por tergiversación, corrige todos los puntos anteriores antes de solicitar la revisión: Google suele conceder un número limitado de solicitudes de nueva revisión, así que una corrección a medias que falle la revisión consume una de tus oportunidades.

Un ciclo de corrección y verificación que sí limpia la cola

Los rechazos no desaparecen en cuanto guardas un ajuste. Trabaja el ciclo con método:

• Corrige en el origen, no en Merchant Center. Cambia el ajuste de PrestaShop o la lógica de la fuente de datos para que la siguiente regeneración sea correcta; parchear un producto a mano en Merchant Center se sobrescribe en la siguiente lectura de la fuente de datos.
• Regenera la fuente de datos para que los datos corregidos estén realmente en el archivo que lee Google. (Justo por eso importa la tarea cron diaria anterior: sin ella, tu corrección se queda en PrestaShop pero nunca llega a Google.)
• Vuelve a obtenerla y espera al rastreo. La reaprobación del artículo llega tras el siguiente procesamiento de la fuente de datos y rastreo de la página, no al pulsar guardar. La mayoría se resuelven en uno o dos días; no hagas ediciones impulsivas mientras tanto.
• Revisa de nuevo Diagnóstico, empezando por el problema principal. Confirma que el recuento de productos afectados ha bajado antes de pasar al siguiente problema.

Mantenerlos en verde: supervisión

Una vez que la cola está limpia, el trabajo pasa a ser preventivo. Revisa Diagnóstico cada semana, aborda los nuevos rechazos en uno o dos días (los rechazos prolongados pueden arrastrar el estado de la cuenta hacia una advertencia) y mantén la fuente de datos regenerándose según el calendario para que los precios y el stock no se desincronicen nunca. La mayoría de las oleadas "repentinas" de rechazos son una fuente de datos desactualizada poniéndose al día con un lote de cambios de precio; un cron fiable elimina silenciosamente toda esa categoría de problema.

El patrón en todos los errores anteriores es el mismo: un rechazo es Google diciéndote que la fuente de datos y la página publicada discrepan en algo: precio, stock, una imagen, un identificador, una política. Corrige la discrepancia en su origen en PrestaShop, regenera y el rojo desaparece. Una vez que los productos están aprobados de forma fiable, la siguiente palanca es hacer que compitan: títulos más precisos, la taxonomía correcta, etiquetas personalizadas para pujas; ese es el terreno de la guía de optimización de la fuente de datos. Y si estás dando un paso atrás para pensar en la estrategia de ejecutar campañas de Shopping de forma rentable, empieza por Google Merchant para el éxito PPC en PrestaShop y no inviertas presupuesto antes de leer cómo elegir el presupuesto adecuado para Google Ads: una fuente de datos limpia solo da resultados si el gasto que la respalda está bien dimensionado.

Preguntas frecuentes sobre rechazos de la fuente de datos de Merchant

¿Cómo distingo un problema a nivel de artículo de uno a nivel de cuenta? Usa Productos → Diagnóstico (o "Requiere atención" en Merchant Center Next), no el icono rojo de cada producto. Agrupa los rechazos por problema y etiqueta cada uno como nivel Cuenta, Artículo o Fuente de datos, con el recuento de productos afectados. Un problema de artículo rechaza unos pocos productos y se resuelve en la siguiente lectura de la fuente de datos; un problema de cuenta (tergiversación, política, suspensión) puede dejar todo fuera de línea de una vez y necesita otra respuesta.

¿Por qué la "discrepancia de precio" es el rechazo más común en PrestaShop? Google rastrea la página publicada y compara su precio visible con el precio de la fuente de datos. La causa habitual es una discrepancia de modo fiscal: la fuente de datos exporta precios sin impuestos mientras que la tienda B2C muestra precios con impuestos incluidos. Comprobación rápida: abre el producto en incógnito y busca su g:price en la fuente de datos; si la proporción es tu tipo de IVA (1.19, 1.21, 1.23...), cambia la fuente de datos a precios con impuestos incluidos y se limpiará todo el lote.

Mis rechazos aparecen y desaparecen "aleatoriamente": ¿por qué? Casi siempre por una fuente de datos desactualizada. Un archivo generado una vez es una fotografía de tu catálogo en ese momento; cada edición posterior de precio o stock lo desincroniza respecto a las páginas que rastrea Google, así que los rechazos siguen tus ediciones, no un único ajuste roto. Regénéralo según un calendario, a diario como mínimo, cada hora si haces ventas flash, mediante el módulo Tareas cron de PrestaShop o cron real del sistema.

Mis imágenes de producto están rechazadas: ¿qué falla? Tres causas comunes: la fuente de datos apunta a una miniatura (home_default) en lugar del tipo de imagen grande, por lo que activa "imagen demasiado pequeña"; hay una insignia promocional ("OFERTA", "-30%") incrustada en la foto, lo que no está permitido; o la URL no es rastreable (robots.txt bloquea /img/, un WAF bloquea el rastreador de Google o hay un 404). Pega el g:image_link exacto en una ventana de incógnito: si no puedes cargarlo sin iniciar sesión, Google tampoco puede.

¿Cuánto tarda la reaprobación después de corregir algo? No es instantánea. Corrige en el origen en PrestaShop (parchear un producto a mano en Merchant Center se sobrescribe en la siguiente lectura), regenera la fuente de datos para que los datos corregidos estén en el archivo que lee Google y espera al siguiente procesamiento y rastreo: la mayoría se resuelven en uno o dos días. Revisa Diagnóstico empezando por el problema principal y confirma que el recuento de afectados ha bajado antes de avanzar.

Lecturas relacionadas

• Smart Google Merchant feed manager, genera una fuente de datos que lee precios y stock en tiempo real, cerrando el bucle de rechazos por fuente de datos desactualizada.
• Guía de optimización de la fuente de datos de Merchant Center, una vez aprobados los productos, cómo hacer que compitan en títulos, taxonomía y etiquetas.
• Elegir el presupuesto adecuado para Google Ads, una fuente de datos limpia solo compensa si el gasto está bien dimensionado.