Understand what needs protecting
WordPress reads wp-config.php on the server. Visitors do not need to download its contents. On a correctly configured PHP server, requesting the file does not display its source, but a copied file named wp-config.php.bak or a ZIP archive can be served as an ordinary download.
The configuration file guide explains its main settings. You do not need to understand or rewrite those settings to check how the file is stored. Never paste its contents into a public forum or send an unredacted screenshot to support.
1. Locate the correct file and keep a private recovery copy
Sign in to your hosting panel, select the website and open File Manager. Find the installation containing wp-admin, wp-includes and wp-content. Look for wp-config.php in that directory; WordPress can also use a configuration file one level above it. Ask the host to identify the active file if the layout is unclear.
Before editing access rules, make a current backup and download a separate configuration copy to private storage. Keep hosting access open so you can undo a mistake even if WordPress stops loading. Record the original permission value and any server rule you change.
Do not create the recovery copy beside the live file with a .bak, .old or .txt suffix. Avoid moving the active file as a first step: managed hosting, multiple installations and deployment tools can depend on its location.
2. Remove copies from web-accessible directories
In File Manager, inspect the website root and any backup folders you created. Look for configuration copies, editor temporary files and archives containing the site. Confirm what each file is before moving it into private storage outside the web root or removing the redundant copy. Keep the active wp-config.php in place.
The web root is the directory whose files the server makes available through your domain. A folder called private or backups inside it is not automatically protected. Ask the host to confirm which storage location is outside public delivery if the panel does not make that boundary clear.
Review how your backup plugin stores downloadable archives and how long they remain on the server. Also follow the debug logging guide to avoid exposing diagnostic output. A protected configuration file does not make a separate archive or log private.
3. Ask the host to confirm ownership and permissions
Send support the file path, not its contents. Ask them to confirm that the account running WordPress can read it and that unrelated hosting accounts cannot. The required owner, group and numeric permissions depend on how their server runs PHP.
WordPress documents 400 or 440 as restrictive examples for wp-config.php, but applying either without the correct ownership can break the site. Use only the value your host confirms for this account. Our file permissions guide explains the difference between the number and ownership.
Have the host apply the setting if it is managed centrally. For a confirmed manual change, record the old value, change this file only and test the site immediately. Restore the recorded value if WordPress stops working, then ask support to resolve the mismatch. Do not apply the same restrictive value recursively to all site files.
4. Block direct requests using the supported server method
Ask the host whether direct HTTP requests to wp-config.php are already denied. Managed platforms can enforce this centrally. For Nginx or an unknown server type, have the host make the appropriate rule; an Apache .htaccess snippet does not configure Nginx.
Only if the host confirms Apache 2.4, .htaccess support and permission to add this rule, download a private copy of the existing .htaccess file and place the following block at its top, outside the WordPress-managed section. Preserve existing rules and avoid adding a duplicate restriction.
<Files "wp-config.php">
Require all denied
</Files>5. Verify protection and deal with any exposure
Check the homepage and dashboard immediately after a change. If a new 500 error appears, restore only your .htaccess change using File Manager and ask the host to check the error. For a healthy site, ask support to verify that a direct request for the configuration file is denied at the intended layer.
You can also open the normal site address followed by /wp-config.php in a private window, preserving any WordPress installation subdirectory. A denial such as 403 supports the access check. Receiving a blank page only shows that no visible content was returned, so it does not prove the blocking rule works. Do not use a public testing service that asks you to upload the file.
If configuration text downloads or appears in the browser, stop and contact the host to restrict access immediately. Treat the exposed database password, keys and any other secrets in the file as disclosed. Have support change the database password and its matching configuration value together, review database access, and replace the WordPress keys and salts. Removing the public copy cannot undo a previous download.
Finish by checking that removed backup-copy addresses no longer return their contents and ask the host to inspect any cache or alternate delivery path. For ongoing protection, disable the dashboard's code editors and keep server backups private. These controls reduce exposure; they do not clean an already compromised website.
Official references
WordPress describes configuration file protection and the settings stored in wp-config.php. Apache documents the Require access control directive.
Get help with the next step
If you have found a downloadable configuration copy or cannot confirm what is exposed, ask BugShield to help assess the site. Share the affected address and your host's findings without attaching the secrets themselves.