Automating Blog Publishing Between Notion and Squarespace

Before we talk about my current publishing process, let's discuss how I got here. I started out writing in Notion and hosting on Squarespace—a quick way to get a more professional blog up and running. But the friction of moving content between the two became too much. So I made a trade: I swapped the professional polish and published directly on Notion instead. It was simpler, but came with its own limitations. Now I've come full circle, back to writing in Notion and publishing on Squarespace. The difference? This time I've built a better, less manual process to bridge the gap.

Why I swapped from Squarespace to Notion originally.

Friction. Squarespace's main strength is its drag-and-drop block editor. It's quite similar to editing Notion pages, which you'd think would make the migration smooth. But it's not really the case when you're actually moving a blog post over. Blocks are great for managing different sections of a normal website page, but they're a pain when you need a bunch of different ones in a single post.

Here were the problems:

• Multiple block types. I copy the text from my Notion page over to the Squarespace editor. My posts typically need multiple block types, generally a mix of text and image, occasionally code blocks etc. So I have to manually add these different block types and manually reupload images hosted on Notion to Squarespace.
• Notion's page mentions. When I reference other pages in Notion using @mentions, they become clickable links to those internal Notion pages. Copy that text into Squarespace and those links come along for the ride—except now they're pointing to private Notion.so URLs that my blog readers can't access. So I have to go through and manually strip out those links, turning them back into plain text. It's not a huge task, but it's another small friction point that adds up when you're publishing regularly. Or in my case, trying to form the habit of publishing regularly.

Why I didn't just write directly into Squarespace?

My entire knowledge management system lives in Notion. I've built my workflow around Tiago Forte's CODE framework, he outlined in Building a Second Brain —Capture, Organise, Distill, Express. Articles, videos, and podcasts get captured into my Library database. I organise them with tags and metadata. Then I distill the most valuable insights into individual notes in my notes database that I can reference and connect across projects. All of that happens in Notion. Writing directly in Squarespace would mean isolating the final step—Expression—from everything that feeds it. I'd lose the ability to easily reference my library of resources, pull in relevant notes, and creating those links to related research while I'm writing.

Beyond just having my resources at hand, there's the friction factor. Switching to Squarespace to write would mean context switching between tools right when I'm trying to write. In Notion, I can seamlessly move from researching a topic in my Library to drafting a post to connecting it with other content I'm working on—all without leaving the workspace. The whole point of CODE is reducing friction at every stage so you actually get to the Express part. If I had to jump to a separate tool every time I wanted to write, I'd be adding back the exact friction I was trying to eliminate by leaving Squarespace in the first place.

Not Designed for Writing

To be clear, neither Squarespace nor Notion are particularly great writing tools. Dedicated writing apps like Ulysses, iA Writer, or even Google Docs offer features that Notion simply doesn't have—distraction-free modes, sophisticated typography controls, grammar tools, a better focus on the actual prose rather than the structure. A block based editor can feel a little more clunky for long-form writing. But those missing features are a reasonable trade-off for having my entire workflow in one place. The ability to reference my Library, link to my Notes, and transition from research to writing without switching contexts is more valuable to me than a cleaner writing experience. I'd rather deal with that than lose the connective tissue that makes the whole CODE process work.

One thing that helps offset Notion's limitations as a writing tool is using an AI agent for editing passes. I can ask it to tighten up prose, check for clarity, or suggest better phrasing without leaving my workspace. It works very effectively and but it handles a lot of the mechanical work. That said, I do miss having built-in grammar checking like you'd get in Google Docs or leveraging a tool like Grammarly. Notion doesn't flag typos, misplaced commas, or awkward phrasing as you type. The AI agent can help with a final pass, but there's something valuable about catching those issues in real-time while you're still in the flow of writing. It's another trade-off I've accepted, but it's one I notice every time I publish.

Publishing in Notion

Research and Writing in a Nutshell

My writing and research process is built around Tiago Forte's CODE framework, in Building a Second Brain —Capture, Organise, Distill, Express—and it all lives in Notion. When I come across valuable resources, I capture them quickly into my Library database using tools like Save to Notion for web articles, Readwise for Kindle highlights, and Readwise Reader for YouTube transcripts and newsletters. The key is keeping capture frictionless while staying selective about what I save, orienting around action and keeping an eye toward the work I'm actually doing. Once captured, I organise resources with metadata like tags and author relations, but I separate this step from capture to stay present with whatever I'm working on. When I actually consume the content, I distill the most valuable insights into individual notes in my Notes database—converting specific excerpts into standalone pages that I can connect across projects. I use Notion buttons and automations to relate these notes back to their source and automatically inherit properties like author and tags. These distilled notes then surface contextually across my workspace—on project pages, under relevant tags, or linked directly to content I'm drafting—which brings us to Expression. Instead of starting research when it's time to write, all that groundwork is already done. I can reference my Library, pull in relevant Notes, and make connections between ideas without leaving Notion. The whole system is designed to reduce friction at every stage so I can move seamlessly from research to writing.

Publishing Process

When I was publishing directly on Notion, my setup included two separate databases: my Content database where I worked and a Blog database where I'd actually publish finished posts via Notion sites. This separation made sense in theory—keep the messy, work-in-progress stuff separate, as well as different database properties etc. that are more private or just not useful for readers. But in practice, it created a problem with how I was using synced blocks.

Synced blocks are incredibly powerful for maintaining a single source of truth. When I distill insights from my Library into individual notes, those notes live in my Notes database. I can reference those notes across multiple pieces of content by inserting them as synced blocks. The beauty of this approach is that if I need to update a quote, add context, or correct something, I make the edit once in the original note and it updates everywhere that synced block appears. It's exactly the kind of connected thinking that makes a PKM system valuable.

Here's where the problem emerged. When I'd draft a post in my Content database, I'd pull in relevant notes as synced blocks. Perfect. But when it came time to publish, I needed to move that content to my Blog database where it would be publicly accessible through Notion Sites. However, my notes database with the original synced blocks is a private database. My options were:

Publish the notes, making individual notes pages public. This was very cumbersome. I could in theory publish my whole notes database but this was definitely not an option for me.

The only other viable alternative was to unsync the blocks, converting them to regular text and losing the connection entirely. This solved the privacy issue but defeated the entire purpose of using synced blocks in the first place. I'd lose the ability to maintain that single source of truth. For example, when Notion released tabbed page content—a feature I'd been hoping for and mentioned so in a couple of different posts—I only had to update the original synced block once. That single edit propagated across every post where I'd mentioned wanting that feature. If I'd unsynced those blocks, I'd need to hunt down each instance manually and update them individually. Neither option was ideal. The first impeded my research system. The second made maintaining published content more of a challenge. I needed to find a way to maintain the connection between my notes and my published content without exposing my private workspace to the world.

That brings me to my other issue with Notion as a publishing platform. It has very basic website/SEO functionality. When I switched from Squarespace to Notion sites I did notice my views took a hit. In truth, my metrics and SEO optimization has never been a big focus for me, and I'm sure there's lots more I could have done in Notion sites to improve performance. Squarespace has a suite of built-in SEO and analytic tools that give you much better control and data on your site performance.

Migrating Back to Squarespace

For the above reasons, I decided to give Squarespace another shot. This time I wanted to put in place a more automated process to bridge the gap between Notion and Squarespace without the manual friction that drove me away in the first place.

The core issue was getting content out of Notion in a format that Squarespace could easily consume. I needed to solve three specific problems:

1. Converting page mentions to external links

When I reference other pages in Notion using @mentions, they're stored as internal Notion URLs. Copy that into Squarespace and readers get links to private pages they can't access. I needed a way to automatically convert these mentions to proper external URLs. For pages that represent tools or resources, I track a URL property that stores a public web address or affiliate link to whatever tool, resource I'm referring to. This is where I hand it over to Notion 3.0's agent functions. The agent creates a new page and transcribes all the text I have in my completed blog post, only swapping page mentions for hyperlinks using the URL in the URL property of the mentioned page.

2. Hosting images externally

Notion hosts images on its own CDN, but those URLs change frequently so aren't reliable for image hosting. I needed to rehost images somewhere permanent. I use Cloudinary for this. The automation detects any image blocks in the exported content, uploads each image to Cloudinary via their API, and replaces the Notion image URL with the permanent Cloudinary URL. Cloudinary appears to have a generous free tier and provides stable URLs that won't break if I move content around in Notion. I say appears because the pricing structure is a little convoluted. It's a credit based system, that would equate to 25gb of storage but bandwidth, transformations, etc.

From Cloudinary's FAQs; 1 Credit equals 1000 transformations or 1GB of managed storage or 1GB of viewing bandwidth or 500 SD video seconds or 250 HD video processing seconds.

Their paid plans are expensive, it's a powerful tool, that does a lot more than image hosting and API calls. Their target market is probably enterprise clients. However, from some limited testing, I think the free tier will be enough for my needs here, but I'll continue to test it over the coming weeks before fully migrating over.

The simple version of my automation checks for images, on the page where I drafted the post, uploads these to Cloudinary then adds these to image blocks and appends them to the new page (with the updated links). This then gets passed back over to my agent, who places the images in the correct place in the content. That just leaves me with one copy/paste straight into a markdown block in Squarespace. The automation needs to be tidied up a little, but once that's done I'll include a link to it here.

I'm back on Squarespace, but this time without the friction that drove me away. My research and writing stay in Notion where they belong—connected to my Library, my Notes, and the rest of my CODE workflow. The automation handles the tedious parts of getting my Notion content into Squarespace and with publicly accessible images and links.

It's not a perfect system yet. I no longer have one source of truth for my blog post. There's a draft post, built using my note system with page mentions etc. There's a related page with the final draft (updated links and cloudinary images) ready to be copied into Squarespace and then there's the Squarespace page itself. So when it comes to updating existing posts, I'll need to make a call as to whether it's important to retroactively update the Notion pages as well. I don't update posts very regularly, and if I do they tend to be small changes so this was an acceptable compromise for me.

The automation also still needs some refinement and I'm monitoring Cloudinary's free tier to make sure it actually covers my needs. But the core problem is solved. I'm no longer choosing between a connected writing system and a proper publishing platform. I've found a way to have both.

If you're wrestling with similar friction between your writing tools and your publishing platform, the lesson here isn't "use my exact setup." It's that automation can often bridge gaps that feel like binary choices. The time invested in building that bridge pays back every time you publish.

More from the Blog

See the knowledge management template mentioned in this post here.