One Voice Per Site: Building Tone Rules That Actually Hold

You run ten sites. You paste the same brand brief into all ten. Three months later, every site sounds like the same slightly-off writer, and none of them sounds like itself.

The fix isn't a better brief. It's encoding audience, tone, and topic map once per site, as rules a pipeline can actually enforce. By the end of this post you'll know what to write down for each site, in what order, and how to prove the voice held.

What you need first: the sites themselves. Their published pages, not your memory of them.

Why one shared brief breaks ten sites

A brief is written for one audience. When you paste it into Site B's pipeline, Site B's posts address Site A's reader with Site A's vocabulary. Draftlume documents that absent or inadequately defined style guides lead to generic, off-brand AI copy. Frontitude makes the sharper point: vague, non-specific instructions produce inconsistent tone, style, and terminology, which quietly undermines brand coherence on every site at once.

The failure mode is predictable. Your fintech brief says "address stakeholders concerned with compliance." Your woodworking blog now writes about compliance stakeholders. Nobody catches it, because each post is individually plausible.

The pitfall to avoid here is "close enough" voice rules. If a rule doesn't name the audience, it can't be enforced. "Professional but friendly" is not a rule. "Second person, contractions on, no sentence over 25 words, never say 'leverage'" is a rule.

What to encode per site: audience, tone, topic map

Three things, per site. Nothing else survives contact with a pipeline.

Audience. Who reads this site, in one or two sentences, with the vocabulary they already use. "Home woodworkers shopping for their first lathe" is an audience. "Enthusiasts" is not.

Tone. Concrete rules, not adjectives. Brande.ai's help centre lists exactly the kind of rules AI tools can encode: active voice, contractions, banned words, punctuation preferences. Write yours at that level of specificity.

Topic map. The territory this site covers, and just as important, what it doesn't. A topic map with no edges lets any trending idea walk in.

ContentRails' terms define Project DNA as the profile of each site's audience and voice built from the sites you add as projects (contentrails.ai). One DNA per project. Not one per company.

Step 1: Write the DNA from the site's own pages, not from memory

Read the site's best existing pages first. The voice is already in the copy. Your memory of the voice is usually your memory of the pitch deck.

Write rules a machine can follow, not vibes a human can infer. Atomwriter recommends comprehensive, machine-readable style guides with clear, actionable instructions so AI output consistently reflects the brand's voice. "Warm" is a vibe. "Contractions on, sentences under 20 words, second person" is a rule.

This is also where ContentRails does the work for you. It writes the Project DNA, covering audience, tone, and topics, automatically from your site's pages, with no brief to write, and you can edit it if it's off (contentrails.ai, contentrails.ai). Point it at the site, read what it produced, correct the parts that miss. That correction is the highest-value ten minutes in this whole process.

Pitfall: writing the DNA from the company's self-description instead of its actual published voice. The About page says "innovative." The blog says "here's how to fix a wobbly fence post." Trust the fence post.

Step 2: Keep each site's rules isolated from the others

A DNA only holds if it can't drift. Store each one inside its own project, so nothing leaks. ContentRails keeps each project's DNA, topics, and posts separate, with nothing bleeding between the sites you run. Ten sites, ten voices, by default rather than by discipline.

Set automation per project too, not globally. ContentRails offers four levels, Off, Suggest topics, Write drafts, and Full autopilot, set per project under Settings. Its own blog argues no single rule fits every site you run (contentrails.ai), and voice rules are no exception. Your experiment site can run further ahead than your money site.

The pitfall: a global "house voice" setting that quietly overrides the per-site DNA. If you have an account-wide tone preference anywhere in your stack, delete it. House voice is shared brief with better branding.

Step 3: Run topic research and drafting inside the DNA, not around it

Topic ideas should come from the site's topic map, not from whatever is trending. ContentRails' research checks what your site already covers and what's new in your niche, drafts ten ideas, and a separate critic scores them. The critic scores fit, not just novelty.

The sequence matters as much as the ideas. ContentRails' pipeline runs plan, research, cited fact sheet, outline, draft, checks, editor, in that order, each step logged (contentrails.ai). Voice and sourcing rules fail together if drafting happens before either is set. That's why the cited fact sheet comes before the draft: the draft can only cite what was retrieved, with no step where prose is written first and sources found later.

Pitfall: letting a hot topic pull a site outside its topic map because the idea scored well. A high score on an off-map topic is still off-map. Reject it or amend the topic map deliberately, on purpose, in writing.

Step 4: Review against the DNA before anything publishes

Check each draft against that site's DNA, not your general taste. Three questions: right audience, right tone rules, on-topic. Your taste is calibrated to your favorite site. That's exactly the bias this whole setup exists to defeat.

Know what the tool does and doesn't promise. ContentRails' terms state generated content may still contain errors, and you are responsible for reviewing before publishing. Drafts aren't published until you approve them unless full autopilot is on, and every draft carries its sources.

The pitfall: approving a draft because it's accurate. Accuracy isn't voice. A factually perfect post addressed to the wrong reader is still a failed post.

Before/after: the same topic under two different Project DNAs

Topic: "How to price a subscription product."

Before — one shared brief, fintech SaaS voice pasted everywhere:

Subscription pricing strategy requires stakeholders to conduct a comprehensive analysis of market positioning and customer segmentation prior to determining optimal price points. Organizations should leverage cohort-based analysis to maximize lifetime value.

Now imagine that on a hobbyist woodworking blog that got the same brief. Correct facts, wrong planet.

After — per-site DNA. The SaaS site gets the formal version above, aimed at finance leads, jargon intact. The woodworking site gets:

So you want to charge for your plans. Here's the honest math. Most of your buyers will spend a modest amount without blinking. Don't overthink the tier structure; two options beat five, every time.

Same topic. Two correct voices. Short sentences, contractions, hobbyist-budget framing on the second, formal register and "stakeholders" on the first. The only thing that changed was the DNA each draft was written under.

You can test this on a single site first. ContentRails' free plan runs one project end to end, including a Project DNA, topics, and three posts a month.

How to check it worked, and what to do next

Run the blind test. Read a new draft without seeing the site name. If you can't tell which site it belongs to, the DNA isn't holding. This takes thirty seconds per draft and catches more than any checklist.

Then spot-check tone rules one by one against the draft: contractions, banned words, sentence length. Rules you wrote in Step 1 are now a rubric. Grade against them, not against whether you liked the post.

Re-read the DNA whenever the site changes direction. A stale DNA produces a stale voice, and you remain responsible for review before publish either way.

Next step: audit one site this week. Fix its DNA, generate its next draft, and compare that draft to the last one before approving anything for publish.

The decision rule: if you can't say which site a draft came from with the byline hidden, the voice rules aren't holding. Fix the DNA, not the draft. Then pick your two most different sites, run the pipeline on both, and compare the drafts against each DNA before anything goes out.