How to change the WordPress database table prefix?

To change the WordPress database table prefix, you rename every table that starts with the old prefix (usually wp_), update the $table_prefix value in wp-config.php to match, and then update a handful of rows in the options and usermeta tables whose names include the prefix. You can do this manually with SQL, with WP-CLI, or with a security plugin that automates the steps. Always take a full database backup first, because a mistake can lock you out of your own dashboard.

Changing the prefix is a common hardening recommendation, but it's often misunderstood. It's a minor obscurity measure, not a replacement for real protections like updates and secure code. This guide explains what the table prefix is, what changing it does and doesn't protect against, and walks you through three reliable methods, including the easily missed steps that cause "You do not have sufficient permissions" errors.

What Is the WordPress Database Table Prefix?

WordPress stores its data in a set of MySQL or MariaDB tables. Every table name starts with a prefix, which is wp_ by default:

• wp_posts
• wp_postmeta
• wp_users
• wp_usermeta
• wp_options
• wp_terms, wp_termmeta, wp_term_taxonomy, wp_term_relationships
• wp_comments, wp_commentmeta
• wp_links

Plugins add their own tables with the same prefix, such as WooCommerce's wp_wc_orders or wp_woocommerce_sessions.

The prefix is defined in wp-config.php:

$table_prefix = 'wp_';

Its original purpose is practical: it lets multiple WordPress installations share one database without their tables colliding. On Multisite, subsites also get numbered prefixes like wp_2_posts.

Does Changing the Prefix Improve Security?

Changing the prefix provides a small amount of protection, and it's worth being honest about how much.

What It Can Help With

Some automated SQL injection attacks assume the default wp_ prefix. If a vulnerable plugin allows SQL injection, a payload that targets wp_users directly will fail against a site using a different prefix. That can slow down or break low-effort, automated attacks.

What It Doesn't Protect Against

• Skilled attackers: If an attacker can run SQL queries through an injection flaw, they can usually discover table names by querying the database's information_schema. A custom prefix won't stop them.
• Other attack types: It does nothing against brute-force logins, vulnerable plugins that don't involve SQL, stolen passwords, or XSS.
• The root cause: The real fix for SQL injection is using prepared statements, like $wpdb->prepare(), and keeping plugins updated.

When Is It Worth Doing?

• New sites: Setting a custom prefix during installation is free and harmless. The WordPress installer asks for it, and most hosts' one-click installers randomize it for you.
• Existing sites: Changing it later carries some risk of breaking things. It can still be worthwhile as part of a broader hardening process, especially if you're comfortable with databases and have good backups.

If you're short on time, prioritize updates, strong authentication, a web application firewall, and backups before changing the prefix.

Before You Start

Preparation is what makes this change safe:

1. Take a full backup: Back up the database and files. Confirm the backup is complete and that you know how to restore it.

2. Use a staging site if you can: Test the change on a staging copy first.

3. Put the site in maintenance mode: Prevents visitors and background processes from writing data during the change. With WP-CLI: wp maintenance-mode activate.

4. Deactivate caching temporarily: Object caches like Redis or Memcached may hold references to old option names. You'll flush the cache afterwards.

5. Choose a new prefix: Use only letters, numbers, and underscores, end it with an underscore, and keep it reasonably short. For example, sjd7k_ or site24_. Avoid uppercase letters, because MySQL table name case sensitivity varies between operating systems.

6. Note your current prefix: Check wp-config.php, or run:

wp config get table_prefix

Method 1: Change the Prefix With WP-CLI and SQL

This method gives you full control and works on any host with SSH access. The steps are: rename tables, update wp-config.php, then fix the prefixed rows in options and usermeta.

Step 1: Export a Backup

wp db export backup-before-prefix-change.sql

Move this file outside the web root when you're done, or delete it after confirming the change worked, so it can't be downloaded.

Step 2: List the Tables to Rename

wp db tables --all-tables-with-prefix

This lists every table using the current prefix, including plugin tables.

Step 3: Rename the Tables

Generate and run RENAME TABLE statements for every table. This short script builds them for you. Set the old and new prefixes first:

OLD_PREFIX="wp_"
NEW_PREFIX="sjd7k_"

for TABLE in $(wp db tables --all-tables-with-prefix --format=csv | tr ',' ' '); do
  NEW_TABLE="${NEW_PREFIX}${TABLE#"$OLD_PREFIX"}"
  echo "Renaming $TABLE to $NEW_TABLE"
  wp db query "RENAME TABLE \`$TABLE\` TO \`$NEW_TABLE\`;"
done

The ${TABLE#"$OLD_PREFIX"} expression strips the old prefix from the start of each name. After this, WordPress will temporarily be unable to find its tables, which is expected.

Step 4: Update wp-config.php

Change the prefix line in wp-config.php:

$table_prefix = 'sjd7k_';

Or with WP-CLI:

wp config set table_prefix sjd7k_ --type=variable

Step 5: Update Prefixed Option Names

WordPress stores user roles in an option named after the prefix, for example wp_user_roles. It must be renamed to match the new prefix:

wp db query "UPDATE sjd7k_options SET option_name = 'sjd7k_user_roles' WHERE option_name = 'wp_user_roles';"

Check whether any other options start with the old prefix, as some plugins create them:

wp db query "SELECT option_name FROM sjd7k_options WHERE option_name LIKE 'wp\_%';"

The backslash escapes the underscore, which is otherwise a wildcard in SQL LIKE. Review the results before renaming anything else. Only rename options that are clearly prefix-based, like wp_user_roles. Many plugins legitimately use option names that start with wp_ for unrelated reasons, such as wp_page_for_privacy_policy, which is a core option and must not be renamed.

Step 6: Update Prefixed User Meta Keys

User capabilities and levels are stored in usermeta with prefixed keys like wp_capabilities and wp_user_level. Update all keys that start with the old prefix:

wp db query "UPDATE sjd7k_usermeta SET meta_key = CONCAT('sjd7k_', SUBSTRING(meta_key, 4)) WHERE meta_key LIKE 'wp\_%';"

SUBSTRING(meta_key, 4) removes the first three characters (wp_). If your old prefix is a different length, adjust the number: it should be the old prefix's length plus one.

This covers wp_capabilities, wp_user_level, wp_user-settings, wp_user-settings-time, wp_dashboard_quick_press_last_post_id, and similar keys that WordPress creates per prefix.

Step 7: Flush Caches and Test

wp cache flush
wp maintenance-mode deactivate

Then:

• Log in to the dashboard and confirm you have full admin access.
• Visit several front-end pages.
• Check Settings > Permalinks and click Save Changes to refresh rewrite rules.
• Test key plugin features like forms, checkout, or memberships.

Method 2: Change the Prefix Manually in phpMyAdmin

If you don't have SSH access, you can use phpMyAdmin from your hosting control panel.

• Back up the database: In phpMyAdmin, select your database and use the Export tab to download a full SQL backup.

• Rename the tables: Select the database, tick all tables with the old prefix, and choose Replace table prefix from the "With selected" dropdown. Enter the old prefix (wp_) and the new prefix (sjd7k_), then submit. Alternatively, run RENAME TABLE statements in the SQL tab:

RENAME TABLE
  wp_commentmeta TO sjd7k_commentmeta,
  wp_comments TO sjd7k_comments,
  wp_links TO sjd7k_links,
  wp_options TO sjd7k_options,
  wp_postmeta TO sjd7k_postmeta,
  wp_posts TO sjd7k_posts,
  wp_termmeta TO sjd7k_termmeta,
  wp_terms TO sjd7k_terms,
  wp_term_relationships TO sjd7k_term_relationships,
  wp_term_taxonomy TO sjd7k_term_taxonomy,
  wp_usermeta TO sjd7k_usermeta,
  wp_users TO sjd7k_users;

Add any plugin tables to this list. The statement above only covers the core tables.

• Update wp-config.php: Change $table_prefix to your new prefix using your host's file manager or SFTP.

• Update the options table:

UPDATE sjd7k_options
SET option_name = 'sjd7k_user_roles'
WHERE option_name = 'wp_user_roles';

• Update the usermeta table:

UPDATE sjd7k_usermeta
SET meta_key = CONCAT('sjd7k_', SUBSTRING(meta_key, 4))
WHERE meta_key LIKE 'wp\_%';

• Test thoroughly: Log in, check the dashboard, and test the front end.

Method 3: Use a Security Plugin

Some security plugins can change the table prefix for you, handling the table renames, wp-config.php update, and option and usermeta changes automatically.

• All-In-One Security (AIOS): Includes a database prefix change feature in its database security settings.
• Solid Security: Has historically included a database prefix change tool in its advanced or tweaks settings, though availability varies by version.

Plugin menus change over time, so check the plugin's current documentation. Even with a plugin, take a full backup first, because a failure halfway through (for example, a timeout on a large database) can leave the site in a broken state. The plugin also needs write access to wp-config.php; if it can't write to the file, it will usually tell you to update it manually.

Multisite Considerations

On WordPress Multisite, each subsite has its own set of tables, like wp_2_posts and wp_2_options, plus network-wide tables like wp_blogs, wp_site, wp_sitemeta, and wp_signups. Changing the prefix on Multisite requires:

• Renaming every subsite's tables, not just the main site's.
• Updating the wp_N_user_roles option in every subsite's options table.
• Updating usermeta keys for every subsite, such as wp_2_capabilities.

The WP-CLI loop in Method 1 renames all tables. For the options, you'd repeat the update for each subsite table. Because of the complexity, test very carefully on staging first.

Troubleshooting

"You do not have sufficient permissions to access this page": The most common problem. It means the usermeta keys or the user_roles option still use the old prefix. Re-run the updates from Steps 5 and 6.

"Error establishing a database connection" or the installer appears: WordPress can't find its tables. Check that $table_prefix in wp-config.php exactly matches the new table names, including the trailing underscore.

A plugin stopped working: The plugin may have its own tables you didn't rename, or it may store the prefix in its settings. Check for tables still using the old prefix with wp db tables or phpMyAdmin.

Everything is broken and you want to roll back: Restore your database backup and revert wp-config.php to the old prefix:

wp db import backup-before-prefix-change.sql
wp config set table_prefix wp_ --type=variable
wp cache flush

Writing Prefix-Safe Custom Code

If you write custom code, never hard-code wp_ in table names. Use the $wpdb properties instead, which always reflect the current prefix:

<?php
global $wpdb;

$author_id = 5;

$titles = $wpdb->get_col(
    $wpdb->prepare(
        "SELECT post_title FROM {$wpdb->posts} WHERE post_author = %d AND post_status = %s",
        $author_id,
        'publish'
    )
);

// For custom tables, build the name from $wpdb->prefix.
$table_name = $wpdb->prefix . 'sajjad_logs';

This way, your code keeps working if the prefix ever changes, and you're also using prepared statements, which is the real protection against SQL injection.

---

FAQ: Changing the WordPress Table Prefix

---

Conclusion

Changing the WordPress database table prefix involves four parts: renaming the tables, updating $table_prefix in wp-config.php, renaming the user_roles option, and updating prefixed usermeta keys. Miss one, and you'll likely run into missing tables or permission errors, which is why a full backup and a staging test are essential.

Keep the benefit in perspective. A custom prefix can deter lazy, automated SQL injection attempts, but it won't stop a determined attacker. Treat it as one small layer in a broader strategy that includes timely updates, prepared statements in custom code, strong authentication, a firewall, and reliable backups.