Cómo crear una ficha de producto que entiendan Google, los clientes y la IA

Una ficha, tres lectores y una sola verdad

Punto de partida

Una persona llega a una ficha para decidir si un producto resuelve su necesidad y si puede confiar en la compra. Google intenta identificar la entidad, relacionarla con una consulta y mostrar datos actuales. Un asistente de IA necesita comparar restricciones, atributos y condiciones para responder una pregunta concreta.

Los tres lectores no necesitan tres textos distintos. Necesitan la misma realidad expresada de forma clara en la página, organizada en campos consistentes y distribuida por los canales adecuados. Crear una versión persuasiva para humanos y otra inflada para máquinas multiplica contradicciones.

La arquitectura correcta parte del catálogo o PIM como fuente de verdad. De ahí salen la página visible, el marcado Product, el feed de Merchant Center, los marketplaces y, cuando proceda, otros feeds comerciales. Cada destino adapta el formato, pero no inventa el dato.

Una ficha se entiende cuando puede responder sin ambigüedad qué es el producto, qué variante se está viendo, cuánto cuesta, si está disponible, para quién sirve, qué incluye, cuándo llega y cómo se devuelve. Esa claridad también suele reducir soporte y devoluciones evitables.

Google no pide un schema mágico para aparecer en sus funciones de IA

AI Mode

Google Search Central explica que una página puede aparecer como enlace de apoyo en AI Overviews o AI Mode si está indexada, puede mostrarse con snippet y cumple los requisitos habituales de Search. No existe un requisito técnico adicional ni un tipo especial de schema.org para estas funciones.

La recomendación oficial sigue siendo permitir el rastreo, enlazar internamente la página, ofrecer una buena experiencia, mantener la información importante en texto y acompañarla con imágenes o vídeo de calidad. También pide que los datos estructurados coincidan con el texto visible y que Merchant Center esté actualizado.

Esto desmonta dos atajos. Un archivo creado únicamente para una supuesta IA no sustituye una ficha indexable; y añadir cientos de propiedades ocultas no arregla una página pobre. El dato estructurado ayuda a clasificar información que ya existe y es cierta.

Tampoco hay garantía de inclusión. Cumplir las directrices hace la página elegible, pero Google decide cuándo rastrea, indexa y muestra cada resultado. La estrategia debe mejorar la utilidad y la distribución, no vender una promesa de aparición.

Empieza por las preguntas que bloquean la compra

Contenido visible

Antes de escribir, reúne búsquedas internas, chats, correos, preguntas de preventa, motivos de devolución y objeciones de tienda física. Ese material revela cómo habla el cliente y qué información falta en el catálogo.

Para una zapatilla de senderismo, las preguntas no terminan en color y talla. El comprador puede necesitar saber si la horma es estrecha, qué terreno soporta, cuánto pesa, si la membrana es impermeable, si la plantilla se extrae y cómo elegir talla con calcetín grueso.

La ficha debería contestar primero lo decisivo. Un resumen breve identifica producto, uso principal y diferencia verificable; después aparecen selección de variante, precio, disponibilidad, entrega, devolución y llamada a la compra. Especificaciones, guía, reseñas y FAQs amplían la decisión sin ocultar condiciones esenciales.

Escribir para la persona también mejora la extracción automática porque convierte afirmaciones vagas en hechos. 'Rendimiento increíble' no puede compararse. 'Peso de 410 gramos por zapatilla en talla 42' sí, siempre que la medición y la talla de referencia sean reales.

• Qué es y para qué uso está diseñado.
• Quién debería elegirlo y quién necesita otra opción.
• Medidas, materiales, compatibilidad y contenido del paquete.
• Variante seleccionada, precio, stock, entrega y devolución.
• Limitaciones, mantenimiento, garantía y documentos útiles.

El título identifica; la descripción ayuda a decidir

Copy de producto

El nombre debe ser estable y distinguir el producto sin promociones temporales. Una estructura habitual combina marca, modelo, tipo de producto y atributos que separan la variante, como color, capacidad o talla cuando la URL representa esa variante.

Merchant Center exige título y descripción y recomienda incluir características relevantes. Prohíbe usar la descripción como espacio para promociones, enlaces, información de pago o comparaciones ajenas al producto. El feed tiene sus propias reglas; no conviene copiar sin revisar todo el texto comercial de la web.

En la página, la descripción puede explicar beneficio y contexto, pero cada afirmación debe apoyarse en una característica. En lugar de 'la mejor zapatilla para cualquier aventura', resulta más útil explicar el tipo de suela, la protección, el rango de terreno y las condiciones para las que no se recomienda.

No hace falta repetir la misma frase en H1, subtítulo, pestañas y FAQ. La repetición ocupa espacio sin añadir evidencia. Cada bloque debe responder una parte distinta de la decisión y mantener el mismo vocabulario para el producto.

SKU, GTIN, marca y MPN ayudan a saber de qué producto se habla

Identidad

Los nombres comerciales pueden parecerse, cambiar por país o repetirse entre variantes. Los identificadores permiten conectar la oferta de una tienda con el producto correcto y diferenciar una unidad real de otra.

El SKU es el identificador interno de la oferta o variante. El GTIN identifica globalmente un producto cuando el fabricante lo ha asignado. El MPN es la referencia del fabricante y la marca indica quién lo produce. No se debe fabricar un GTIN ficticio para rellenar un campo.

Google permite expresar estos valores mediante propiedades como sku, gtin, mpn y brand en Product, y mediante sus atributos correspondientes en Merchant Center. Deben conservar formato y valor a través de página y feed.

En productos propios sin GTIN, se declara la situación de acuerdo con las especificaciones del canal y se utiliza una combinación estable de marca y MPN cuando corresponda. La ausencia legítima de un identificador es preferible a un dato falso que mezcle entidades.

• SKU: identifica tu variante dentro del catálogo.
• GTIN: identifica globalmente el artículo cuando existe.
• MPN: referencia asignada por el fabricante.
• Marca: organización responsable del producto.
• ID de grupo: reúne variantes del mismo producto padre.

Los atributos importantes no deberían vivir enterrados en un párrafo

Especificaciones

Material, dimensiones, peso, capacidad, compatibilidad, consumo, cuidados y certificaciones deben aparecer en una tabla o lista con nombre y valor. El texto narrativo puede explicar por qué importan, pero no debería ser el único lugar donde existen.

La estructura facilita comparación, filtros, atención al cliente y reutilización en feeds. También permite validar que una unidad sea coherente: centímetros frente a milímetros, peso neto frente a peso embalado o capacidad útil frente a total.

Google Merchant Center dispone de product detail para especificaciones adicionales, organizado por sección, atributo y valor. La documentación indica que este detalle puede mejorar la comprensión en superficies tradicionales y guiadas por IA.

Cada categoría necesita su diccionario. Una tabla universal termina llena de campos irrelevantes. Define atributos obligatorios por tipo de producto, unidad controlada, valores permitidos, responsable y evidencia de origen.

Las variantes deben cambiar la página, la oferta y los datos

ProductGroup

Seleccionar una talla o color no puede ser un cambio meramente visual si precio, stock, imagen, SKU o entrega son distintos. La variante elegida debe quedar identificada y sus datos deben actualizarse de forma accesible.

Google documenta ProductGroup para agrupar variantes con productGroupID, variesBy y hasVariant, junto a Product. Los factores admitidos incluyen color, talla, edad sugerida, género sugerido, material y patrón.

Una tienda puede utilizar una página única para las variantes o URLs diferenciadas, pero debe aplicar correctamente canonical, enlaces y marcado según su arquitectura. En una URL por variante, el contenido y la oferta tienen que describir esa variante concreta.

El error frecuente es enviar al feed una variante disponible y mantener en el HTML el precio o stock del producto padre. Otro es usar el mismo SKU para todos los colores. Esas inconsistencias dificultan identificación, actualización y medición.

Precio, stock, envío y devolución forman una sola promesa

Oferta

El comprador interpreta estas condiciones en conjunto. Un precio atractivo pierde valor si el envío aparece tarde, la fecha es ambigua o la devolución tiene un coste inesperado. Para una máquina, una oferta desactualizada puede recomendar un artículo sin stock o con un precio que ya no existe.

El marcado Offer admite precio, moneda, disponibilidad, condición y URL, y las experiencias de merchant listing pueden incorporar envío y política de devolución. La página visible, el checkout, JSON-LD y Merchant Center deben proceder de la misma actualización.

Google recomienda mantener precio y disponibilidad al día mediante feeds frecuentes, API o datos estructurados. Las discrepancias pueden provocar errores o desaprobaciones y, antes de eso, rompen la confianza del cliente.

En 2026, Merchant Center añadió atributos de envío como hora límite de preparación y pedido mínimo. No todos los comercios necesitan cada campo, pero sí una definición operativa capaz de responder cuándo se prepara, cuánto cuesta y qué condiciones cambian por país o producto.

