Antes de anunciar, ordena tu feed de productos en Merchant Center
Proceso para alinear catálogo, página y Merchant Center, detectar desajustes por producto y corregir la fuente antes de invertir en campañas.

En este artículo8 secciones
Lectura práctica
9 min · 8 secciones principales
Antes de activar una campaña de Shopping o ampliar las fichas gratuitas, conviene tratar el feed como un contrato operativo, no como un archivo que marketing “sube” una vez. Cada producto debe conservar la misma identidad, precio, disponibilidad, variante, imagen y destino desde el sistema que gobierna el catálogo hasta Merchant Center.
La meta no es obtener una pantalla sin avisos por unos minutos. Es construir una ruta de corrección que permita responder dos preguntas: ¿en qué superficie nació el dato incorrecto y qué sistema debe corregirse para que el error no reaparezca en la siguiente sincronización? Este proceso sirve para tiendas que ya venden en línea y para equipos que están preparando su primera activación.
El feed no empieza en Merchant Center
Google advierte que la información incorrecta, imprecisa, faltante o contradictoria puede causar rechazos, limitar la elegibilidad o mostrar productos de forma incorrecta. También exige que datos como precio y disponibilidad coincidan con la página de destino y, cuando aplica, con la confirmación de compra. Por eso, revisar sólo la columna marcada en Merchant Center suele atender el síntoma, no la causa.
La cadena real suele tener al menos cuatro superficies: el catálogo del comercio —ERP, PIM, plataforma ecommerce o una hoja controlada—; la página del producto; los datos estructurados; y la fuente que recibe Merchant Center. Después vienen el procesamiento, los diagnósticos y los destinos publicitarios u orgánicos. Un cambio manual en el último eslabón puede quedar bien hoy y desaparecer mañana cuando vuelva a correr la fuente principal.
Empieza por dibujar esa cadena para tu operación. Anota quién puede editar cada tramo, cada cuánto se actualiza y qué evidencia permite saber si un cambio llegó al siguiente sistema. Si nadie puede explicar el recorrido de un precio desde el catálogo hasta la ficha pública, todavía no hay una fuente de verdad operable.
Define un contrato de producto antes de corregir filas
Para Albi, un contrato de producto es una lista breve de atributos, responsables y reglas de sincronización que todos los sistemas deben respetar. No es una función de Google ni requiere una herramienta específica. Su valor está en convertir un rechazo aislado en una decisión reproducible.
El contrato debería cubrir, como mínimo:
- Identidad: ID estable, SKU, marca cuando corresponda y los identificadores comerciales disponibles. Cambiar un ID para “reiniciar” un producto rompe continuidad y dificulta rastrear la corrección.
- Oferta: precio regular, precio promocional, moneda y vigencia. Define qué sistema abre y cierra una promoción y cómo evita enviar un descuento vencido.
- Inventario: estados admitidos, frecuencia de actualización y regla para reservar o liberar existencias. La página no debe prometer disponibilidad que el feed niega, ni al revés.
- Variantes: ID individual, agrupación, color, talla u otra característica distintiva, además de una URL que represente correctamente la selección.
- Destino y medios: URL canónica del producto, imagen principal, imágenes adicionales y permisos de rastreo. La fotografía debe representar la variante enviada.
- Entrega: configuración de envío, tiempos de procesamiento y cualquier condición mínima que realmente aplique a la oferta.
Para cada grupo agrega cinco columnas: sistema propietario, formato permitido, frecuencia, superficie pública donde se comprueba y responsable de corregir. Esa tabla evita que marketing edite precio, operaciones edite títulos y desarrollo edite disponibilidad sin saber cuál cambio sobrevivirá.

Elige la fuente según la operación que ya existe
Merchant Center admite distintas fuentes y métodos. La decisión no debería empezar por la opción más sofisticada, sino por la que pueda conservar datos actuales sin trabajo manual imposible de sostener.
- Conexión de plataforma: funciona cuando la tienda ya gobierna precio, inventario, variantes y URLs correctamente. Antes de activarla, confirma qué campos controla la integración y cómo se resuelve un dato que también llega por otra fuente.
- Archivo o Google Sheets: puede ser suficiente para un catálogo pequeño y estable si hay un dueño, validaciones y una frecuencia documentada. Deja de ser una solución segura cuando varias personas sobrescriben celdas o cuando precio e inventario cambian más rápido que la actualización.
- Merchant API: tiene sentido para operaciones que necesitan actualizaciones frecuentes o integración directa. Su costo no es sólo desarrollo inicial: requiere monitoreo, manejo de errores e identificación estable.
- Datos automáticos del sitio: pueden ayudar a actualizar precio, disponibilidad y estado desde la página y sus datos estructurados. Google aclara que esta automatización no sustituye las actualizaciones regulares de la fuente principal.
Si dos fuentes envían el mismo atributo, documenta cuál debe prevalecer. Evita “arreglar” el valor en una fuente secundaria sin modificar el sistema propietario: la conciliación posterior puede restaurar el error. Cuando la arquitectura ya no responde a la operación, una revisión de apps, web e integraciones puede ser más útil que seguir agregando parches.
Compara la página, el marcado y la variante exacta
No valides únicamente el producto padre. Elige una variante y recorre las superficies con su ID exacto. Compara título, precio, moneda, disponibilidad, URL e imagen en el catálogo fuente, la página renderizada, el marcado estructurado y Merchant Center.
Los datos estructurados de producto ayudan a Google a comprender y verificar la información de la página, pero no garantizan que una oferta se muestre. Para catálogos con variantes, la documentación de Google contempla ProductGroup, variesBy, hasVariant y productGroupID; además, cada variante debe poder identificarse y aterrizar en una URL que represente su selección. La implementación concreta depende de la plataforma, por lo que debe probarse en la página final, no sólo en una plantilla.
Haz la comparación en este orden:
- Busca el ID exacto en Merchant Center y revisa si ya terminó de procesarse.
- Abre la URL enviada, selecciona la variante y confirma lo que una persona puede comprar.
- Inspecciona el marcado generado para esa variante; no asumas que coincide con el texto visible.
- Regresa al sistema propietario y corrige ahí. Después vuelve a sincronizar y conserva evidencia del antes y el después.
Las imágenes merecen la misma disciplina. Una foto genérica o que no corresponde al color enviado deteriora la consistencia aun cuando el archivo tenga buena resolución. Si el catálogo visual todavía cambia entre variantes o sesiones, aplica primero un proceso de fotografía de producto consistente.
Prioriza por alcance e impacto, no por el orden de la bandeja
La sección “Requiere atención” es una entrada al diagnóstico, pero el orden de trabajo debe reflejar el negocio y el alcance técnico. Usa dos ejes: cuántos artículos comparten la causa —un SKU, una familia o todo el catálogo— y qué efecto tiene —no se publica, muestra información incorrecta o sólo pierde una mejora recomendada—.

