For years I ran all my sites on WordPress. I recently moved two of them, including this site, to plain static HTML. An AI assistant maintains the files on its own computer and deploys them to Netlify. I haven’t logged in to an admin panel since.
That setup turned out to be a practical take on the headless CMS idea. Here is what it looks like day to day, what got better, and where it falls short.
What “headless CMS” means here
A traditional CMS like WordPress bundles everything together: the content, the database, the theme that renders it, and the admin panel you edit it in. A headless CMS splits those apart. Content lives in one place, the presentation layer lives in another, and the two are connected through an API.
My version goes one step further. The content and the presentation are just HTML files on disk. There is no CMS application at all. The “head” I edit through is an AI assistant. I describe a change in a message, it edits the files, shows me a preview, and publishes when I say so.
In other words, the admin panel has been replaced by a conversation.
How the pieces fit
Content and layout
hand-written HTML and CSS, one folder per page, with clean URLs.
Editor
a Grok Bot with its own persistent cloud computer, where the working copy of the site lives.
Hosting
Netlify, which serves the files from a CDN and runs a couple of small functions.
Source of truth
the assistant’s copy plus the live deploy. If I want the files, I download them.
I wrote about the build itself in how to build a static website, and about the assistant in What Is Grok Bot? This post is about what it’s like to live with.
Leaving WordPress behind
Each migration started the same way. The assistant pulled the content out of WordPress, through the REST API on one site and a full mirror on the other. Then it rebuilt each page as static HTML, moved images into a local images folder, and stripped out the WordPress runtime.
The step I cared about most was keeping my URLs. Posts stayed at their original paths. Where something had to move, a redirect went into a single _redirects file. On the consulting site that meant carrying over about 70 redirect rules from the old host, checking each one, and fixing the ones that pointed at pages that no longer existed. On my blog, one old post URL threw a 404 after launch, and the fix was a one-line redirect. My earlier post on post URL structure explains why that matters so much.
Before shutting down the old WordPress install, I had the assistant archive everything: 25 posts, the pages, and the media library, all stored separately from the live site. That old install kept triggering plugin vulnerability alerts from the host. Now I can delete it without losing anything.
Easy management through plain-English requests
Here are some real requests from the past few weeks:
“Remove the call-to-action buttons from the homepage. I’m going to rethink my CTAs.”
“Replace this post’s featured image with something that keeps the text but matches the site’s colors.”
“Bring this post over from the old site.”
“Run a proofreading pass on this post and apply only the high-priority fixes.”
Each one took a single message. There was no hunting through theme settings, no page builder fighting me over spacing, and no plugin to install for a one-off task. The new featured image, for example, was drawn in code using the exact brand colors and heading font.
Preview before publish
Every change follows the same rule.
Request
I describe a change in a message.
Draft preview
The assistant deploys a draft to a unique preview URL and sends me the link.
Revise
If I don’t like what I see, I say so, and it revises the draft.
Publish
Nothing goes to production until I reply “publish.”
Backups and rollback
Before any meaningful change, the assistant copies the site to a dated backup folder with a name that describes the change, like “pre-analytics” or “pre-trim.” The consulting site has well over a dozen of them now. Netlify also keeps every past deploy, so rolling back is one step on either side.
Global changes in one pass
This is where static plus AI really beats a theme-based CMS. When every page is a file, a site-wide change is just a script that runs over all of them, and the assistant writes that script for you.
Fonts
I switched my blog to Inter for body text and Ubuntu for headings across every page in one pass.
Footers
an outdated copyright line came off every page at once.
Examples
old demo domains in code samples were swapped for example.com everywhere.
Titles and meta
a title and description audit ran across every page and the fixes went in together.
Pruning
on the consulting site, outdated posts were unpublished, redirected, and stripped out of internal links and listings in a single change.
On WordPress, each of these would have meant a plugin, a theme edit, a database search-and-replace, or an afternoon of clicking.
| WordPress | Static HTML + AI | |
|---|---|---|
| Editing | Admin panel, theme settings, page builder | A plain-English request, then a preview link |
| Site-wide changes | A plugin, a theme edit, or a database search-and-replace | One script that runs over every file |
| Security | Login page, database, plugins that need patching | No login page, no database, no plugins |
| Running costs | Managed hosting, premium plugins, page builder license | Inexpensive static hosting, often a free tier |
| Your content | Stored in a database | Plain files you can download |
| Visual editor | Drag blocks and see them update live | None. You describe the change and review a preview |
Fast performance, by default
A static page has no PHP to run, no database queries, and no plugin scripts piling up in the page. The host just sends a file from the nearest edge server.
After the migration, the consulting site’s Lighthouse performance scores were already in the 90s. A focused performance pass pushed them higher. These are before-and-after Lighthouse reports I had the assistant save:
Lighthouse performance score, before → after
Most of that came from compressing images and removing leftovers that WordPress had loaded on every page. If you’re curious why WordPress pages get heavy in the first place, see WordPress page experience.
Security and cost
No plugins, no database, no alerts
The attack surface of a static site is tiny. There is no login page to brute-force, no database to inject into, and no plugins waiting for their next security patch. The steady stream of vulnerability emails stopped the day the sites moved.
Lower running costs
Static hosting is inexpensive, and a small site often fits within a host’s free tier. I’m not paying for managed WordPress hosting, premium plugins, or a page builder license. The assistant’s subscription replaces most of the hours I used to spend maintaining the stack.
Full SEO control
With every byte of the page under your control, SEO stops being a negotiation with a theme and a plugin.
- Titles and meta descriptions are written for each page and checked for length and duplicates.
- Structured data is hand-placed JSON-LD: BlogPosting, breadcrumbs, FAQ, and WebSite markup on the homepage. More on that in my structured data guide.
- Redirects live in one readable file.
- The sitemap is updated whenever a page is added, like this one.
- Image SEO: the assistant audited images for missing alt text and fixed them.
Internal linking works the same way. When a new post goes up, I can ask the assistant to scan the whole site, find passages in older posts where a link to the new post fits naturally, and add the links in one pass. Like every other change, it goes to a preview first.
“Add two contextually relevant internal links from other posts to this post.”
Privacy-friendly analytics
I wanted to see traffic without a cookie banner. The assistant built a small visitor tracker that runs on a Netlify function. It sets no cookies, stores no IP addresses, and reports to a password-protected stats page on the site. It runs alongside Ahrefs Web Analytics, and a short privacy page explains both.
The same tracker went onto both sites in an afternoon, because once it existed for one site, copying it was just another request.
Honest tradeoffs
This approach isn’t for everyone.
No visual editor
You can’t drag a block around and see it update live. You describe what you want and review a preview.
You rely on the assistant
It does good work, but it can misread a request or miss something. Once it told me a phrase was gone when a few copies were left. The preview step and backups exist for exactly that reason.
Approval is part of the job
Publishing waits for you. That’s a feature, but it means you stay in the loop.
Not a fit for every site
Stores, membership sites, and anything with many authors or heavy logged-in features still belong on a full platform. Brochure sites, consulting sites, and blogs are the sweet spot.
You own your content
One tradeoff runs in your favor. Everything is plain files. There’s no proprietary format and no database export to wrestle with. If I stop using the assistant tomorrow, any developer, or any text editor, can pick up the site where it left off.
Frequently asked questions
Is this really a headless CMS?
Not in the product sense. There’s no content API or separate CMS app. But the idea is the same: content is decoupled from the presentation layer, and an AI assistant takes the place of the admin panel as the editing interface.
Do I need to know HTML to run a site this way?
No. I make requests in plain English and review a preview link. Knowing a little HTML helps when you want to check the assistant’s work, but it isn’t required.
What happens to my old WordPress URLs?
You keep them. Pages can live at the same paths, and anything that moves gets a 301 redirect in a single redirects file, so links and rankings carry over.
Can I still add forms, analytics and other features?
Yes. A static host can run small serverless functions, which is how I added a cookie-free visitor counter with a password-protected stats page. Anything that needs heavy logged-in features is a sign the site may not be a good fit.
What if I stop using the AI assistant?
The site is plain HTML files. You can download them from the host, open them in any editor, or hand them to a developer. Nothing is locked inside a database or a proprietary builder.
The bottom line
Static HTML used to mean giving up easy editing in exchange for speed and security. An AI assistant removes that tradeoff for many small business sites. You get a fast, secure, cheap site that you fully own, plus an editor that takes requests in plain English.
If your WordPress site is mostly pages and posts, and the vulnerability alerts are wearing you down, it’s worth a look.