Cloudflare Redirects for Static Blog URL Migrations
I keep changing this blog. The Worker exists so readers do not have to care.
The site used month-based post URLs, then moved to year-and-slug URLs. Tag pages moved from /tag/ to /tags/. I also want one canonical domain instead of splitting links between www.kahwee.com and kahwee.com.
Every one of those changes leaves a trail of links in feeds, search results, bookmarks, and other posts. Static HTML cannot fix that trail on its own. A redirect has to catch the old request before the browser reaches a missing file.
That is the whole reason this blog has a Cloudflare Worker.
The Worker carries the old addresses
The Worker runs before Cloudflare serves the static files. It handles three cases:
- Redirect
www.kahwee.comtokahwee.com. - Redirect old
/YYYY/MM/slug/paths to/YYYY/slug/. - Redirect old
/tag/slug/paths to/tags/slug/.
Everything else goes straight to the generated asset bundle. The Worker also serves the blog's custom 404 page when no file exists.
The Worker renders no posts, queries no database, personalizes no pages, and exposes no dashboard. It is a compatibility layer for decisions I have already made. The tag redirect pattern is the clearest example.
Static lets the runtime stay boring
Bunki turns the Markdown and templates into a dist/ directory before deployment. Cloudflare serves that directory as static assets. Most requests never need application logic.
That is the stack I want for a blog. Publishing a post should generate a page, upload files, and finish. Why I built a static blog covers the original decision. The Worker preserves the consequence of changing my mind later.
The hosting move from Pages to Workers kept that contract intact. The generator still produces the same files. Wrangler still deploys the same directory. The migration note records that change because it was deliberately boring.
Images get their own path
Post images and video live in the kahwee-com R2 bucket behind img.kahwee.com. They publish separately from the HTML bundle.
That split has one benefit I care about: article pages can change without tying every image URL to the deployment that happened to publish them. Image assets keep a stable home. The Worker keeps the page paths stable. Bunki keeps generating the pages.
None of this makes the blog more exciting. It gives me permission to change the site without breaking the work already published on it. That is enough.