When you run more than one site

This is the page I most wanted to exist, because it describes how I actually work. I’ve spent twenty years running SEO sites and I operate several revenue-generating blogs on this exact tool. A CMS editor is fine when you have one site and you’re writing today’s post. It falls apart the moment your job is to keep five, ten, or twenty sites healthy at once, because everything it makes you do is per-post and per-site: log in here, fix a meta description, log out, log in there, do it again. The work that actually moves an agency’s numbers is the same change applied across a lot of posts and a lot of clients — and a web admin is the worst possible shape for that.

Specter changes the unit you work in from “a CMS behind a login” to one workspace across every client site. Subscribe now for 500 free credits.

The shape of multi-site work

When you manage several sites, your real tasks look like this: refresh a client’s stale top-of-funnel posts before a quarterly review, normalize tags across an archive three writers contributed to, fix internal links after a content cluster gets reorganized, add a disclosure or CTA to every post in a category, generate meta descriptions for the forty posts that never got one. Each is trivial in concept and brutal by hand, and it repeats across every account you hold. A CMS UI gives you no find-and-replace across posts, no bulk metadata view, and no way to let AI touch the whole archive. So the highest-leverage work is exactly the work the tool fights you on.

Every client in one place

Connect each client’s Ghost, WordPress, Shopify, or Webflow site once and its whole archive is content you can search, edit, and run recipes against. The day-to-day jobs become passes instead of marathons: refreshing old posts at scale, bulk SEO edits to titles and metadata, fixing internal links across the archive. Run the recipe, review the result, publish what’s right — across one account without touching another. Browsing and reviewing cost nothing; only AI runs spend credits.

The parts that matter when it’s a client’s site

Working fast on someone else’s blog is only an asset if it’s also safe. Before a bulk pass, Specter’s dry-run shows exactly which posts would be created, updated, or flagged as a conflict — so you see the blast radius on a client account before a single change is written. If a client edited a post while you were working, Specter prompts you about the conflict instead of silently overwriting their change — the kind of mistake that loses an account. And every publish keeps a snapshot behind it, so a bad pass is something you roll back, not something you re-do by hand.

Built to be wanted in front of clients

If you’re the kind of operator eyeing the Admin API and wondering whether to script all this yourself, that’s a fair instinct worth thinking through: why not just use the API directly lays out what a robust two-way sync actually takes to build and maintain. And if you’d rather run it on your own hardware — a folder per client as plain files, under your own git history — the desktop and open-source edition does exactly that.

The promise for an agency is narrow and real: every client’s site in one place, the cross-archive work the editor can’t do, every change reviewed before it ships, and a history of all of it. That’s the workflow I run my own sites on, which is the only reason I’m comfortable putting it in front of yours.