I set up a blog AI publishes to. Here's what actually broke.

By Daniel S. · June 23, 2026

The goal was simple: I write a post once, and getting it live takes one action — no copying files around, no dashboard, no manual upload. An AI assistant writes the markdown; a single push publishes it.

It works now. But getting there broke in three places, and the breaks are the useful part — because they're the ones nobody mentions when they tell you to "just use a static site." Here's the real version: the shape that works, what went wrong, and the exact fix for each.

The shape that works

The whole site is plain files. Markdown posts live in a folder, a static-site generator turns them into HTML, and the host rebuilds automatically whenever the files change. Concretely: markdown in a Git repo → a build runs on push → the host serves it. Pushing to the repo is publishing.

Why this shape and not a CMS dashboard? Two reasons that hold up:

• Any AI can drive it. Every coding-capable assistant can read and write markdown and commit to Git. A proprietary CMS locks you to whatever one vendor's connector exposes. Files in a repo are the most universal interface there is.
• You get a review step for free. The AI proposes a change; you see the diff before it ships. Publishing straight to a live database has no natural pause for "wait, check that." Git gives you the pause without effort.

The cost is real but small: you write in markdown instead of a visual editor, and you wire up things like analytics yourself. If you already work in markdown, that's not a cost at all.

What broke #1: the hidden file that vanished on upload

The first attempts published through the host's web uploader — drag the folder onto the page, commit. It kept producing a half-broken site: pages with no styling, and build logs full of errors like "layout does not exist" and "filter not found."

The cause took a while to see. The build's config file was a dotfile — a name starting with a . — and the Mac Finder hides those by default. So when I dragged the folder to upload, the config silently didn't come along. The build then ran with no config, and every setting that depended on it collapsed in a cascade.

The fix, two parts:

1. Renamed the config to a visible file so it can't get hidden again. (If you're on Eleventy, that means using eleventy.config.js rather than the hidden .eleventy.js.)
2. Stopped uploading by hand entirely. Drag-upload drops files quietly — a hidden config here, the contents of a subfolder there — and never tells you. Git doesn't. It tracks every file exactly, dotfiles included, and pushes them as one atomic set. This is the single biggest reliability win: the upload step stopped being a place where things go missing.

If you want the genuinely one-command version, a tool with built-in Git — like Claude Code — can write the post and push it in the same step. A desktop Git app does the same job in two clicks. Either way, the lesson is: don't hand-pick files for upload. Let version control move the whole set.

What broke #2: the site that looked broken but wasn't

After fixing the upload, the live site still looked unstyled in my browser. Easy to assume the deploy was still broken.

It wasn't. Checking what the server actually sent — the raw HTML and the stylesheet — showed both were correct and current. The stylesheet was being delivered fine. The problem was entirely on my end: my browser had cached the earlier, broken version, and stylesheets are told to cache for hours. So I was looking at an old copy while the real site was already fixed.

The fix: verify against the server, not your eyeballs. A hard reload (Cmd+Shift+R) or a private/incognito window bypasses the cache and shows you what's really live. The moment I opened the site in a private window, it was perfect. Hours of "it's still broken" would have been one private-window check.

The general lesson is bigger than blogs: when something looks wrong after a deploy, confirm what the server is sending before you start fixing the deploy. Half the time the deploy is already fine and you're chasing a ghost.

What broke #3: the apex worked, "www" didn't

The bare domain loaded perfectly. The www. version threw an SSL error and showed nothing. If you'd typed "www" out of habit — or had it bookmarked that way — you'd have concluded the whole site was down.

The cause: only the bare domain had been added as a custom domain on the host, so only it got a certificate. The www hostname had no cert, so the secure connection failed before any page could load.

The fix: add www as a second custom domain in the host's dashboard so it issues a certificate for it too, then point one at the other so you don't split your traffic and search signals across two addresses. Most hosts add the DNS record for you. One setting, but invisible until someone hits the wrong hostname.

The honest catches

• Don't let the AI publish straight to live. The value of this setup is the review step. Keep it: AI writes the post, you read the diff, you push. The discipline matters more once the AI can publish on its own.
• You own the parts a dashboard would hide. Custom domains, redirects, analytics, anything you monetize with — you wire those yourself. It's not hard, but it's on you, and the failures (like the www cert) are quiet until someone trips on them.
• Your browser will lie to you. Cache makes a fixed site look broken and, worse, can make a broken change look fine. Verify against the server.
• It's markdown, not a visual editor. If you don't already write in markdown, that's a real adjustment — be honest with yourself about whether you'll stick with it.

The payoff

With all three fixed, publishing collapsed to what I wanted at the start: the post gets written, I review the change, one push sends it, and the site rebuilds itself a minute later. No uploads to babysit, no files to drop, no dashboard to log into.

If you're setting up the same thing: use Git from the first day instead of any web uploader, keep your config files visible, check the live site in a private window before you trust it, and add www as its own domain. Those four moves skip every break above.