• Precio final de la variante y moneda correcta.
• Disponibilidad real, no stock almacenado en caché durante días.
• Coste y plazo según destino y hora de pedido.
• Condición del artículo: nuevo, usado o reacondicionado.
• Plazo, coste y requisitos de devolución visibles antes de pagar.

Las imágenes y el vídeo deben demostrar, no decorar

Contenido visual

Una galería útil muestra el producto completo, ángulos, textura, escala, detalle funcional, accesorios incluidos y uso real. El color debe aproximarse al artículo y cada variante necesita imágenes que correspondan con la selección.

El texto alternativo describe la imagen en contexto y ayuda a la accesibilidad; no es una lista de palabras clave. Los nombres de archivo, dimensiones estables y recursos rastreables completan una implementación técnica básica.

La actualización 2026 de Merchant Center incorporó video link como atributo opcional. Desde el 30 de junio de 2026, Google comenzó a validar política y calidad para que esos vídeos pudieran mostrarse. El vídeo debe enseñar el producto y no sustituir especificaciones escritas.

Google también anunció que el mínimo de 500 por 500 píxeles para imágenes de producto se aplicará desde el 31 de enero de 2027. Cumplir el mínimo evita incidencias; para que el comprador inspeccione el producto conviene partir de originales mayores y nítidos.

Product y Offer traducen la ficha a un formato estándar

JSON-LD

Los datos estructurados permiten clasificar explícitamente el producto y su oferta. En una ficha comprable, Product puede incluir nombre, descripción, imagen, marca e identificadores; Offer añade URL, precio, moneda, disponibilidad y condición.

Según el caso, también pueden expresarse valoraciones reales, detalles de envío y política de devolución. No todas las propiedades son obligatorias ni todas producen una mejora visible. La documentación de Google, no una plantilla antigua, debe decidir qué se implementa.

Google recomienda JSON-LD y exige que el marcado represente el contenido de la página. Añadir una valoración no visible, un precio sin impuestos cuando la página muestra otro o InStock para una variante agotada incumple el principio básico de coherencia.

La validación tiene dos niveles: sintaxis y realidad. Rich Results Test puede detectar propiedades o formatos problemáticos; una prueba de negocio debe comparar el JSON-LD renderizado con la variante, el precio y la disponibilidad que ve una persona.

• Product: name, description, image, brand, sku, gtin o mpn cuando correspondan.
• Offer: url, price, priceCurrency, availability e itemCondition.
• ProductGroup: grupo, propiedades comunes y variantes reales.
• AggregateRating y Review: solo con reseñas auténticas y visibles.
• Shipping y returns: únicamente si las reglas coinciden con la oferta.

Merchant Center y los datos estructurados se complementan

Distribución

El marcado vive en cada página y ayuda a Google a recuperar información actual. El feed permite enviar el catálogo de forma sistemática, controlar atributos, programar actualizaciones y revisar incidencias en Merchant Center.

Google explica que usar ambos maximiza la elegibilidad y ayuda a verificar datos. No deben gestionarse como bases independientes. Una promoción, cambio de stock o nueva variante debería actualizar el sistema de origen y propagarse con una latencia conocida.

El feed aporta campos que no siempre tienen equivalencia directa en schema.org, mientras la página aporta contexto, contenido visible y experiencia de compra. La combinación es más completa que cualquiera de las dos capas aislada.

El control diario debe buscar productos rechazados, diferencias de precio, imágenes inválidas, identificadores ausentes y URLs que no conducen a la variante enviada. El volumen de productos aprobados no sustituye la calidad del dato.

Los atributos conversacionales convierten preguntas en datos de catálogo

Merchant Center 2026

Google documenta atributos conversacionales opcionales para complementar la especificación principal: question and answer, document link, related product, item group title, variant option y popularity rank. Están diseñados para ayudar a experiencias como AI Mode a comprender matices del producto.

Una FAQ puede aclarar si la zapatilla admite una plantilla ortopédica. Un documento puede enlazar el manual. Related product puede distinguir accesorio, pieza necesaria, sustituto o artículo comprado junto a él. Variant option enumera las propiedades que identifican una variante.

La documentación recomienda una fuente suplementaria o el feed principal y permite Merchant API. También advierte que no hace falta duplicar información que ya se envía correctamente en description, product highlight o product detail.

