What to actually do
og.jpg, preview images, fonts, analytics ID.config.js; no pen name links to another.I ran three pen names. Different voices, different genres, different websites, different newsletters, different email addresses. Months of separation work, and it held.
Then I found that a single search query could have collapsed all three into one owner, because every one of them served the same favicon.
Not a link. Not a byline. A 1 kilobyte icon in a browser tab.
This module is in two halves because the job is: building a persona that reads as real, and not leaking that it isn't. The second is harder, and I got it wrong first.
Each row is one shared surface. The dots are the pen names it ties together. Every one of these was live for months, and none of it was visible while reading the sites.
This is what an audit of my own three sites turned up. Every one of these was live, in production, for months.
| The surface | What it leaked | How you'd find it |
|---|---|---|
| The flagship's monogram favicon, served on all three domains | All three sites are one operator | Favicon hash search on Shodan or Censys |
The pen-name roster in public config.js |
Every name, domain, email and API endpoint, on all 15 pages | View Source |
| An "Owner" footer link pointing at the flagship domain | A literal hyperlink from B and C to A, on 13 pages | Scrolling to the bottom |
A flagship-branded og.jpg on all three domains |
Byte-identical file, and it literally printed the flagship's name and URL | Paste a link into any chat app. Or reverse image search. |
A shared author ID in llms.txt |
The same storefront identity, in a file written for AI crawlers | Fetch one file |
Not one of those is visible while reading the site. The three sites looked entirely separate. A reader would never have caught four of the five.
All five are trivially machine-detectable.
Companies scan every website on the internet, all day, forever. When they reach a site they take its little tab icon and file it away, then let anyone search by it.
My three sites had the same icon. So the answer to "which sites belong to this person?" was already sitting in a public database, filed months before anyone thought to ask, and looking it up costs one search. Three sites, one icon, one search.
The scanners (Shodan and Censys are the two that matter) don't store the icon itself. They store a hash of it, a short fingerprint computed from the file's bytes. Identical bytes produce an identical fingerprint, and that fingerprint is an indexed, searchable field.
Nobody has to investigate you for this to happen. The sequence goes:
And it generalises, because any byte-identical file served from two places is a join key. The favicon is the famous one because it is tiny, cached forever, copied between projects without thinking, and indexed by third parties you have no relationship with. But the same logic applies to a shared analytics ID, a shared preview image, a shared font file, or a shared error page. If two of your properties serve identical bytes, someone else's database has already linked them.
So the defence isn't a new icon. The defence is that nothing byte-identical crosses a persona boundary, anywhere, ever.
I want to be precise about what I got wrong, because it's what everyone gets wrong. I was defending against a reader, a curious fan of one pen name poking around. That threat model is inverted.
Readers don't view source, don't hash icons, and have never heard of Censys. The correlation gets precomputed by infrastructure that was never looking for you, and querying it costs one line. The database already has the answer and is waiting to be asked.
The og.jpg is the same lesson with nothing technical about it. It was byte-identical across three domains, one reverse-image-search away, and printed the flagship's name. Every time someone shared a link to pen name B in a group chat, the preview card showed pen name A's branding. It's the front door.
The favicon is fixed. Each pen name has its own now, different bytes, not a renamed copy.
That does not undo the exposure, and this is the part I'd most want you to take seriously.
config.js. If it did, archive.org will serve that snapshot on request. Indefinitely.The rule that follows is uncomfortable: you cannot audit your way out of a breach after the fact. You can only avoid making it. A persona leak behaves like a disclosed password, not a bug.
That asymmetry is why this module comes before any of the pipeline work. The pipeline failures cost money. This one costs the thing you can't rebuild.
Everything above is infrastructure. There's a second surface, and it's worse.
My writing agent's file paths were hardcoded to the flagship pen name's directory, with no parameter for which pen name it was writing as. A book commissioned for pen name B would draft into pen name A's folder and pick up pen name A's byline and pen name A's newsletter URL on the way through.
Where does that end up? Not in a config file. In the manuscript. In the back matter. In an epub, uploaded, sold, sitting on a stranger's Kindle, with the wrong author's name and the wrong author's mailing list inside it.
No crawler catches that, and no website audit does either. You find out when a reader emails the wrong author, and by then it is distributed to everyone who bought the book and cannot be recalled.
So the facade has two surfaces, and they fail differently:
| Infrastructure | The artifact | |
|---|---|---|
| Visibility | Public and machine-indexed | Private until you ship |
| How it's found | Automatically, by crawlers, for free | A reader notices |
| Fixable? | Forward, yes. Retroactively, no. | Not at all. It's on their device. |
Most people building this only ever think about the first column. The second one is the one that ships.
A persona is not a name. It is every surface a machine can hash.
The prose is the part everyone works on and the part that matters least. Nobody is correlating your writing style. Stylometry is a research problem. Favicon hashing is a search box.
| Effort most people spend | Effort it deserves |
|---|---|
| Making the voices sound different | Some. Table stakes, and the easy part. |
| Separate bios and photos | Some. It's visible, so it's obvious. |
| Every machine-readable surface | Almost all of it. This is where you get caught. |
The defensive half keeps a persona from collapsing. It doesn't make one exist. What follows is the part that actually worked, and the useful bits are the counterintuitive ones.
My first approach was a detailed text prompt describing each author's appearance, reused for every image. It produced a different woman every generation. Text prompts don't carry identity. They carry a vibe, and the vibe re-rolls each time.
What fixed it was generating one good headshot and then uploading it as a reference image for every subsequent shot. Same face, every time. What anchors the identity is a file, not a paragraph of description.
Each pen name gets a spec file, versioned alongside the site, holding:
If the spec only exists in your head, you don't have a persona. You have a memory of one, and memories drift.
This is the finding I'd pay for, and it's completely backwards from instinct.
The tell isn't the face, it's the image quality. An AI portrait fails because it looks like a professional photograph of someone who doesn't exist. Real people do not have studio lighting in their bedrooms.
So the prompt splits in two directions at once:
Both of the obvious "corrections" made it worse:
Then finish it in code, not in the prompt. A post-processing pass adds grain, chroma noise, chromatic aberration, vignetting and a recompression cycle. Two strengths: light for a selfie, heavier for a candid. That step does more for believability than any amount of prompt wrangling. It simulates a mediocre camera and a lossy pipeline, which is what actually makes a photo look real.
Two more that took real iteration:
Each persona has a headshot, a portrait selfie, and a weekend photo: candid, with friends, doing something specific and mundane. Pickleball. A dim cocktail bar. Rooftop drinks.
The weekend photo is the one that makes the persona real, and it's the one nobody builds. An author with only a headshot is a stock photo. An author with a bad photo of herself at a bar has a life. Nobody consciously registers it, but everybody notices its absence, as the vague sense that a page is "off."
Three sites, three palettes, three typefaces, three hair colours, three eye colours, three lip colours. Chosen so that no two are similar, deliberately, up front. This is cheap when you do it first and nearly impossible to retrofit once each pen name has a catalogue.
I run exactly one admin panel, on one domain, that can reach all three pen names.
That sounds like it contradicts everything above. It doesn't, and the distinction matters:
Back when that roster sat in config.js, one convenience feature (a brand switcher) put the complete list of names, domains, emails and endpoints into view-source on every page of the flagship's site.
And here's the honest part, because the fix wasn't free: stripping the roster out broke the multi-brand admin. It degrades to single-brand now and fails safe. Restoring it properly means serving the roster from an authenticated API, or hosting the owner console on a neutral domain that isn't any pen name's. That work is not done. The facade is intact and the tooling is worse, and I took that trade knowingly. That is what these trades actually look like.
Run this per pen name. It exists because vigilance doesn't work and a list does.
Static surfaces
og.jpg and every social preview image. Check the bytes, not the filename.llms.txt, robots.txt, humans.txt, any declared author or storefront ID.Infrastructure
Content, the one that ships
Process
That last line is the actual lesson. Four of my five breaches were shipped by someone who knew the rule and was being careful. Careful doesn't scale to three brands and 500 books. A test does.
That test is what the paid kit ships. Work this checklist by hand today, and you should. The kit is the version that can't forget.
Three of everything. Three sites, three certificates, three analytics properties, three newsletter systems, three photo sets, three spec files. Every shared component is a correlation risk, so "just reuse the header" stops being a convenience decision and becomes a security one.
That's the honest price of the persona layer, and it's why Module 2 is about content lanes. If you're paying three times for infrastructure, the pen names had better be genuinely different products. Otherwise you're paying triple to run one business badly.
It's also why I won't show you my catalogue in this course. Not caution for its own sake. I watched a favicon undo months of separation work in one query. Publishing the roster deliberately, in order to sell a course about the roster, would be the same mistake with better marketing.