You have a Notion workspace full of writing. Some of it is genuinely good. And at some point you thought: what if I just… published this?

It makes sense. You’re already writing there. The pages look nice. There’s even an export button. How hard could it be?

Harder than you’d expect. And not for the reasons you’d guess.

#The Export That Loses Everything

Notion’s export-to-markdown feature sounds perfect on paper. In practice, it’s a lossy translation between two incompatible formats.

Notion stores content in a proprietary block format. Markdown is a lightweight syntax designed in 2004. When you export, Notion has to flatten its rich structure into something Markdown can represent. A lot gets lost in the process.

Callout blocks become raw HTML. Databases export as CSV files that lose every view, filter, and relation you set up. Colors, synced blocks, and embeds are silently dropped.

Images are the worst part. Notion serves images through presigned URLs that expire after one hour. Your exported markdown references files in a separate folder, but the paths are often broken. Nested pages generate filenames so long they can exceed Windows’ 260-character path limit and silently fail to extract.

This isn’t a bug. It’s a structural mismatch. Notion’s internal format is richer than Markdown. The export will always be lossy because the source is more complex than the target.

#The Third-Party Bridge

The export problems spawned an entire ecosystem of tools. Super, Potion, Notion2Blog, Feather — services that read your Notion workspace through the API and render it as a website.

Some of them are pretty good. But they all share the same fundamental architecture: your content lives in Notion, and a separate service translates it on the fly.

This means your blog depends on two services staying alive and compatible. Notion changes their API — and they do, regularly — and your publishing pipeline breaks until the bridge service catches up.

It also means your content is still locked in Notion’s format. You’re not publishing Markdown. You’re publishing Notion blocks that get translated at render time. If you ever want to leave, you’re back to the export problem.

#Notion Sites: Close But Not Quite

Notion launched their own publishing feature — Notion Sites — which lets you publish pages directly to the web.

It’s the cleanest option if you’re committed to Notion. No third-party dependency. No export step. But there are real limitations.

You get a yourname.notion.site domain by default. Custom domains are available, but only on paid plans — and then only as a separate add-on that runs $8–10/month per domain, on top of your subscription. The design options are constrained to what Notion pages look like. Your blog looks like… Notion. Which is fine if you like Notion’s aesthetic, but there’s no way to make it look like yours.

Performance is another concern. Notion pages are JavaScript-heavy applications. They’re not slow, exactly, but they’re not the snappy static HTML that search engines and readers prefer.

And the deeper issue remains: your content is still Notion’s format. Not portable files on your computer. Not Markdown you can open in any editor. Notion blocks, in Notion’s database, behind Notion’s login.

#The Real Problem

The real problem isn’t that Notion is bad. It’s that Notion is a thinking tool being asked to be a publishing tool. Those are different jobs.

A thinking tool should be flexible, interconnected, and private. Notion is all of those things. It’s genuinely excellent for organizing ideas, collaborating on documents, and building internal knowledge bases.

A publishing tool should produce portable output, load fast for readers, give you control over presentation, and not create dependencies on a single vendor.

No tool does both jobs well. The features that make Notion great for thinking — proprietary blocks, real-time collaboration, database views — are exactly what make it awkward for publishing.

#What If You Just Wrote in Markdown?

Here’s the thing about Markdown: it’s boring. There’s no proprietary format. No API. No blocks. Just text files with some punctuation.

But that boringness is the entire point.

A Markdown file written today will be readable in fifty years. You can open it in any text editor on any operating system. You can move it between apps — Obsidian, iA Writer, VS Code, Bear, a plain text editor — without losing anything. There’s no export step because there’s nothing to export from.

If you write in Markdown, publishing becomes a file operation. Not an API call. Not an export. Not a translation. You already have the output format. You just need somewhere to put it.

#A Different Architecture

With FolderPress, I took this literally. You put Markdown files in a Dropbox folder. That’s the whole publishing step.

No export pipeline. No third-party bridge. No API dependency. You write a .md file, save it to a folder, and it’s on the internet. The file you write in is the file that gets published.

Want to draft something? Name it post.draft.md. Want to publish? Rename it to post.md. Want to unpublish? Add .draft back. The file system is the interface.

This isn’t for everyone. If you love Notion’s databases and want your blog tightly integrated with your project management, a Notion-to-blog bridge might be the right tradeoff. There are real reasons to keep everything in one tool.

But if what you actually want is to get your writing onto the internet — reliably, in a format you control, without fighting an export pipeline — the answer might be to skip the translation layer entirely.

Write in Markdown. Publish the file.

#When Notion Makes Sense (And When It Doesn’t)

Use Notion for what it’s good at: team wikis, project tracking, databases, internal docs. It’s a phenomenal workspace.

But if your goal is a personal blog — something you want to own, control, and keep running for years — building on a proprietary format adds fragility for no real benefit.

The best publishing workflow is the one with the fewest steps between your finished thought and a URL. Every translation layer, every export step, every third-party bridge is a place where things can break, formats can drift, and motivation can die.

The simplest path from writing to published is a file that’s already in the right format, in a folder that’s already connected to the internet.

That’s not a pitch. It’s just fewer moving parts.