Hosting WordPress like a developer, not a consumer.

Most WordPress sites aren’t hosted. They’re parked. Somewhere on a shared server, next to four hundred other sites, reached by an FTP password taped into a document called logins final FINAL.docx. It works, right up until the afternoon someone edits functions.php in the browser file manager, on the live site, and the white screen of death arrives for every visitor at once.

That’s consumer hosting: the live site is the only site, changes happen by hand, and there is no undo. Hosting WordPress like a developer isn’t about a fancier control panel. It’s about four boring habits that turn a WordPress site from a thing you’re scared to touch into a thing you can change on a Tuesday and forget about.

What consumer hosting costs you.

Shared hosting is cheap because you’re sharing. A traffic spike on someone else’s site slows yours. A security problem on a neighbour can become yours. You get a control panel, a one-click WordPress installer, and FTP - and every one of those is optimised for setup, not for the next ten years.

The deeper cost is that there’s nowhere safe to try anything. No staging site means every change is a live change. So nobody upgrades PHP, because what if it breaks. Nobody updates the big plugins, because what if it breaks. The site freezes in amber - an old PHP version, a pile of plugins nobody dares touch - and slowly becomes the thing you have to replace instead of maintain.

Version control is the whole game.

Everything else follows from one decision: the site’s code lives in git, and the live server never gets edited directly.

For us that means the theme and our own plugins are version-controlled, and a deploy pushes only that code to the server. WordPress core, third-party plugins and uploads stay on the box and update themselves. There’s no FTP, because there’s nothing to hand-upload. A deploy is a command, and because it’s a command, it can be repeated, reviewed, and rolled back.

We take it one step further and version the content structure too - post types, fields and even the seed content live in the repository as code, so a fresh environment can be rebuilt from the repo instead of a database someone remembered to export. The database still holds the living content; the shape of the site is code.

# Pull production's database into staging, then rewrite the domain safely.
wp db export - | ssh staging "wp db import -"
wp search-replace 'https://site.com' 'https://staging.site.com' --all-tables --precise
wp cache flush

A staging site that matches production.

Staging isn’t a luxury, it’s where the scary things happen so they don’t happen live. A PHP 8.2 to 8.3 jump, a WooCommerce major version, a plugin you’re not sure about - all of it goes to a staging site that mirrors production, gets tested, and only then gets promoted. The client sees the change before the public does. Nothing reaches production that hasn’t already run somewhere identical.

WP-CLI for anything you’d otherwise click.

If you find yourself clicking the same thing twice in wp-admin, it’s a script. Plugin updates, user creation, cache flushes, exports, bulk edits, the migration above - all of it runs from the command line, which means it can run the same way on staging and production, and it can run unattended.

A task you can script is a task you can trust at 2am. A task you do by hand in a browser is a task you’ll get wrong at 2am.

Performance is a server setting, not a plugin.

We don’t install caching plugins (the plugin pile explains why). Caching belongs to the server: a page cache in Nginx and a Redis object cache for the database queries WordPress repeats on every request. Add a CDN in front for static assets and images, serve WebP, and the site is fast before a single “optimizer” plugin is considered. The plugins that promise speed are mostly patching around a server that was never set up properly in the first place.

And backups are snapshots, not a plugin’s nightly zip sitting in the same wp-content folder as the site it’s supposed to save. Server-level snapshots, kept off the server, are the version you can actually restore from when the box itself is the thing that died.

What this buys you, at year five.

Sites hosted this way are boring in the best way. PHP upgrades are a staging test and a deploy, not a gamble. A new developer clones staging and is productive in an hour, because the site is in git, not in a stranger’s FTP account. And when something does break, the fix is a commit and a deploy with a clear history behind it - not a frantic afternoon in a file manager hoping you remember what the file looked like before.

This is the same standard we bring to the custom platforms we build in Laravel and Vue: version control, staging, scripted deploys, servers we actually configure. WordPress deserves the same seriousness. If your site currently lives on shared hosting behind an FTP password, moving it onto a real setup is usually the cheapest reliability upgrade you can buy.