Google Merchant Center rechaza tus productos: los errores del feed de PrestaShop
Por qué Merchant Center desaprueba productos de una tienda PrestaShop: precio que no coincide, GTIN ausente, combinaciones mal agrupadas e imágenes rechazadas. Con la corrección de cada caso.
Autor y revisor: Jon González
El día que Merchant Center te apaga los anuncios
No suele avisar con antelación. Un martes entras a la cuenta y hay ochocientos productos desaprobados, las campañas de Shopping sirviendo a media máquina y un mensaje que dice algo sobre valores que no coinciden.
La buena noticia es que ese número casi siempre miente. Ochocientos productos caídos rara vez son ochocientos problemas: suelen ser uno repetido ochocientas veces. La mala es que hasta que no encuentras cuál, sigues sin anunciar.
Esta guía recorre los rechazos que más aparecen en tiendas PrestaShop y cómo se corrige cada uno.
Cómo leer el diagnóstico
Antes de tocar el feed, ve a la sección de diagnóstico de Merchant Center y ordena por motivo, no por producto. La lista de productos afectados es ruido; el motivo es el trabajo.
Verás dos categorías con consecuencias muy distintas:
Desaprobación. El producto no se muestra. Es urgente.
Advertencia. El producto se muestra pero rinde peor, y en muchos casos se convierte en desaprobación pasado un plazo. Es importante, no urgente.
Empieza siempre por el motivo que afecta a más productos. Suele ser uno solo y suele arreglarse en el mismo sitio.
El error más caro: el precio que no coincide
Es el rechazo número uno en tiendas españolas y casi siempre tiene la misma causa.
Google no se fía del feed: entra en la ficha del producto y compara. Si el precio que lee en la página no es el que has declarado, desaprueba el producto por discrepancia de valores.
Las tres causas, por orden de frecuencia:
El IVA. En España el precio del feed va con impuestos incluidos. Si tu exportación toma el precio base de PrestaShop sin aplicar la tasa, todo tu catálogo llegará un veintiuno por ciento por debajo del que Google ve en la web.
// El segundo parámetro es el que decide si el precio lleva impuestos.
// Exportar con false es la causa habitual del rechazo por discrepancia.
$precio = Product::getPriceStatic(
(int) $idProducto,
true, // con impuestos: obligatorio para el feed en España
(int) $idCombinacion,
2, // dos decimales
null,
false,
true // aplicando las reducciones vigentes
);Las promociones que solo existen en un sitio. Una regla de catálogo que rebaja el precio en la web pero que la exportación no contempla produce exactamente el mismo síntoma, al revés.
Los precios por grupo de clientes. Si tu tienda muestra un precio distinto según el grupo, el feed debe llevar el que ve un visitante anónimo, que es el que verá Google.
El formato también importa: el importe va con punto decimal y el código de moneda separado, 24.90 EUR, no 24,90 €.
Identificadores: GTIN, marca y el campo que casi nadie rellena
Google quiere saber qué producto es exactamente. Para eso pide identificadores.
Si el producto tiene código de barras, va el GTIN, y va bien: los de trece dígitos completos, sin espacios y sin el guion. Un GTIN inventado o mal copiado es peor que ninguno, porque asocia tu anuncio al producto equivocado.
Si es de marca propia y no tiene código de barras, no se deja el campo vacío. Se declara explícitamente que ese producto no tiene identificador:
<g:brand>Mi Marca</g:brand>
<g:identifier_exists>no</g:identifier_exists>Dejarlo vacío sin más es lo que produce la advertencia de identificadores insuficientes, que con el tiempo degrada el rendimiento del producto en las subastas.
En PrestaShop el código de barras vive en la pestaña de cantidades de cada producto y también en cada combinación, que es donde suele estar sin rellenar.
Combinaciones: el error de exportar una sola fila
Este es específico de las tiendas con tallas y colores, y es el que más volumen tumba.
Para tu cliente, una camiseta con cinco tallas es un producto. Para Google son cinco artículos distintos, cada uno con su identificador, su disponibilidad y su precio, unidos por un mismo identificador de grupo.
<item>
<g:id>1234-38</g:id>
<g:item_group_id>1234</g:item_group_id>
<g:title>Camiseta de algodón orgánico - Azul, talla 38</g:title>
<g:size>38</g:size>
<g:color>Azul</g:color>
<g:availability>in_stock</g:availability>
<g:price>24.90 EUR</g:price>
<g:link>https://tutienda.es/camisetas/1234-camiseta.html#/talla-38</g:link>
</item>Los tres fallos que se ven una y otra vez:
- Exportar solo el producto padre, con lo que Google anuncia tallas agotadas.
- Exportar las combinaciones sin el identificador de grupo, y entonces Google las trata como productos sin relación y las considera duplicados.
- Repetir el mismo enlace para todas: cada variante debe llevar a su propia selección, o el cliente aterriza en la talla equivocada.
Imágenes que Google rechaza
Menos frecuente pero muy fácil de evitar:
- Por debajo de 250 × 250 píxeles no entra. Y esa es la medida mínima; con imágenes pequeñas el anuncio se ve peor que el de la competencia.
- Nada de marcas de agua, logotipos superpuestos, texto promocional ni marcos.
- Nada de imágenes de relleno tipo “próximamente”.
- La URL de la imagen tiene que ser accesible: si tu servidor bloquea peticiones sin cabecera de navegador, Google no la descarga y el producto cae.
Comprueba también que robots.txt no bloquea Googlebot-Image. Es un clásico: alguien bloqueó el directorio de imágenes para ahorrar rastreo y se llevó por delante Shopping.
Catálogos grandes: cuando la exportación se cae
En tiendas de varios miles de referencias la exportación se rompe por dos motivos, y ninguno da un error claro.
Memoria agotada. Cargar el catálogo entero en un array antes de escribir el XML se come la memoria disponible. Hay que escribir por lotes e ir volcando a disco.
Tiempo de ejecución superado. Si la exportación se lanza por URL, PHP-FPM la corta a mitad y el fichero queda truncado. Un XML incompleto no siempre da error de sintaxis: a veces sube perfectamente con la mitad del catálogo, y entonces la desaparición de productos parece un misterio.
// Volcado por lotes: con el catálogo entero en memoria, a partir de unos
// pocos miles de referencias el proceso muere sin mensaje útil.
$offset = 0;
$lote = 500;
do {
$filas = Db::getInstance()->executeS(
'SELECT id_product FROM ' . _DB_PREFIX_ . 'product
WHERE active = 1 LIMIT ' . (int) $offset . ', ' . (int) $lote
);
foreach ($filas as $fila) {
fwrite($manejador, construirItem((int) $fila['id_product']));
}
$offset += $lote;
} while (count($filas) === $lote);Y siempre: escribir a un fichero temporal y renombrar al final. Si Google descarga el feed mientras lo estás generando, se lleva medio catálogo.
Lo que no funciona
Volver a subir el feed sin cambiar nada. La revisión es automática; si el motivo sigue ahí, el resultado será el mismo tres días después.
Pedir revisión de la cuenta con los errores puestos. Gasta un intento y no arregla nada.
Rellenar el GTIN con el número de referencia interna. Google lo valida contra el estándar. Un código que no cumple el dígito de control se rechaza, y si por casualidad cumple, estarás anunciando el producto de otro.
Meter la marca en el título para “posicionar mejor”. El título es del producto. Los adornos tipo envío gratis o oferta están expresamente prohibidos y son motivo de desaprobación.
Exportar productos sin stock para no perder visibilidad. Se marca la disponibilidad real. Anunciar lo agotado genera una mala experiencia que Google mide y penaliza.
Validar antes de publicar
El ciclo natural de trabajo con Merchant Center es lento: subes, esperas la revisión, te enteras del fallo. Con eso, corregir tres errores encadenados se puede ir a más de una semana con las campañas a medio gas.
La alternativa es revisar el fichero antes de subirlo, contra las reglas que ya se conocen: campos obligatorios presentes, precio con impuestos y formato correcto, disponibilidad dentro del vocabulario permitido, identificadores coherentes, enlaces que responden 200, imágenes que se descargan.
No sustituye a la revisión de Google, pero convierte una semana de idas y venidas en una tarde.
Si te apañas con esto, no necesitas nada más
Un feed se genera con un script, y si tu catálogo es estable y no tiene combinaciones, el script que escribas te va a durar años.
Lo que cuesta mantener es el resto: que la exportación no se caiga cuando el catálogo crezca, que las combinaciones sigan agrupadas cuando alguien añada un color, que el precio siga cuadrando después de la próxima regla de promoción, y saber qué producto concreto rompe el fichero cuando Merchant Center lo rechace dentro de tres semanas.
Ampliación editorial · revisión 2026
La decisión central de esta guía
¿Por qué Merchant Center desaprueba los productos de mi tienda PrestaShop?
Casi siempre por un motivo repetido muchas veces, no por muchos motivos distintos. El más frecuente en tiendas españolas es la discrepancia de precio: el feed exporta el importe sin impuestos mientras Google lee en la ficha el precio con IVA. Le siguen los identificadores ausentes y las combinaciones exportadas como una sola fila o sin identificador de grupo.
Ordena el diagnóstico por motivo y ataca primero el que afecta a más productos. Separa desaprobaciones, que apagan el anuncio, de advertencias, que solo lo degradan. Y valida el fichero antes de subirlo, porque el ciclo de subir y esperar revisión convierte tres errores encadenados en una semana sin campañas.
Comprueba el precio del feed contra el que ve un visitante anónimo en la ficha, no contra el de tu grupo de cliente. Verifica que cada enlace responde 200, que las imágenes se descargan sin cabecera de navegador y que robots.txt no bloquea el rastreador de imágenes.
No se estiman tiempos de recuperación: la revisión de Google es automática pero no inmediata. Rellenar el GTIN con la referencia interna es peor que dejarlo declarado como inexistente, y anunciar productos agotados genera una experiencia que Google mide y penaliza.
Marco técnico
Medición de marketing que conecta inversión con margen
Marketing digital es un sistema de adquisición y aprendizaje que relaciona audiencia, mensaje, canal, página de destino, oportunidad y resultado económico. Las plataformas publicitarias muestran señales útiles, pero la empresa necesita su propia definición de lead, venta, margen y periodo de atribución.
La medición empieza antes de activar campañas. Cada objetivo se traduce en un evento y un criterio de calidad. Enviar un formulario no equivale a una oportunidad; una compra no garantiza margen; una llamada puede proceder de soporte. Conectar origen, sesión y estado comercial evita optimizar el algoritmo hacia interacciones fáciles pero poco valiosas.
ROAS divide ingresos atribuidos entre gasto publicitario, pero no incluye necesariamente producto, comisión, logística, devolución, agencia ni tiempo comercial. Por eso se acompaña de margen de contribución, coste por oportunidad aceptada y tasa de cierre. Una campaña con ROAS alto puede destruir rentabilidad si concentra productos o clientes costosos.
SEO y SEM cubren horizontes distintos. La publicidad permite probar demanda y mensaje con rapidez, mientras el contenido orgánico puede construir un activo acumulativo. La asignación depende de plazo, competencia, capacidad de conversión y caja. No existe un porcentaje universal para los primeros mil euros ni una frontera donde un canal deje de aportar.
La página de destino mantiene coherencia con la consulta y el anuncio. Explica la propuesta, demuestra, resuelve objeciones y ofrece una acción. Enviar todo el tráfico a la portada mezcla intenciones; crear una landing por cada palabra sin contenido distinto multiplica copias. La estructura sigue la necesidad del usuario.
Lista de control antes de ejecutar
- 01Conversión definida
Evento, valor, deduplicación y criterio de aceptación se acuerdan antes de optimizar.
- 02Consentimiento comprobado
Etiquetas y plataformas respetan la elección y minimizan datos personales.
- 03Mensaje alineado
Consulta, anuncio, landing y oferta usan la misma promesa y el mismo siguiente paso.
- 04Margen disponible
La lectura incluye devoluciones, costes variables y capacidad comercial.
- 05Periodo adecuado
El análisis respeta ciclo de venta, retraso de conversión y estacionalidad.
- 06Aprendizaje documentado
Cada prueba registra hipótesis, cambio, resultado y decisión para no repetir experimentos.
Qué medir para saber si funciona
Separa métricas de entrega —impresiones, alcance, clics—, comportamiento —lectura, formulario, carrito— y negocio —oportunidad, venta, margen, repetición—. El panel debe permitir una decisión; si una cifra no cambia presupuesto, mensaje o operación, probablemente sea secundaria.
La atribución no descubre una verdad única. Último clic, primer clic y modelos de plataforma responden preguntas diferentes. Mantén identificadores consistentes, compara fuentes y declara limitaciones. Para ciclos largos, la conversación comercial y el CRM aportan contexto que una cookie no conserva.
Playbook propio de esta guía
Feed de producto de PrestaShop que Merchant Center acepta
Esta ampliación desarrolla el problema específico de google merchant center rechaza tus productos: los errores del feed de prestashop y no se reutiliza en otras entradas del Laboratorio.
El precio, que es donde se cae el catálogo entero
Google no se fía del feed: entra en la ficha y compara. Si el precio declarado no coincide con el que lee en la página, desaprueba por discrepancia de valores. En España el importe del feed va con impuestos incluidos, así que una exportación que tome el precio base de PrestaShop sin aplicar la tasa deja todo el catálogo por debajo del precio real y lo tumba de golpe. Es el rechazo más frecuente y el que más asusta, porque afecta a todo a la vez.
Las otras dos causas del mismo síntoma son las promociones que solo existen en un lado y los precios por grupo de clientes. Una regla de catálogo que rebaja en la web pero que la exportación no contempla produce el desajuste al revés, y un feed generado con el precio de un grupo concreto nunca coincidirá con el que ve un visitante anónimo, que es el único que Google puede leer. El formato remata la jugada: punto decimal y código de moneda separado, no coma ni símbolo.
Identificadores y combinaciones
Google necesita saber qué producto es exactamente, y para eso pide identificadores. Si hay código de barras va el GTIN completo y correcto, porque uno inventado asocia el anuncio al producto de otra empresa. Si el producto es de marca propia y no tiene código, no se deja el campo vacío: se declara explícitamente que no existe identificador. Dejarlo en blanco produce la advertencia de identificadores insuficientes, que con el tiempo degrada el rendimiento en las subastas sin llegar a apagar el anuncio.
Las combinaciones son lo que más volumen tumba en tiendas de moda. Una camiseta con cinco tallas es un producto para el cliente y cinco artículos para Google, cada uno con su identificador, su disponibilidad y su precio, unidos por un mismo identificador de grupo. Exportar solo el producto padre acaba anunciando tallas agotadas; exportar las variantes sin agruparlas hace que Google las trate como duplicados; y repetir el mismo enlace en todas manda al cliente a la talla equivocada.
Generar el fichero sin romperlo
En catálogos de varios miles de referencias la exportación falla por memoria o por tiempo, y ninguno de los dos casos da un mensaje claro. Cargar el catálogo entero en memoria antes de escribir agota el límite; lanzar la exportación por URL hace que PHP corte el proceso a mitad. Lo segundo es especialmente traicionero porque un XML truncado no siempre da error de sintaxis: a veces sube limpiamente con la mitad del catálogo, y la desaparición de productos parece un misterio sin causa.
La forma robusta es volcar por lotes a un fichero temporal e ir escribiendo a disco en lugar de acumular, y renombrar el fichero solo cuando esté completo. Si Google descarga el feed mientras se está generando, se lleva medio catálogo y la próxima revisión desaprobará todo lo que faltaba. Escribir y renombrar cuesta dos líneas y evita una categoría entera de incidencias difíciles de reproducir.
Cuaderno de campo: ochocientos productos caídos son un error, no ochocientos
La primera reacción ante una pantalla de Merchant Center con cientos de productos desaprobados es de pánico, y ese pánico lleva casi siempre a la peor decisión posible: empezar a corregir productos uno a uno. El número de productos afectados es la métrica menos útil de esa pantalla. La útil es el motivo, y ordenar por motivo suele revelar que las ochocientas líneas rojas son una sola causa repetida, casi siempre en la generación del fichero y no en las fichas. Cuando la causa es el precio sin impuestos, se corrige en una línea de la exportación y los ochocientos vuelven en la siguiente revisión. Cuando es la falta de agrupación de combinaciones, se corrige en el bucle que las escribe. En ambos casos el trabajo real es de minutos, y lo que consume el día es no haber ordenado por motivo al principio.
El rechazo por discrepancia de precio merece atención especial porque su causa es contraintuitiva. La gente asume que si el feed sale de la misma base de datos que la web, los precios coincidirán por construcción. No es así: la web muestra el precio final que ve un cliente concreto, con sus impuestos, sus reglas de catálogo y su grupo, mientras que la exportación suele tirar del precio base del producto porque es el campo más obvio. Los dos números son correctos, se refieren a cosas distintas y solo uno de ellos es el que Google va a leer al entrar en la ficha. La comprobación honesta es abrir la ficha en una ventana de incógnito y comparar con el fichero, que es exactamente lo que hace el rastreador.
Los catálogos grandes traen un fallo que no se parece a un fallo. La exportación se lanza, no da error, sube y una parte del catálogo desaparece de los anuncios sin motivo aparente. La causa suele ser un proceso cortado por tiempo o por memoria que dejó el XML a medias, y lo que despista es que un fichero truncado puede ser sintácticamente válido si el corte cae entre dos elementos. Nadie sospecha del fichero porque el fichero se subió bien. La disciplina que evita toda esta familia de incidencias es escribir por lotes a un temporal y renombrar solo al final, de modo que el feed publicado esté completo o sea el anterior, pero nunca la mitad del nuevo.
Sobre construirlo a mano o comprarlo, el reparto es el habitual. Generar un XML que cumpla la especificación es un ejercicio acotado, y si el catálogo es estable y sin combinaciones, el script escrito una vez dura años. El coste aparece cuando el catálogo cambia de forma: alguien añade colores a una referencia, aparece una promoción nueva, se migra a la siguiente rama de PrestaShop. Entonces la pregunta deja de ser cómo se escribe un feed y pasa a ser qué producto concreto está rompiendo el fichero, que es una pregunta muy distinta y mucho más cara de responder a las tres semanas y con las campañas apagadas.
Comprobaciones antes de cerrar
- 01El precio del feed lleva impuestos
En España es obligatorio y es la causa número uno de la desaprobación masiva por discrepancia.
- 02El precio coincide con el del visitante anónimo
No con el de tu grupo de cliente ni con el de una promoción que solo existe en un lado.
- 03Cada combinación es un artículo con grupo
Identificador propio, disponibilidad propia, enlace propio y el mismo identificador de grupo.
- 04Sin GTIN se declara que no existe
El campo vacío genera advertencia; la referencia interna en su lugar es peor todavía.
- 05Las imágenes se descargan sin cabecera de navegador
Y robots.txt no bloquea el rastreador de imágenes, que es como se pierde Shopping sin enterarse.
- 06El fichero se renombra al terminar
Generar sobre el fichero publicado deja que Google descargue medio catálogo.
Revisa el feed cuando se añadan combinaciones nuevas, cuando cambie el esquema de promociones y después de cada actualización de PrestaShop. Si un motivo de rechazo reaparece cada pocos meses, el problema no es el feed sino el proceso que lo genera: algo lo está regenerando con reglas distintas a las que se validaron.
Pasos del procedimiento
1. Lee el diagnóstico por motivo, no por número
Merchant Center agrupa los rechazos por causa. Mil productos caídos suelen ser un solo error repetido mil veces, y arreglarlo una vez los devuelve todos.
2. Cuadra el precio del feed con el de la ficha
En España el precio del feed va con IVA incluido y debe coincidir con el que Google lee en la página. La causa habitual del desajuste es el IVA o una promoción que solo existe en uno de los dos sitios.
3. Resuelve los identificadores de producto
Si el producto tiene código de barras, va el GTIN. Si es de marca propia y no lo tiene, se declara que no existe identificador en lugar de dejar el campo vacío.
4. Exporta cada combinación como un artículo agrupado
Una talla no es un producto distinto para el cliente pero sí una fila distinta para Google, todas unidas por el mismo identificador de grupo.
5. Comprueba que Google puede entrar en la ficha
Una URL que responde 404, redirige o está bloqueada en robots.txt tumba el producto aunque el feed sea perfecto.
6. Valida el feed antes de subirlo
Revisar el fichero contra las reglas conocidas antes de publicarlo evita el ciclo de subir, esperar la revisión y descubrir el fallo tres días después.
Control editorial
Metodología y fuentes
Los motivos de rechazo descritos son los que más aparecen al trabajar feeds de tiendas PrestaShop 8 y 9 contra Merchant Center. Las reglas de atributos y de imagen se contrastan con la especificación pública de Google; no se estiman porcentajes de recuperación de productos porque dependen del catálogo de cada tienda.
- Google — Especificación de datos de producto ↗
Atributos obligatorios, formatos aceptados y vocabulario de disponibilidad.
- Google — Identificadores únicos de producto ↗
Cuándo es obligatorio el GTIN y cómo declarar que no existe.
- Google — Requisitos de las imágenes de producto ↗
Tamaños mínimos y elementos prohibidos en la imagen.
- PrestaShop DevDocs — Precios y reglas de catálogo ↗
Cómo calcula PrestaShop el precio final con impuestos y reducciones.
