{"id":1651,"date":"2026-11-04T15:00:00","date_gmt":"2026-11-04T20:00:00","guid":{"rendered":"https:\/\/www.seomos.com\/?p=1651"},"modified":"2026-10-30T14:39:21","modified_gmt":"2026-10-30T19:39:21","slug":"productos-rechazados-merchant-center","status":"publish","type":"post","link":"https:\/\/www.seomos.com\/en\/blog\/productos-rechazados-merchant-center\/","title":{"rendered":"Disapproved Merchant Center products: what to check"},"content":{"rendered":"
\n

Para recuperar productos rechazados en Merchant Center, empieza por el motivo exacto y su alcance.<\/strong> Un precio incoherente, una disponibilidad distinta o una incidencia de cuenta no se corrigen de la misma forma. Cambiar t\u00edtulos al azar o volver a subir el feed puede dejar intacta la causa y complicar el seguimiento.<\/p>\n

El objetivo es construir una evidencia sencilla: qu\u00e9 dato recibi\u00f3 Google, qu\u00e9 encuentra el comprador y qu\u00e9 configuraci\u00f3n provoca la diferencia. Despu\u00e9s se corrige la fuente responsable, se confirma la actualizaci\u00f3n y se sigue el proceso de revisi\u00f3n que corresponda. La aprobaci\u00f3n final depende de Google; ninguna agencia puede garantizarla.<\/p>\n

Primero distingue productos, destinos y problemas de cuenta<\/h2>\n

En la secci\u00f3n de incidencias, abre el detalle antes de editar. La p\u00e1gina de detalles de Merchant Center<\/a> re\u00fane el problema, los productos afectados y las indicaciones disponibles. Anota pa\u00eds, fuente de datos y destino cuando aparezcan: un producto puede tener un alcance distinto del que supones al ver una alerta general.<\/p>\n

\n\n\n\n\n\n\n\n\n
Lo que observas<\/th>\nQu\u00e9 comprobar<\/th>\nQu\u00e9 evitar<\/th>\n<\/tr>\n<\/thead>\n
Unos pocos productos rechazados<\/td>\nIDs, variantes, pa\u00eds y atributos concretos.<\/td>\nModificar todo el cat\u00e1logo para resolver una incidencia aislada.<\/td>\n<\/tr>\n
Muchos productos con el mismo error<\/td>\nPlantilla, integraci\u00f3n, reglas del feed y datos compartidos.<\/td>\nCorregir a mano cada fila sin reparar la fuente com\u00fan.<\/td>\n<\/tr>\n
Advertencia o suspensi\u00f3n de cuenta<\/td>\nMotivo de cuenta, sitio y pol\u00edticas indicadas.<\/td>\nSuponer que subir un producto nuevo elimina la incidencia.<\/td>\n<\/tr>\n
Precio o stock distintos<\/td>\nFeed, variante, p\u00e1gina, datos estructurados y actualizaci\u00f3n.<\/td>\nPedir revisi\u00f3n antes de que la correcci\u00f3n sea visible.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Google diferencia medidas sobre productos y sobre cuentas en su documentaci\u00f3n de calidad de datos<\/a>. Conserva ese alcance en el registro: no es lo mismo una variante excluida que una suspensi\u00f3n que afecta a la participaci\u00f3n de la cuenta.<\/p>\n

C\u00f3mo investigar un precio que no coincide<\/h2>\n

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\u00e9n si la integraci\u00f3n env\u00eda un precio rebajado caducado, una variante distinta o una moneda que depende de la ubicaci\u00f3n del visitante.<\/p>\n

Google explica c\u00f3mo corregir el precio que no coincide<\/a> y la importancia de que el dato sea accesible de forma coherente en la p\u00e1gina. Un cambio visual hecho con JavaScript puede no resolver una discrepancia si el HTML inicial o los datos estructurados todav\u00eda presentan otro importe. Coordina la correcci\u00f3n con quien gestiona la tienda.<\/p>\n

Comprueba la cadena completa<\/h3>\n
    \n
  1. Identifica el sistema que contiene el precio correcto: ERP, plataforma de ecommerce u otra fuente.<\/li>\n
  2. Revisa c\u00f3mo se transforma para el feed y cu\u00e1ndo se actualiza.<\/li>\n
  3. Comprueba p\u00e1gina, variante seleccionada y datos estructurados.<\/li>\n
  4. Actualiza la fuente que genera la discrepancia.<\/li>\n
  5. Confirma el dato procesado y conserva un ejemplo antes y despu\u00e9s.<\/li>\n<\/ol>\n

    Las actualizaciones autom\u00e1ticas<\/a> pueden ayudar en determinadas discrepancias, pero no sustituyen una integraci\u00f3n consistente. Si cada sincronizaci\u00f3n vuelve a enviar el precio antiguo, corregirlo manualmente en un punto ser\u00e1 una soluci\u00f3n temporal.<\/p>\n

    Si el problema es disponibilidad, revisa variantes y tiempos<\/h2>\n

    Un producto puede existir en la tienda y no estar disponible para la variante o el pa\u00eds enviados. Contrasta el stock del ID afectado, la p\u00e1gina, las condiciones de compra y la frecuencia de actualizaci\u00f3n. Una plantilla que marca todo como disponible puede fallar aunque el inventario interno sea correcto.<\/p>\n

    La gu\u00eda oficial sobre disponibilidad que no coincide<\/a> describe la reparaci\u00f3n y la revisi\u00f3n. No interpretes la permanencia inmediata de una alerta como prueba de que la correcci\u00f3n fall\u00f3: puede faltar procesamiento o una nueva comprobaci\u00f3n. Verifica la secuencia y el estado antes de acumular cambios.<\/p>\n

    Ejemplo hipot\u00e9tico: una promoci\u00f3n que termina en la tienda<\/h2>\n

    Una tienda finaliza una promoci\u00f3n 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\u00f3gica y verifica un grupo de IDs afectados antes de extender el control al resto.<\/p>\n

    Solicitar una revisi\u00f3n sin arreglar esa tarea no habr\u00eda eliminado la causa: la siguiente sincronizaci\u00f3n volver\u00eda a introducirla. El ejemplo es hipot\u00e9tico y no representa un caso ni un resultado de SEOMOS. Sirve para distinguir una reparaci\u00f3n de datos de una simple nueva carga del archivo.<\/p>\n

    Qu\u00e9 documentar antes de solicitar revisi\u00f3n<\/h2>\n