Turn your Obsidian article map into a WordPress site
A WordPress site usually starts as a list of posts. An Obsidian vault starts as a set of connected ideas. If you want an AI second brain to become a public site, the second model is more useful.
The goal is not to copy notes into WordPress one by one. The goal is to keep Obsidian as the place where the thinking happens, then project the useful public layer into WordPress.
That means three things need to move together:
- the article
- the links between articles
- the reader’s path through the material
Keep Obsidian as the source of truth
Write and edit the article in Obsidian first. Give it a stable identity, a clear slug, a publishing status, a language, and a short excerpt.
WordPress should receive that article. It should not become the place where the article’s meaning is decided.
This matters because context systems break when the same idea has two competing homes. If the title, category, or internal link changes in WordPress but not in Obsidian, the site may still look fine while the map behind it becomes unreliable.
For a small site, manual copying can work. For a growing knowledge system, use a simple rule: Obsidian is the source, WordPress is the projection.
Publish the map, not just the page
A normal blog archive tells the reader what was published. A knowledge graph tells the reader how ideas relate.
That is the difference.
If an article explains why context matters more than prompts, it should connect to the five-note setup. The setup article should then connect to the hands-on Obsidian guide and the decision-log loop.
The graph does not need to show every possible relationship. It should show the relationships that help the reader continue.
Use links as editorial decisions
A link is not decoration. It is an editorial decision.
Before publishing an article, ask:
- What does this article explain?
- What does the reader need before this?
- What should the reader read next?
- Which link would only add noise?
- Which link moves the reader closer to action?
This is where Obsidian is useful. You can see and revise the relationships before they become navigation on the public site.
Give the graph a job
Do not add a graph because it looks like Obsidian. Give it a job.
On the home page, the graph can act as a site map. It can show the main clusters: capture, organize, consult, act, privacy, tools, and product guides.
Inside an article, the graph should be smaller. It should show the current article and nearby context. The reader should be able to answer one question quickly: where do I go from here?
A full graph and a local graph are different interfaces. Treat them differently.
Separate languages cleanly
If the site has English and Japanese versions, do not mix untranslated articles into the wrong language graph.
A Japanese reader should not open a Japanese graph and find a path that silently drops into English unless that is clearly intentional. The same applies in reverse.
The graph should respect the same language boundary as the navigation, URLs, and calls to action.
Start with a small public layer
You do not need to publish the whole vault.
Start with a public layer that has:
- a small set of start-here articles
- stable article identifiers
- clear internal links
- one visible path for beginners
- one call to action
Then let the graph grow as the public system becomes clearer.
This keeps the site useful before it becomes large.
The practical workflow
A simple workflow looks like this:
1. Write the article in Obsidian. 2. Add stable frontmatter: title, slug, status, pillar, level, language, and excerpt. 3. Add only the links that help the reader. 4. Preview the article map. 5. Sync the article and graph data to WordPress. 6. Check the public page, local graph, language, and call to action. 7. Fix the source note if something is wrong.
The important part is step seven. Do not fix the public site in a way that leaves the source note behind.
Use a publication contract for every note
A graph becomes publishable when each note states what it is and the publishing layer knows what to do with it. The exact fields can differ, but the contract should be explicit.
---
uid: sbs-0123
title: "How to prepare context for one AI decision"
slug: prepare-ai-decision-context
publish: true
lang: en
content_id: sbs-0123
tier: free
pillar: consult
level: beginner
excerpt: "Build a small decision brief without sharing your whole vault."
---The fields solve different problems: uid gives the article a stable identity, slug controls the public address, publish creates an explicit gate, and content_id lets translations identify the same concept even when their URLs differ.
Before a sync can publish the note, run this mapping check:
| Source decision | WordPress projection | Failure behavior |
|---|---|---|
publish: true | create or update the managed post | stop if required identity fields are missing |
publish: false | keep it outside the public article set | do not expose the draft body |
| Wiki-link to a published UID | internal public link | report unresolved destinations |
| Wiki-link to a private or missing note | no public link | warn or fail according to policy |
shared content_id, different locale | translation relationship | require both sides before emitting alternates |
This table is the heart of the bridge. It turns publishing from “copy whatever is in this folder” into a set of reviewable decisions.
Verify one article end to end
Choose one harmless sample note and record four pieces of evidence: its source UID, its WordPress post ID, its final URL, and the result of a second sync. The second run should report no change. Then open every rendered internal link from that page and confirm that language navigation stays within its translation group.
Do this before scaling the graph. A sync that cannot prove identity and idempotency for one note will create harder-to-repair ambiguity across a hundred notes.
Why this matters for AI context
A connected article map is not only for readers. It is also useful for the AI assistant that helps maintain the system.
When the articles are linked clearly, the assistant can see which idea explains another idea, which note belongs to a beginner path, and which content supports a product page. That makes future editing, translation, and packaging easier.
This is the same principle behind a personal context OS. Context should not live only in a chat window. It should live in a structure you can inspect, correct, and publish.
A WordPress site can show that structure to readers. Obsidian can remain the place where it is built.
Join the Starter Kit waitlist if you want one notification when the kit is ready.