How to Change the WordPress Database Table Prefix (Without Breaking Your Site)

Updated November 2026 by Marius: rewritten and tested on WordPress 7.1.4 with MariaDB 11.8. Originally published by Hardeep Asrani in 2014.

The old version of this post told you to rename every option that starts with wp_ after changing the table prefix. I tried that on a fresh WordPress 7.1 site, and it quietly breaks the privacy policy page setting. So I rewrote the post and tested every step on a throwaway site with a couple of popular plugins, including the ways it goes wrong.

In this guide, I will show you step-by-step how to change the database prefix of an existing WordPress site, with WP-CLI, with phpMyAdmin or with a plugin, and how to check that nothing broke.

The short answer

• Changing $table_prefix in wp-config.php is not enough. You also have to rename every table (plugin tables too), one row in the options table and the per-user rows in the usermeta table.
• Rename only the wp_user_roles option. Five other core options also start with wp_, but they are not tied to the prefix.
• Write the usermeta condition as LIKE 'wp\_%', with the backslash. Without it, the underscore matches any character and you also rename keys such as Yoast’s wpseo_title.
• Turn on maintenance mode first. Between renaming the tables and saving wp-config.php, visitors would otherwise get the WordPress installation screen.

Should you change it at all?

A custom prefix is often sold as a security fix. I don’t see it that way. It can stop an automated SQL injection that assumes the tables are called wp_users, but it doesn’t fix the hole. Anyone who can run SQL on your database can also list your table names from information_schema. Keeping WordPress and plugins updated matters much more.

The good reason to use a different prefix is running more than one WordPress install in the same database, which is exactly how I shared users and logins between two WordPress sites. For a new site, just pick the prefix in the installer (the “Table Prefix” field) or in wp-config.php before you install. It’s free at that point. On an existing site, follow the steps below.

What depends on the prefix

Here’s what I found on my test site (WordPress 7.1.4 with the Redirection and Yoast SEO plugins, two users and one redirect). The prefix shows up in three places:

• Table names: 12 core tables, plus every table a plugin creates. Redirection added 4 and Yoast added 6, so I had 22 in total.
• One row in the options table: wp_user_roles, which holds the list of roles and their capabilities.
• Rows in the usermeta table: wp_capabilities (the user’s role), wp_user_level and wp_dashboard_quick_press_last_post_id in my case. Other plugins can add more.

And this is what happened when I skipped a part:

What I changed	What I got
Only $table_prefix in wp-config.php	Every page redirected to /wp-admin/install.php (the “WordPress › Installation” screen)
Tables and wp-config.php, but not the rows	The front end worked, but every wp-admin page said “Sorry, you are not allowed to access this page.” (403), for the admin and the editor
Plus the user_roles option only	Same error
Plus the usermeta rows only	Same error, and the Users list showed both users with no role
Only the 12 core tables (plugin tables kept wp_)	The site and wp-admin worked, but my test redirect stopped working: /old-page/ returned 200 instead of the 301, without any error
Everything (tables, the option, usermeta, wp-config.php)	Everything worked: roles, wp-admin, the redirect, the privacy policy link

The last-but-one row is the one I’d worry about the most. Most older guides list the 12 core tables only, and nothing tells you that a plugin lost its data.

1. Back up the database

I highly recommend taking a full database backup first. With WP-CLI it’s one command (it’s also the second line of the script below). In phpMyAdmin, select the database, open the Export tab and click Export.

Keep the file until you’ve checked the site. If something goes wrong, you import it back and set the old prefix in wp-config.php again. If phpMyAdmin rejects the file as too large when you import it, raise phpMyAdmin’s import limit first.

Also look up your current prefix in wp-config.php (the $table_prefix line). I’ll use wp_ as the old prefix and tp7x_ as the new one. Replace both with yours. Only letters, numbers and underscores are allowed, and ending it with an underscore keeps the table names readable.

2. Change the prefix with WP-CLI

There are multiple ways to do it, but if you have SSH access, I prefer WP-CLI. The whole thing takes a couple of seconds, so the site is in maintenance mode for a very short time. Run this in the WordPress folder:

wp maintenance-mode activate
wp db export before-prefix-change.sql

wp db query --skip-column-names "SELECT CONCAT('RENAME TABLE \`', TABLE_NAME, '\` TO \`tp7x_', SUBSTRING(TABLE_NAME, 4), '\`;') FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME LIKE 'wp\_%'" > rename-tables.sql
cat rename-tables.sql
wp db query < rename-tables.sql

wp db query "UPDATE tp7x_options SET option_name = 'tp7x_user_roles' WHERE option_name = 'wp_user_roles'"
wp db query "UPDATE tp7x_usermeta SET meta_key = CONCAT('tp7x_', SUBSTRING(meta_key, 4)) WHERE meta_key LIKE 'wp\_%'"

wp config set table_prefix tp7x_ --type=variable
wp maintenance-mode deactivateCode language: Bash (bash)

What it does, line by line:

1. Puts the site in maintenance mode. Visitors get a “Briefly unavailable for scheduled maintenance” page (HTTP 503) instead of the install screen while the prefix doesn’t match. I checked this halfway through on my test site.
2. Exports the database to before-prefix-change.sql.
3. Builds one RENAME TABLE statement for every table that starts with wp_, plugin tables included, and saves them to a file. The 4 in SUBSTRING(TABLE_NAME, 4) is the length of wp_ plus one. If your old prefix is longer, adjust it. cat shows you the statements before they run.
4. Renames the tables.
5. Renames the wp_user_roles option (1 row in my case).
6. Renames the usermeta keys that start with wp_ (6 rows here: 3 keys for each of my 2 users).
7. Updates $table_prefix in wp-config.php.
8. Turns maintenance mode off.

