Integrating schema.org markup for a narrated article: using AudioObject well
Your audio version exists for readers, but a search engine can't see it on its own. Here's the AudioObject markup to integrate so it's signalled, with the exact snippet to copy.
You have added an audio version to your articles. Readers hear it, the "listen" button is there, everything works. But a search engine knows nothing about that audio file: it reads HTML, sees a player, and has no way to guess that it's the spoken version of the article below. Structured markup exists for exactly this, telling the machine what a human understands at a glance. It's an integration step that's often skipped, even though it costs only a few lines.
What schema.org changes, and what it doesn't
Structured data doesn't alter your page. It adds, in an invisible block, a description of the page's content in a format that Google, Bing and others know how to read. For an article, the reference type is Article (or NewsArticle for the press). For its spoken version, there's a dedicated type: AudioObject. By attaching it to the article, you state plainly: "this page has an article, and here is its recording."
Let's be honest about the expected effect. This markup does not push you up the results by magic, and nobody serious should promise that. What it does is make the audio eligible for treatments that would otherwise ignore it: a listenable-content indicator, possible pickup by a voice assistant, and a finer understanding of the page by the engine. It's a condition, not a guarantee. Most of what you actually gain from voicing your pages comes from real usage, a subject we cover in audio and article SEO.
The exact markup
Here's the block to insert in your page head, once the audio is live. It links the article to its recording through the audio property.
``
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "The exact title of your article",
"datePublished": "2026-08-26",
"author": { "@type": "Person", "name": "Author name" },
"audio": {
"@type": "AudioObject",
"contentUrl": "https://yoursite.com/audio/my-article.mp3",
"encodingFormat": "audio/mpeg",
"duration": "PT6M12S",
"name": "Audio version: the exact title of your article"
}
}
</script>
Three properties deserve your attention. contentUrl must point at the audio file itself, not at the page that contains it: an engine wants the media's address, reachable directly. encodingFormat states the MIME type (audio/mpeg for an MP3) and saves the engine from guessing. duration is written in ISO 8601 format: PT6M12S means six minutes and twelve seconds. That duration isn't cosmetic, it's often what lets an interface announce "6 min listen" before the file even loads.
The trap of two dates and moving content
A common mistake: marking up an audio whose URL or duration no longer matches what is actually served. You fix the article, regenerate the audio, the duration changes, but the markup keeps the old value. An engine that cross-checks the claim against the file then finds an inconsistency, and repeated inconsistency erodes the trust it places in your pages. The rule is simple: the markup updates at the same time as the audio, never patched afterwards by hand. This is precisely what a feed or an API handle for you, carrying the right duration and the right address on every regeneration. Our enriched RSS feed exposes these up-to-date values, so you never have to copy them across.
The WordPress case, where the question really arises
In practice this markup is hard to maintain by hand on a living blog: every new article would need its block, every correction would need to update it. It's the kind of task nobody does reliably for long. On WordPress, inserting the player and declaring the structured data can travel together, carried by the same mechanism that generates the audio. If your site runs on WordPress, the plugin page explains how the player is added without touching your theme, and the markup follows the same path, article after article, without you writing a line of JSON.
What to remember
An unmarked audio is a half-integrated audio: your readers benefit, machines ignore it. The AudioObject type, attached to your article through the audio property, fills that silence in a few lines. Copy the block above, fill three fields with your file's real values (address, format, duration), and above all keep it current when the audio changes. The rest, the fidelity of the French reading, the punctuation, the numbers, plays out upstream, in the tool that produces the sound: that's the subject of our French text to speech page.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo