Schema AudioObject

TL;DR — El schema AudioObject es código que añades a una página para etiquetar un fragmento de audio: «este es un episodio de podcast», «esta es su duración», «este es el lugar donde vive el archivo». Conviene ser claro desde el principio: añadirlo no te proporciona un resultado de audio especial en Google. No desbloquea ninguna tarjeta ni insignia de audio. Su valor consiste sobre todo en insertar ese audio de forma ordenada dentro de otro contenido marcado y aportar una ayuda plausible, aunque no demostrada, a la forma en que los buscadores y las herramientas de IA entienden el audio, no en ganar una función de búsqueda visible.

Qué es el schema AudioObject

Cuando una página tiene un reproductor de audio —un episodio de podcast, una versión narrada de un artículo o un clip de sonido— puedes ver y oír qué es. Un buscador ve sobre todo texto sin formato y un archivo multimedia sobre el que tiene que hacer suposiciones. El schema AudioObject lo explicita en código mediante el vocabulario compartido de schema.org: etiqueta el name del audio, dónde está el archivo (contentUrl), cuánto dura (duration) y cuál es su formato (encodingFormat).

Como la mayoría de los schemas, se escribe como JSON-LD: un pequeño bloque de código que se coloca en la página sin cambiar su aspecto.

La parte honesta: lo que no hace

Esto es lo que la mayoría de las guías no te dice con claridad. Algunos tipos de schema te dan un resultado de búsqueda más completo: Recipe ofrece una tarjeta de receta y VideoObject puede ofrecer una miniatura de vídeo. AudioObject no. A día de hoy no existe ningún rich result propio de Google para él: no aparece en la lista oficial de tipos de datos estructurados compatibles de Google, y las dos páginas de guía que esperarías encontrar (/structured-data/podcast y /structured-data/media-clip) sencillamente no existen; devuelven «no encontrado».

Así que, si tu único motivo para añadir AudioObject es «conseguiré un resultado de podcast en Google», la respuesta honesta es: no lo conseguirás. No es motivo para alarmarse; solo es motivo para saber qué estás obteniendo realmente.

Entonces, ¿por qué añadirlo?

Quedan dos razones legítimas:

• Ayudar a las máquinas a entender el audio. Los motores de respuesta de IA y los sistemas de búsqueda leen cada vez más los datos estructurados para averiguar qué contiene una página. Un marcado AudioObject limpio es una apuesta razonable en esa dirección —«esta página tiene un episodio de podcast de 42 minutos llamado X»—, aunque nadie ha publicado pruebas directas de que AudioObject, en concreto, cambie algo para los sistemas de IA. Trátalo como un beneficio plausible, no demostrado, y no como una garantía.
• Insertar audio dentro de otro contenido. Si tienes un artículo con una versión de audio narrada, puedes anidar un AudioObject dentro del marcado del artículo para conectar formalmente ambos elementos.

Tres cosas que la gente confunde

• AudioObject no es un rich result de podcast. Hoy no existe una función de Google así.
• El schema no es lo mismo que un feed RSS. Lo que realmente lleva tu podcast a Apple Podcasts y Spotify es tu feed RSS, no el schema de la página.
• AudioObject no es PodcastEpisode. Google tiene tipos de podcast independientes y ninguno te proporciona un rich result.

¿Quieres la lista de propiedades, la comparación entre AudioObject, PodcastEpisode y RSS y un marco sencillo para decidir si merece la pena? Cambia a la pestaña Advanced.

TL;DR — schema.org/AudioObject (normalmente JSON-LD) describe contenido de audio mediante contentUrl, duration, name y encodingFormat. La conclusión central y verificada es que no tiene un rich result propio en Google. No aparece en la lista oficial de tipos de datos estructurados compatibles de Google, y las dos URL plausibles de guías de funciones (/structured-data/podcast, /structured-data/media-clip) devuelven 404. Su valor es insertar audio dentro de otro contenido marcado (por ejemplo, associatedMedia de un Article) y aportar una ayuda plausible —pero no verificada de forma independiente— a la comprensión de entidades y contenido en superficies orientadas a la IA, no una tarjeta de la SERP. No lo confundas con PodcastSeries/PodcastEpisode (tipos independientes de Google para gestionar podcasts, también sin rich result) ni con los feeds RSS (el mecanismo real para descubrir podcasts mediante Apple/Spotify, sin relación con el schema de la página). Trátalo como uno de los tipos de menor prioridad de este grupo.

