Domain verification for article audio: why a text-to-speech service should ask, and how ours works
If an audio service can fetch any URL you give it, anyone can turn someone else's site into audio. Here is how WeDispatch checks that a site is yours (meta tag or DNS TXT record), what the check actually inspects, how long it lasts, and when you never need it.
Most text-to-speech services for publishers start the same way: paste the URL of one of your articles, wait a few seconds, listen. It is a good demo. It is also, if nothing else is checked, a way for anyone with an account to have a service's servers fetch, extract and voice someone else's journalism.
Since 1 October 2026, WeDispatch only reads an article from its URL if that URL sits on a domain the account has verified. This post explains why we made that change, what the check inspects in detail, and the cases where you will never see it. If you are evaluating audio vendors, it is also a question worth asking each of them.
The gap it closes
A service that accepts a URL fetches the page from its own servers. Without a check, a new account could point it at a national newspaper, a competitor or any blog, and receive a finished audio file of content it does not own.
We already asked customers to confirm they hold the rights to what they have read aloud. A legal review at the end of September concluded that a checkbox was not enough: a declaration identifies who is responsible after the fact, it does not prevent anything. Verification closes the door beforehand.
It now applies to every path where our servers fetch a page on your behalf: adding an article by URL, estimating its cost, the first audio offered at sign-up, watched RSS feeds, and PDFs given by a web address.
Two ways to prove it
The model is the one search engines use for webmaster tools. You get a code, unique to your account and that domain ("wd-" followed by 24 characters), and place it where only the site owner can.
A meta tag in the <head> of the home page:
<meta name="wedispatch-verification" content="wd-…">
Or a TXT record on the domain's DNS:
wedispatch-verification=wd-…
The DNS route suits teams whose website is run by an agency but who control the domain, or who would rather not touch the templates at all. DNS changes can take a few minutes to propagate, and the screen says so if the first attempt finds nothing.
Both live in the customer dashboard under "Install on my site", in the "Your domains" block. Only the account owner and administrators can use it, since it opens an entire site to reading. An account can verify up to twenty domains.
What the check actually inspects
A verification step is only worth something if it cannot be gamed. Several details were tightened during a security audit on 30 September:
- Only the real
<head>counts. The tag is ignored inside HTML comments, scripts and text areas. Otherwise a home page that displays visitor content, such as comments or reviews, would let a stranger plant the code. - Attributes are parsed, not pattern-matched. A page description that happens to contain the words "wedispatch-verification" next to a token does not pass.
- A domain covers its subdomains, never the other way round. Verifying example.com opens www.example.com and blog.example.com. Someone who only controls blog.example.com cannot open example.com by placing a tag there, which is why we read the home page of the domain itself. A redirect from example.com to www.example.com is accepted, because it stays on your domain.
- Redirects cannot leave verified domains. An article URL on a verified site that redirects to someone else's site is not followed.
- Proof expires after thirty days. It is then re-checked automatically on the next read, with nothing for you to do. If the code is gone, for instance after a redesign or a domain sale, the domain goes back to "awaiting verification" and URL-based reading stops.
One trade-off was decided in the customer's favour. If your site is simply unreachable when the thirty-day re-check happens, the domain stays open and the check is retried later. Only a code that is confirmed missing closes a domain. A ten-second outage on day thirty-one should not stop every feed you run.
When you never need it
Verification only matters when our servers go and fetch a page. When you send the text yourself, there is nothing to prove.
That is how the WordPress plugin works: it sends each article's text at publication, and our servers never read your site. If you are on WordPress, you can skip domain verification altogether. The same goes for pasting text into the dashboard, which needs no verification at all; generating audio from pasted text covers that route.
At sign-up, if the first article you propose is on an unverified domain, you are not simply refused. The box shows both codes, verifies on the spot, then starts the audio, and always offers the option of starting from the article's text instead.
RSS feeds depend on it
If you planned to voice new articles automatically through RSS feed auto-discovery, verification comes first: a feed is only polled on a verified domain. Removing a domain stops its feeds and URL-based adding for that site. The dashboard asks for confirmation first, and you would need to verify again to undo it.
The short version
Two minutes, once per site, and only if you want us to read your articles by their URL. In exchange, nobody can have your site read aloud from their own account. It belongs on any vendor review alongside the other items in our security questionnaire for audio tools.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo