Should You Move wp-config.php Above the Webroot?

Every so often the same WordPress security tip does the rounds: move wp-config.php one folder up, out of your webroot. WordPress will find it automatically, the file is no longer reachable over HTTP, job done.

It's a tip that splits opinion sharply. Half the responses are "yes, standard procedure, do it." The other half are "if an attacker is already inside your hosting account, this changes nothing." Both are right, and that's the interesting bit. The disagreement is really about what you're defending against.

This post is about what the move actually does, what it doesn't, and when it's worth the five minutes.

What the move actually does

WordPress looks for wp-config.php in two places: the same directory as wp-load.php (your webroot), and one directory above it. If it finds the file one level up, it loads it from there with no further configuration needed. This isn't a hack or a hidden feature. It's a documented part of how WordPress boots.

So the procedure is: move wp-config.php from /public_html/ (or /www/, or wherever your webroot lives) up one level, into the parent folder. Nothing else changes. The site keeps working. The file is now outside any path the web server will serve.

That's the whole change.

What it protects against

The real question is what threat model this addresses. There are three scenarios where moving the file genuinely helps.

PHP stops executing is the textbook reason. If your server misconfigures itself, your hosting plan lapses, or someone disables PHP for a directory mid-upgrade, files inside the webroot can suddenly start serving as plain text. A request for wp-config.php returns your database credentials and security keys in the response body. It's rare, but it has happened to real sites, often during a hosting migration or a server panic.

A file outside the webroot is never served, regardless of what PHP is doing. The web server has no path to it.

Accidental disclosure is the next one. Backup tools that zip the webroot, deployment scripts that tar up public_html, file managers that let you download a folder. All of these will happily include wp-config.php if it's inside the directory they're operating on. Moving it up means the file isn't in the bundle by default. You have to explicitly add it, which forces a moment of "wait, do I actually want to ship credentials in this archive?"

Misconfigured .htaccess or nginx rules are the third. Most hardening guides include a rule to deny direct HTTP access to wp-config.php. That rule is one typo away from not working. A file that isn't in the webroot doesn't depend on a deny rule being correct, because there's nothing to deny.

In all three cases, the protection comes from the same thing: the file simply isn't somewhere the web server can reach.

What it doesn't protect against

The counter-argument is the honest one. If an attacker has shell access, FTP access, or any kind of foothold on the server itself, moving wp-config.php up one folder doesn't slow them down for more than about ten seconds. They can ls .. from your webroot and read the file directly.

So this move is not a defence against a compromised server. It's not a defence against a hosting account that's been broken into. And it does nothing for the much more common attack paths: weak passwords, outdated plugins, leaked credentials. If you're hoping that moving one file will harden your site against actual attackers, you've misread the threat.

Anyone who treats this as a serious security control is overrating it. Anyone who dismisses it because it doesn't stop a determined attacker is missing what it's actually for: closing low-probability disclosure paths that are cheap to close.

How it pairs with environment variables

There's a stronger version of this, which is to keep credentials out of wp-config.php entirely. Instead of hard-coding DB_PASSWORD in the file, you set it as an environment variable on the server and read it in:

define('DB_PASSWORD', getenv('WP_DB_PASSWORD'));

This means the credentials live in your server configuration rather than a file. A leaked wp-config.php no longer leaks the password, because the password isn't in it. The trade-off is that you need somewhere sensible to manage those environment variables, which on a typical shared host is awkward. On a VPS or container setup, it's straightforward and worth doing.

If you're already moving the file above the webroot, this is a natural next step.

When to actually do it

Move wp-config.php above the webroot if:

You run your own VPS or dedicated server, and you control the file layout
Your hosting account gives you access to one level above public_html
You're already in the file doing something else and the move costs you a minute

Don't bother if:

Your host doesn't give you access above the webroot. Some don't.
You're hoping it'll do something it doesn't, like stop a real intrusion
You haven't done the bigger items first. A site with a weak admin password and three outdated plugins doesn't get safer by relocating one file.

The right framing is that it's a small piece of hygiene, not a security control. It removes a disclosure path that probably won't happen, but if it does, the consequences are total. Cheap to close, so close it.

Where this sits in the bigger picture

Hardening WordPress is a lot of small moves like this one. Each one closes a specific path that an attacker, or an accident, might otherwise find. Individually they look minor. Together they're what separates a site that holds up from one that doesn't.

The Protect My WP handbook walks through the full set, layer by layer, with the reasoning behind each one, the exact configuration, and the things that look like good advice but aren't worth your time. If you found this post useful, the book is the same approach applied to every layer of a WordPress install.

Get the book for £19.