Publishing Obsidian Notes to a Public Site (Overview)

This is a high-level pattern for publishing a subset of an Obsidian vault as a public website. The exact export script can be custom, but the overall workflow is repeatable.

The Workflow

flowchart TD
  A["Obsidian vault (Markdown)"] --> B["Select notes to publish"]
  B --> C["Export/transform (links, assets, frontmatter)"]
  C --> D["Static site repo (Hugo/other)"]
  D --> E["Git push"]
  E --> F["Static hosting (Cloudflare Pages / Netlify / Vercel)"]

Core Idea

  • Keep everything in one private vault.
  • Mark only some notes as publishable (for example, via a tag).
  • Export those notes into a separate “public site” repo in a deterministic way (so diffs are clean).
  • Let the host rebuild and deploy automatically on every push.

What The Export Step Typically Does

  • Converts Obsidian-style links (wikilinks) into standard Markdown links.
  • Copies referenced images/attachments into the site and rewrites paths.
  • Normalizes frontmatter (title, tags, dates).
  • Optionally removes internal-only blocks.

Benefits

  • One writing workspace (Obsidian), many outputs (private vault + public site).
  • A clear boundary between private and public content.
  • Easy automation: one command or a cron job can publish updates.

Practical Notes

  • Prefer an allow-list approach (only publish what’s explicitly marked).
  • Treat “publishing” as a build step: idempotent output, minimal diffs.
  • Keep secrets out of notes; assume anything tagged publish may become public.

Example Toolchain (One Real Setup)

This is one concrete way to implement the export/transform/deploy step without exposing any private content:

Example “one command publish” wrapper:

dev    # wrapper script
# -> make deploy
# -> export notes tagged 'publish' into the Hugo repo
# -> build the site
# -> git commit + git push (triggering the host deploy)