Fleet Sites and Shared Standards Without Blandness

Taciturn Studios runs a family of websites alongside its books: topic sites, tools, author pages and reference projects. Running many sites with a small team creates an obvious temptation: build one template and stamp it everywhere. That saves time, but it also produces a fleet of sites that look, sound and feel identical, which is bad for readers and, increasingly, bad for search visibility.

Our approach is to share the plumbing and protect the personality. This post explains where we draw that line and why.

What should be shared

Some things should be identical across every site, because doing them differently adds risk without adding value.

Legal and policy pages

Every site needs a privacy policy, terms of use, a cookie notice where required, and clear disclosures for advertising and affiliate links. These have to be accurate for how the site actually works, which means they must reflect the real analytics, advertising and data practices in use. Sharing a vetted foundation, then adjusting the details per site, is far safer than writing each from scratch.

Disclosure rules aren't optional. In the United States, the Federal Trade Commission's Endorsement Guides require clear disclosure of material connections such as affiliate commissions. In the EU and UK, the GDPR and related rules govern consent and data handling. A shared, maintained policy layer means a change in our practices or the rules can be applied everywhere at once.

Analytics and measurement

Each site should have its own analytics property so its numbers aren't mixed with others, but the way we measure should be consistent: the same core events, the same naming, the same dashboards. That consistency lets us compare sites honestly and notice when one starts to drift.

Technical SEO foundations

The basics of being findable are the same everywhere: a correct sitemap, sensible canonical URLs, real 404 responses for pages that don't exist, fast mobile pages, descriptive titles, and server-rendered or prerendered content that search engines can read. These belong in shared code and checks, not in each site's to-do list. Google's own Search Essentials documentation is the reference we work from.

Security and maintenance

Dependency updates, secret handling, deploy processes and monitoring should follow one standard. When a vulnerability is announced in a common library, we want one checklist to run across the fleet, not a separate investigation per site. We cover the repository side of this in Contractor-Friendly Repo Hygiene.

What must not be shared

Here's where fleets usually go wrong.

Voice

A site about smoothie recipes and a site about Stoic philosophy shouldn't sound alike. Each needs its own register, vocabulary and sense of who it's talking to. Generic voice is easy to spot, and readers who notice it stop trusting the content.

We write a short voice note for each site: who the reader is, what they already know, how formal to be, what the site never does. Writers and editors use it before touching anything.

Content

This is the most important line. Templated content, meaning the same article structure with a few words swapped or paragraphs padded out to hit a length, is exactly what both readers and search engines have learned to distrust. Google's guidance on "helpful, reliable, people-first content" asks whether content provides original information, analysis or insight, and its spam policies (updated in March 2024) specifically name "scaled content abuse": producing many pages primarily to manipulate rankings rather than help people.

So content is never shared or templated across sites. Each article should exist because it answers a real question for that site's reader, with sources where facts are claimed. We'd rather a site have ten genuinely useful articles than a hundred hollow ones. More on how we pace this in A Calm Approach to Shipping Content at Scale.

Design details

A shared component library is fine, the same way many publications share a content management system. But color, typography, imagery and layout choices should fit the subject. A shared skeleton with distinct skin is the goal.

How we keep the line clear

A few practices help:

1. A fleet checklist for the shared layer. Legal pages present and accurate, analytics installed, sitemap valid, real 404s, mobile performance acceptable, ads.txt correct where ads run. It's mechanical and checked regularly.
2. A voice note for the distinctive layer. One page per site, reviewed before new content goes up.
3. No copy-paste between sites. If two sites need to cover a similar topic, each writes its own piece from its own angle.
4. Regular audits. We periodically read a sample of each site's pages as a visitor would. Checklists catch broken plumbing; only reading catches blandness.

Mistakes we try not to repeat

Running several sites teaches lessons the hard way. A few we keep in front of us:

• Fixing a shared problem one site at a time. When the same bug shows up on a second site, it belongs in the shared layer, with a check that catches it everywhere.
• Letting a template set the length. An article should be as long as its subject needs. Padding a short answer to hit a word count makes it worse for the reader, and readers notice.
• Copying a policy page without reading it. A privacy policy that mentions a newsletter the site doesn't have, or omits the analytics it does use, is inaccurate, not just untidy.
• Assuming a site is fine because the dashboard is green. Uptime monitors don't notice a page that loads perfectly and says nothing useful. Only a human reading the page does.

The payoff

Shared standards make a fleet cheaper and safer to run. Distinct voices make each site worth visiting. Getting both is the difference between a portfolio of real publications and a network of interchangeable pages.

It also makes measurement more honest. When every site shares the same foundation, differences in performance usually come from the content and the audience, not from a broken sitemap. We describe what we watch in Measuring Fleet Health Beyond Vanity Traffic.

If you run more than one site yourself, whether an author site plus a series site or a few hobby projects, the same split applies at any scale: standardize what protects you, and personalize what readers come for. You can see the rest of what we build on the Taciturn websites page.