Atiende primero las fallas de catálogo completo que bloquean o desinforman. Luego resuelve causas compartidas por una familia; después, casos de un solo SKU. Una excepción es cualquier producto que todavía pueda comprarse con precio o disponibilidad incorrectos: aunque afecte una sola variante, merece contención inmediata.
Ejemplo hipotético: si varias tallas reciben el mismo precio incorrecto porque una transformación ignora la promoción, corregir filas individuales sólo oculta el patrón. La acción durable es reparar la regla, volver a generar la fuente y revisar una muestra de variantes. Para saber si el cambio quedó estable, incorpora el diagnóstico a la analítica y medición, no a una captura aislada.
Incorpora los cambios de 2026 sin perder el orden
La actualización de especificaciones de 2026 agregó opciones de envío a nivel de producto, entre ellas handling_cutoff_time para una hora límite diaria de procesamiento y minimum_order_value para una compra mínima. También añadió etiquetas para beneficios de envío asociados con programas de lealtad. Estos atributos sólo deben enviarse cuando describen condiciones reales y su propietario está definido.
video_link es opcional. Desde el 30 de junio de 2026, los videos enviados pueden publicarse y reciben verificaciones de calidad y políticas; un problema del video impide publicar ese video, no la oferta asociada. No conviertas la novedad en prioridad si identidad, precio, inventario o variantes siguen sin conciliar.
Para image_link y additional_image_link, Google comenzó a emitir advertencias el 14 de abril de 2026 cuando las imágenes no cumplen el futuro mínimo de 500 × 500 píxeles. La aplicación del requisito inicia el 31 de enero de 2027. Una advertencia actual no equivale automáticamente a un rechazo actual, pero sí permite localizar deuda visual antes de la fecha. Revisa también rastreo, representación precisa y ausencia de imágenes genéricas.
Ejecuta una validación previa a pauta
Antes de ampliar inversión, selecciona una muestra que fuerce escenarios distintos: producto con precio regular, producto en promoción, producto agotado y una familia con variantes. Si el catálogo tiene reglas especiales de envío, agrega un caso que las active. La muestra no sustituye una revisión completa, pero revela si la ruta de datos funciona antes de exponer todo el inventario.
Para cada caso:
- Registra ID, variante, URL y sistema propietario.
- Compara precio, moneda, disponibilidad, título e imagen en las cuatro superficies.
- Clasifica el hallazgo por alcance e impacto.
- Corrige la fuente propietaria y ejecuta la sincronización normal.
- Busca de nuevo el ID exacto en Merchant Center. Considera que el procesamiento puede tardar de minutos a horas.
- Activa primero el subconjunto que ya está limpio y monitorea recurrencias; no uses la campaña como prueba de calidad del catálogo.
La presencia de un producto en Merchant Center no significa por sí sola que esté visible ni disponible en todos los destinos. Del mismo modo, cumplir las especificaciones habilita la participación, pero no garantiza ventas. La campaña necesita una oferta competitiva, una página utilizable y medición confiable; el feed ordenado evita que esas decisiones se apoyen en datos contradictorios.
Si tu equipo no puede seguir un error desde Merchant Center hasta la fuente que lo creó, el siguiente paso no es aumentar presupuesto. Es documentar el contrato de producto, asignar responsables y probar la sincronización con una muestra controlada. Albi puede ayudarte a conectar catálogo, sitio y medición para preparar una activación verificable en comercio, retail y ecommerce. Conversemos sobre tu implementación.
Fuentes consultadas
- Especificaciones de datos de productos de Merchant Center
- Actualización de las especificaciones de datos de productos para 2026
- Actualizaciones automáticas de artículos
- Cómo administrar las fuentes de datos
- Cómo verificar los datos de productos enviados
- Datos estructurados de producto y variantes
- Datos estructurados para variantes de productos