A knowledge base an AI system will cite is not a blog, it is an architecture: a hub-and-spoke set of pages built around one named identity, each fact stated in exactly one canonical place, every claim backed by schema, every page dated honestly, and every section written to survive being read alone. Depth and consistency of structure matter more than raw volume, and the single fastest way to lose citations is to let two pages on your own site quietly disagree with each other.
Step two of the PEO method is where most people go wrong. They publish more pages when the engine is asking for a more coherent structure. Here is the technical architecture that turns a stack of pages into a knowledge base a retrieval system can trust.
Depth with a point of view
The mistake to avoid is bland comprehensiveness. The internet already drowns in competent, characterless explainers, and engines increasingly discount them, because a machine can generate an infinite supply of them. What a machine cannot generate is your specific, opinionated take, the position only you hold because of what you have actually done.
So publish positions, not summaries. Not "what is personal branding," a question the engine can answer without you, but the contrarian, earned view you formed from real work: what most people get wrong, what you changed your mind about, the counterintuitive thing your experience taught you.
Could a machine have written this without you? If yes, it will not move your Knowledge signal. If it carries a position only you can defend, backed by a fact only you can cite, it will.
The architecture: hub-and-spoke, not a flat pile of posts
Most personal sites grow as a flat list: a blog folder where every post sits at the same level, linked to nothing but the homepage and the next post chronologically. That structure tells a retrieval system nothing about which pages matter most or how they relate. A knowledge base an engine can navigate is built the opposite way: one pillar page per core topic, stating the complete, canonical view, with a cluster of supporting pages underneath it, each covering one sub-question and linking back up to the pillar.
For a personal brand, the pillar is usually the about page or a dedicated topic hub, the page that names you, states your specialization, and links out to every deep-dive that expands on a piece of it. The spokes are individual articles, each answering one narrow question in the depth a pillar page cannot afford. When a retrieval system encounters a spoke page, the internal link back to the pillar, and the pillar's link out to every other spoke, tells it these pages form one coherent body of work rather than unrelated documents that happen to share a domain.
1. One pillar page per topic, naming you and stating the complete position.
2. Five to fifteen spoke pages, each answering one sub-question the pillar only summarizes.
3. Every spoke links up to the pillar in its first two paragraphs.
4. The pillar links out to every spoke, grouped by sub-theme.
5. New spokes get added under existing pillars before a new pillar is created.
The mechanics of why individual sections need to stand alone inside this structure are covered in chunk theory: a hub-and-spoke architecture decides which pages exist and how they connect, while passage-level formatting decides whether any single section within them survives being retrieved on its own.
Canonical facts: one source of truth per claim
Every knowledge base accumulates repeated facts: years of experience, number of clients served, the year a company was founded, a credential earned once. The instinct is to restate these facts wherever they are relevant, which is exactly how a site ends up contradicting itself. One page says twelve years of experience, written the year it was published and never updated. Another, written two years later, still says twelve. A retrieval system that pulls both passages into the same context window sees a contradiction and often responds by trusting neither number, or by quietly dropping your source from the answer entirely.
The fix is to designate one page, usually the about page or a dedicated facts page, as the canonical source for every recurring number and claim. Every other page that needs the fact links to that page rather than restating the number independently. When the fact changes, you update it once, in one place, and every reference stays accurate by pointing at a source instead of duplicating a value.
| Approach | What happens over time | Effect on citation |
|---|---|---|
| Restate the fact on every page | Pages drift out of sync as some get updated and others do not | Conflicting numbers across sources reduce trust and citation odds |
| One canonical page, others link to it | A single edit keeps every reference accurate | One consistent number reinforces the same claim across the site |
| No stated fact, vague language instead | Nothing to contradict, but nothing specific to cite either | Passages without specifics are rarely lifted into answers at all |
Three ways sites handle recurring facts, and what each one does to citation odds over time.
The deeper mechanics of how conflicting facts across sources actively suppress citation, not just fail to help it, are covered in contradiction debt. Treat that piece as the audit checklist to run once the canonical-fact structure above is in place.
Format so the engine can lift you
Engines quote what is easy to extract. Lead with a clear, direct answer near the top of each piece, the 30-to-60-word version an answer engine can lift whole. Then expand. Use clean structure, real headings, and question-shaped sections that match how buyers ask. Make the attribution unambiguous, so every piece obviously belongs to one identity. The passage-level rules for doing this well are the entire subject of answer-shaped writing, and they apply to every spoke page in the hub-and-spoke structure above.
Internal linking patterns that carry authority to the pages that matter
Internal links do two jobs in a knowledge base: they tell a crawler which pages exist, and they tell a retrieval system which pages are related enough to be considered together. Three patterns matter most for a personal knowledge base.
- Upward links from every spoke to its pillar. Placed early in the body, not buried in a related-posts widget at the bottom, so the connection is visible in the first chunk a crawler is likely to index.
- Lateral links between spokes that share a sub-theme. When two articles both bear on the same buying question, link them to each other directly, rather than relying on the pillar to connect them indirectly.
- Downward links from the pillar to every spoke. Grouped by sub-theme rather than dumped as one long list, so the grouping itself communicates the topic's internal structure.
Anchor text matters more here than in traditional SEO link-building. Use the actual phrase a buyer would type as a query, not a generic "read more," because the anchor text is one of the few signals a retrieval system has about why two pages are connected.
Schema.org: making the identity behind the base machine-parseable
A hub-and-spoke structure tells a crawler how your pages relate to each other. Schema.org markup tells it who the pages are about, in a format that does not require inference. A Person block, present on the pillar page and ideally referenced consistently across spokes, is the anchor.
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Your Name",
"url": "https://yoursite.com/about",
"description": "One-sentence, canonical description of who you are and what you do.",
"knowsAbout": ["Topic One", "Topic Two", "Topic Three"],
"sameAs": [
"https://www.linkedin.com/in/yourname",
"https://www.wikidata.org/wiki/YourEntityID"
]
}
A minimal Person block for the pillar page of a personal knowledge base.
The sameAs array is doing more work than it looks like it is doing: it is the mechanism that lets an engine merge mentions of you across platforms into one entity instead of treating each profile as a separate, unrelated person. That mechanism is explained fully in sameAs: the most underrated markup, and the broader case for Person and Organization schema across a whole site is in the Person schema JSON-LD guide. If your name collides with other people online, the disambiguation problem this solves is covered separately in name collisions in PEO.
Freshness signals: why dateModified is not cosmetic
A visible publish date and an accurate dateModified value do real work beyond reassuring a human visitor. Retrieval systems and the crawlers that feed them weigh recency as one signal among several when a topic has any time-sensitive component, and a page that claims to be current but carries a two-year-old, unchanged date undercuts its own credibility even if the content is still accurate. Update the visible date and the schema date together, and only when something on the page has actually changed. A date bumped without a real edit is a freshness signal you cannot back up if anyone checks.
Keep a simple internal log of what changed and when, even a one-line changelog at the bottom of a pillar page. It gives you an honest answer when you ask yourself whether today's date bump is earned, and it gives a human reader the same confidence a machine is inferring from the schema.
Attribute everything to one name
A knowledge base only counts if the engine can attribute it to you. Publish under a consistent name, on properties clearly connected to your identity, with a consistent bio repeated word for word where it appears. Scattered, anonymous, or inconsistently bylined work dilutes the very signal you are trying to build. The identity layer that ties bylines, schema, and profile pages into one recognizable entity is covered in structuring your identity for machines, and the specific pattern for the about page itself is in the machine-readable about page.
Where to publish
Own the core: a site or properties you control, where the canonical version of your thinking lives, structured as the hub-and-spoke architecture above. Then extend onto platforms the engines already trust and crawl, and consider a dedicated llms.txt file that points AI crawlers directly at your canonical pages. The goal is not to be everywhere, it is to be deep, consistent, and attributable in the places that feed the answers your buyers see. A useful way to think about the whole base as a graph of entities and facts rather than a stack of pages is laid out in knowledge graphs for people.
A worked example: Priya Nair's knowledge base, before and after
Imagine a fractional CFO named Priya Nair with eleven pages published over three years: a homepage, an about page, and nine blog posts added in no particular order. Her "years of experience" figure appears differently on four separate pages because each was written and never revisited. None of the posts link to each other, and none link back to the about page in the body text. Her bio is worded three different ways across her site, her LinkedIn, and a guest post from the previous year.
The rebuild does not require new content. It requires restructuring what exists: the about page becomes the pillar and the single canonical source for her years of experience and client count, every blog post gets one upward link to the about page added to its opening paragraphs, posts that cover related sub-questions get linked to each other, a Person schema block goes on the about page with a sameAs entry for her LinkedIn profile, and the three versions of her bio get replaced with one sentence, copied verbatim everywhere it appears. Nothing new was written, and the site went from eleven disconnected documents to one coherent, checkable body of work.
FAQ
How much do I need to publish? +
Should I write for humans or machines? +
Does guest posting count? +
How do I stop pages on my own site from contradicting each other? +
Do I need schema markup for a personal knowledge base? +
How often should a knowledge base be updated? +
Find out what AI says about you today.
Start with a baseline. See the exact words the engines return about your name, then decide.
Claim your name →