wp-config.php is the file WordPress reads before anything else. It holds the database credentials, the security keys, and a set of constants that change how WordPress behaves, several of which are worth setting on every site and are not set by default.
It is also the file most likely to take a site down if edited carelessly, so the first section is about that.
Before editing it
Copy it first. Right-click in File Manager, copy, name it wp-config-backup.php. A mistake here produces a blank site, and having the original beside it turns a crisis into a thirty-second fix.
Two things break it silently. A stray space before the opening <?php or after a closing tag produces a "headers already sent" warning. And a missing semicolon produces a blank page with nothing in the log, because PHP failed before it could log anything.
Add new lines above the comment that says to stop editing. Anything below it may not take effect.
The database block
define( 'DB_NAME', 'account_wp01' ); define( 'DB_USER', 'account_wpuser' ); define( 'DB_PASSWORD', 'the password' ); define( 'DB_HOST', 'localhost' );
On Ahosting DB_HOST is localhost. Both the database name and the user carry your account prefix, and forgetting it is the most common cause of "Error establishing a database connection". Every credential looks right because the prefix is invisible in the panel.
Security keys
The block of eight random values encrypts session cookies. WordPress publishes a generator; paste the whole generated block over the placeholder one.
Leaving the placeholders in place is a real weakness and takes ten seconds to fix.
Regenerating them invalidates every existing session, which immediately logs out anyone holding a stolen cookie. That makes it the first thing to do when you suspect a compromise, before deleting any files.
The constants worth setting on every site
Disable the file editor. Removes the fastest route from a stolen administrator password to code running on your server:
define( 'DISALLOW_FILE_EDIT', true );
Cap post revisions. WordPress stores every revision indefinitely by default, and a page edited fifty times leaves fifty rows:
define( 'WP_POST_REVISIONS', 5 );
Do not set this to false. The storage saving is small and the day you need to undo an edit you will want them.
Raise the memory limit when you see "Allowed memory size exhausted":
define( 'WP_MEMORY_LIMIT', '256M' );
If it has no effect, the ceiling is set lower at the server level and WordPress cannot exceed it. See configuring PHP settings.
The constants that fix specific problems
Lock the site URL when a wrong value in the database has locked you out of the admin area:
define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );
These override the stored values, which makes them the way back from a redirect loop or a broken URL setting. Be consistent about www; a mismatch here against a server redirect is the usual cause of the loop in the first place.
Debug logging when something is broken:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY must be false on a live site: errors go to wp-content/debug.log rather than appearing to visitors. Turn all three off when you are finished; the file grows without limit otherwise.
Database repair, temporarily:
define( 'WP_ALLOW_REPAIR', true );
Remove that line immediately after use. While it is set, the repair page is deliberately reachable without logging in.
The constant to be careful with
define( 'AUTOMATIC_UPDATER_DISABLED', true );
This disables all automatic updating, including security releases. It exists for sites managed by external tooling that applies updates itself.
On an ordinary site it is a mistake, and it is worth checking whether a previous developer left it in place. It is silent, and a site can sit unpatched for years behind it while the dashboard looks normal.
Keep secrets out of version control
This file contains your database password. If the site is in a Git repository, wp-config.php does not belong in it, and removing it later does not remove it, because the history keeps it.
Git version control in cPanel goes over keeping the repository above the web root for the same reason.
The debugging constants deserve their own treatment, including the one that must never be enabled on a live site. How to Debug WordPress with WP_DEBUG and Logs goes into it.
Where the file lives, and why that matters
WordPress looks for the file in the installation directory and, failing that, one level above it, provided no other WordPress installation is there.
Moving it up puts the database credentials outside the web root, where a web server misconfiguration cannot serve them as text. That is a real protection and it costs nothing.
mv ~/public_html/wp-config.php ~/wp-config.php
It does not help against code running inside the account, which can read it wherever it is. What it prevents is the specific failure where PHP stops executing and the server sends the file's contents to a visitor, which happens during a botched update or a PHP version change.
Do not leave a copy behind. And check for the ones that accumulate: wp-config.php.bak and wp-config.old in the web root are served as plain text by default, because the server does not recognise the extension. Directory indexes and hidden files explains blocking them.
Order matters more than people expect
The file is executed top to bottom, and the first definition of a constant wins. A later definition is ignored silently.
That explains a recurring confusion: a debugging constant added at the bottom of the file appears to do nothing, because something above already defined it.
Anything you add must also come before the line about not editing past this point, since the settings file is loaded there. A constant placed after it is set too late to affect anything WordPress has already decided.
grep -n "define(" wp-config.php | head -30
Reading the file with line numbers is the fastest way to find a duplicate definition, which is the usual cause of a setting that refuses to take effect.
Rotating the security keys
The keys sign the cookies that keep people logged in. Changing them invalidates every session immediately, and that is exactly what makes them useful.
After any compromise, or after removing an administrator whose device you cannot account for, replacing the keys logs out everybody including whoever should not be there. It is faster and more complete than hunting for sessions.
Nothing else is affected, content, settings and passwords are untouched. The only cost is that every user signs in again, which is worth a support note if the site has many.
Cleaning up a hacked WordPress site goes over where this belongs in the sequence, and it is early rather than late.
Settings that belong per environment
A staging copy needs different values from the live site, and hard-coding them in one file is how staging ends up sending real email or writing to the live database.
The workable pattern is to branch on the hostname, so the same file behaves correctly in both places:
if ( $_SERVER['HTTP_HOST'] === 'dev.example.com' ) {
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'DB_NAME', 'user_sitedev' );
}
That removes the step people forget when copying a site. Making a development copy of a site walks through the rest, including why the copy must never write to the live database.