Esquema SoftwareApplication: el precio y la valoración que deciden si aparece

El esquema SoftwareApplication solo es elegible para el resultado enriquecido de aplicación de Google cuando incluye tres cosas: name, offers.price y aggregateRating o review. Una página puede declarar el nombre y la categoría, omitir las otras dos y pasar igualmente cualquier validador de sintaxis. Válido no es elegible. La documentación de Google sobre aplicaciones, leída el 2026-10-25, trata un precio o una valoración ausentes como una condición incumplida, no como un aviso.

Qué exige el esquema SoftwareApplication

Tres propiedades hacen el trabajo. Dos son opcionales en schema.org y obligatorias para Google, y esa diferencia explica por qué tantas páginas se quedan a una línea del objetivo.

La valoración es lo que frena a la mayoría. Un aggregateRating necesita ratingValue y ratingCount; una review individual necesita autor y puntuación. Las directrices de Google sobre fragmentos de reseñas son explícitas: no agrupes reseñas ni valoraciones de otros sitios, y no incluyas reseñas falsas ni incentivadas sin divulgarlo. La valoración debe ser de tu producto y de personas que lo hayan usado.

applicationCategory toma un valor de la lista admitida por Google. BusinessApplication, DeveloperApplication y DesignApplication están en ella; WebApplication es un tipo, no una categoría. Copia un valor de la documentación en lugar de inventar una etiqueta que suene bien.

Un resultado de aplicación es un nombre con un precio y una valoración. Si falta uno de los tres, Google no tiene nada que mostrar.

Qué tipo usar: WebApplication, SoftwareApplication o Product

Un producto que funciona en el navegador suele ser una WebApplication; una aplicación de escritorio o móvil que se instala es una SoftwareApplication; un artículo vendido desde un catálogo es un Product. Google admite los tres, y el error consiste en apilar dos tipos en la misma página con precios distintos.

Hay una excepción documentada que conviene conocer antes de elegir: Google no muestra resultado enriquecido para una aplicación que solo lleva el tipo VideoGame. Hay que añadir un segundo tipo, por ejemplo MobileApplication. Es un caso estrecho, pero es justo el detalle que deja un marcado correcto sin ningún efecto visible.

Si tu página ya vende un plan con precio y disponibilidad, lee antes cómo escribir una landing page de producto y decide qué tipo es dueño del precio en esa página. No marques los dos con cifras diferentes.

El entregable: un bloque para copiar

Este es el bloque mínimo elegible para un producto web con un plan gratuito. Cambia los cuatro valores y mantén la estructura.

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Example",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "ratingCount": "128"
  }
}

El plan gratuito es la trampa clásica: offers.price sigue siendo obligatorio cuando la respuesta es cero, así que escribe "price": "0" en lugar de borrar el objeto offer. Con un plan de pago, usa el precio de entrada real y conserva priceCurrency. Para una aplicación descargable, cambia @type a SoftwareApplication e indica en qué plataformas se ejecuta.

Los valores deben salir de la misma ficha que tu descripción de producto para todos los canales, para que el precio y el nombre no se separen entre páginas.

Añade aggregateRating solo si la página muestra esa valoración a quien la visita. Las reglas generales de datos estructurados exigen que el marcado describa el contenido visible; una valoración que solo vive dentro de una etiqueta script es una declaración engañosa. Las reglas de reseñas añaden que las valoraciones agregadas deben venir de reseñas reales, no de otro sitio.

El entregable: la comprobación en ocho líneas

Hazlas en orden. Las cuatro primeras detienen un bloque que no puede funcionar; las cuatro siguientes detienen un bloque que funciona pero describe la página equivocada.

El bloque va en la plantilla de la página, junto al título y la descripción, para que no se desplace cuando alguien edite el cuerpo. Los valores deben venir de donde los renderiza la página; una valoración escrita a mano es el primer campo que envejece mal.

1. Pega la URL de la página en Rich Results Test y confirma que detecta “Software app”.
2. Lee los errores antes que los avisos. Una propiedad obligatoria ausente es un error; una recomendada ausente no lo es.
3. Abre la misma URL en la inspección de URLs y comprueba que el HTML renderizado contiene el bloque.
4. Vigila el informe de datos estructurados en Search Console los días siguientes. Dice lo que Google encontró, no lo que querías.

Por qué un marcado válido sigue sin aparecer

Los fallos suelen tener cuatro formas y ninguna es un error de sintaxis. El bloque se analiza, la página se indexa y el resultado no sale nunca.

La cuarta fila es la más silenciosa. Muchas veces se marca el anuncio de lanzamiento porque es la página que el equipo edita, mientras que la página de producto, la que de verdad describe la aplicación, no lleva nada. Google evalúa la página donde está el bloque. Si quieres el resultado en la página de producto, el bloque tiene que estar allí.

Hay otro fallo anterior: el JSON está roto, con una coma de más o una comilla de menos. La prueba muestra entonces un error de análisis y Search Console separa esos casos en el informe de datos estructurados ilegibles. No hay que adivinar.

Lo que no sabemos y cuándo parar

No sabemos con qué frecuencia Google decide mostrar el resultado de aplicación cuando una página es elegible. Google no publica una tasa de aparición, no garantiza que una función con datos estructurados se muestre, y no lo hemos medido el tiempo suficiente en nuestras páginas como para dar una cifra. La elegibilidad está en tu mano; la aparición no.

También hay un caso en el que la respuesta honesta es esperar. Si el producto aún no tiene valoraciones reales, no inventes un número ni copies uno de un sitio de reseñas. Publica el nombre, la categoría y el precio, y añade la valoración cuando usuarios reales hayan dejado una. Una valoración ausente cuesta el resultado enriquecido; una fabricada cuesta el marcado, la página y la confianza para la que se escribió.

Para cuando la prueba liste la aplicación sin errores y la página visible coincida con el bloque. Lo que queda es medir si el resultado aparece, y eso pertenece a la parte de análisis de búsqueda e IA, no al código fuente.

Preguntas frecuentes

¿Para qué sirve el esquema SoftwareApplication?

Es un marcado de schema.org que describe un producto de software en una página: nombre, categoría, plataformas, precio y valoración. Google lo usa para decidir si la página puede mostrar un resultado de aplicación con nombre, precio y estrellas.

¿Google sigue admitiendo este marcado?

Sí. La documentación de aplicaciones de Google seguía disponible y con fecha de actualización del 2026-09-08 cuando la leímos el 2026-10-25, y el resultado de aplicación sigue en la lista de funciones admitidas. A diferencia de FAQ y HowTo, no se ha retirado.

¿El marcado de aplicación muestra estrellas?

Solo si lleva una valoración o una reseña. Con nombre y precio pero sin valoración, la página no cumple las propiedades obligatorias. Con una valoración inventada, el problema pasa de la aparición al cumplimiento de las normas.

¿Hay que escribir SoftwareApplication y Product a la vez?

No. Elige el tipo que corresponde a lo que vende la página y deja que uno sea dueño del precio. Dos tipos con precios distintos en la misma página dan a Google dos hechos contradictorios y a ti ninguna forma de saber cuál leyó.

¿Por qué Rich Results Test no encuentra nada?

Casi siempre porque el JSON-LD se añade con JavaScript después del HTML que la prueba ve primero, o porque la URL probada no es la que lleva el bloque. Renderiza el bloque en el servidor y prueba la URL exacta que debe posicionar, no la portada.