Schema de comercio

TL;DR — “Commerce schema” es mi forma abreviada de referirme a los tipos de schema.org que usas para marcar cosas que las personas pueden buscar y usar para actuar — productos para comprar y empleos para postularse. Hay tres: Product (un artículo en venta), ProductGroup (un grupo de variantes, como una camisa en varias tallas y colores) y JobPosting (un único empleo abierto). Añade el adecuado y tu página se vuelve elegible para un listado de búsqueda más atractivo — resultados de productos estilo Shopping o una tarjeta de Google Jobs. No hace que tu página posicione más alto, no garantiza que el resultado se muestre realmente ni obtenga más clics, y tampoco es una forma de conseguir que la IA te cite. Este centro te dirige al tipo correcto; las tablas completas de propiedades están en el artículo propio de cada tipo.

Qué significa “commerce schema”

El término «schema de comercio» es una agrupación práctica, no un único tipo de schema.org ni una función de Google. Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product Google documenta requisitos y condiciones de elegibilidad de marcado de datos estructurados distintos para productos, listados de comerciantes y organizaciones. Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

Cuando miras una página que vende una chaqueta, puedes distinguir el precio, las opciones de color y la etiqueta “in stock” con solo leer. Un motor de búsqueda ve texto sin formato y tiene que adivinar. El marcado de datos estructurados es código que añades para especificarlo — “este es el precio”, “esta es la disponibilidad”, “este es un título de empleo” — usando un vocabulario compartido de un sitio llamado schema.org.

“Commerce schema” no es un término oficial. Es solo mi término paraguas para los tipos de schema.org que describen listados comerciales o transaccionales — elementos individuales que una persona puede buscar, filtrar y con los que puede hacer algo:

• Product — un único artículo que está a la venta.
• ProductGroup — un elemento principal que reúne las variantes de un artículo (tallas, colores) para que los motores de búsqueda sepan que son opciones del mismo artículo, no productos separados.
• JobPosting — un puesto abierto en una página de empleo.

Agrupo estos tres porque comparten una función en SEO: los añades para que Google pueda convertir tu listado en un resultado de búsqueda especializado. Pero que quede claro — Google y schema.org no los clasifica juntos. Retomaré esa honestidad en la pestaña Advanced, porque importa.

La función de este centro se deriva de eso: es un enrutador, no la guía de implementación. A continuación, averigua cuál de los tres tipos corresponde a tu página y luego lee el análisis detallado de ese tipo (y, cuando estén involucradas reseñas, devoluciones o envíos, los registros adyacentes Review/MerchantReturnPolicy/OfferShippingDetails) para las tablas de propiedades reales.

Por qué vale la pena: resultados enriquecidos

La recompensa son los resultados enriquecidos — los listados mejorados que destacan en la búsqueda:

• 🛍️ un producto con precio, una etiqueta “in stock” y estrellas de reseñas
• 👕 un producto que muestra sus opciones de talla y color
• 💼 un empleo que aparece en el cuadro de empleos de Google con la empresa, la ubicación y el salario

Añade los datos estructurados correspondientes con todos sus detalles obligatorios y tu página será elegible para ese tratamiento. Elegible, nunca garantizado: Google sigue decidiendo si realmente lo muestra.

Lo que la mayoría de las personas entiende mal

Añadir datos estructurados de comercio no hace que posiciones más alto. Google lo ha dicho clara y repetidamente. Lo que hacen los datos estructurados es hacerte elegible para un listado más enriquecido y ayudar a los motores de búsqueda a entender tu página. Eso es diferente de posicionar mejor — y ser elegible tampoco es lo mismo que estar garantizado: un marcado válido no promete que el resultado enriquecido realmente se muestre, no promete más clics y no es una forma de ser citado en una respuesta de IA. Trata cada uno de esos como un resultado independiente.

Una trampa más para principiantes: estos tipos no son intercambiables. Usa Product para un solo artículo, ProductGroup cuando ese artículo tiene variantes y JobPosting para una oferta de empleo — y nunca para una página que enumera varios empleos a la vez. Esa última regla es más estricta de lo que la mayoría espera.

¿Quieres la versión completa — dónde se ubican estos en la jerarquía de schema.org, cómo se conecta cada uno con Merchant Center y Google Jobs, y qué artículo leer a continuación? Cambia a la pestaña Avanzado.

TL;DR — “Commerce schema” es mi agrupación como profesional, no una categoría de Google ni de schema.org, para los tipos de listados que obtienen resultados enriquecidos transaccionales: Product, ProductGroup y JobPosting. Google de hecho los separa: Product/Variantes se encuentran bajo “Shopping”, y Job posting está en la lista general de guías de funciones. schema.org tampoco los unifica: Product → ProductGroup es una relación real de padre/hijo (Thing > Product > ProductGroup), mientras que JobPosting está en la rama Intangible (Thing > Intangible > JobPosting), sin relación con Product. Lo único que une a los tres es el caso de uso de SEO — listados estructurados que Google convierte en un tratamiento especializado en la SERP (listados de Merchant, Google Jobs). Nada de esto es un factor de posicionamiento; consigue elegibilidad — no una visualización garantizada, un aumento del CTR ni una cita de IA, que son tres resultados separados y no garantizados. La elegibilidad de Review/AggregateRating se rige por su propio perfil separado, y los datos de devolución/envío se dividen en una política a nivel de Organization más excepciones a nivel de Offer — dos contratos más a los que este centro solo redirige. Y el riesgo del ciclo de vida difiere entre los tres: un Product desactualizado principalmente pierde elegibilidad, pero un JobPosting desactualizado y no caducado puede activar una acción manual.

Primero, un planteamiento honesto: esta es mi agrupación, no la de Google

La agrupación de este artículo combina varios vocabularios y funciones de búsqueda relacionados por comodidad. Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product Cada experiencia de Google tiene sus propias propiedades obligatorias y recomendadas, y un marcado válido no garantiza la visualización. Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

Quiero ser transparente desde el principio, porque la mayor parte del contenido que habla sobre los datos estructurados de “commerce” o “ecommerce” implica sutilmente que estos tipos son una familia oficial. No lo son.

• La propia documentación de Google los separa. En la galería de datos estructurados, “Job posting” aparece en la lista plana y general Feature guides, justo junto a tipos no relacionados como Article, Local business y Organization. Mientras tanto, “Product snippet”, “Merchant listing” y “Variants” están bajo un subtítulo independiente de Shopping. Dos familias de documentación diferentes.
• schema.org no los unifica. Su propia jerarquía de tipos tiene un grupo dedicado a “Product, Offer, and AggregateOffer” (traducción) «Product, Offer y AggregateOffer», y JobPosting no aparece en ningún agrupamiento de nivel superior junto a él.

Entonces, ¿por qué ponerlos en un solo artículo? Porque en la práctica —la forma en que realmente trabaja un profesional SEO — son el mismo tipo de problema: contenido estructurado y en forma de listado que marcas para desbloquear una experiencia de búsqueda especializada. Ese caso de uso compartido es real y útil. La taxonomía compartida no lo es. Prefiero decirlo sin rodeos que fingir que Google dibujó esta caja.

Los tres tipos de un vistazo

• Product (schema.org/Product) — un único artículo vendible. Google convierte el marcado válido de Product en dos experiencias: fragmentos de producto (estrellas de reseña y precio en páginas que no son de compra) y listados de comerciantes (resultados más completos al estilo Shopping en páginas donde puedes comprar el artículo). Lo mínimo para un resultado enriquecido: name más al menos uno de offers, review o aggregateRating — pero la vía de review/ aggregateRating se rige por las reglas separadas de Google para los fragmentos de reseña (su propio perfil de elegibilidad, incluida la restricción de reseñas autointeresadas), no una regla general de “cualquier página de producto puede mostrar estrellas”. No toda página de Product o de comerciante califica automáticamente para estrellas de reseña; consulta el análisis detallado de Review Schema para ese perfil.
• ProductGroup (schema.org/ProductGroup) — un elemento primario que agrupa las variantes de un artículo conceptual (una camiseta en varias tallas y colores) para que Google entienda que son opciones del mismo producto, no listados no relacionados. Vincula las variantes entre sí con hasVariant, variesBy y productGroupID. Es crucial que no reemplaza a Product — cada variante sigue siendo su propio Product completo; el ProductGroup se sitúa por encima de ellas.
• JobPosting (schema.org/JobPosting) — una única oferta de empleo, con marcado para que sea elegible para la experiencia Google Jobs (la tarjeta/carrusel de listados en Search). Las propiedades requeridas básicas son title, description, datePosted, hiringOrganization y jobLocation (o applicantLocationRequirements para roles totalmente remotos).

Mantengo esta página central deliberadamente superficial en las tablas de propiedades de cada tipo — los análisis en profundidad están en los tres artículos secundarios que señalo al final.

Dónde se ubican en la jerarquía de schema.org

Esta es la parte que casi nadie cita correctamente, y es la diferencia entre una suposición y un hecho:

• Product — Thing > Product.
• ProductGroup — Thing > Product > ProductGroup. Es un subtipo de Product genuino, hereda todas las propiedades de Product y añade hasVariant, productGroupID y variesBy. Por tanto, “Product vs ProductGroup” no es una disyuntiva real — ProductGroup es un Product especializado, diseñado específicamente para el caso de variantes.
• JobPosting — Thing > Intangible > JobPosting. Una rama completamente separada. La definición de JobPosting no hace referencia a Product, Offer ni a ningún tipo de comercio.

Conclusión: Product y ProductGroup están relacionados taxonómicamente (padre/hijo, verificable, citable); JobPosting no está relacionado taxonómicamente. El hilo conductor entre los tres es el caso de uso de SEO, no la herencia de tipos. Di eso, y estarás en terreno sólido.

Product vs. ProductGroup: cuándo usar cada uno

Regla simple:

• Una configuración comprable → Product simple. Un único SKU, un precio, una página que se puede comprar.
• Un elemento conceptual, varias variantes comprables → ProductGroup que envuelve a sus miembros Product. El caso de la camisa en cinco colores. Un ProductGroup en sí no se ofrece a la venta; sus miembros hasVariant sí, cada uno con su propio sku/gtin, precio y disponibilidad.

Google también documenta ProductGroup de manera diferente: está en la página Variants, no como una guía de función independiente de nivel superior, lo que refuerza que Google lo trata como una extensión de Product en lugar de un tipo de resultado enriquecido completamente separado. Las tablas de propiedades completas, la trampa de la URL completa de variesBy y la conciliación de item_group_id de Merchant Center corresponden al análisis detallado de ProductGroup, no aquí.

JobPosting: el caso atípico

JobPosting no comparte nada taxonómicamente con Product, pero tiene la misma forma de problema, por lo que se gana su lugar en este centro. Dos cosas lo diferencian operativamente:

1. Un trabajo por página, siempre. La regla de Google: “The JobPosting markup must only be used on pages that contain a single job posting.” (traducción) «El marcado JobPosting solo debe usarse en páginas que contengan una única oferta de empleo.» Nunca en una página de listado o de resultados de búsqueda. Product/ProductGroup no tiene una restricción equivalente de un solo elemento por página; de hecho, ProductGroup existe precisamente para manejar varias variantes en una página.
2. Las ofertas vencidas son una obligación de cumplimiento, no algo de configurar y olvidar. Más sobre el riesgo a continuación: aquí es donde lo que está en juego diverge más de Product.

Reglas comunes a los tres

Aunque los tipos no comparten una taxonomía, comparten las directrices generales de datos estructurados de Google, y vale la pena establecer las reglas una sola vez:

• Las propiedades obligatorias son el filtro de elegibilidad. Si omites una propiedad obligatoria, la página no es elegible para ese resultado enriquecido. Las propiedades recomendadas aumentan la calidad — Google usa literalmente el salario de una oferta de empleo como ejemplo: los usuarios prefieren las ofertas con salarios indicados frente a las que no los tienen. La misma lógica de «más completo es mejor» se aplica a Product.
• Elegibilidad ≠ visualización garantizada. El marcado válido te incluye en el conjunto; los sistemas de Google aún deciden por separado si muestran la mejora.
• Marca solo contenido visible y preciso. Sin marcado invisible, sin reseñas falsas, sin datos engañosos — las políticas de spam y de calidad del contenido de Google se aplican a los tres, además de que cada tipo tiene su propia política específica de la función (la política de contenido de JobPosting, por ejemplo).
• JSON-LD es el formato recomendado para todos ellos — más fácil de mantener a escala que Microdata/RDFa en línea.

Dónde se conecta cada uno más allá del marcado en la página

El verdadero valor unificador no es la taxonomía — es que Google da al contenido de tipo listado su propio tratamiento de línea de productos:

• Product / ProductGroup ↔ Google Merchant Center. Puedes proporcionar datos de producto como datos estructurados en la página, como feed de Merchant Center, o ambos. Google recomienda ambos para maximizar la elegibilidad, y los concilia — son sistemas separados que se validan por separado, no un único envío. Superar la prueba de resultados enriquecidos no significa que tu feed sea válido, y viceversa. El precio y la disponibilidad deben coincidir en el marcado en la página, el feed y el proceso de pago.
• JobPosting ↔ Google Jobs. El marcado válido de JobPosting hace que una página de un único empleo sea elegible para la experiencia de Jobs — un vertical distinto, no la superficie de Shopping.
• Las devoluciones y los envíos se dividen de la misma manera, con un nivel de detalle más fino. MerchantReturnPolicy suele estar en el nivel de Organization — tu plazo y condiciones de devolución estándar para todo el sitio. OfferShippingDetails funciona en el nivel de Offer y existe específicamente para anular el valor predeterminado del nivel de organización para un artículo (un producto más pesado, una región con tarifas diferentes). Trátalos como dos registros separados, cada uno de los cuales puede quedar desactualizado por su cuenta, no como un bloque único que configuras una vez — la política del nivel de organización y cualquier excepción del nivel de oferta necesitan su propio mantenimiento. Las reglas de prioridad completas están en los análisis detallados de MerchantReturnPolicy y OfferShippingDetails.
• Los datos estructurados en la página, un feed de Merchant Center y lo que las funciones de búsqueda de Google o una respuesta de IA muestran realmente son tres contratos separados, no un único flujo — el marcado válido otorga elegibilidad en el primero, no alimenta automáticamente el segundo, y no garantiza nada en el tercero. Superar uno no demuestra paridad con los demás.

Vale la pena señalar claramente la asimetría de Bing: Bing valida genéricamente los tres tipos con respecto a la estructura de schema.org, pero no publica tablas de propiedades obligatorias/recomendadas específicas ni políticas de contenido para ninguno de ellos, y no tiene equivalente a Merchant listings o Google Jobs. En concreto, sobre ProductGroup, el propio Fabrice Canel de Bing dijo (septiembre de 2024) que aún no consume el marcado de ProductGroup en sus leyendas de compras, aunque está “on their radar.” (traducción) «en su radar.» Así que: mismo vocabulario base, pero solo Google ha creado experiencias de resultados enriquecidos dedicadas y documentadas sobre él.

Diferencias de riesgo y de ciclo de vida

Este es el contraste que más quiero que la gente interiorice, porque nadie más lo plantea así: los listados obsoletos necesitan higiene del ciclo de vida en los tres tipos — pero lo que está en juego difiere marcadamente.

• Un Product obsoleto o agotado por lo general solo pierde elegibilidad para resultados enriquecidos, o muestra una etiqueta “sold out”/“out of stock”. Molesto, no catastrófico.
• Un JobPosting obsoleto y no eliminado es algo muy distinto. Google: “We don’t allow expired job postings,” (traducción) «No permitimos las ofertas de empleo caducadas», y el no caducar o eliminar las ofertas cerradas “may result in a manual action.” (traducción) «puede dar lugar a una acción manual». Ese es un resultado materialmente peor que la inelegibilidad ordinaria. Las tres formas aceptadas de caducar una oferta: establecer validThrough en el pasado, devolver un 404/410, o eliminar el marcado.

La misma lección — los listados estructurados necesitan un proceso de ciclo de vida — pero si solo creas un flujo de limpieza, créalo para las ofertas de empleo.

¿El commerce schema ayuda al SEO?

No, no las posiciones. John Mueller ha sido directo: “Structured data won’t make your site rank better.” (traducción) «Los datos estructurados no harán que tu sitio posicione mejor.» Lo que hacen es ganar elegibilidad para resultados enriquecidos y experiencias especializadas, y, por separado, ayudar a Google a entender tus páginas. Confundir “añadí schema” con “posicionaré mejor” es el mito más común en los tres tipos.

Y no solo se trata de posiciones. La elegibilidad, un resultado enriquecido realmente mostrado, un aumento del CTR y los ingresos son cuatro afirmaciones distintas: no las combines en una sola. El marcado válido no garantiza que tu listado aparezca en Shopping o en la experiencia de Jobs (la elegibilidad no es visualización), no garantiza más clics y —dado que ninguno de los tipos de schema de este hub son señales documentadas de visibilidad en IA— tampoco es una palanca para aparecer o ser citado en AI Overviews o AI Mode. Mide cada uno de esos resultados por separado; una implementación de schema vale la pena por la función de búsqueda que puede ganar, no como un indicador indirecto de ninguno de los demás.

Mi propia opinión se hace eco de la de Mueller: sabe para qué sirve realmente schema antes de dedicar tiempo de desarrollo. Llegó para quedarse —Mueller también ha dicho que Google no está eliminando schema—, pero lo implementas para ganar una función de búsqueda, no para subir en los resultados, garantizar un clic o mover una respuesta de IA.

Adónde ir a continuación

Este hub es el mapa; cada uno de estos es su propio análisis detallado anidado bajo él:

• Datos estructurados de producto — las dos experiencias de Google (fragmentos de producto frente a listados de comerciantes), la división entre propiedades obligatorias y recomendadas, la enumeración availability y la confusión entre feed y marcado, aclarada. Comienza aquí si tu página vende un solo artículo.
• ProductGroup schema — la agrupación de variantes con hasVariant/variesBy/ productGroupID, los patrones de una sola página frente a varias páginas, el problema de la URL completa de schema.org y la conciliación con item_group_id de Merchant Center. Comienza aquí si tu artículo está disponible en tallas/colores/materiales.
• JobPosting schema — las propiedades obligatorias frente a las recomendadas, la gestión de remoto/híbrido, la regla de un empleo por página, la higiene de caducidad y los cambios de acceso a la Indexing API en 2024–2025 para portales de empleo. Comienza aquí para una página de empleo o un portal de empleo.
• MerchantReturnPolicy schema — el tipo anidado a nivel de propiedad para tu política de devoluciones: el orden de prioridad entre el marcado y la configuración de Merchant Center, y la confusión entre applicableCountry y returnPolicyCountry.
• OfferShippingDetails schema — la propiedad complementaria de tarifa de envío/destino/tiempo de entrega, y cuándo la exige realmente Google para los listados gratuitos.
• Review schema — el perfil de elegibilidad independiente que hay detrás de la ruta review/ aggregateRating hacia un resultado enriquecido de producto: las reglas de reseña única frente a agregada, la restricción de reseñas en beneficio propio y por qué no todas las páginas de producto califican automáticamente para las estrellas. Comienza aquí una vez que hayas dejado atrás «cuál de los tres uso» y pases a «esta página realmente puede mostrar estrellas de reseñas».