Qué es el schema AudioObject y cuál es la verdad honesta sobre lo que no hace

schema.org/AudioObject es un subtipo de MediaObject para representar una pieza de audio: un episodio de podcast, un artículo narrado o un clip de sonido. El vocabulario es real y estable. Lo que no es real es una función de Google Search asociada a él.

Lo comprobé directamente, y merece la pena decirlo sin rodeos: AudioObject no tiene un tratamiento confirmado de rich result en Google. Tres hechos concretos lo respaldan:

• No aparece entre las entradas de la lista de tipos de datos estructurados compatibles oficial de Google (la «search gallery»). Todos los tipos que obtienen un rich result están en esa lista. AudioObject no.
• Las dos URL de guías de funciones que esperarías —developers.google.com/search/docs/appearance/structured-data/podcast y .../media-clip— devuelven 404. No hay página de documentación porque no hay función.
• En la guía de vídeo de Google, el marcado de clips se unifica bajo VideoObject/Clip/BroadcastEvent. No existe en developers.google.com ninguna tabla paralela de propiedades obligatorias o recomendadas, ni un carrusel o insignia específicos de AudioObject.

Soy partidario del marcado schema siempre que te proporcione una función de búsqueda. Este es el caso más claro de todo el grupo de datos estructurados de un marcado que no la proporciona; por eso lo útil es hablar con franqueza en vez de fabricar urgencia.

AudioObject frente a PodcastSeries, PodcastEpisode y los feeds RSS

Este trío se mezcla constantemente, y desenredarlo constituye gran parte del valor práctico de este artículo.

• AudioObject: el tipo genérico de schema.org para «una pieza de audio». No tiene rich result de Google.
• PodcastSeries / PodcastEpisode: tipos independientes y específicos de podcasts de Google. Históricamente estuvieron vinculados a superficies de gestión de podcasts, no a un rich result de Search. En el vocabulario de schema.org, un PodcastEpisode puede referenciar su archivo multimedia mediante la propiedad associatedMedia; el AudioObject sigue siendo la entidad a nivel de archivo que está debajo, relacionada con el episodio pero no es el mismo nodo. Conviene recordar que Google Podcasts cerró en 2024, lo que eliminó una de las pocas superficies donde este marcado tenía un consumidor directo plausible; refuerza la prioridad baja, no crea una oportunidad nueva.
• MusicRecording: una confusión común que conviene corregir directamente: MusicRecording es un tipo CreativeWork de schema.org, no un subtipo de AudioObject. Si marcas una pista musical, modela la pista como MusicRecording y, si quieres describir el archivo de audio por separado, añade un AudioObject distinto en lugar de suponer que un tipo hereda del otro.
• Feeds RSS: esto es lo que más necesita oír la gente: lo que realmente consigue que un podcast aparezca en Apple Podcasts, Spotify y otras apps es tu feed RSS, enviado a esos directorios. Es un mecanismo completamente distinto del schema de la página. Ninguna cantidad de marcado AudioObject coloca tu programa en una app de podcasts; eso lo hace el feed.

Así que, cuando alguien pregunte «¿deberíamos añadir schema de podcast para SEO?», la respuesta precisa suele separar tres preguntas: ¿quieres un rich result de Google? (no existe); ¿quieres distribuirlo en apps? (eso es RSS, no schema); ¿quieres legibilidad general para máquinas? (ahí AudioObject tiene un valor modesto).

Cuándo sigue mereciendo la pena implementarlo

Incluso sin un rich result, hay razones defendibles para añadir AudioObject:

