Rolling out a shared template across many sites

A shared base build is a maintenance decision, not a disguise. You keep one theme, one plugin set and one patching routine so that a security fix reaches every property the same afternoon. The cost is that everything you did not bother to change becomes a shared marker. Nobody has to reverse-engineer anything: the same placeholder bio, the same sample page and the same author name across a dozen domains are simply visible. The work is separating the layer that benefits from being identical from the layer that has to be genuinely written per site.

Why a shared base is worth defending

Running each site on its own bespoke stack sounds safer and is usually worse. A single base gives you one version to track, one place to test an update before it reaches production, and one honest answer to "is this vulnerability present here". Estates that drifted into per-site improvisation tend to be the ones carrying an unpatched component for months, because nobody could say what was installed where. Keep the base. Fix the leakage instead.

The two layers

The line is not "public versus private". It is whether a reader or a customer is meant to experience the item as belonging to this specific site. A cache TTL is not. An About page is.

The artefacts people forget

These survive launch because they are boring, and they are exactly what turns a reasonable engineering choice into an obvious pattern.

• Sample and demo content. The starter post, the placeholder page, the demo images that shipped with the theme. Delete them, do not merely unpublish them; unpublished drafts still occupy predictable URLs and slugs.
• Meta descriptions. A template default such as "Just another site" or an unchanged tagline propagates to every property and shows up verbatim in search results.
• Author records. The account you build with becomes the byline. Sites that were never meant to look related end up sharing one display name, one avatar hash and one author archive URL structure.
• Boilerplate legal and contact pages. Privacy and terms text can share structure, but the entity, address and email inside them must be the real ones for that site.
• Feed and comment defaults. Ping settings, default comment author, feed titles and RSS descriptions all inherit from the base.
• Leftover verification and analytics tags. A tag copied from the first build reports every site into one property, which is both a footprint and a data problem.
• Committed development traces. Readme files, build manifests and comment blocks naming the internal project.

Make the base incapable of carrying identity

The reliable fix is structural, not diligence-based. Strip the base build until it physically cannot carry a value that belongs to one site.

1. Remove every piece of real content from the base. It ships with empty sections and no posts.
2. Move site-specific values into one configuration file per site: entity name, contact address, author display name, description, analytics identifier.
3. Make the build refuse to complete if any of those values is still blank or still equals the base default.
4. After launch, list one field at a time across every site and look for repeats. Duplicate meta description, duplicate author name and duplicate contact address are the three that appear most often.
5. Re-run that comparison whenever you add a site, because the newest clone is the one that inherited the most.

None of this changes what a site is or claims to be. It changes only whether your operational shortcuts are doing the talking. If your base is a managed CMS build, most of these defaults come from the platform rather than from you, so a WordPress hosting environment with a clean starting profile removes a good share of the cleanup before it starts. The sequencing side of a multi-site rollout is covered separately in launch playbooks, and the ongoing update discipline in running your estate.