How to Change the WordPress Table Prefix (And Whether You Actually Should)

Every WordPress install ships with a database table prefix, usually wp_, sitting in front of every table name: wp_posts, wp_options, wp_usermeta, and so on. Somewhere around 2013, a wave of security blog posts started telling people to change it, framing a non-default prefix as a meaningful line of defense against attackers. That advice has outlived its usefulness, but the mechanics of doing it safely are still worth knowing, because plenty of hosts, migration tools, and security plugins still offer a “change prefix” button, and if you click it without understanding what happens underneath, you can break a site in about four seconds.

What the table prefix actually does

The prefix exists so multiple WordPress installs can share a single MySQL database without table name collisions. That’s the entire original purpose. WordPress core reads the prefix from the $table_prefix variable in wp-config.php and uses it to build every table reference at runtime through $wpdb->prefix.

The security argument goes like this: if an attacker is running an automated SQL injection payload that assumes the default wp_ prefix, a custom prefix breaks that assumption and the payload fails. That’s true, narrowly. It stops the laziest, most generic mass-scan payloads that hardcode wp_users in a query string. It does nothing against an attacker who has already achieved SQL injection with wildcard table discovery (SELECT table_name FROM information_schema.tables defeats a custom prefix in one query), nothing against XML-RPC brute force, nothing against a compromised plugin with arbitrary file upload, and nothing against credential stuffing using a leaked password list. Sucuri and Wordfence have both published research over the years pointing out that prefix changes are, at best, a minor speed bump against unsophisticated bots, not a real control.

None of that means you shouldn’t do it. If your host’s automated scanner insists on it, or you’re consolidating a legacy multisite install where table collisions are a genuine risk, changing the prefix is a reasonable, low-cost step. Just don’t treat it as a substitute for what actually stops attacks: keeping core, themes, and plugins updated, using unique strong passwords with two-factor authentication, restricting the database user’s privileges to only what WordPress needs, and putting parameterized queries in front of anything that touches $wpdb directly in custom code.

Before you touch anything: back up properly

A prefix change touches every table in your database plus a config file. If it goes wrong halfway through, you get a white screen and a database full of tables that don’t match what wp-config.php expects. Take a full database export (via phpMyAdmin’s Export tab, WP-CLI’s wp db export, or your host’s backup tool) and a copy of your wp-config.php before doing anything else. Store both somewhere outside the site’s own directory, a local download or a separate storage bucket, not just another folder on the same server.

Method 1: WP-CLI (the method that doesn’t miss anything)

If you have shell access, this is the safest route because WP-CLI handles the serialized data problem correctly, more on that below.

wp config get table_prefix
wp search-replace 'wp_' 'newprefix_' --skip-columns=guid --precise

That’s not quite complete on its own, though. search-replace handles content values, but the actual table names and the $table_prefix constant need separate handling. The cleanest sequence is: rename each table with RENAME TABLE statements, update wp_usermeta.meta_key and wp_options.option_name rows that reference the old prefix (things like wp_user_roles and wp_capabilities), then update wp-config.php. A number of maintenance plugins, iThemes Security’s “Change Database Table Prefix” feature under System Tweaks, and the standalone Change Table Prefix plugin, automate exactly this sequence and are worth using unless you enjoy writing raw SQL loops.

Method 2: Manual, via phpMyAdmin

Step 1, Rename the tables

In phpMyAdmin, select your database, check all tables, and use the “With selected” dropdown or run individual statements:

RENAME TABLE wp_posts TO newprefix_posts;
RENAME TABLE wp_postmeta TO newprefix_postmeta;
RENAME TABLE wp_options TO newprefix_options;
RENAME TABLE wp_users TO newprefix_users;
RENAME TABLE wp_usermeta TO newprefix_usermeta;
RENAME TABLE wp_comments TO newprefix_comments;
RENAME TABLE wp_commentmeta TO newprefix_commentmeta;
RENAME TABLE wp_terms TO newprefix_terms;
RENAME TABLE wp_term_taxonomy TO newprefix_term_taxonomy;
RENAME TABLE wp_term_relationships TO newprefix_term_relationships;
RENAME TABLE wp_links TO newprefix_links;

Repeat for every table with the old prefix, including any that plugins added (WooCommerce, for example, adds several of its own). Missing even one plugin table is the single most common cause of a “site loads but this feature is broken” report after a prefix change.

Step 2, Fix the two tables where the prefix is baked into the data, not just the table name