• Insertar audio en un Article. Si la página es principalmente un artículo con una versión narrada, anidar un AudioObject dentro del Article (por ejemplo, como associatedMedia) conecta formalmente ambos. El Article puede tener su propio valor; AudioObject solo hace explícito el componente de audio.
• Comprensión de entidades y contenido en superficies de IA. AI Overviews y otros sistemas orientados a LLM leen cada vez más los datos estructurados para entender el contenido de una página, y un marcado AudioObject completo puede ayudarles razonablemente a reconocer qué es el audio. Es una hipótesis direccional basada en el uso general de los datos estructurados, no una afirmación respaldada por un estudio específico sobre AudioObject ni por una declaración de Google; tómala con cautela y no la vendas como garantía.
• Completitud de schema.org en sitios que ya trabajan mucho los datos estructurados. Si ya marcas todo lo demás de forma limpia, añadir AudioObject es barato y mantiene coherente el grafo; simplemente no esperes un beneficio de SERP.

Implementación básica: las propiedades que merece la pena usar

Como no existe una tabla de requisitos de Google, apóyate en el propio vocabulario de schema.org. Estas son las propiedades que merece la pena documentar aunque no haya un rich result:

Conviene señalar una propiedad por separado: transcript. Es un campo real y válido de AudioObject, y schema.org lo documenta directamente, pero no está demostrado que colocar una transcripción únicamente dentro de JSON-LD haga que las palabras habladas sean indexables, citables o aptas para un fragmento destacado; ese beneficio del lado del consumidor no se ha verificado. Si quieres que una transcripción tenga peso SEO o en las respuestas de IA, publícala también como texto visible y accesible de la página. Trata la propiedad schema como registro legible por máquinas junto a ese texto visible, no como sustituto.

Un bloque JSON-LD mínimo:

{
  "@context": "https://schema.org/",
  "@type": "AudioObject",
  "name": "Episode 12: Structured Data Myths",
  "contentUrl": "https://example.com/audio/ep12.mp3",
  "encodingFormat": "audio/mpeg",
  "duration": "PT42M30S",
  "uploadDate": "2026-06-01",
  "description": "We separate the schema hype from what actually earns a search feature."
}

Y anidado como versión de audio de un Article:

{
  "@context": "https://schema.org/",
  "@type": "Article",
  "headline": "Structured Data Myths",
  "associatedMedia": {
    "@type": "AudioObject",
    "name": "Structured Data Myths (narrated)",
    "contentUrl": "https://example.com/audio/narrated.mp3",
    "encodingFormat": "audio/mpeg",
    "duration": "PT42M30S"
  }
}

¿Deberías molestarte? Un marco de priorización

Prefiero que dediques el esfuerzo donde compensa, así que aquí tienes una clasificación honesta:

1. ¿Quieres un rich result de Google? AudioObject es la herramienta equivocada: no existe ninguno. Dedica el tiempo a un tipo que tenga una función documentada.
2. ¿Quieres que tu podcast aparezca en Apple/Spotify? Eso es tu feed RSS, no el schema. Asegúrate de que el feed es correcto y está enviado.
3. ¿Ya marcas todo lo demás y quieres una comprensión limpia de entidades/IA? Añadir AudioObject es un acabado razonable y barato; calibra las expectativas hacia la «legibilidad para máquinas», no hacia una «tarjeta de SERP».

Para la mayoría de los sitios, AudioObject se sitúa cerca del final de la lista de prioridades de datos estructurados. No es una crítica al vocabulario; es una lectura exacta del beneficio actual. Para entender dónde se sitúa el marcado de audio frente a sus parientes, los tipos VideoObject, CreativeWork y el trabajo más amplio de Schema Markup y Structured Data de este sitio ofrecen el contexto completo.

Resumen de IA

Una síntesis de la versión Avanzada:

• Qué es: marcado schema.org/AudioObject (normalmente JSON-LD) que etiqueta contenido de audio —episodios de podcast, artículos narrados y clips de sonido— mediante propiedades como contentUrl, duration, name y encodingFormat.
• Conclusión central (verificada): AudioObject no tiene un rich result propio en Google. No aparece en la lista oficial de tipos de datos estructurados compatibles; las dos URL plausibles de guías de funciones (/structured-data/podcast y /structured-data/media-clip) devuelven 404. No desbloquea ninguna tarjeta, insignia ni carrusel de audio.
• Para qué sirve realmente: insertar audio dentro de otro contenido marcado (por ejemplo, associatedMedia de un Article) y aportar una ayuda plausible —pero no verificada de forma independiente— a la comprensión de entidades y contenido en superficies de IA. No es una función visible de la SERP.
• Cuatro cosas que no debes confundir:
  • AudioObject = tipo genérico de audio, sin rich result.
  • PodcastSeries/PodcastEpisode = tipos independientes de Google para gestionar podcasts, también sin rich result (y Google Podcasts cerró en 2024); un PodcastEpisode puede referenciar su archivo mediante associatedMedia, pero AudioObject sigue siendo la entidad a nivel de archivo.
  • MusicRecording = tipo CreativeWork, no subtipo de AudioObject: modela una pista musical como MusicRecording y su archivo de audio, si hace falta, como AudioObject independiente.
  • Feeds RSS = el mecanismo real que incluye un podcast en Apple Podcasts / Spotify, sin relación con el schema de la página.
• Propiedades que merece la pena usar: name, contentUrl, duration (ISO 8601), encodingFormat (tipo MIME), además de description/uploadDate. transcript también es un campo válido, pero no está verificado que una transcripción solo en JSON-LD haga que las palabras habladas sean indexables o aptas para fragmentos destacados; si ese resultado te importa, publica también el texto visible de la transcripción.
• Prioridad: uno de los tipos de menor prioridad de este grupo. Añádelo por completitud y por una hipótesis razonable, no demostrada, de comprensión por IA en sitios que ya trabajan mucho los datos estructurados; no por una función de búsqueda inexistente.
• Clasificación: ¿quieres un rich result? Herramienta equivocada. ¿Quieres distribución en apps? Eso es RSS. ¿Quieres legibilidad limpia para máquinas? AudioObject es un acabado razonable y barato.

Documentación oficial

Referencias de fuentes primarias; aquí, de forma poco habitual, el hallazgo más importante es lo que la documentación no contiene.

Hallazgo clave: no existe una página de función AudioObject

• La lista de tipos de datos estructurados compatibles de Google (la «search gallery») es el índice canónico de todos los tipos que obtienen un rich result. AudioObject no aparece.
• https://developers.google.com/search/docs/appearance/structured-data/podcast → 404 (página no encontrada). No existe una guía de Google de «datos estructurados de podcast».
• https://developers.google.com/search/docs/appearance/structured-data/media-clip → 404 (página no encontrada). No existe una guía de función de Google para «media clip» (audio).

Esos dos 404 y la ausencia en la lista de tipos compatibles son el titular. Cuando un tipo tiene una función de Google Search, cuenta con una página de guía documentada y una entrada en la galería. AudioObject no tiene ninguna de las dos.

Dónde se documenta realmente el marcado de audio/clips (vídeo, no audio)

• Datos estructurados de vídeo (VideoObject / Clip / BroadcastEvent): el marcado de clips de Google vive aquí, unificado bajo VideoObject. No existe una tabla paralela de requisitos para AudioObject.

Documentación independiente de Google sobre podcasts (RSS/gestión, no rich result)

• Las guías de Google «About podcasting on Google» y de gestión de podcasts (ahora integradas en la ayuda de Podcast Publisher Center de Google) tratan del envío y la gestión de feeds RSS, no de que el marcado schema.org/AudioObject alimente un rich result de Search. (Google Podcasts cerró en 2024, lo que reduce aún más la relevancia de esta superficie).

El vocabulario

• schema.org/AudioObject: definición del tipo y lista completa de propiedades, ya que Google no publica una lista específica de funciones.

Bing / Microsoft

• No existe una guía específica de Bing sobre AudioObject o podcasts; solo la descripción general de datos estructurados (compatibilidad con schema.org, JSON-LD recomendado y Markup Validator genérico).

Citas de la fuente

Aquí hay, de forma inusual, poco que citar, y ese es el punto. Google no publica una guía de rich results para AudioObject, así que no existe un pasaje oficial que prometa una función que podamos citar. La «cita» verificada de este tema es realmente una ausencia: no hay entrada en la galería de tipos compatibles, no hay página de función y las dos URL candidatas devuelven 404. No voy a fabricar una declaración de Google que no existe.

La única frase registrada que merece encabezar el artículo es mía, porque resume exactamente por qué AudioObject tiene baja prioridad:

