Para recuperar productos rechazados en Merchant Center, empieza por el motivo exacto y su alcance. Un precio incoherente, una disponibilidad distinta o una incidencia de cuenta no se corrigen de la misma forma. Cambiar títulos al azar o volver a subir el feed puede dejar intacta la causa y complicar el seguimiento.
El objetivo es construir una evidencia sencilla: qué dato recibió Google, qué encuentra el comprador y qué configuración provoca la diferencia. Después se corrige la fuente responsable, se confirma la actualización y se sigue el proceso de revisión que corresponda. La aprobación final depende de Google; ninguna agencia puede garantizarla.
Primero distingue productos, destinos y problemas de cuenta
En la sección de incidencias, abre el detalle antes de editar. La página de detalles de Merchant Center reúne el problema, los productos afectados y las indicaciones disponibles. Anota país, fuente de datos y destino cuando aparezcan: un producto puede tener un alcance distinto del que supones al ver una alerta general.
| Lo que observas | Qué comprobar | Qué evitar |
|---|---|---|
| Unos pocos productos rechazados | IDs, variantes, país y atributos concretos. | Modificar todo el catálogo para resolver una incidencia aislada. |
| Muchos productos con el mismo error | Plantilla, integración, reglas del feed y datos compartidos. | Corregir a mano cada fila sin reparar la fuente común. |
| Advertencia o suspensión de cuenta | Motivo de cuenta, sitio y políticas indicadas. | Suponer que subir un producto nuevo elimina la incidencia. |
| Precio o stock distintos | Feed, variante, página, datos estructurados y actualización. | Pedir revisión antes de que la corrección sea visible. |
Google diferencia medidas sobre productos y sobre cuentas en su documentación de calidad de datos. Conserva ese alcance en el registro: no es lo mismo una variante excluida que una suspensión que afecta a la participación de la cuenta.
Cómo investigar un precio que no coincide
Elige un ID afectado y abre la URL enviada para su variante y mercado. Compara precio, moneda y condiciones con el dato que figura en Merchant Center. Revisa también si la integración envía un precio rebajado caducado, una variante distinta o una moneda que depende de la ubicación del visitante.
Google explica cómo corregir el precio que no coincide y la importancia de que el dato sea accesible de forma coherente en la página. Un cambio visual hecho con JavaScript puede no resolver una discrepancia si el HTML inicial o los datos estructurados todavía presentan otro importe. Coordina la corrección con quien gestiona la tienda.
Comprueba la cadena completa
- Identifica el sistema que contiene el precio correcto: ERP, plataforma de ecommerce u otra fuente.
- Revisa cómo se transforma para el feed y cuándo se actualiza.
- Comprueba página, variante seleccionada y datos estructurados.
- Actualiza la fuente que genera la discrepancia.
- Confirma el dato procesado y conserva un ejemplo antes y después.
Las actualizaciones automáticas pueden ayudar en determinadas discrepancias, pero no sustituyen una integración consistente. Si cada sincronización vuelve a enviar el precio antiguo, corregirlo manualmente en un punto será una solución temporal.
Si el problema es disponibilidad, revisa variantes y tiempos
Un producto puede existir en la tienda y no estar disponible para la variante o el país enviados. Contrasta el stock del ID afectado, la página, las condiciones de compra y la frecuencia de actualización. Una plantilla que marca todo como disponible puede fallar aunque el inventario interno sea correcto.
La guía oficial sobre disponibilidad que no coincide describe la reparación y la revisión. No interpretes la permanencia inmediata de una alerta como prueba de que la corrección falló: puede faltar procesamiento o una nueva comprobación. Verifica la secuencia y el estado antes de acumular cambios.
Ejemplo hipotético: una promoción que termina en la tienda
Una tienda finaliza una promoción el lunes. La web recupera el precio habitual, pero una tarea programada sigue generando el feed con el valor promocional. Algunas variantes se rechazan. El equipo identifica el campo de origen y la tarea, corrige la lógica y verifica un grupo de IDs afectados antes de extender el control al resto.
Solicitar una revisión sin arreglar esa tarea no habría eliminado la causa: la siguiente sincronización volvería a introducirla. El ejemplo es hipotético y no representa un caso ni un resultado de SEOMOS. Sirve para distinguir una reparación de datos de una simple nueva carga del archivo.
Qué documentar antes de solicitar revisión
- Motivo exacto y alcance de la incidencia.
- IDs de muestra y URLs de las variantes afectadas.
- Fuente modificada, responsable y fecha de actualización.
- Evidencia de consistencia entre dato procesado, página y compra.
- Incidencias relacionadas todavía pendientes.
Solicita revisión solo cuando corresponda y hayas corregido lo indicado. Puede haber periodos de espera o límites a las solicitudes; sigue el estado mostrado por la cuenta. No prometas una fecha de aprobación al equipo comercial ni cambies todo el catálogo mientras una corrección concreta está siendo evaluada.
Cuándo hace falta revisar también la campaña
Un producto aprobado no garantiza impresiones o ventas. Después de resolver Merchant Center, revisa la vinculación, la selección de productos y la configuración publicitaria pertinente. Separa ese diagnóstico del rechazo para no cambiar pujas o presupuestos cuando el inventario ni siquiera era elegible.
En nuestra gestión de Google Ads para ecommerce, catálogo, medición y rentabilidad se estudian juntos. La auditoría puede identificar dónde investigar; los cambios en una integración o en la tienda se acuerdan según el alcance y los accesos disponibles.
Crea una muestra que represente el problema
No investigues únicamente el primer producto de la lista. Si la incidencia afecta distintas variantes, mercados o fuentes, elige una muestra que cubra esas diferencias. Incluye un producto afectado y otro aparentemente correcto cuando sea posible. Esa comparación ayuda a encontrar si el fallo pertenece a una regla compartida o a un dato individual.
Para cada muestra, conserva el ID exacto, la URL enviada, la variante seleccionada, el mercado y el motivo mostrado. Guarda el momento de la observación. Comparar un feed de ayer con una página modificada hace unos minutos puede crear una contradicción aparente. La evidencia debe permitir a otra persona repetir la comprobación sin adivinar qué versión revisaste.
Separa el sistema de origen de las transformaciones
Una tienda puede tener un precio correcto en su plataforma y un valor equivocado en el archivo final. Entre ambos pueden existir reglas, conectores, cachés y tareas programadas. Dibuja la cadena con nombres concretos: sistema comercial, integración, fuente enviada y dato procesado. Después identifica dónde aparece por primera vez la diferencia.
No cambies todos los eslabones para conseguir que una muestra coincida. Si arreglas manualmente el archivo mientras el conector conserva el error, la siguiente actualización puede deshacer la corrección. Si modificas la tienda para adaptarla a un feed incorrecto, puedes perjudicar la oferta real. La fuente responsable debe corregirse sin perder la referencia comercial válida.
Asigna un responsable por tramo. El equipo de pauta puede detectar la discrepancia y validar su alcance, mientras desarrollo corrige una transformación y operaciones confirma precio o inventario. Sin esa separación, varias personas pueden editar el mismo dato con criterios diferentes. Un registro breve de decisiones evita que una reparación genere otra incidencia.
Revisa variantes sin asumir que la página inicial basta
Un producto con tallas, colores o presentaciones necesita una comprobación por el ID afectado. Abre el destino recibido y observa qué variante aparece seleccionada. Comprueba si el precio, la imagen y la disponibilidad corresponden a esa combinación. Una página de producto genérica puede verse correcta mientras la variante enviada sigue siendo incoherente.
Examina también la experiencia sin una sesión previa. Una cookie, una ubicación elegida o una preferencia guardada pueden modificar lo que ves. No deduzcas que Google o un comprador nuevo reciben la misma versión que tu navegador habitual. Registra contexto y condiciones, y comparte una forma reproducible de llegar a la variante correcta.
Utiliza una ficha de evidencia por incidencia
| Campo | Qué registrar | Qué decisión permite |
|---|---|---|
| Alcance | Motivo, país, destino y productos afectados | Priorizar la causa común antes de editar filas |
| Dato procesado | Valor y fecha visibles en Merchant Center | Saber qué información recibió la plataforma |
| Experiencia de compra | URL, variante y condición observada | Localizar la discrepancia real para el usuario |
| Corrección | Fuente modificada y responsable | Evitar cambios contradictorios o temporales |
| Validación | Comprobaciones completadas y pendientes | Decidir si corresponde solicitar revisión |
La ficha no debe convertirse en un almacén de información sensible. Usa muestras necesarias y controles de acceso. Un resumen con IDs, estados y enlaces suele ser suficiente para coordinar. Si compartes capturas, revisa que no incluyan pedidos, datos de clientes o accesos que no aportan nada al diagnóstico.
Prioriza por causa y capacidad de reparación
El número de productos afectados importa, pero no es el único criterio. Una regla que modifica todo un catálogo puede merecer atención antes que varios errores aislados. También conviene considerar qué productos forman parte de la oferta actual y qué equipo puede reparar la fuente. Documenta la prioridad para evitar que cada alerta nueva interrumpa el trabajo iniciado.
No confundas urgencia comercial con permiso para declarar una reparación completa. Si solo validaste una muestra, explica qué representa y qué falta comprobar. Cuando el cambio es de plantilla, revisa otros casos que utilizan esa plantilla. Cuando es un dato individual, evita extenderlo a productos que tienen condiciones distintas.
Ejemplo hipotético: dos conectores actualizan el mismo catálogo
Imagina una tienda donde una integración envía el inventario actualizado y otra tarea antigua vuelve a publicar un archivo previo por la noche. Durante el día, el producto parece correcto; al siguiente control, reaparece el error. El equipo podría interpretar esa alternancia como un fallo de revisión cuando en realidad hay dos fuentes compitiendo por mantener el dato.
El diagnóstico compara horarios, fuentes e IDs afectados. Después identifica qué proceso debe ser responsable y retira o corrige el flujo redundante con una validación acordada. No basta con volver a cargar el archivo correcto cada mañana. El escenario es ficticio y no demuestra que esta sea la causa de otra cuenta: ilustra por qué la cronología forma parte de la investigación.
Prepara la reapertura comercial después de la corrección
Cuando la incidencia se resuelva, comprueba que la oferta siga siendo atendible: producto disponible, página funcional y recorrido de compra coherente. Si se pausaron campañas o productos durante el trabajo, registra quién decide reactivarlos. Resolver una alerta no autoriza automáticamente ampliar inversión ni cambiar una estrategia comercial.
Conserva una revisión posterior a la siguiente actualización habitual de datos. Así puedes comprobar que la fuente no reintroduce el problema. Anota qué señal detectaría una regresión y quién la atenderá. El cierre útil de una incidencia incluye la causa corregida, la evidencia y el control de mantenimiento, además del estado que muestra Merchant Center.
Tu primera auditoría Google Ads es gratis. Revisemos qué limita tu cuenta y qué conviene mejorar primero. Solicitar mi auditoría gratuita.
Preguntas frecuentes
¿Debo borrar y volver a cargar los productos rechazados?
No como primera medida. Identifica la causa y corrige la fuente. Una nueva carga puede repetir el mismo error si la integración o la página siguen enviando datos incoherentes.
¿Cuánto tarda Google en aprobar una corrección?
Depende de la incidencia, el procesamiento y el proceso de revisión aplicable. Sigue el estado de Merchant Center; no existe una fecha de aprobación garantizada para cualquier caso.
¿Un rechazo de producto significa que la cuenta está suspendida?
No necesariamente. Una incidencia puede afectar productos concretos o tener alcance de cuenta. Comprueba el motivo y los elementos afectados en el detalle.
¿SEOMOS puede revisar el problema gratis?
La primera auditoría Google Ads es gratis y puede identificar qué parte de la cuenta o del catálogo conviene investigar. Las reparaciones e integraciones se acuerdan según el alcance.
