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 in two halves. Building a persona that reads as a real person is the part everyone thinks about. Not leaking that it isn't is the part that actually decides whether it survives. The second half 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.
Here's 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 |
Look at that list again and notice what it has in common: not one of them is visible while reading the site. The three sites looked entirely separate. Different palettes, different typefaces, different photos, different prose. A human reader would never have caught four of the five.
All five are trivially machine-detectable.
That gap, between what a reader notices and what a machine indexes, is the whole subject of this half of the module.
Here's the short version, and it's the only part you have to understand.
There are companies that 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 they let anyone search by that icon.
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 and nothing else.
That's it. Three sites, one icon, one search.
The scanners (Shodan and Censys are the two that matter) do not 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.
So the sequence is not "someone investigates you." It is:
The reason this generalises: 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.
The defence is not "change the icon." It is: nothing byte-identical crosses a persona boundary.
I want to be precise about what I got wrong, because it's what everyone gets wrong. I was defending against a reader. I pictured a fan of one pen name getting curious and poking around. That threat model is inverted.
Readers are not the threat. Readers don't view source, don't hash icons, and have never heard of Censys. The threat is that the correlation is precomputed by infrastructure that was never looking for you, and querying it costs one line. You are not hiding from a detective. You are hiding from a database that already has the answer and is waiting to be asked.
The og.jpg is the same lesson wearing different clothes. It wasn't just shared, it was byte-identical across three domains, which makes it one reverse-image-search away, and the image itself had the flagship's name printed on it. Every time someone shared a link to pen name B in a group chat, the preview card showed pen name A's branding. That is not an obscure technical leak. It is 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. Archive.org will serve it on request. Indefinitely.So 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. The fix stops the bleeding. It does not restore the secret.
That asymmetry is why this module comes before any of the pipeline work. The pipeline failures cost money. This one costs the thing you cannot rebuild.
Everything above is infrastructure. There is a second surface, and it is 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.
Think about where that ends 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. No audit of your websites catches it. 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 think only 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. Here's what actually worked, and the useful parts 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 do not carry identity. They carry a vibe, and the vibe re-rolls each time.
The fix: generate one good headshot, then upload it as a reference image for every subsequent shot. Same face, every time. The identity anchor is a file, not a paragraph.
Each pen name gets a spec file, versioned alongside the site, holding:
If your persona spec is in your head, you have no persona. You have a memory of one, and it drifts.
This is the finding I'd pay for, and it's completely backwards from instinct.
The tell is not the face. The tell is the image quality. An AI portrait fails because it looks like a professional photograph of a person who does not 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 rather than 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, because it is simulating the actual physical thing that makes a photo look real, which is a mediocre camera and a lossy pipeline.
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 is 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. 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 is not any pen name's. That work is not done. The facade is intact and the tooling is worse, and I took that trade knowingly, which is what these trades actually look like.
Run this per pen name. It exists because vigilance does not 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 does not 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 cannot 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 is the honest price of the persona layer, and it is why Module 2 is about content lanes. If you are paying three times for infrastructure, the pen names had better be genuinely different products. Otherwise you are paying triple to run one business badly.
And it's 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.