Patrick Stox

• “I’m a fan of schema markup as long as it gets you a search feature.” (traducción) «Soy partidario del marcado schema siempre que te proporcione una función de búsqueda». Ahrefs — Estrategias de SEO empresarial para un crecimiento máximo

Esa frase resume toda la tensión. AudioObject es el caso más claro de este grupo de schema que no te proporciona una función de búsqueda; por eso la postura honesta es añadirlo para la comprensión de entidades/IA si ya trabajas mucho los datos estructurados y omitirlo si tu única motivación es conseguir un beneficio en la SERP.

Mitos y errores de AudioObject que debes evitar

Mito: «El schema AudioObject te proporciona un rich result de podcast en Google». Falso: la documentación actual de Google no incluye esa función. AudioObject no aparece en la galería oficial de tipos de datos estructurados compatibles y las dos URL plausibles de guías de funciones (/structured-data/podcast y /structured-data/media-clip) devuelven 404. Añadir el marcado no produce una tarjeta, insignia ni carrusel de audio.

Mito: «El schema de podcast y un feed RSS son lo mismo». No lo son, y esta confusión provoca un desperdicio real de esfuerzo. Tu feed RSS es el mecanismo que incluye un podcast en Apple Podcasts, Spotify y otras apps. El schema de la página es una capa de marcado de entidades separada y actualmente de bajo beneficio. Si tu objetivo es la distribución en apps, corrige el feed; el schema no lo hará.

Mito: «AudioObject y PodcastEpisode son intercambiables y uno de ellos produce un rich result». Son tipos distintos y ninguno consigue un rich result de Google Search. PodcastSeries/PodcastEpisode son tipos independientes de Google para gestionar podcasts, vinculados a superficies de RSS/gestión y no a una función de la SERP.

Mito: «Como Google Podcasts cerró en 2024, el schema de podcasts no sirve para nada». Es una exageración. El cierre de Google Podcasts eliminó un consumidor plausible del marcado, por eso este tipo tiene baja prioridad. Pero AudioObject todavía puede ayudar a la comprensión general de entidades/IA del audio de una página; simplemente nunca tuvo un rich result de Search que perder, así que el cierre no eliminó una función existente.

Error: añadir AudioObject esperando un impulso SEO y saltarse lo importante. Si alguien insiste en «schema de podcast para SEO», redirige la energía: no hay un rich result que ganar, así que asegúrate de que el feed RSS es correcto (para la distribución en apps) y que el contenido de la página es realmente útil (para el posicionamiento) antes de dedicar tiempo a un marcado sin beneficio de SERP.

Error: valores de propiedades descuidados. Si lo añades, haz bien lo básico: una contentUrl real que apunte al archivo de audio, duration en ISO 8601 (PT42M30S, no «42:30») y un tipo MIME encodingFormat válido (audio/mpeg, no «mp3»). Los valores incorrectos no ayudan a nadie, ni a las personas ni a las máquinas.

¿Deberías añadir AudioObject a esta página?

La respuesta honesta depende por completo de lo que realmente intentas conseguir con el audio: un episodio de podcast, un objetivo de distribución en apps y un artículo narrado requieren soluciones distintas, y solo una de ellas es «añadir schema AudioObject».

Modelos mentales

1. «¿Este tipo consigue un rich result?» es una consulta, no una suposición. Antes de dar por hecho que un tipo de schema merece tu tiempo, comprueba la galería oficial de tipos de datos estructurados compatibles de Google. AudioObject no está en ella y ninguna de las dos URL de guías de funciones que esperarías (/structured-data/podcast, /structured-data/media-clip) resuelve. Cuando un tipo está realmente ausente de la galería, trata esa ausencia como el hallazgo, no como un hueco de investigación.

2. La distribución y el marcado de entidades son trabajos distintos. Llevar un podcast a Apple Podcasts o Spotify es un problema del feed RSS. Ayudar a un buscador o sistema de IA a entender qué es el audio es un problema de schema. No se sustituyen entre sí: arreglar uno nunca arregla el otro, así que identifica primero qué trabajo necesitas hacer antes de recurrir al marcado.

