For publishers
Fill the long tail your desk cannot reach.
A publication already has the authority, the archive and the standards. What it does not have is a spare afternoon per language for the thousands of specific questions that never justify a reporter — but do account for a large share of what gets searched. That layer is what this covers, under your review, on a domain you own.
Approval before publishingOne line per marketSyndicate it or host it
What the archive does not answer yet.
Not the story of the day. The reference layer underneath it, which is where durable search demand lives.
- The unanswered long tail
- The specific, low-volume questions your desk would answer if it had a spare afternoon: procedures, comparisons, timings, definitions, local detail. Individually small, collectively most of the search.
- The evergreen layer
- Process and reference content that does not expire with the news cycle, and keeps earning impressions between the stories that spike and fall.
- One market at a time
- Each language is planned from its own market's searches, with its own dates, rather than a machine translation of the English archive that no one in that market would ever type.
- Series and clusters
- Entries can be grouped so that a set of posts builds one topic properly instead of scattering single articles across a subject and never returning to it.
- A machine-readable surface
- Sitemap, canonical URLs, structured data and an llms.txt per blog, generated from what is published — so crawlers and answer engines can take the archive in properly.
- Syndication on your terms
- If it should not be a hosted blog, read the posts from the API as markdown or rendered HTML and publish them into the CMS your editors already use.
The steady version of an archive.
Five steps, and the third is the one that keeps a masthead's standards intact: what the desk keeps and what it discards.
- 01
Scan the domain
Free and without an account: the homepage and the sitemap, plus the queries the publication does not answer yet. On a large archive, that gap is usually the interesting part.
- 02
Connect a market
One DNS record for a blog hostname under a domain you own, one language line to start. Nothing is installed and your CMS keeps serving the archive it serves today.
- 03
Set the editorial standard
The plan shows the query, the intent, the outline and the date. Your desk discards what does not fit the title's standards — before a word is written.
- 04
Leave approval on
Approval can be required account-wide, which is usually the right default for a publisher: nothing publishes under your masthead without a person releasing it.
- 05
Report per site and query
Search Console read-only: which long-tail queries the domain is earning impressions for, market by market, alongside the stories your desk already tracks.
What stays with the desk.
A title’s standards are not a template, and a pipeline cannot own them. Anything that carries legal risk, reads as reporting or touches a subject your lawyers have opinions about is a decision for the people whose names are on the masthead.
What this can do is keep the reference layer current — per market, on schedule — while the desk spends its time on the work only the desk can do.
- Editorial standards, house style and the line you will not cross
- Anything that reads as reporting rather than explanation
- Legal risk, defamation and the topics that need a lawyer
- Which subjects are off limits for automated production
- Corrections, and the decision about what gets taken down
A spike, or an archive.
News traffic is spiky by nature. The layer underneath it is not, and that is the layer worth automating.
Spikes only
- Traffic that arrives with a story and leaves with it
- Nothing published in the weeks between stories
- Reference questions answered by whoever is free
- One language, however many markets the title serves
- No reporting on the long tail, because it was never built
Spikes and an archive
- A baseline of durable pages under the news traffic
- A post on each publishing day, spike or not
- One answer per query, reviewed before it goes out
- Each market planned from its own searches
- Impressions per query, per market, in Search Console
What this is not
It is not a newsroom, not a wire service and not a replacement for reporting. It does not file, does not react to events, and does not decide what matters — and if a publication’s reputation rests on original access and analysis, that reputation is untouched by anything published here.
The usual caveat also applies without decoration: rankings, traffic and revenue are not guaranteed. The archive here is a body of work published on a schedule, reviewed by you, on a domain you own.
The machine-readable surface, for free.
Every blog is served with the files a crawler or an answer engine wants, generated from what is published — which matters more the larger the archive gets.
A sitemap listing every published post, a robots.txt that invites crawling, a canonical URL on each page, per-post structured data and an llms.txt indexing the archive for models that read one. None of it needs a plugin, a build or a developer.
Publishers with an existing CMS can take the same posts as data instead: markdown or rendered HTML, one request per page of results, filtered by site and language.
- Sitemap generated from published posts only
- Canonical URLs, one page per post
- Structured data with the article's real date
- llms.txt indexing the blog for language models
- Read-only API for syndication into your own CMS
More on content
- For local businesses
Answer the question before they call.
- For ecommerce
The blog around the catalogue — product pages stay yours.
- For hotels & travel
Answer the guest in the language they searched in.
- For restaurants
The question that ends in a table — menus and prices stay yours.
- For dentists & clinics
Answer the treatment and cost questions, with clinical review.
- For law firms
Clients search the situation, not the practice area.
- For WordPress sites
A blog for WordPress without a plugin or a theme edit.
Questions publishers ask.
Including whether this replaces a desk, whether everything can be reviewed, and how a large archive stays out of its own way.
Does this replace editors or journalists?
No, and it should not be sold that way. It fills the layer underneath the newsroom: the reference and process questions that never justify a reporter's afternoon but together account for a large share of search. Reporting, judgement and voice stay with the desk.
Can we review everything before it publishes?
Yes, and for a publisher that is the sensible setting. Approval can be required for the account, so every draft waits for a person to release it — and the review can happen earlier, at planning time, where discarding an entry costs nothing.
Will it produce news?
No. There is no mechanism for reacting to an event, and nothing should pretend otherwise. The plan covers durable questions — how something works, what a procedure involves, how two options compare — which is the part of a publication's surface that does not need a newsroom on call.
How does it handle several markets at once?
Each language is a separate line with its own plan and calendar, planned from that market's own searches. That is the difference between adding a market and translating into one: the German entries are built from German queries, not from your English archive.
Can the posts go into our own CMS instead?
Yes. The read API returns every post as markdown or as rendered HTML, with metadata and images, on an account-level key — so a build or an import can publish them where your editors already work. Nothing in the API can write back into Xt4b.
What about duplicate content against our archive?
Each entry targets a query the domain does not answer yet, and every page carries its own canonical URL. Where your archive already answers a question, that is the page that should rank, and the blog links to it rather than restating it.
Does volume hurt a site?
Publishing near-duplicate pages at volume does, which is why the plan is one query per post and the cadence is a choice rather than a setting for maximum output. A slower calendar of distinct answers is the more defensible way to build an archive.
What does it cost, and what is guaranteed?
20€ per website, per language, per month, with the scan free and without an account. Results are not: rankings, traffic and revenue are not guaranteed, which is stated in the terms of service and in every answer on this site.
Start with your archive
Build the layer under the news.
Scan the domain and read the plan: the queries your archive does not answer yet, the outlines behind them, and the dates they would publish on.
Review before publishing20€ / site / language / month3 days free, no card