Para una visión más amplia, este hub se integra dentro del subclúster más amplio de datos estructurados; consulta también allí el artículo hermano sobre marcado de datos estructurados para conocer el vocabulario, los formatos y el ciclo de obsolescencia. Y todo esto se encuentra en el clúster de on-page, donde los datos estructurados se sitúan junto al resto del SEO técnico on-page.

Resumen de IA

Una interpretación condensada de la versión Advanced:

• Qué es: el «schema de comercio» es una agrupación práctica de Patrick — no una categoría de Google ni de schema.org — para los tipos de listado de schema.org que obtienen resultados enriquecidos transaccionales: Product, ProductGroup, JobPosting.
• No es una familia oficial: la galería de Google coloca Product/listado de Merchant/Variants bajo “Shopping” y Job posting en la lista general de guías de funciones. schema.org agrupa «Product, Offer y AggregateOffer» juntos y no clasifica JobPosting en ningún grupo de nivel superior con ellos.
• Jerarquía: Product = Thing > Product; ProductGroup = Thing > Product > ProductGroup (un subtipo real de Product, para variantes); JobPosting = Thing > Intangible > JobPosting (rama no relacionada). Product/ProductGroup son padre/hijo; JobPosting está taxonómicamente separado.
• Cuándo usar cada uno: una configuración que se puede comprar → Product; un elemento con variantes → ProductGroup que envuelve a sus miembros Product (ProductGroup en sí no se vende); una oferta de empleo abierta → JobPosting (un empleo por página, nunca una página de listado).
• Resultados enriquecidos: Product → fragmentos de producto + listados de merchant; ProductGroup → listados de merchant que admiten variantes; JobPosting → Google Jobs.
• Reglas compartidas: propiedades obligatorias = filtro de elegibilidad; elegibilidad ≠ visualización garantizada; marca únicamente el contenido visible/preciso; se recomienda JSON-LD.
• Más allá del marcado: Product/ProductGroup ↔ Google Merchant Center (sistemas separados pero reconciliados; proporciona ambos; precio/disponibilidad deben coincidir con el marcado, el feed y el proceso de pago). JobPosting ↔ Google Jobs. Las devoluciones/envíos se dividen de la misma forma con un nivel de detalle más fino — MerchantReturnPolicy suele ser de nivel de Organization, mientras que OfferShippingDetails lo anula por Offer para excepciones; dos registros, dos calendarios de mantenimiento.
• Las estrellas de reseña son un perfil separado: la ruta review/aggregateRating hacia un resultado enriquecido de Product se rige por las reglas de elegibilidad de fragmentos de reseña de Google, no por una regla general de «cualquier página de producto califica» — consulta el artículo de Review schema.
• Bing: valida los tres de forma genérica, sin especificaciones/políticas específicas, sin equivalentes de listados de merchant o de Jobs; según Fabrice Canel (septiembre de 2024), aún no usa el marcado de ProductGroup en las leyendas de compras.
• Perfil de riesgo: un Product obsoleto en su mayoría pierde elegibilidad; un JobPosting obsoleto/no eliminado puede desencadenar una acción manual — haz que caduque mediante un validThrough en el pasado, 404/410, o la eliminación del marcado.
• Impacto SEO: no es un factor de posicionamiento (Mueller: “Structured data won’t make your site rank better” (traducción) «Los datos estructurados no harán que tu sitio se posicione mejor») — obtiene elegibilidad y ayuda a la comprensión, pero eso es independiente de una visualización real, un aumento del CTR o una cita en una respuesta de IA; ninguno de los tipos de este hub es una señal documentada de visibilidad en IA.
• Este hub dirige, no implementa: las tablas de propiedades completas están en los análisis detallados de Product, ProductGroup, JobPosting, Review, MerchantReturnPolicy y OfferShippingDetails, no aquí.

Documentación oficial

Documentación de fuentes primarias sobre los tres tipos de Commerce Schema y las reglas que comparten.

Google — reglas compartidas

• Directrices generales de datos estructurados — el principio de elegibilidad, las políticas de calidad del contenido y de spam que se aplican a los tres tipos.
• Galería de búsqueda de datos estructurados — la fuente de verdad sobre lo que actualmente produce resultados enriquecidos; también donde puedes ver la división entre “Shopping” y “Feature guides”.

Google — Product y ProductGroup (“Shopping”)

• Introducción a los datos estructurados de producto — la separación entre el fragmento de producto y el listado de merchant, y la relación entre los datos estructurados y el feed.
• Datos estructurados de fragmento de producto — propiedades obligatorias/recomendadas para la experiencia de fragmento más ligera.
• Datos estructurados de listado de merchant — los requisitos más estrictos de “comprarlo aquí”.
• Datos estructurados de variante de producto (ProductGroup) — dónde se documenta ProductGroup, como una extensión de Product.
• Merchant Center — Especificación de datos de producto — la especificación del lado del feed que se concilia con el marcado en la página.

Google — JobPosting (“Guías de funciones”)

• Datos estructurados de oferta de empleo — propiedades obligatorias/recomendadas, la regla de un empleo por página, las políticas de contenido y la gestión de caducidad.

Schema.org (taxonomía)

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · resumen de la jerarquía de tipos

Bing / Microsoft

• Bing Webmaster Tools — Marcado de tu sitio con datos estructurados — compatibilidad genérica con schema.org; sin una especificación de elegibilidad específica por tipo.

Citas de la fuente

Declaraciones públicas. Cuando una página expone el texto, el enlace es un enlace profundo que salta al fragmento citado.

Documentación de Google — el principio de elegibilidad compartido

• “Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without…” (traducción) «Especifica todas las propiedades obligatorias enumeradas en la documentación para tu tipo de resultado enriquecido específico. Los elementos a los que les faltan propiedades obligatorias no son aptos para resultados enriquecidos. Cuantas más propiedades recomendadas proporciones, mayor calidad tendrá el resultado para los usuarios. Por ejemplo: los usuarios prefieren las ofertas de empleo con salarios indicados explícitamente que aquellas sin ellos…» Ir a la cita
• “Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies.” (traducción) «El contenido de los datos estructurados también debe seguir los lineamientos o las políticas de contenido adicionales, según se documenta en la guía de la función específica. Por ejemplo, el contenido de los datos estructurados JobPosting debe seguir las políticas de contenido de las ofertas de empleo.» Ir a la cita

Documentos de Google — Producto y la relación con Merchant Center

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (traducción) «Existen dos tipos de marcado: fragmentos de producto para páginas que no son de compra, que destacan las reseñas, y listados de comerciante para páginas de compra, que resaltan detalles del producto como las tallas y el envío.» Ir a la cita
• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (traducción) «Para proporcionar datos de producto enriquecidos a la Búsqueda de Google, puedes añadir datos estructurados de producto a tus páginas web, subir feeds de datos con Google Merchant Center y optar por los listados gratuitos en la consola de Merchant Center, o ambas cosas.» Ir a la cita

Documentación de Google — Reglas distintivas de JobPosting

• _“The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job.” (traducción) «El marcado JobPosting solo debe usarse en páginas que contienen una única oferta de empleo. No permitimos el uso del marcado JobPosting en ninguna otra página, incluidas las páginas que no muestran ninguna oferta de empleo.» Ir a la cita
• _“We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past.” (traducción) «No permitimos las ofertas de empleo caducadas. Idealmente, deberías eliminar las ofertas de empleo caducadas de tu sitio web. Si prefieres no eliminarlas, entonces necesitas asegurarte de que la propiedad validThrough tenga un valor y esté en el pasado.» Ir a la cita
• _“Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action.” (traducción) «Las ofertas que ya no están abiertas a postulaciones deben caducarse de una de las siguientes formas. No tomar medidas oportunas sobre las ofertas caducadas puede dar lugar a una acción manual.» Ir a la cita

John Mueller, Google — el schema no es un factor de posicionamiento

• “Structured data won’t make your site rank better.” (traducción) «Los datos estructurados no harán que tu sitio se posicione mejor.» Y: “It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search.” (traducción) «Está bien usarlo para otras cosas en schema.org; eso no causará problemas, pero es poco probable que haya un cambio visible en Google Search.» Cobertura Difundido a través de la cobertura de Search Engine Roundtable de las publicaciones de Mueller en Bluesky de abril de 2025; trata la redacción como un informe secundario transcrito.
• “In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side.” (traducción) «Para poder mostrarse como resultado enriquecido, debes asegurarte de que la página use los datos estructurados correctos y cumpla las políticas apropiadas de nuestra parte.» Cobertura Difundido a través de la cobertura de Search Engine Land de una respuesta de #AskGoogleWebmasters de 2019.
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (traducción) «Exacto. Ten en cuenta que los tipos de marcado van y vienen, pero hay unos pocos valiosos que deberías conservar, como title y meta robots.» Cobertura Difundido a través de la cobertura de Search Engine Roundtable de una respuesta de Reddit de noviembre de 2025.

Fabrice Canel, Microsoft Bing — sobre ProductGroup

• “ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned!” (traducción) «El marcado ProductGroup todavía no se usa en nuestras leyendas, pero está en nuestro radar. Nuestro equipo está supervisando de cerca su adopción. ¡Mantente al tanto!» Cobertura Difundido a través de la cobertura de Search Engine Roundtable de una declaración de septiembre de 2024 en X; con fecha — vuelve a verificar el soporte actual de ProductGroup en Bing antes de basarte en él.

Commerce Schema de un vistazo

Los tres tipos comparados

Datos rápidos