This is the step every quick tutorial skips, and it’s the reason manual prefix changes have a reputation for breaking sites. WordPress stores serialized PHP arrays inside certain rows, and some of those arrays reference table names directly as strings. Two rows in particular need manual correction:

• In newprefix_options, find the row where option_name = 'wp_user_roles'. Rename that option_name value to newprefix_user_roles.
• In newprefix_usermeta, find every row where meta_key starts with wp_, commonly wp_capabilities and wp_user_level. Rename each to use the new prefix instead.

Skip this step and every user on the site loses their role and capabilities on the next page load, because WordPress looks for {$table_prefix}_capabilities and finds nothing. This is almost always the actual cause when someone reports “I changed my prefix and now I can’t log into wp-admin.”

Step 3, Update wp-config.php

Open the file and change the line:

$table_prefix = 'wp_';

to:

$table_prefix = 'newprefix_';

Save it, then load the site. If you did steps 1 and 2 correctly, it should behave exactly as it did before, just querying different table names underneath.

Managed hosts often won’t let you do this at all

If you’re on WP Engine, Kinsta, Pressable, or a similar managed platform, don’t be surprised if the manual method above simply doesn’t work the way it’s described. These hosts frequently lock down direct wp-config.php editing through their file manager, route database access through a proxy that restricts certain statement types, or run their own staging/git-push deployment pipeline that will overwrite a manually edited config file on the next deploy. WP Engine specifically discourages prefix changes and, in some plans, blocks the raw RENAME TABLE approach through their database access layer entirely.

On a managed host, the practical path is usually one of three things: open a support ticket and ask if they’ll do it for you (several will, since it’s a routine request), clone the site to a staging environment you fully control (a local Local by Flywheel install, or a DigitalOcean droplet with a vanilla WordPress install) where you have unrestricted database access, or accept that on a locked-down managed host the marginal security value described above doesn’t justify fighting the platform’s guardrails. Given how small the actual security benefit is, this is usually the point where it’s reasonable to just skip it.

Testing on staging first, not production

Even with a full backup, running this directly on a live production site while customers or members are actively browsing is a bad idea. A prefix change involves table renames, which briefly lock the affected tables. On a small site with a handful of daily visitors that’s a non-event. On a site running BuddyPress, WooCommerce, or any plugin doing frequent writes (activity feeds, cart sessions, order processing), a mistimed table rename can produce a burst of database errors for anyone hitting the site mid-migration. Clone the site to staging, run the full process there, confirm every plugin and every custom feature still works, and only then repeat the process on production during a low-traffic window.

What if you’re on WordPress Multisite?

Multisite complicates this further because each subsite already gets its own set of prefixed tables layered on top of the network’s base prefix, site ID 2 gets wp_2_posts, wp_2_options, and so on, while the network-wide tables (wp_blogs, wp_site, wp_sitemeta, wp_users, wp_usermeta) stay unprefixed by site ID since users and blog registrations are shared across the network. Changing the base wp_ prefix on a multisite install means renaming every one of those per-site table sets, not just one, and getting the site-ID segment of the table name exactly right for each. WP-CLI’s search-replace command supports the --network flag for exactly this scenario, and honestly, on anything beyond a two or three site network, doing this by hand in phpMyAdmin stops being realistic. Use WP-CLI or don’t attempt it.

Choosing a prefix

Stick to lowercase letters, numbers, and underscores, and end it with an underscore to match WordPress’s expected format. Avoid anything guessable from the domain name (using example_ for example.com defeats the point) and avoid hyphens or spaces, which some MySQL configurations reject outright. A short random string like x7q2_ works fine; there’s no benefit to making it long or clever.

What actually breaks after a prefix change, ranked by frequency

1. User roles and capabilities disappear, caused by skipping the serialized-data fix in Step 2, above. Fix by correcting the option_name and meta_key values.
2. A plugin stops working entirely, usually a plugin with poorly written code that hardcodes wp_ instead of calling $wpdb->prefix. This is a real bug in the plugin, not something you did wrong, and it’s worth reporting to the plugin author. Search the plugin’s code for literal 'wp_' strings to confirm before assuming your migration is at fault.
3. Object cache or transients show stale data, if you’re on a persistent object cache (Redis, Memcached), flush it after the change. Cache keys sometimes incorporate the table prefix and stale entries can point at tables that no longer exist under the old name.
4. A custom table created by old bespoke code isn’t found, if a developer years ago wrote a custom table creation script that hardcoded wp_ instead of using $wpdb->prefix, that table won’t get renamed by any of the automated tools and needs to be found and renamed manually.
5. Serialized data in wp_options referencing the old prefix in a way that isn’t obviously a table or meta name, a small number of plugins store the prefix as part of a serialized array value used for internal bookkeeping (import/export settings, migration state, license validation caches). These are rarer and harder to spot, and the fastest way to find them is a raw SQL search: SELECT option_name FROM newprefix_options WHERE option_value LIKE '%wp_%' run after the rename, filtering out obvious false positives like URLs containing “wp-content”.