3. Anida el audio en el contenido al que apoya, en lugar de tratarlo como independiente. Cuando el audio acompaña a otro contenido —por ejemplo, una versión narrada de un artículo—, la acción de mayor valor es anidar AudioObject dentro del marcado de ese contenido (por ejemplo, associatedMedia de un Article), no publicarlo como un bloque aislado sin relación con la página que lo rodea.

4. La prioridad aumenta en proporción a la cantidad de datos estructurados que ya tiene el sitio. En un sitio que ya invierte en una cobertura amplia de schema en todas partes, añadir AudioObject es un acabado barato y coherente. En un sitio con poca cobertura y tiempo limitado, es una de las adiciones de menor retorno porque al final no hay ninguna función de SERP esperando.

5. Sin una tabla de requisitos de Google, la corrección procede del vocabulario, no de una lista de comprobación. Google no publica una tabla específica de propiedades obligatorias o recomendadas para AudioObject, así que el estándar de «hacerlo bien» son las definiciones de schema.org: duration en ISO 8601 (PT42M30S, no "42:30"), encodingFormat como tipo MIME real (audio/mpeg, no "mp3") y una contentUrl que resuelva realmente al archivo.

Herramientas para validar y generar marcado AudioObject

Como no hay una función de rich result de Google que perseguir, lo útil es hacer bien el JSON-LD y entender honestamente para qué te hará apto y para qué no; estas tres herramientas gratuitas propias cubren todo el recorrido.

• Schema Markup Validator: pega tu JSON-LD AudioObject (independiente o anidado en associatedMedia de un Article) y obtén una validación por niveles de gravedad frente al vocabulario de schema.org, incluidas las comprobaciones del grafo @id entre bloques. Es la herramienta adecuada para confirmar que duration está en ISO 8601, que encodingFormat es un tipo MIME real y que contentUrl está bien formada: lo importante ahora que no hay una tabla de requisitos de Google.
• Rich-Result Eligibility Checker: ejecuta el JSON-LD de tu página y comprueba, tipo por tipo, para qué sirve y para qué no te hace apto. En el caso de AudioObject, espera que confirme el hallazgo honesto de este artículo: el tipo no tiene asociado ningún rich result de Google, así que no esperes un veredicto de aptitud/no aptitud como el que obtendrías para Product o Recipe.
• Schema Markup Generator: crea el bloque JSON-LD AudioObject (o el anidamiento Article-con-associatedMedia mostrado arriba) mediante un formulario guiado en lugar de escribir las propiedades a mano y expórtalo listo para pegarlo.

Ponte a prueba: AudioObject Schema

Cinco preguntas rápidas sobre para qué sirve realmente el marcado AudioObject y sobre las distinciones que suelen causar problemas. Elige una respuesta para cada pregunta y comprueba el resultado.

Recursos que merecen tu tiempo

Lo que he escrito sobre este tema

No he publicado una guía independiente de AudioObject y, sinceramente, dado lo poco que este tipo hace por Search, tampoco hay mucha cobertura de terceros que merezca la pena perseguir. La mayoría de las recopilaciones de «tipos de schema» ni siquiera enumeran AudioObject como tipo propio, lo que dice algo sobre su prioridad. En lugar de rellenar esta sección, lo honesto es enviarte al vocabulario y al trabajo relacionado de datos estructurados de este sitio. Para situar el marcado de audio entre sus parientes, consulta los tipos VideoObject y CreativeWork, además de los hubs generales de Schema Markup y Structured Data bajo los que se organiza este artículo; para el ángulo de IA, Schema Markup para IA.

Fuentes primarias

• schema.org/AudioObject: definición del tipo y lista completa de propiedades. Como Google no publica una guía específica de funciones, es la referencia autorizada del vocabulario.
• Tipos de datos estructurados compatibles (search gallery) (Google): índice canónico de los tipos que obtienen rich results. Es útil precisamente porque AudioObject no está en él.
• Datos estructurados de vídeo (Google): lugar donde vive realmente el marcado de clips, unificado bajo VideoObject; no existe un equivalente de AudioObject.
• Ayuda de Podcast Publisher Center (Google): lado de gestión de RSS/feeds de los podcasts, distinto del schema de la página y de cualquier rich result de Search.

Registro de cambios