Un catálogo en Merchant no se "sube": se mantiene. Cada día la web cambia precios, stock y páginas; cada día Google rastrea y compara; cada día algo deja de cuadrar. Esta lección es el mantenimiento — y por qué el catálogo limpio es una ventaja competitiva, no un trámite.
Leer el Diagnóstico
Merchant Center → Productos → Diagnóstico (o Necesita atención):
- Problemas de la cuenta: afectan a todo (políticas, sitio, envío). Prioridad absoluta.
- Problemas de productos: por motivo, con el número de productos afectados y los productos concretos (descargables). Hay tres gravedades: errores (desaprobación), advertencias (el producto sirve pero limitado o con riesgo) y notificaciones (mejoras).
- Problemas de la fuente de datos: el archivo no se procesó bien (columnas, codificación, filas inválidas).
Estados de producto:
| Estado | Significado | Acción |
|---|---|---|
| Aprobado | Sirve en todos los destinos | — |
| Aprobado (limitado) | Sirve, pero con menos visibilidad (datos pobres, imagen, sin GTIN, "limitado por rendimiento") | Enriquecer |
| Desaprobado | No sirve | Corregir la causa; reprocesa en la siguiente actualización |
| Pendiente | En revisión (nuevo producto: hasta 3 días hábiles) | Esperar |
| Caducado | Más de 30 días sin actualización de la fuente | Reactivar el feed |
El diagnóstico tiene historial por fechas: un salto de desaprobados coincide con un cambio (rediseño, migración, cambio de IVA): es el primer sitio donde mirar cuando Shopping "se cae".
El problema número uno: precios y stock desincronizados
Google rastrea la página y compara con el feed; si el precio o la disponibilidad no coinciden en el momento del rastreo, desaprueba. Las causas: ofertas flash, precios por variante, IVA, redondeos, stock que se agota entre actualizaciones, caché de la web.
Tres soluciones por tamaño:
- Tienda pequeña (fetch diario): feed programado a la hora en que cambian los precios (tras la actualización del ERP), datos estructurados correctos en la ficha y actualizaciones automáticas activadas (Google corrige precio y disponibilidad desde la página sin desaprobar, dentro de un margen).
- Tienda media (varias veces al día): feed principal diario +
feed suplementario de precio/stock cada 1-2 horas (solo
id,price,sale_price,availability) — ligero y frecuente. - Tienda grande o precios dinámicos (tiempo real): Merchant API (antes Content API): la tienda envía cada cambio de precio/stock al instante. Es la solución definitiva; las plataformas grandes lo hacen por ti.
Datos estructurados (schema.org/Product → Offer con price,
priceCurrency, availability, itemCondition): Google los lee para
verificar. Sin ellos, las actualizaciones automáticas no funcionan y las
comparaciones son menos fiables. Comprueba con la herramienta de
resultados enriquecidos.
Calidad del catálogo: de "aprobado" a "competitivo"
Aprobado no es suficiente. Google gradúa la calidad de datos y la usa en la subasta de Shopping (relevancia) y en la visibilidad (listados gratuitos, fichas de comparación):
- Completitud: cuantos más atributos válidos (imágenes adicionales, highlights, detail, color/material/talla, GTIN), más contextos donde aparecer.
- Coherencia: precio/stock/envío = web.
- Imágenes: calidad, tamaño, fondo, varias vistas.
- Identificadores: GTIN empareja con el catálogo de Google → reseñas agregadas, "comparar precios", informe de competitividad de precios (lección 5).
- Limitado por rendimiento: Google recorta la entrega de productos con datos pobres que además no rinden; la salida es enriquecer.
La calidad del catálogo es el único factor de Shopping que la competencia no ve ni puede copiar: es tu ventaja silenciosa.
Frecuencia de actualización real
- Fetch programado: una vez al día (hora elegible); más, con API.
- Reprocesado tras corregir: el producto pasa a pendiente y se revisa en horas (hasta 3 días si es nuevo).
- Caducidad: producto sin actualizar en 30 días → caducado; feeds abandonados se vacían solos.
- Cambios de precio en la web sin cambio de feed: desaprobación hasta el siguiente fetch (por eso la frecuencia importa).
Rutina semanal de mantenimiento (30 min)
- Diagnóstico: problemas de cuenta → cero; errores por motivo (tendencia frente a la semana anterior).
- Desaprobados por precio/disponibilidad: si > 1-2 %, subir frecuencia o arreglar sincronización.
- Limitados: los 20 productos de más ventas con "limitado" → enriquecer.
- Nuevos productos en pendiente > 3 días → revisar.
- Productos caducados o sin impresiones con stock → títulos/categoría.
- Feed suplementario: títulos de los productos con más gasto y pocas ventas (lección 2).
- Alertas: activar los correos de Merchant y, mejor, automatizarlas.
🔧 Esto lo resuelve el script: el Shopping Ninja lee el rendimiento por producto desde Google Ads y lo cruza con la hoja del cliente (ventas reales, márgenes) para señalar productos desaprobados, sin impresiones, o que gastan sin vender; genera títulos optimizados para un feed suplementario y permite excluir o negativizar por casilla con historial. Es el mantenimiento del catálogo convertido en una hoja con acciones, en vez de una inspección manual semanal.
Qué debes recordar
- El Diagnóstico es el tablero: problemas de cuenta primero, después errores de producto por motivo, con historial para detectar el cambio que los causó.
- El problema número uno es la desincronización de precio/stock: fetch a la hora correcta + datos estructurados + actualizaciones automáticas; suplementario frecuente; API para tiempo real.
- Aprobado no basta: calidad de datos (completitud, imágenes, GTIN) decide relevancia y visibilidad; "limitado" se arregla enriqueciendo.
- Rutina semanal de 30 minutos — o automatizada.