Moving wp-content: when it helps, when it breaks things

wp-content holds themes, plugins, and uploads. WordPress expects that layout by default. You can point core at a different path with constants in wp-config.php. That is a maintenance decision, not a meaningful defense against modern automated attacks.

Renaming the folder so bots “cannot find” plugins is mostly security theater. Attackers hit known plugin URLs, XML-RPC, and login forms. They do not need a friendly folder name. Plenty of plugins and must-use tooling also assume /wp-content/.

If you need real hardening, start with the hardening guide and login security.

Correct constants (there is no WP_CONTENT_FOLDERNAME)

WordPress documents two related defines:

• WP_CONTENT_DIR: absolute filesystem path to the content directory
• WP_CONTENT_URL: full URL to that directory (no trailing slash)

There is no supported WP_CONTENT_FOLDERNAME constant. Older tutorials that invent it are wrong and will not rename the folder for you.

Place custom defines in wp-config.php above the line that says /* That's all, stop editing! */ (and before ABSPATH is required).

Example: content directory in a custom path

define( 'WP_CONTENT_DIR', '/var/www/example.com/site-content' );
define( 'WP_CONTENT_URL', 'https://example.com/site-content' );

Then:

1. Back up the site.
2. Move the existing wp-content directory to that path (or copy, verify, then remove the old one).
3. Confirm WP_CONTENT_DIR matches the real server path and WP_CONTENT_URL matches the public URL.
4. Load the front end and wp-admin. Check that media, themes, and plugins still resolve.

Do not leave a trailing slash on either value.

“Rename only” in the same parent directory

If the folder stays next to wp-admin and you only change the directory name, you still set both path and URL to the new name:

define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/app-content' );
define( 'WP_CONTENT_URL', 'https://example.com/app-content' );

Rename/move the folder on disk to match. Test thoroughly.

When a custom content path is reasonable

• Hosting layout requirements (rare)
• Separating uploads onto another volume (often better solved with UPLOADS or object storage plugins)
• Advanced multi-app deployments where you already own the breakage risk

When to skip it

• You want “more security” with one clever trick
• You use many third-party plugins and cannot regression-test them
• You are on managed WordPress hosting that forbids or resets custom paths
• You do not have a full backup and a rollback plan

Protect wp-config instead of hiding folders

wp-config.php holds database credentials and salts. Keep it non-writable by the web user when your host allows that, outside the web root if the host supports it, and never committed to a public repo. Security Ninja’s scanner checks common wp-config permission mistakes.

More practical hardening beats folder renaming every time: updates, few admins, 2FA, backups, and a firewall.