Estos campos no autorizan a generar respuestas imaginarias. Cada relación, respuesta y documento debe estar validado por producto u operaciones. Una IA puede amplificar un dato útil, pero también una incompatibilidad falsa.

• question_and_answer: dudas específicas con respuesta comprobada.
• document_link: manuales o instrucciones relacionados.
• related_product: accesorios, piezas, sustitutos o compras conjuntas.
• item_group_title y variant_option: contexto de familia y variante.
• popularity_rank: posición relativa dentro del inventario del comercio.

ChatGPT también trabaja con información pública y datos de producto

Otros asistentes

OpenAI explica que amplió Agentic Commerce Protocol para que los comercios compartan feeds de producto y promociones con ChatGPT. El objetivo declarado es disponer de información más completa y actualizada durante el descubrimiento y la comparación.

Según su anuncio de marzo de 2026, existen varias vías de entrega, incluidas integraciones mediante proveedores como Salesforce y Stripe. Los productos de comercios Shopify se incorporan mediante Shopify Catalog sin que cada tienda tenga que realizar un trabajo adicional individual.

Esto no significa que una ficha solo deba prepararse para ChatGPT ni que enviar un feed garantice una recomendación. La información pública, las reseñas y otras fuentes pueden formar parte del contexto, y los sistemas cambian.

La decisión robusta es conservar catálogo limpio, URLs accesibles, identificadores, atributos, stock y condiciones consistentes. Después se habilitan canales concretos según plataforma, mercado y capacidad de mantenerlos.

FAQs y reseñas aportan lenguaje real, pero no deben fabricarse

Confianza

Las preguntas frecuentes funcionan cuando nacen de dudas repetidas y responden de forma específica. Una lista genérica escrita solo para ampliar texto añade poco y puede ocultar contradicciones con la política de envío o garantía.

Las reseñas ayudan a conocer ajuste, uso prolongado y problemas que la marca no había previsto. Deben moderarse con reglas transparentes y mantener tanto señales positivas como críticas legítimas. Resumirlas no permite cambiar su sentido.

Los datos estructurados de valoración deben corresponder con opiniones que aparecen en la página y cumplir las directrices aplicables. No se marca una puntuación editorial como si fuera un agregado de compradores ni se importan cifras sin trazabilidad.

La autoridad del producto también se construye con manuales, soporte, información del fabricante, páginas de categoría coherentes y menciones externas. Una ficha técnicamente perfecta no compensa un comercio sin identidad, condiciones o atención reconocible.

La información decisiva debe existir en el HTML que puede rastrearse

SEO técnico

Una ficha puede verse bien en el navegador y entregar poco contenido al rastreador si todo depende de una interacción, una API bloqueada o JavaScript que falla. Nombre, descripción, oferta y enlaces esenciales deberían renderizarse de forma fiable.

Las variantes necesitan enlaces descubribles cuando tienen URLs propias. El sitemap debe incluir páginas canónicas indexables, no combinaciones de filtros sin valor. Robots, noindex, canonical y estado HTTP tienen que expresar la misma intención.

La velocidad también afecta al comprador. Imágenes enormes, aplicaciones de reseñas, selectores y personalización pueden retrasar la información principal o mover el botón de compra. Reservar dimensiones y priorizar el contenido visible evita saltos.

La prueba debe cubrir móvil, usuario sin sesión, Googlebot mediante inspección de URL y variante agotada. Una ficha que solo funciona con cookies previas o una localización concreta puede estar distribuyendo datos incompletos.

Ejemplo: convertir una zapatilla genérica en una entidad comprensible

Antes y después

Una ficha débil muestra 'Zapatilla Trek Pro', cuatro fotografías y 'máxima comodidad'. El selector cambia de color, pero la URL, el SKU, la imagen principal y el stock del marcado permanecen iguales. La guía de tallas es una imagen pequeña y la devolución aparece en el footer.

La versión útil identifica marca, modelo, categoría y variante; explica terreno recomendado y límites; ofrece peso con talla de referencia, drop, material, membrana, suela, horma, cuidados y contenido. La tabla utiliza unidades consistentes y la guía de talla es texto accesible.

Cada combinación vendible conserva SKU y stock. ProductGroup reúne la familia; Product y Offer describen la variante; Merchant Center recibe ID, grupo, atributos, imágenes, precio y disponibilidad equivalentes. La FAQ contesta plantilla extraíble, impermeabilidad y elección de talla con datos validados.

No se ha escrito para un robot. Se ha eliminado ambigüedad para que comprador, soporte, buscador y asistente trabajen con la misma zapatilla y no con cuatro versiones incompatibles.