• El «schema de comercio» es una agrupación para profesionales, no una categoría de Google ni de schema.org — los tres tipos comparten un caso de uso de SEO, no una taxonomía.
• Product y ProductGroup son padre/hijo; JobPosting es una rama no relacionada.
• Elegibilidad ≠ visualización — el marcado válido te incluye en el grupo; Google aún decide si muestra la mejora.
• No es un factor de posicionamiento — y tampoco garantiza el CTR, la visualización ni las citas en IA. Los datos estructurados otorgan elegibilidad para resultados enriquecidos y ayudan a la comprensión. Que el resultado se muestre realmente, que consiga más clics y que aparezca en una respuesta de IA son tres resultados separados y no garantizados.
• La elegibilidad de Review/AggregateRating tiene su propio perfil. No todas las páginas de producto o de comerciante califican automáticamente para las calificaciones con estrellas; esa ruta pasa por las reglas independientes de fragmentos de Review de Google. Consulta el análisis detallado de Review schema.
• Las devoluciones y los envíos también se dividen con un nivel de detalle más fino. MerchantReturnPolicy suele ser de nivel de Organization (tu política predeterminada); OfferShippingDetails la anula por Offer para excepciones. Dos registros, dos calendarios de mantenimiento.
• JSON-LD es el formato recomendado por Google para los tres.
• El feed de Merchant Center y el marcado de Product en la página son sistemas separados que Google concilia — proporciona ambos y mantén la coherencia de precio/disponibilidad en el marcado, el feed y el proceso de pago.
• La higiene de ofertas de empleo es lo más crítico: haz caducar las ofertas cerradas (una vez pasada validThrough, con 404/410, o eliminando el marcado) o te arriesgas a una acción manual.

¿Qué tipo de Commerce Schema necesito?

Responde para la página a la que estás añadiendo marcado y darás con el tipo correcto (y con el análisis detallado adecuado para leer a continuación).

Errores que realmente veo con Commerce Schema

Estos son errores concretos que las personas cometen con el marcado de datos estructurados de Product, ProductGroup y JobPosting — no errores hipotéticos. Cada uno tiene una solución.

Colocar marcado de datos estructurados de JobPosting en una página que enumera varios empleos

La regla de Google es explícita: el marcado de datos estructurados de JobPosting “must only be used on pages that contain a single job posting,” (traducción) «debe usarse únicamente en páginas que contienen una única oferta de empleo,» y no está permitido en ninguna otra página, incluida una página que no enumera ningún empleo. Añadirlo a una página índice de empleos o de resultados de búsqueda no te hace obtener varios listados de Jobs — simplemente hace que el marcado de datos estructurados no cumpla y no sea elegible.

En su lugar, haz lo siguiente: asigna a cada puesto abierto su propia URL de un solo empleo y añade marcado de datos estructurados solo a esa página. Usa la página de listado/índice para la navegación, no para JobPosting Schema.

Dejar publicada una oferta de empleo cerrada sin caducarla

Un Product obsoleto mayormente solo pierde elegibilidad o muestra “out of stock” — levemente molesto. Un JobPosting obsoleto es una clase de riesgo diferente: Google dice que no permite ofertas de empleo caducadas, y el hecho de no caducar o eliminar una oferta cerrada “may result in a manual action.” (traducción) «puede dar lugar a una acción manual.» Esa es una penalización a todo el sitio, no un fragmento de resultados enriquecidos perdido.

Haz en su lugar: en cuanto se cierre un puesto, haz una de las tres cosas que Google acepta — establece validThrough en una fecha pasada, devuelve un 404/410 en la URL o elimina por completo el marcado JobPosting. Integra esto en el paso de cierre de tu sistema de contratación, no como una tarea manual posterior.

Tratar ProductGroup como sustituto del marcado de cada variante

ProductGroup es un elemento principal que vincula las variantes mediante hasVariant, variesBy y productGroupID — pero no reemplaza a Product. Cada variante (cada combinación de tamaño, color o material) aún necesita su propio marcado completo de Product con su propio sku/gtin, precio y disponibilidad. Publicar solo el ProductGroup y omitir las entradas individuales de Product deja las variantes sin los datos que Google realmente necesita para venderlas.

Haz en su lugar: marca cada variante que pueda comprarse como su propio Product y luego envuelve el conjunto en un ProductGroup que las referencie.

Esperar que los datos estructurados de comercio mejoren tus posiciones

Este es el mito más común en los tres tipos, y Google lo ha dicho de manera clara y repetida — John Mueller: “Structured data won’t make your site rank better.” (traducción) «Los datos estructurados no harán que tu sitio se posicione mejor.» Tratar la implementación de datos estructurados como una estrategia de posicionamiento establece una expectativa incorrecta para las partes interesadas y puede llevar a tomar atajos en otras áreas a favor del trabajo de marcado que nunca iba a mejorar las posiciones.

