Create a Blog With AI in One Afternoon: Claude Builds It, You Own the Domain, and the Second Post Isn't the Hard Part
Michael Sacca•Every "create a blog with AI" article on the internet follows the same script: open ChatGPT, ask for a blog post about your niche, copy it somewhere, congratulations. It treats the blog as a writing exercise. It never mentions hosting, never mentions the domain, and never asks the only question that matters three weeks later — can you do this again next Tuesday without rebuilding everything?
If you want to publish, not tinker, the blog is infrastructure. It needs three things: a site that exists at a URL you own, a way to put new writing into it without dread, and a maintenance burden you can actually carry. Here's how to get all three in one afternoon, with Claude doing the scaffolding and you making the decisions.
The afternoon, hour by hour
Hour 1: Have Claude scaffold the blog, not a "blog page"
The mistake is asking Claude for "a blog website" and getting a single HTML file with three hardcoded articles. That's a brochure with a blog costume on. What you want is a static site built around a content model: a folder of markdown files where each post is one file, a template that wraps every file in your layout, and a build step that turns the folder into pages.
Ask Claude for exactly that:
Build me a static blog using [Eleventy/Astro/Hugo — pick one].
Requirements:
- Posts are markdown files in a /posts folder with title, date, and slug in frontmatter
- A post template with a readable single-column layout
- An index page listing posts newest-first
- An RSS feed
- A README explaining the one command to build and the one command to serve locally
Do not hardcode any posts. Show me the folder structure first, then the files.
Which generator you pick matters less than the shape. Eleventy, Astro, and Hugo all do the same job — markdown in, pages out — and Claude knows all of them well enough to scaffold one correctly. If you have no opinion, tell Claude to pick for you and explain why in one sentence. The point is that adding a post later means adding a markdown file, not editing HTML.
This is also the moment to give Claude your brand constraints — fonts, colors, voice notes — so the blog doesn't come out looking like every other generated site. There's a whole discipline to that spec file, which I covered in Give Claude a Brand Kit, Not a Prompt: The Spec File That Keeps 30 AI-Generated Pages From Looking Like 30 Different Agencies. Same rule applies to a blog: write the constraints once, reference them forever.
Hour 2: Deploy it and point your domain
This blog has covered the deployment path in detail already, so I won't rehash it. Claude Built It, ChatGPT Coded It: The Three Paths From AI-Generated Code to a Live Domain maps the full path from generated code to a live site, and You Built It With ChatGPT. Here's How to Point Your Domain at It. walks the DNS side — export, deploy, point. For a static blog the short version is: push the folder to a Git repository, connect that repo to a static host, and the host rebuilds the site every time you add a post. Buy the domain at a registrar you've heard of, point it at the host per their docs, and you own the URL outright. Nobody can take it, reprice it, or fold it into a platform that gets shut down.
That last point is the actual answer to "AI domain hosting." There is no AI domain hosting. There's AI building the thing and ordinary hosting carrying it — and the ordinary hosting for a static blog is about the easiest hosting that exists, because there's no database, no PHP, and nothing to patch.
The shortcut: just do this on HTML Pub. Everything in Hour 2 — repos, build hooks, DNS records — is the manual route. HTML Pub exists because you shouldn't have to run your own deploy pipeline to own a static blog. You connect your domain, drop in markdown posts, and it handles the build and hosting for you. The reason this guide walks the generic path first is so you understand exactly what HTML Pub is doing underneath — but if the goal is a blog you own, publishing weekly, with no YAML to break, that's the one-step version of everything above.
Hour 3: Build the posting workflow so the second post isn't the hard part
Here's where generic guides genuinely fail. They help you publish post one and abandon you. The second post is where blogs die, because post one was an event and post two is a system you never built.
Fix it with three artifacts, all created in this same afternoon:
1. A post template file. A markdown file in your repo called _template.md with the frontmatter already filled in except for the parts that change:
---
title:
date:
slug:
excerpt:
---
## The problem
## What to do about it
## The honest caveat
Your future self copies this file, fills in four fields, and starts writing. The structure is already the structure.
2. A drafting prompt. If you draft with Claude, don't re-explain your blog every time. Keep a standing prompt that includes: who reads the blog, the voice rules, the standard sections, and the rule that Claude outputs a markdown file matching your frontmatter, ready to drop into /posts. Now "draft this week's post about X" is a two-minute interaction, and the output is already formatted for your build system — not a chatty essay you have to restructure by hand.
3. A publish checklist. Four lines, written once: add the markdown file, write a real title and excerpt, run the build locally and glance at it, commit and push. The host rebuilds. You're live. Total elapsed time for a post you've already drafted: minutes.
Do these three things and the weekly rhythm becomes: draft with the standing prompt, drop the file in, push. That's the difference between a blog and a blog-shaped artifact.
The honest tradeoffs: static AI blog vs. WordPress
You will find a hundred posts telling you WordPress is the answer and a hundred telling you it's dead. Here's the tradeoff as it actually lands for someone who wants to publish.
Where the static AI blog wins:
- Setup and ownership. One afternoon, your domain, your files in your repo. Nothing to renew beyond the domain and (on most static hosts) nothing to pay until traffic gives you a reason to.
- Zero maintenance. No core updates, no plugin updates, no database to back up, no security plugins to stack. A static blog's attack surface is roughly the size of the files sitting on it.
- Speed by default. Pre-built pages load fast with no tuning. If you eventually run paid traffic to posts, that baseline matters — the same class of performance problems I broke down in The Performance Budget for AI-Generated Landing Pages: What Claude's Code Costs You in Ad Load Time mostly doesn't exist here, because the build step strips what you didn't use.
- The workflow compounds. Markdown files in a repo scale linearly. Post 200 is exactly as easy to publish as post 2.
Where it costs you — and I mean costs, not inconveniences:
- No editor UI. Publishing means touching files. If "log into a dashboard and type into a box" is a requirement for you — because you hand off writing, or because you know you won't open a terminal — a hand-rolled static blog will fight you. This is exactly the objection HTML Pub is built to erase: it gives you the static site's speed and ownership and an editor to write in, so you don't have to choose between owning the files and having a place to type. There are other CMS frontends that sit on top of static sites, but configuring one yourself is exactly the tinkering you said you didn't want to do.
- Dynamic features are real work. Comments, members, a newsletter signup that stores anything, search across posts — every one of those is a third-party service to wire in or a feature to build. On WordPress, most are a plugin install. If your blog's plan depends on community features from day one, that's a WordPress-shaped requirement and you should listen to it.
- You're the deploy pipeline. On WordPress, hitting Publish is the whole job. On a static blog, the push triggers the rebuild, and when the build breaks — a malformed frontmatter field, a broken link in a template — you're the one who fixes it. Claude is good at fixing these, but "good at fixing" and "never happens" are different things.
The decision rule I'd use: if the blog is primarily you publishing writing under your own name, static wins almost every time, because the things it lacks are things you weren't going to use in year one anyway. If the blog is a multi-author publication, or membership and comments are the product, WordPress's overhead buys you something you'll actually use. And if you want the static path without running your own pipeline, that's literally what HTML Pub is for — same files, same ownership, none of the build-wrangling.
What you own at the end of the afternoon
A domain registered to you. A Git repository with every post you'll ever write in plain markdown, readable in any text editor for the next few decades. A host that rebuilds when you push. A template, a standing prompt, and a checklist that make the next post a routine instead of a project.
That's a real blog. The generic guides gave you a first post; this gives you the twentieth one a path. Start writing it.