wp db query and wp config set don’t need WordPress to load, so they keep working while the tables and wp-config.php don’t match.

3. Or change it in phpMyAdmin

No SSH? You can do the same in phpMyAdmin and your host’s file manager. It takes a few minutes, so start with maintenance mode: create a file called .maintenance in the WordPress folder (next to wp-config.php) with this line:

<?php $upgrading = time(); ?>Code language: PHP (php)

WordPress shows the maintenance page while that file exists, but ignores it after 10 minutes. If you need longer, save the file again.

Next, rename the tables. phpMyAdmin has a built-in action for it (I checked version 5.2.3):

1. Click your database and stay on the Structure tab.
2. Tick Check all at the bottom of the table list. If the database holds tables of another site, untick those.
3. In the With selected menu, choose Replace table prefix.
4. Enter wp_ as the old prefix and tp7x_ as the new one, and confirm.

That action only renames tables. Open the SQL tab and run the two row updates:

UPDATE tp7x_options SET option_name = 'tp7x_user_roles' WHERE option_name = 'wp_user_roles';
UPDATE tp7x_usermeta SET meta_key = CONCAT('tp7x_', SUBSTRING(meta_key, 4)) WHERE meta_key LIKE 'wp\_%';Code language: SQL (Structured Query Language) (sql)

Using Adminer or another client without a prefix action? This query builds the RENAME TABLE statements for you. Copy its results and run them as a second query:

SELECT CONCAT('RENAME TABLE `', TABLE_NAME, '` TO `tp7x_', SUBSTRING(TABLE_NAME, 4), '`;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME LIKE 'wp\_%';Code language: SQL (Structured Query Language) (sql)

Last, but not least, edit wp-config.php, change the $table_prefix line to your new prefix, and delete the .maintenance file.

Two mistakes I tested so you don’t have to

Renaming every option that starts with wp_

On a fresh WordPress 7.1 install, six options start with wp_:

• wp_user_roles (the only one tied to the prefix)
• wp_page_for_privacy_policy
• wp_attachment_pages_enabled
• wp_calendar_block_has_published_posts
• wp_force_deactivated_plugins
• wp_notes_notify

The last five are normal option names that WordPress always looks up as they are, whatever your prefix. When I renamed all six, WordPress lost the privacy policy page: the “Privacy Policy” link disappeared from the login page, and wp option get wp_page_for_privacy_policy said the option doesn’t exist. With only wp_user_roles renamed, the link stayed.

Forgetting the backslash in LIKE

In SQL, _ in a LIKE pattern means “any single character”. So LIKE 'wp_%' matches every key that starts with “wp”, not only wp_. Yoast SEO saves an author’s SEO title and description as wpseo_title and wpseo_metadesc in usermeta. When I ran the usermeta update without the backslash, those keys became tp7x_eo_title and tp7x_eo_metadesc, so Yoast would no longer find the author’s SEO settings. With LIKE 'wp\_%', they stayed untouched.

4. Or let a plugin do it

If you’d rather not touch SQL, All-In-One Security (AIOS) has a Database security → Database prefix tool. I ran the same code its “Change database prefix” button runs (version 5.5.1) on my test site, and it did everything right:

• It renamed all 31 tables, including the plugin tables (AIOS adds 9 of its own).
• It renamed only wp_user_roles and left the other five wp_ options alone.
• It updated the usermeta keys with an escaped LIKE, so Yoast’s keys were safe.
• It saved a backup copy of wp-config.php and then edited the prefix in it. The tool only runs if the plugin can write to wp-config.php.

After that, the admin, the editor and my redirect all worked. AIOS is a big security plugin to install for one job, so you can deactivate it afterwards if you don’t want the rest. It doesn’t make a database backup for you, so do step 1 anyway.

The plugin the old version of this post recommended, Change Table Prefix, is still around (version 3.0, about 1,000 installs). I only read its code, which uses the same approach, but I didn’t run it.

5. Check that everything works

I would never leave a change like this untested. Here’s what I check:

• Log in and open a few wp-admin pages. “Sorry, you are not allowed to access this page.” means the option or usermeta rows weren’t renamed.
• Open Users. Every user should still have a role.
• Test whatever your plugins store in their own tables: a redirect, a form entry, an order.
• Make sure no table kept the old prefix. In phpMyAdmin, look at the table list. With WP-CLI, wp db tables --all-tables lists them all.
• If you use a persistent object cache (Redis or Memcached), flush it, so WordPress doesn’t read the old option names from the cache.

If you got the same results, you can delete the backup when you’re happy (or keep it somewhere safe). That’s it! Your WordPress site now runs on the new table prefix.

Limitations

• I tested a single site on MariaDB 11.8. The statements are plain MySQL, but I didn’t run them on MySQL itself.
• Multisite has more to rename: tables like wp_2_posts for each site, network tables like wp_sitemeta, and a roles option in every site’s options table (wp_2_user_roles). I didn’t test that. The AIOS code handles the per-site roles options, but check everything twice.
• If a plugin stored a key starting with your old prefix in a place I didn’t cover (another table, or inside a serialized value), it won’t be renamed. I didn’t find one with Redirection, Yoast and AIOS, but I can’t speak for every plugin.