Haz en su lugar: implementa datos estructurados de comercio para ganar elegibilidad para una función de búsqueda específica (un listado de comerciante, una tarjeta de empleo) — un objetivo legítimo con su propio valor en clics y presentación — y mídelo frente a ese objetivo, no frente a la posición en el ranking.

Dejar que el marcado en la página, el feed de Merchant Center y el proceso de pago se desincronicen

Los datos de producto pueden provenir de datos estructurados en la página, de un feed de Merchant Center o de ambos, y Google los concilia como sistemas separados en lugar de tratar uno como una copia del otro. Pasar la Prueba de resultados enriquecidos no significa que tu feed sea válido, y viceversa — si el precio o la disponibilidad difieren entre el marcado, el feed y lo que realmente cobra el proceso de pago, esa discrepancia socava tanto la elegibilidad como la confianza del usuario.

Haz en su lugar: mantén el precio y la disponibilidad idénticos en las tres superficies, y valida el marcado en la página y el feed por separado en lugar de asumir que uno cubre al otro.

Herramientas para crear y comprobar datos estructurados de comercio

Mi Validador de marcado de datos estructurados es la primera parada una vez que has escrito JSON-LD para cualquiera de los tres tipos. Pega un bloque de Product, ProductGroup o JobPosting (o una página completa) y ejecuta comprobaciones clasificadas por gravedad contra el vocabulario de schema.org y los requisitos de resultados enriquecidos de Google — útil para detectar una propiedad obligatoria faltante antes de publicarlo, independientemente de cuál de los tres tipos estés trabajando.

Mi Comprobador de elegibilidad para resultados enriquecidos responde a la pregunta más específica a la que este hub vuelve una y otra vez: no “¿es válido este JSON-LD?”, sino “¿esta página realmente califica para un resultado enriquecido?”. Pega JSON-LD, una página HTML o recupera una URL en vivo, y muestra qué campos obligatorios están presentes y cuáles faltan para Product (offers/review/aggregateRating) o JobPosting (title, description, datePosted, hiringOrganization, jobLocation): el filtro exacto de elegibilidad que describe este artículo.

Mi Comprobador de SEO para PDP está creado específicamente para la parte de la página de detalles de producto de este hub: examina una página de producto en vivo más allá de los datos estructurados, y cubre las señales en la página que acompañan al marcado de Product/ProductGroup cuando decides si una página de un solo SKU o una página de variantes agrupadas está configurada correctamente.

Una vez que el marcado supere esas comprobaciones, ejecuta la página en la propia Prueba de resultados enriquecidos de Google; es la herramienta que Google usa realmente para decidir la elegibilidad, por lo que tiene la última palabra antes de publicarla, para cualquiera de los tres tipos de este hub.

Ponte a prueba: Commerce Schema

Cinco preguntas rápidas sobre los tres tipos de Commerce Schema, cómo se relacionan y qué hacen (y qué no hacen). Elige una respuesta para cada una y luego comprueba.

Recursos que merecen tu tiempo

Mis artículos sobre marcado de datos estructurados

• Marcado de datos estructurados — mi visión más amplia sobre el vocabulario, los formatos, la comprensión de entidades y el ciclo de obsolescencia. Commerce Schema es una parte de esto.
• Guía del SEO técnico para principiantes — donde presento el marcado de datos estructurados como código que ayuda a los motores a entender el contenido y potencia las funciones que hacen que un listado destaque.
• SEO empresarial — mi regla pragmática, aplicada también aquí: “I’m a fan of schema markup as long as it gets you a search feature.” (traducción) «Soy fan del marcado de datos estructurados siempre que te consiga una función de búsqueda.»

Mis ponencias

• Cómo funciona la búsqueda (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y el posicionamiento; contexto útil sobre dónde encajan los datos estructurados. (Se aplica mi descargo de responsabilidad habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni precisa.»)

De toda la industria

• Google vuelve a decir que los datos estructurados no hacen que tu sitio posicione mejor (Search Engine Roundtable) — la declaración de Mueller de abril de 2025, el desmentido del mito detrás de todo este centro.
• Google no está eliminando Schema: los marcados pueden ir y venir (Search Engine Roundtable) — el enfoque de “markup types come and go, but a precious few you should hold on to” (traducción) «los tipos de marcado van y vienen, pero unos pocos preciados deberías conservarlos».
• Bing puede usar el marcado ProductGroup en el futuro (Search Engine Roundtable) — la declaración de Fabrice Canel de septiembre de 2024 sobre la falta de compatibilidad de Bing con ProductGroup.
• Sigue las directrices de datos estructurados si quieres el resultado enriquecido (Search Engine Land) — Mueller sobre la elegibilidad, que requiere el marcado correcto y el cumplimiento de las políticas.
• Jerarquía de tipos de schema.org — el propio vocabulario, directamente de la fuente; consulta la agrupación “Product, Offer, and AggregateOffer” y dónde está JobPosting (y dónde no).

Registro de cambios