For agencies
Run every client’s blog from one plan.
The part of content that does not scale is the writing, the metadata and remembering to publish. Connect each client site, and that part runs on the publishing days you set per site.
One account, many sitesPer-client domainsApproval before publishing
What each site gets.
Sites are separate by design: separate domains, separate languages, separate calendars, separate search data. Nothing bleeds between clients.
- Its own domain
- Each client's blog is hosted on their subdomain or apex. One DNS record per client, added when you connect the site.
- Its own languages
- A language is not a setting: it is a separate editorial line with its own plan, its own target queries and its own dated entries.
- Its own place on the calendar
- Planned, writing, published and failed-review states per post, per client, on the one calendar the account shows, with dates you can move and posts you can discard.
- Its own search data
- Connect a client's Search Console read-only and the clicks, impressions and average position sit beside their calendar.
- Its own plan per client
- Queries the client's site already answers are marked as covered and left alone, so you are not billing for a second version of a page that exists.
- Its own API feed
- Every account gets an API key: pull the posts a site has published — status, language, URL, dates — into the report you already send.
A month across your clients.
The rhythm does not change with the number of sites — only the number of calendars you are looking at. Five steps, from plan to report.
- 01
Plans land per site
Each client's calendar fills with dated entries: the query, the intent, the outline and the metadata, per language.
- 02
You approve, or it runs
Discard a post that does not fit the client's positioning. The plan is the brief behind each post, not the finished article.
- 03
Posts are written to the brief
Drafts follow the spec that was approved — same query, same outline — so there is no reinterpretation to catch later.
- 04
Publishing happens on the date
Live on the client's own domain with canonical URLs, structured data and the sitemap updated in the same run.
- 05
The report is already written
Clicks, impressions and average position per site, plus the API feed if the numbers need to live in your own dashboard.
Reporting you do not have to assemble.
Each site reports clicks, impressions and average position beside its calendar, so the monthly update is a screenshot rather than a spreadsheet. Where a client wants the raw rows, the API returns every published post with its URL, status, language and dates.
Because the blog is on the client’s own domain, these numbers belong to a property they own — which is a much easier renewal conversation than traffic that lives inside someone else’s platform.
1,204
Clicks
48,910
Impressions
12.4
Avg. position
What stays yours.
Xt4b handles the pipeline. It does not decide what a client should say — that is the judgement you are paid for, and it is the part the plan is designed to make easier, not replace.
- Which queries are worth going after for each client
- What gets published, and what gets discarded instead
- The dates, the languages and the cadence per market
- The brief behind any post you want written differently
- Everything downstream: reporting, strategy, the client relationship
Where agency hours actually go.
Content ops do not fail on strategy. They fail on the approving, the formatting and the chasing, repeated for every client.
Content ops, done by hand
- A spreadsheet per client, updated by hand from three tools
- Drafts sitting in an inbox waiting for a designer
- Metadata and internal links left to whoever publishes
- A monthly report that takes longer than the work it describes
- Nothing published in the week a big project lands
With Xt4b
- One dashboard, one calendar across every site and language
- Images, metadata and links produced with the draft
- Publishing happens on the date without an extra hand
- Numbers sit beside the calendar, ready to screenshot
- The pipeline keeps its cadence while you are firefighting
It fits the stack the client already has.
The concern with a platform is always what it locks you into. Here is what it touches, and what it leaves alone.
- Their domain, their URLs
- The blog answers on the client's own hostname, with canonical URLs pointing at it. You are not building equity on a platform you do not own.
- Their Search Console
- Access is read-only and per site, so a client can revoke it without losing anything, and you never hold write access to their property.
- Their CMS, if they have one
- Posts come back from the API with the markdown, the metadata and the published URL, so an existing CMS can be the destination instead of the blog.
- Their languages
- One site can carry several editorial lines. A German line gets its own queries and its own dates — not translated English posts on the same schedule.
- No new accounts to manage
- Client sites live in your account, so there is one login, one dashboard and one calendar view across everything you run.
- Nothing to explain at renewal
- Every published post is a URL you can show, with the impressions and clicks it earned, per site and per language.
More on content
- For startups
A content function without a content hire.
- For SaaS
Be the answer before the demo request.
- For B2B SaaS
Present for the six-month research window, not the launch week.
- For marketing teams
A pipeline behind the calendar, per site and language.
- For consultants
The enquiries that begin with a search.
Questions agencies ask.
Including the one about who is accountable for a bad post.
Do you white-label the platform?
The blog is hosted on your client's own domain with their own branding, so a reader never leaves their site. The dashboard you work in is Xt4b's, and the work it produces is yours to report on as you like.
How many client sites can one account run?
Sites are added individually, each with its own blog domain and its own languages, and the dashboard reports on them side by side — every post on one calendar, labelled with the site it belongs to. There is no separate account per client.
Do our clients need their own accounts?
No. You connect their domain and, if they agree, their Search Console read-only. From the client's side there is nothing to log into — the output appears on their own site.
Who is responsible if a post is wrong?
You are — turn approval on and nothing publishes until you release it, which is exactly where you want the last look. Posts that fail the final fact-check are held back and flagged rather than published quietly.
Can I get the content without using the blog?
Yes. The API returns the posts a site has generated with their status, language, dates and published URL, so a client's existing CMS can be the destination if you would rather keep their blog where it is.
How do we handle client approvals?
Turn approval on and every post waits for you before it publishes, so a client's sign-off happens before anything goes live rather than after. A post that does not fit the client can be discarded first.
Do you promise rankings for our clients?
No. You get a plan aimed at queries the client does not rank for, dated publishing and the data to show what it earned. Ranking, traffic and revenue are not guaranteed — and you should be wary of any content supplier who says otherwise.
Start with one client
Run one client site, then the rest.
Create an account and connect a client's domain: their plan lands on the calendar, and approval can be left on so nothing goes live without you.
Per-site domainsAPI for your reporting7 days free, no card30-day money-back guarantee