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

El esquema SoftwareApplication solo califica para el resultado enriquecido de aplicación de Google cuando lleva tres datos: name, offers.price y aggregateRating o review. Una página puede declarar el nombre y la categoría, dejar fuera los otros dos y aun así pasar cualquier validador de sintaxis. Válido no es elegible. La documentación de Google sobre aplicaciones, revisada el 2026-10-25, toma un precio o una calificación ausente como una condición incumplida, no como una advertencia.

Qué pide el esquema SoftwareApplication

Tres propiedades hacen el trabajo. Dos son opcionales en schema.org y obligatorias para Google, y esa diferencia explica por qué muchas páginas se quedan a un campo de distancia.

La calificación es el campo que detiene a más equipos. Un aggregateRating necesita ratingValue y ratingCount; una review individual necesita autor y puntaje. Las guías de Google sobre fragmentos de reseñas son claras: no agrupes reseñas ni calificaciones de otros sitios, y no incluyas reseñas falsas ni incentivadas sin informarlo. La calificación tiene que ser de tu producto y de gente que lo haya usado.

applicationCategory toma un valor de la lista admitida por Google. BusinessApplication, DeveloperApplication y DesignApplication están en esa lista; 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 calificació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 que vendes desde un catálogo es un Product. Google admite los tres, y el error es apilar dos tipos en la misma página con precios distintos.

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

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

El entregable: un bloque para pegar

Este es el bloque mínimo que puede calificar para un producto web con plan gratis. Cambia los cuatro valores y conserva 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 gratis es la trampa clásica: offers.price sigue siendo obligatorio cuando la respuesta es cero, así que escribe "price": "0" en vez 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 corre.

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.

Agrega aggregateRating solo si la página muestra esa calificación a quien entra. Las reglas generales de datos estructurados piden que el marcado describa el contenido visible; una calificación que solo vive dentro de una etiqueta script es una declaración engañosa. Las reglas de reseñas agregan que las calificaciones agrupadas deben venir de reseñas reales, no de otro sitio.

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

Hazlas en orden. Las cuatro primeras frenan un bloque que no puede funcionar; las cuatro siguientes frenan 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 mueva cuando alguien edite el cuerpo. Los valores deben venir de donde los renderiza la página; una calificación escrita a mano es el primer campo que se vuelve viejo.

1. Pega la URL de la página en Rich Results Test y confirma que detecta “Software app”.
2. Lee los errores antes que las advertencias. 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 verifica que el HTML renderizado contiene el bloque.
4. Revisa 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 igual no aparece

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 ahí.

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 califica. 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 todavía no tiene calificaciones 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 agrega la calificación cuando usuarios reales hayan dejado una. Una calificació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 calificación. Google lo usa para decidir si la página puede mostrar un resultado de aplicación con nombre, precio y estrellas.

¿Google todavía admite 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 revisamos 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 retiró.

¿El marcado de aplicación muestra estrellas?

Solo si lleva una calificación o una reseña. Con nombre y precio pero sin calificación, la página no cumple las propiedades obligatorias. Con una calificació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 le 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 agrega 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.