Agencies keep paying for hosting slots on things that need no PHP at all: a campaign microsite, documentation for a custom plugin, a spec demo attached to a proposal, a status page for the night the origin is down. Those are folders of static files, and free static hosting covers every one of them without adding to the monthly bill.
Thomas Reid recently wrote up three ways to deploy a static web app for free on Towards Data Science: GitHub Pages, here.now, and Hugging Face Spaces. He built a single-file browser game with Codex in about sixteen minutes and pushed the one index.html to all three. The tutorial holds up. What it can’t tell you is which parts of WordPress client work these hosts can take, because that’s not his world; it’s mine, so here’s where I draw the line.
My position is narrow. Static hosts matter at the edges of WordPress work and for content-only sites, and almost nowhere in between. The test is whether a page needs PHP running at the origin. If it doesn’t, moving it off the origin usually wins on cost and on blast radius.
Where free static hosting earns its keep
The realistic list for a WordPress shop is short:
- Demo and spec pages: a landing page concept, a custom block prototype, a front-end redesign you want the client to click through before theme work lands on their host.
- Plugin documentation: docs for a custom plugin ship better as a plain folder in the repo than as a page tree on the client’s WordPress.
- Campaign pages: a seasonal teaser or launch page that shouldn’t compete for PHP workers with the live store.
- Status and holding pages: a page that stays up when the origin doesn’t, which is the point of hosting it somewhere else.
The GitHub Pages flow is just git. Rename your entry file to index.html, push to a public repo, then open Settings, click Pages, and set the source branch and folder. Free plans on GitHub require the repo to be public for Pages, per the GitHub Pages quickstart, so know that before you push anything client-specific.
cd microsite/
git init
git add .
git commit -m "Campaign microsite"
git branch -M main
git remote add origin https://github.com/your-agency/microsite.git
git push -u origin mainOne wrinkle the single-file game demo hides: a project site serves from a subpath, username.github.io/repo-name/, so absolute asset paths like /style.css will 404. Write your paths relative and the same folder works locally and deployed. And for anything that needs WordPress running in the demo, a static host can’t help; WordPress Playground is the better fit there.
Exporting a WordPress site to static files
The bigger shift is exporting WordPress itself. Simply Static, a plugin on wordpress.org, generates a static copy of an existing install; the free version writes a ZIP or a local directory, and the paid tier adds deployment targets. You build the site in WordPress as usual, export, and host the output. The install that produced it can stay local or behind authentication, and once nothing public executes PHP, the plugin-vulnerability class of problems stops applying to the live site.
There’s a maintenance cost, though. Every content edit is a re-export, so this suits brochure sites, documentation and portfolio sites that change monthly, not stores or news sites. Before you promise it to anyone, check pagination, the sitemap, RSS feeds and hard-coded absolute URLs, because those are the usual breakage on export.
That model also slots into a sane WordPress development workflow: WordPress becomes the build tool and the static output is the artifact you deploy.
Where it stops working
The hard limits are anything with state. WooCommerce is out: cart, checkout, stock, price rules, logged-in accounts and the REST calls behind them all need PHP at the origin. Contact forms die the same way, since most form plugins POST to admin-ajax.php or admin-post.php. Comments, search and wp-login.php all assume a running install too.
The other two hosts from the article have their own edges. Hugging Face static Spaces are free precisely because nothing computes, but they need a README metadata block and render inside a Space page, so they’re better for demos than for everyday hosting. here.now gives anonymous URLs for 24 hours and permanent ones only through an account and an API key (it’s new enough that I’d read the current plan limits before promising a client a URL there). And as Reid says himself, none of these are built for thousands of concurrent users.
Take one parked microsite this week: create a public repo, push the folder, then open Settings, click Pages, and set main as the source. GitHub’s docs say a first publish can take up to ten minutes, so a 404 right after pushing isn’t a failure. And if you’d rather have a content-heavy client site exported and moved off PHP properly, that’s work I do. Send the URL and I’ll tell you quickly whether it exports cleanly.
