Connect your RSS feed: audio follows what you publish, without voicing the whole archive
The method that works whatever your CMS: point us at your feed, and every new article gets an audio. What the first pass does, and why it never touches your back catalogue.
Most integration guides open with the name of a platform: WordPress, Drupal, a specific theme. But there is one route that depends on no platform at all, because it leans on something nearly every site already produces without thinking about it: a feed. RSS, Atom, or even a plain sitemap. You give us its address, and from then on every newly published article gets its audio, with no code to write and no plugin to install. It is the most universal way in, and also the most misunderstood, because one question always comes with it.
The real question: "what about my eight hundred archived articles?"
This is the reasonable fear of any newsroom with a few years behind it. A site with a long history has hundreds, sometimes thousands of articles in its feed. Does connecting that feed mean firing off synthesis for the entire archive at once, with the bill to match? The answer is no, and it is not a marketing reassurance, it is how the mechanism is built.
The first pass produces nothing. It reads the feed and marks everything it finds as already seen. It sets a baseline, and it stops there. No audio is generated for any article that existed before you connected the feed. Only afterwards, on later passes, do new links (the ones that appear in the feed after that first read) trigger a build. In other words: you connect today, and audio starts following what you publish tomorrow. This choice exists for a precise reason, and it comes down to cost. Speech synthesis is billed by the character, and nobody wants to discover after the fact that a simple connection just voiced ten years of archives. The barrier is set by default, on the right side of the line.
What the feed gives us, without asking your CMS for anything
A feed carries more than a list of links. For each article it holds information we read as is, with no connection to your back office: the title, the section (the first category declared on the item), the author byline, the publication date and a short summary. None of this is decorative. The section, for instance, feeds the choice of voice, the audio branding and the per-section statistics, exactly as an API parameter would. The byline is read straight from the feed, which saves us asking you for anything: when it arrives in the historical shape "newsroom@example.com (Jane Smith)", we keep the name in parentheses and never the email address, because publishing an address inside a readable statistic would be a pointless leak.
When the feed carries only the opening of an article (many sites truncate their RSS), we fetch the article page at its address and extract the text from it, and ingestion then follows the same rules as the API. So you do not have to publish your full text in your feed for the reading to be complete.
The guardrails, because a feed is an address you are trusted to give
A feed is checked before it is saved. If it returns no articles (wrong address, a page that is not a feed), it is refused right away rather than polled into the void every fifteen minutes: you would know immediately that something is wrong, instead of believing you are being watched when you are not. A single pass reads at most fifty articles, which is enough to keep up with a normal publishing rhythm without turning into a vacuum cleaner. And a feed (or an article page) larger than five megabytes is refused: beyond that it is no longer an article, and reading it whole into memory would be a risk, not a service. Every redirect met along the way is revalidated, because the address you give stays your address, and we do not follow a detour to just anywhere.
When you genuinely want the archive
Connecting by feed protects your archive by default, but it does not forbid it to you. If you decide to voice an existing back catalogue, that is a deliberate decision, and it goes through another route: batch submission via the API, up to twenty-five articles per request, at your own pace. The duration and cost calculation for a large back catalogue is laid out in how long it takes to add audio to an existing blog, and the full API mechanics are described in adding audio by API. The right way to see the two: the feed follows the future on its own, the API catches up with the past when you choose.
Where this route fits
If you are on WordPress, the plugin is still more direct, because it also handles showing the player inside your articles: the detail is on the WordPress page. For every other site, an in-house CMS, a group framework, a platform with no dedicated plugin, the feed is the route that works without exception, and it is often the fastest to set up, since all it needs is an address. The same feed also serves, in the other direction, to turn your news site into an automatic podcast: what you publish becomes a show that listening platforms track, with no manual export.
Whatever the route, what comes out of the speaker is the same: the French normalisation we stand for happens before integration, not after. The feed changes how your articles enter audio, it changes nothing about how they are read aloud.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo