TL;DR: Generic AI humanizers have no concept of a "protected span," they rewrite everything with equal weight, which means exact-match keywords silently get paraphrased away. Walter MCP fixes this by treating preservation as an explicit constraint passed before the rewrite runs, verified afterward with a compliance report. This post covers the actual mechanism, real prompt templates for single-article and batch (up to 25 items) use, and the specific edge cases that still break if you're not precise about them.
If you've ever run SEO content through a humanizer and found your target keyword quietly turned into a synonym, you've hit the core problem this post is about. It's not a bug in any specific tool, it's a structural consequence of how most humanization works.
Why this breaks by default
Most humanizers operate as a single, undifferentiated rewrite pass. You give them text, they give you back text that's statistically less predictable, varied sentence length, different transition words, less uniform rhythm. That's the whole mechanism. There's no concept baked into that process of "these fourteen characters must survive verbatim, everything else is fair game."
So when a rewrite model decides "best CRM for small business" reads more naturally as "top CRM for small businesses," it's not malfunctioning. It's doing exactly what it was optimized to do: produce more natural, less predictable text. It just has no idea that string was your target keyword and the whole reason the article exists.
This is the same class of problem as prompt injection or context leakage in other AI tooling contexts: the model has no privileged, protected region of its input unless you explicitly tell it one exists.
How Walter's preservation mechanism actually works
Walter MCP handles this by treating preservation as a constraint you pass explicitly before the humanization tool call runs, not something inferred from context. The flow looks like this:
1. detect(text) → paragraph-level AI-likelihood scores
2. humanize(text, preserve=[...exact strings...], flagged_only=true)
3. compliance_report → confirms each preserved string survived
The constraint list isn't a suggestion the model weighs against naturalness. It's closer to a hard filter applied to the rewrite, exact strings you list are checked against the output, and the compliance report step exists specifically because "I told it not to change X" and "X definitely didn't change" are two different claims, and only the second one is worth trusting in an automated pipeline.
The basic single-article prompt
Here's the actual prompt structure for a one-off article:
Write a 1,200-word article targeting "[exact keyword]".
Then:
1. Run detection on the draft. Show me paragraph-level scores, don't
rewrite anything yet.
2. Humanize only the paragraphs that flagged.
3. Preserve these exact strings, character for character, including
capitalization:
- "[exact keyword]"
- "[Brand Name]"
- "[Product Name]"
4. Do not touch any links or numerical data.
5. Return a compliance report confirming each preserved string survived.
The detect-first step matters as much as the preservation list. Humanizing the whole document indiscriminately increases the surface area where something you forgot to list could get touched. Scoping the rewrite to only the flagged paragraphs shrinks that risk mechanically, not just as a style preference.
Scaling it: batch preservation across many items
Single-article preservation is straightforward. The real test is whether it holds up when you're processing 15 product descriptions or a batch of programmatic SEO pages in one pass, since that's where manual verification stops being feasible and you actually need the compliance report to be trustworthy.
Walter's batch tool handles up to 25 items per call, each with its own preservation list:
I have 15 product descriptions. For each one:
1. Humanize the description.
2. Preserve the exact product name and price for that specific item
(see list below, one preservation set per item).
3. Flag any item scoring above 30 on detection after humanization for
my manual review.
4. Return a per-item compliance report.
Item 1: [description] | Preserve: "[Product Name]", "[$Price]"
Item 2: [description] | Preserve: "[Product Name]", "[$Price]"
...
For programmatic SEO specifically, city-and-service landing pages being the common case, the preservation list is usually the page's exact H1 target phrase plus the service keyword:
Generate 20 local landing pages from this list of [city, service] pairs.
For each page:
1. Write a 300-word page targeting "[service] in [city]".
2. Humanize it.
3. Preserve the exact phrase "[service] in [city]" in the H1 and first
paragraph of every single page, no exceptions.
4. Confirm in the report that phrase is present and unmodified on every
page before returning results.
That last line matters more than it looks like it should. On a batch this size, "mostly correct" is a real failure mode, one page out of twenty silently losing its target phrase is exactly the kind of thing that doesn't get caught without an explicit per-item confirmation step.
Verifying preservation programmatically
If you're wiring this into an actual pipeline rather than running it interactively, don't just trust the compliance report text, parse it.
import re
def verify_preservation(compliance_report: str, required_terms: list[str]) -> dict:
results = {}
for term in required_terms:
# crude but effective: check the term is quoted as confirmed
# in the report text, adapt to whatever format your report returns
pattern = re.escape(term)
results[term] = bool(re.search(pattern, compliance_report))
return results
This is intentionally simple, the actual point is: treat the compliance report as structured output you validate against your original constraint list, not prose you skim. If you're processing content at any real volume, that validation step is what turns "the tool says it worked" into something you can actually build an unattended pipeline around.
Where this still breaks
Being straight about the failure modes, since pretending this is bulletproof would be more dangerous than not mentioning it.
Vague terms instead of exact strings. "Preserve our brand name" is not the same instruction as "Google", capitalized exactly like that. The model has to infer what "our brand name" refers to, and inference is exactly the gap that produces inconsistent output. List exact strings, always.
Capitalization and punctuation drift. If your preservation list says google and the source content uses Google, you may get inconsistent casing across a batch, since you've effectively given two different targets across different items. Match the list to the source, exactly, not an approximation of it.
Preserved terms inside a flagged paragraph that also needs structural rewriting. This is the genuinely hard case. If a whole paragraph is flagged and needs rhythm/structure changes, the preserved term inside it has to survive a rewrite happening around it, not just avoid being touched directly. This is where the compliance report earns its keep, since this is the scenario most likely to produce a false sense of security without it.
Plural and singular mismatches. Preserving "AI humanizer" doesn't guarantee "AI humanizers" (plural) is also protected, if your content actually uses both forms, list both explicitly.
Reusable templates
Copy these directly and swap in your own values.
Single article, SEO-focused:
Write a [word count] article targeting "[keyword]". Run detection first,
humanize only flagged paragraphs, preserve "[keyword]", "[brand]", and
all links/stats exactly as written. Return a compliance report.
Batch, e-commerce:
Humanize these [N] product descriptions. Preserve each item's exact
product name and price. Flag anything scoring above [threshold] for
review. Return a per-item compliance report.
Batch, programmatic SEO:
Generate [N] pages from this [variable] list. Preserve "[fixed phrase
pattern]" in the H1 and first paragraph of every page. Confirm presence
on every single page in the report before returning results.
Brand-voice locked:
Apply these constraints to every piece in this conversation: always use
"[preferred term]" not "[avoided term]", always capitalize "[Term]".
After any humanization pass, confirm these rules held before returning
output.
If you're doing this repeatedly, these belong in a saved system prompt or a Walter Skill (a markdown file loaded into a Claude project) rather than retyped per conversation, that's a separate topic, but worth knowing the option exists once the same constraint list keeps showing up across sessions.
FAQs
Does keyword preservation slow down the humanization process?
Marginally, since the model has to check output against a constraint list rather than rewriting freely. In practice this is negligible compared to the time saved versus manually verifying keyword survival after the fact.
What happens if a preserved term genuinely can't fit naturally after a rewrite?
The compliance report should flag this rather than silently dropping the term or silently forcing awkward phrasing. If you see forced, unnatural insertion of a preserved term, that's a signal the surrounding paragraph needed a different rewrite approach, not just a workaround.
Can I preserve terms across multiple languages in one batch?
Yes, though each preserved string still needs to be listed exactly as it should appear in that specific language's version, term lists don't automatically translate or transfer between language variants in a batch.
How many items can be preserved and processed in a single batch call?
Up to 25 items per batch call, each with its own independent preservation list and settings.
Top comments (0)