Run through this list in order after any prefix change, whether you used the manual method or an automated plugin. Automated tools handle the common cases well but rarely catch every custom or third-party table a given site has accumulated over the years, especially on sites that have been through multiple developers and several rounds of plugin churn.

Reading the actual error messages

When a prefix migration goes wrong, the symptom rarely says “prefix” anywhere in it, which is why so many people mistake the cause. A few patterns worth recognizing:

• “Error establishing a database connection” immediately after saving wp-config.php almost always means a typo in the new prefix value, not a connection credentials problem, WordPress can connect fine but then fails to find any tables matching the prefix it’s been told to use.
• A white screen with no error text right after login, with the login page itself working, points at the missing user_roles and capabilities rename from Step 2. WordPress authenticates you, then can’t determine what role you have, and a common (badly written) failure mode for that condition is a blank screen rather than a clear error.
• One specific plugin’s admin page throws a database error while everything else works, that plugin created its own table with a hardcoded prefix reference. Check the plugin’s activation hook or its main PHP file for a literal wp_ string in a CREATE TABLE statement.
• Search results, related posts widgets, or anything relying on custom taxonomy queries return empty, check whether wp_term_relationships, wp_term_taxonomy, and wp_terms were all renamed together and consistently. A partial rename across just one of the three breaks every taxonomy query silently rather than with an error.

Turn on WP_DEBUG and WP_DEBUG_LOG temporarily while troubleshooting (never leave debug output visible on a live production site) and check wp-content/debug.log for the literal SQL error, which will usually name the exact table WordPress expected to find and couldn’t.

Rolling back

If something breaks and you can’t identify the cause quickly, the fastest fix is restoring the database backup you took in the first step and reverting wp-config.php to its original prefix value. Don’t try to debug a half-migrated database under time pressure, restore first, diagnose second, then attempt the migration again once you understand what went wrong.

Common questions

Does changing the prefix affect my permalinks or SEO?

No. The table prefix is purely a database-layer naming convention; it has no relationship to URLs, slugs, or how search engines see your site. Nothing about your rankings, indexed pages, or canonical URLs changes.

Will I need to update anything in my theme’s code?

Only if the theme contains custom code that queries the database directly with a hardcoded prefix instead of using $wpdb->prefix or WordPress’s built-in query functions (WP_Query, get_posts(), and so on). A properly coded theme built against WordPress’s documented APIs never hardcodes a prefix and needs no changes at all. If you inherited a site with a theme full of raw $wpdb->query("SELECT * FROM wp_...") calls, that’s a separate problem worth fixing regardless of whether you change the prefix.

How long does the whole process take?

For a typical small business site with 20-30 tables, the manual method takes about 20-30 minutes once you’re comfortable with phpMyAdmin, most of it spent double-checking the two serialized-data rows. The WP-CLI method with a properly configured plugin-aware search-replace takes under five minutes to run, though budget extra time for testing every plugin’s admin screens afterward regardless of which method you use.

Can I change the prefix back later if I regret it?

Yes, it’s the exact same process run in reverse, with the same care needed around the two serialized-data rows. There’s no one-way door here as long as you keep a record of what the old prefix was.

Does WordPress core ever recommend this?

The official WordPress Codex and developer documentation mention the option during installation (the famous “table prefix” field on the five-minute install screen) but core has never officially recommended changing it as a security measure. That guidance originated from third-party security blogs and hardening checklists, several of which have since been revised to de-emphasize it in favor of more effective controls.

Is it worth doing at all?

If a security scanner or your host is flagging the default prefix and you want the checkbox cleared, go ahead, the process above is safe when followed in order. But if you’re deciding where to spend limited security time on a WordPress site, the prefix is close to the bottom of the list. Ahead of it: enforce two-factor authentication for every admin account, keep automatic background updates on for minor core releases, remove unused plugins and themes entirely rather than just deactivating them, and put a web application firewall in front of login and XML-RPC endpoints. Those four things stop real attacks. A custom table prefix mostly stops the attacks that were never going to succeed anyway.