Unpublishing an article: does its audio go quiet too?

Every publisher pulls stories now and then. Sometimes it is a factual error that is easier to retract than to fix. Sometimes it is a person named in a piece who asks to be taken out of it, a sponsored article whose contract has ended, or a letter from a lawyer. In the CMS, the action takes a second: switch the post back to draft, or send it to the trash, and the page is gone.

The audio is a different matter. It was produced by a separate service, it sits on that service's storage, it has its own URL, and it may be listed in a podcast feed. Unless something tells the service that the article has been withdrawn, the story keeps being read aloud to anyone who has the link. Which is exactly the outcome the unpublish was meant to prevent.

A gap we found in our own product

We will start with our own record. Reviewing the WordPress plugin on 1 October 2026, we found that an article moved to draft, made private, trashed or deleted kept its audio. The file stayed reachable at its direct address, stayed in the podcast feed, and stayed in the "listen next" suggestions shown on other sites of the same account. The API had been able to remove audio since August. Nothing was calling it at the right moment.

This is a common blind spot, not an unusual bug. Audio services are wired to the publish event, because that is when they are asked to work. Very few are wired to its opposite. If you are evaluating a vendor, add it to your security questionnaire word for word: "what happens to the audio when I unpublish?"

What the WordPress plugin does now

The plugin watches for two events. The first is a status change: as soon as a published or scheduled post moves to draft, pending review, private or trash, or stays published but goes behind a password, the plugin schedules removal of its audio. The second is permanent deletion that skips the trash, which happens when the trash is disabled, when someone uses the command line, or when another plugin deletes posts. No status change is announced in that case, so only the deletion hook catches it. Both paths are covered.

Removal does not run while you are clicking "Update". A network call at that point would hold up saving the post. It runs as a background task a few moments later, and the task carries the audio identifiers with it, because after a permanent deletion WordPress has already erased the post's metadata by the time the task runs.

Two edge cases are handled explicitly. If you republish the post before the task runs, the task sees that it is public again and removes nothing. If an audio build is still in progress, the service declines to delete a file that is being written, and the plugin tries again later with an increasing delay. Until removal has actually succeeded, the plugin's Contents screen keeps showing the audio rather than pretending it is gone.

Setup is described on the WordPress page. This behaviour is on as soon as the plugin is connected to your account, with no setting to tick.

What removal deletes, and what it keeps

On the service side, removal deletes the full audio, the short preview, the word timing file and the spoken summary if there was one, for every version of the article, in both storage areas (public and protected). That last part matters: an account can switch access mode between two builds, leaving older files on the other side. Files are deleted before database rows. The reverse order could leave files still being served while the database claims nothing is there, which is the worst kind of half-failure because nobody notices it.

With no versions left, the episode also drops out of the podcast feed, which only lists articles that have a live version.

Three things are kept, and the API response says so: the article record, its listening history and its source text. Past statistics belong to you and should not vanish because a post went to the trash. The text lets you rebuild the audio if the article comes back. And the record ties your CMS identifier to what was consumed, which is what answers billing questions later.

Credits are not refunded. The synthesis happened and was paid for. We would rather state that here than have someone delete audio hoping to get their quota back.

Without WordPress: one API call

On a custom CMS, a static site or a headless setup, nothing watches your publishing statuses for you. Removal is a single call, DELETE /api/v1/podcasts/{article_id}, which does everything described above and returns what it kept. Your integration needs to make that call when an article leaves publication. The CMS API page covers the other calls. The customer dashboard does not currently have a "remove audio" button: it is the API or the plugin.

Editing is not removing

Takedown requests are often settled by editing rather than withdrawing: a full name becomes an initial, a detail is cut. In that case the audio is rebuilt from the new text, and the new version replaces the old one in the player and in the feed, the same way as any edit to a published article.

Replacing is not erasing, though. Earlier versions remain in the article's history. They are no longer served and their addresses are not published anywhere, but they exist. When the issue is legal and the name must not survive anywhere, the safe sequence has two steps: remove the audio, which deletes every version, then build it again from the corrected text.

What no tool can recall

There is a limit worth stating plainly. Removing audio on the service side removes what the service hosts. It cannot reach copies that have already left:

• episodes a podcast app has downloaded to a subscriber's phone, which stay there until the subscriber deletes them or the app refreshes the feed on its own schedule;
• a file a listener saved, or a browser kept in its cache;
• a clip shared on a social network as a video, which now lives on that network.

It is the same limit that applies to text, where screenshots and search caches can outlive a retraction. It is also the best argument for removing quickly: the sooner it happens, the fewer copies exist.

In practice

With the WordPress plugin, unpublishing is enough, and removal follows. Just check a few minutes later that the Contents screen no longer shows the audio. With the API, wire the removal call to your unpublish event now, rather than on the day a legal notice lands. And when an article has to be rewritten for legal reasons, remove and rebuild instead of relying on a plain regeneration.

Read next

• Quote, unquote: should a text-to-speech article announce its quotations?
• Changing your audio volume mid-subscription: what happens to your credits and your invoice
• French text-to-speech for children: choosing a voice for young listeners