How to Change the WordPress Database Table Prefix

Every WordPress install stores its data in tables, and by default they all start with wp_. Because that prefix is predictable, some automated attacks assume it. Switching to a custom random prefix is a small hardening step, and here is how to do it safely.

What the table prefix is

The $table_prefix variable lives in wp-config.php. It sets the text that begins every table name, so wp_posts, wp_options, wp_users, and so on. WordPress reads this value on every request to know which tables to query.

Using a random prefix like xk7q_ instead of wp_ makes blind SQL injection guessing harder, since an attacker can no longer assume the table names. Be honest about the scope, though: this is minor hardening, not a substitute for real security like strong passwords, fresh salts, and keeping core and plugins updated.

Set it on a new install

For a fresh site, this takes one line. Before you run the WordPress installer:

Open the DB Table Prefix Generator and copy a random prefix.
In wp-config.php, find the $table_prefix = 'wp_'; line.
Replace wp_ with your generated value, keeping the trailing underscore (for example $table_prefix = 'xk7q_';).
Run the installer. WordPress creates every table with your custom prefix.

The prefix is generated entirely in your browser, so nothing is sent over the network.

Change it on an existing site

This is the careful part. You are renaming live tables and rewriting two values that store the prefix inside them. Get a fresh prefix from the DB Table Prefix Generator, then work in order.

Back up first. Export the full database and copy wp-config.php before touching anything. If a step goes wrong, you restore and try again.
Rename every table. Change wp_posts to newprefix_posts, wp_options to newprefix_options, and so on for all tables. Tools like phpMyAdmin or WP-CLI can rename in bulk.
Fix the autoload option name. Inside {prefix}options there is a row whose option_name is wp_user_roles. Rename it to newprefix_user_roles, because that key embeds the prefix.
Fix the usermeta keys. In {prefix}usermeta, several meta_key values start with wp_, such as wp_capabilities and wp_user_level. Update each one to start with your new prefix.
Update wp-config.php. Set $table_prefix to match the new prefix exactly.

Load the site and log in. If you skip the options row or the usermeta keys, WordPress loads but your admin loses its capabilities and you see a permissions error. That is the usual symptom of a missed key.

When this is worth doing

Changing the prefix is cheap on a new install, so do it then. On an existing site the migration carries real risk, so only attempt it with a tested backup and ideally on a staging copy first. Treat it as one layer among many, not the layer that secures your site.

Rotate your authentication secrets with the WordPress Salt Generator.
Build a clean, secure config file with the wp-config Generator.
Tune your server’s worker settings with the PHP-FPM Calculator.

Pick a random prefix, back up, rename carefully, and your tables stop being a free guess for attackers.