Audio for paywalled articles: where the text comes from, and who gets the full file
A subscriber-only article is the one a publisher most wants in audio, and the one an audio tool most easily gets wrong: it either narrates the teaser or gives the full story away. How WeDispatch handles both sides, as written in the code, and the one thing no lock can do.
Ask a subscription publisher which articles they would like listeners to hear, and the answer is rarely the free ones. It is the investigation, the analysis, the long interview: the pieces behind the paywall, because those are the reason people pay. They are also the pieces where an audio tool can fail in two opposite ways. It can narrate the three-line teaser that anonymous visitors see. Or it can produce a complete, freely playable audio version of something the site charges for in text.
Both failures come from the same place: treating "make audio from this article" as a single step. It is really two questions. Where does the full text come from? And once the audio exists, who is allowed to hear all of it?
The text: why pasting a URL cannot work
The quickest way to try any text-to-speech service is to paste an article's address. On a paywalled article, this is bound to fail, because the service fetches the page the way an anonymous visitor does, and an anonymous visitor only receives the standfirst.
What matters is how a tool tells you. For a while we answered "no readable article found at this address", which suggested our reader could not parse the page. Since 29 July 2026 the message says what is actually happening: the article is reserved for the site's subscribers, and its public page only contains the introduction. The detection reads what publishers already declare in their structured data rather than guessing from the layout: isAccessibleForFree set to false in the JSON-LD (paywalled publishers publish it because Google asks for it on hidden content), or an article:content_tier meta tag set to locked, metered or paid. We deliberately do not look for CSS class names such as .paywall. They change with every redesign, and a false positive would blame a paywall for what was really a failed fetch.
The right source of the text is the publisher's own system. With the WordPress plugin, the text sent for production is the post content stored in WordPress, not the page rendered to a visitor, so whatever membership plugin hides the article from the public has no effect on what we receive. On another CMS, your server sends the text through the API with its key. Either way the complete text never passes through a reader's browser.
One edge case worth knowing: a WordPress post that is published but password-protected is treated as withdrawn, and its audio is unpublished like that of a post moved back to draft. A post password is not a subscription system, so we do not pretend it is one. Our article on unpublishing an article covers what that withdrawal removes.
The audio: three settings and a preview cut from the same file
In the client area, a screen called "Who can listen" offers three modes: everyone, registered visitors, or subscribers. Outside the open mode, a listener without the right status hears a preview, after which the player invites them to go further. The preview lasts 30 seconds by default and can be set up to five minutes.
The preview is not a second synthesis. It is the opening of the full audio, cut when the article is produced, at no extra character cost. It is made for every article, including on accounts that are fully open today. That looks wasteful until you picture the alternative: a publisher switches the lock on, and every article published before that day has no preview to serve.
Locking the file, not the button
Hiding a play button has never protected a file. In preview mode, the player page receives the address of the preview file only; the address of the full MP3 never appears in the HTML. The word-level timing used for highlighting is withheld too, since it would contain the very text the lock protects. And on a restricted account, the podcast feed carries only previews, so a subscriber-only article does not leak out in full through a podcast app.
Who decides that a visitor is a subscriber
Not us. We do not know who is reading a page and do not want to. Your server vouches for each visitor by signing a short token that says "this visitor is a subscriber", never who they are. The token is tied to one article and expires after 30 minutes, so it cannot unlock the whole site or be passed around for long.
On WordPress, the plugin does this for you:
- you tick the WordPress roles that correspond to paying subscribers, and a signed-in user without one of them counts as merely registered;
- if your subscriptions are not roles (MemberPress, WooCommerce Subscriptions, something custom), one filter,
wedispatch_visitor_status, is the single place to plug in your own rule; - the player asks a route on your own site for its token instead of reading one written into the page, because caching plugins store one visitor's HTML and serve it to everybody, which would hand a subscriber's token to anonymous readers;
- a test button in the plugin settings signs a token and asks us whether we accept it, which is the only way to tell a bad signature from a permissions problem. Both show up as the same complaint: "my subscribers only hear the preview".
If you integrate with the server-side block, note that it is called by your server without any visitor token, so it serves what an anonymous visitor would get. To reserve audio for subscribers, use the API route from your own CMS, where your server can vouch for each reader.
What no lock can do
A subscriber who hears the full article can record it, just as they can copy the text they are reading. The lock stops non-subscribers from obtaining the complete file. It does not control what a legitimate subscriber does with what they were given. No audio player embedded in a web page can, and a vendor who claims otherwise is describing something other than a player.
That leaves the editorial question: should audio be reserved at all? Some publishers open listening on every article and treat it as a way in, which is what the registration wall is built for. Others make it a perk of the subscription. Both live in the same setting and can be changed without producing a single audio again, so you can try one, compare full listens and preview listens in your statistics, and decide on numbers rather than instinct.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo