Leaving Squarespace, Part 4: The Podcast Feed

Part 4 of 6.

What worried me the most about the whole migration

Moving a blog is forgiving. If a post lands at a slightly different URL, you add a redirect and life goes on. A podcast is not forgiving, because a podcast isn’t really a website. It’s one XML file.

That file, the RSS feed, is the podcast. Apple, Spotify, Overcast, Pocket Casts: none of them host your show. They read your feed on a schedule and mirror whatever it says. Every subscriber you have is, at some level, a pointer to that one URL.

Squarespace generated mine. Which meant the single most important artifact of The SE Journey was a file I didn’t write, couldn’t see, and would lose the moment I cancelled.

And this show isn’t finished. It’s on hold. That distinction matters to me.

There are thirteen episodes with Chris sitting in that feed, a real body of work, and “on hold” only stays true for as long as the archive stays intact and reachable. If the feed had broken, or if the episodes had come back looking like something brand new, that wouldn’t have been a technical inconvenience. It would have been a loss. You don’t get to pick a podcast back up later if the thing you’d be picking up got scrambled on the way out the door.

Writing the feed myself

A podcast feed sounds intimidating until you look at one. It’s a channel block (title, description, artwork, category) and then one <item> per episode with a title, a publish date, and an <enclosure> pointing at an MP3.

So I built it. The feed is now generated at build time from a single TypeScript file that holds all thirteen episodes: season and episode numbers, publish dates, durations, blurbs, file sizes. That same file renders the episode page on the site.

That’s the part I’d do again in a heartbeat. One source of truth, two outputs. Add an episode and the page and the feed update together, because they’re the same data. There’s no way for them to disagree, which is a category of bug I simply don’t have anymore.

The tiny invisible ID

Here’s the thing that could have quietly ruined it.

Every <item> in a feed carries a <guid>, a globally unique identifier. It’s invisible. No listener has ever seen one. But it’s how every podcast app on earth answers the question “is this a new episode, or one I already have?”

Apps don’t match on title. They don’t match on URL. They match on GUID.

Which means if I’d generated fresh, clean IDs for my thirteen episodes, which is the obvious thing to do when you’re building a new feed, every app would have concluded that thirteen brand-new episodes had just dropped. Every subscriber gets thirteen notifications for a show that had been quiet for a year and a half. Or worse, the apps keep the old entries too and the archive doubles.

Squarespace’s GUIDs were ugly strings like 5f15f0ae…:60b9b31b…:6755d75f…. Meaningless, and I copied every one of them verbatim into my own feed before touching anything else.

And you only get one shot. Those IDs existed in exactly one place: the feed Squarespace was generating. Cancel first and they’re gone, with no way to recover them and no way to make your new feed look like a continuation. If you take one practical thing from this series, take this: before you cancel anything, save a copy of your current feed.

I didn’t know any of this going in. I’d rather say that plainly, because the version of this story where I calmly planned for GUID preservation from day one is not what happened. I learned it during the move.

That’s the part I keep coming back to. I could have handed this whole migration off and never seen a <guid> in my life. Instead I stayed close enough to the work to follow the steps, which meant I understood the risk while there was still time to do something about it. Staying involved, rather than being completely removed from it, is what made the difference here. Same as it was when I caught the posts that nearly got left behind.

The unglamorous details that actually matter

A few things I’d have gotten wrong on instinct:

• Byte lengths are not decorative. Each <enclosure> declares the file’s exact size. Apple validates it, and some players use it for scrubbing. Every one of the thirteen had to be measured, not estimated.
• The audio has to move too. 1.39 GB of MP3s were still sitting on Squarespace’s CDN. They went to R2, where egress is free, and the feed now points at media.thebetasociety.com.
• Keep your tracking prefix. The episodes were wrapped in a Chartable prefix for stats. Drop it and your historical numbers detach from your new ones. It costs nothing to carry it across, and you can’t reconstruct it later.

Changing the address without losing the room

The final move is telling the directories where the feed lives now. Apple Podcasts Connect took the new URL and picked it up without drama. Spotify is the last one standing as I write this.

The rule that made it safe is simple, and it’s the whole lesson of this part:

Change the URL. Never change the GUIDs.

Do that and the directories treat it as the same show that simply moved house. Subscribers don’t get notified. Nothing re-downloads. Play history survives. The move is invisible, which is exactly what you want. The best possible outcome here is that nobody notices anything happened at all.

What owning it actually changes

Here’s the part I didn’t expect to be thinking about at the end of a migration.

Owning the feed changes the math. When a podcast costs money every month, every decision about it is really a decision about whether it’s still worth the line item. Now it costs me effort and nothing else. That makes it far easier to think about expanding, or building on what’s already there, instead of just deciding whether to keep paying for it.

Not a Bot is the proof. It has a home now, on this same stack, with its own page and its own pipeline. The SE Journey has one too. Whether that means new episodes someday, I honestly don’t know yet. But it’s a question I get to actually sit with now, instead of one that answers itself every renewal.

Next up, Part 5: domains and DNS. Moving three domains to a new registrar, keeping email alive through the switch, and the redirects that keep a decade of old links working.