Case Studies StaticForge: publishing WordPress as static files
StaticForge: publishing WordPress as static files
TL;DR StaticForge exports a WordPress site to static HTML, CSS, JS, and images, so you keep writing in wp-admin but serve a frozen, fast copy from a CDN. The public site has no PHP and no login, which cuts both load time and attack surface.
I like writing in WordPress. I do not like paying for a server that runs PHP just to hand the same HTML to every visitor. StaticForge is how I get both: keep the editor, serve a static copy. This is the story of why I built it and how it works.
The problem
A standard WordPress site renders each page with PHP and a database query on every request. For a content site where the page is the same for everyone, that is a lot of repeated work. It also means the public site carries a login screen, an admin, and a full software stack that all need patching and all present a target.
For a blog or a brochure site, none of that dynamic machinery earns its keep on the public side. The content changes when you publish, not when someone visits.
The approach
The plan is to separate authoring from serving.
- Author in WordPress. Keep wp-admin, the editor, and the workflow you already know.
- Serve static files. Export the rendered site to HTML, CSS, JS, and images, and host those on a CDN.
- Rebuild on change. When you publish, regenerate the static copy and redeploy.
The public site becomes a frozen snapshot: fast, cheap, and with almost nothing to attack.
What shipped
StaticForge crawls your live WordPress site and writes out the static files, ready to deploy to a CDN host. You still log into WordPress to write. When you are done, an export produces the fresh files and they go live. Visitors get plain HTML from the edge, with no PHP and no database in the request path.
The wins line up with the static model in general: better load times, lower hosting cost, and a much smaller attack surface. The cost is that dynamic features move to small services, which for most content sites is just the contact form.
What I learned building it
The tricky part is not the export, it is the edges. Absolute URLs hardcoded in a theme, a stray mixed-content reference, a dynamic widget that assumed PHP would always be there. A static export forces you to find those, which is uncomfortable at first and healthy in the end. It makes the site's real dependencies visible.
If you run a content-led WordPress site and want it fast and low-maintenance, the static route is worth a look. For the wider case, see why static sites keep winning. StaticForge is free on WordPress.org.
FAQ
Why serve WordPress as static files?
You keep the WordPress editor you like, but visitors hit prebuilt files on a CDN instead of PHP rendering a page per request. That means faster loads, cheaper hosting, and almost no attack surface, since there is no database or admin login on the public site.
What happens to dynamic features like forms and search?
They move to a service. Forms post to an external endpoint or a serverless function, and search becomes a client-side index or a hosted search. Everything that renders at build time keeps working unchanged.
How do content updates work after going static?
You edit in wp-admin as usual, then run an export to regenerate the static files and redeploy. This can be manual or wired to a publish hook so a new post triggers a fresh export.