Una auditoría útil comprueba presencia, coherencia y actualización

Control de calidad

Marcar un campo como presente no basta. El precio puede existir y estar desactualizado; el GTIN puede tener formato válido y pertenecer a otro artículo; una imagen puede cargar y enseñar un color distinto.

Para una muestra de productos, compara base de catálogo, página visible, código renderizado, JSON-LD, feed y checkout. Repite con varias categorías, variantes agotadas, promociones, países y dispositivos.

Registra propietario y frecuencia de cada dato. Stock puede cambiar en minutos; dimensiones, solo cuando cambia el producto; devolución, por país o política. La actualización debe responder al riesgo de cada campo.

Después mide resultados: errores de Merchant Center y Search Console, cobertura válida, clics, conversión, consultas internas, contactos de preventa y devoluciones por descripción o incompatibilidad. El rich result es un medio, no el resultado comercial.

• Presencia: el campo necesario existe.
• Exactitud: coincide con producto y condición comercial.
• Consistencia: página, marcado, feed y checkout dicen lo mismo.
• Actualidad: se refresca con la frecuencia adecuada.
• Trazabilidad: tiene fuente, fecha y responsable.

Un plan de treinta días para ordenar el catálogo

Implementación

Durante la primera semana, elige veinte productos que combinen ventas, margen, consultas y devoluciones. Documenta qué campos existen y dónde nacen. Identifica contradicciones antes de añadir nuevas herramientas.

La segunda semana define plantilla y diccionario por categoría: nombre, identificadores, atributos, unidades, variantes, imágenes, preguntas, oferta y políticas. Asigna responsables de producto, operaciones, tecnología y SEO.

La tercera semana implementa o corrige Product, Offer y ProductGroup, sincroniza Merchant Center y valida páginas renderizadas. Despliega primero una muestra y observa errores antes de extenderla a todo el catálogo.

La cuarta semana mejora contenido visible con preguntas reales, revisa imágenes y mide una línea base de conversión, soporte y devoluciones. Solo después incorpora atributos conversacionales o nuevos feeds que el equipo pueda mantener.

• Días 1-7: muestra, inventario de datos y contradicciones.
• Días 8-14: plantilla, diccionario y propietarios.
• Días 15-21: marcado, feed, validación y despliegue controlado.
• Días 22-30: contenido, visuales, medición y expansión.

Siete errores que hacen ilegible una ficha aparentemente completa

Checklist final

La mayoría de fallos no procede de olvidar una palabra clave. Procede de tratar cada superficie como un proyecto independiente o de rellenar campos sin gobierno del dato.

El catálogo gana visibilidad sostenible cuando sus hechos son concretos, accesibles y actualizables. La creatividad sigue siendo importante en fotografías, demostración y explicación, pero no debe alterar identidad o condiciones.

Antes de publicar una variante, pregunta si una persona podría comprarla sin sorpresa y si un sistema podría distinguirla de las demás sin inferir datos ausentes. Si alguna respuesta es negativa, la ficha todavía no está terminada.

• Ocultar información esencial dentro de imágenes o pestañas inaccesibles.
• Usar el mismo SKU, URL o stock para variantes distintas.
• Mostrar un precio y enviar otro al marcado o al feed.
• Inventar GTIN, reseñas, compatibilidades o preguntas frecuentes.
• Añadir schema que no corresponde con el contenido visible.
• Duplicar atributos hasta crear versiones contradictorias.
• Medir validación técnica sin conversión, soporte ni devolución.

La mejor optimización es reducir la distancia entre producto y dato

Conclusión

Google, un cliente y un asistente no interpretan la ficha de la misma manera, pero todos sufren la misma incoherencia. Precio antiguo, talla ambigua, imagen incorrecta o compatibilidad inventada empeoran descubrimiento y compra.

La solución no consiste en escribir para máquinas. Consiste en observar el producto, registrar sus atributos, explicar decisiones, estructurar la oferta y distribuir la misma verdad mediante página y feeds.

Los nuevos campos conversacionales amplían las posibilidades, pero llegan después de identidad, variantes, contenido, precio, stock y políticas. Una capa avanzada construida sobre un catálogo débil solo hace circular el error más deprisa.

Una ficha entendible es una pieza de infraestructura comercial: ayuda a descubrir, comparar, comprar, atender y devolver mejor. Ese valor permanece aunque cambie la interfaz desde la que llega el próximo cliente.