WordPress database prefix: why to change from wp_ and how to do it safely

The default WordPress database prefix is wp_ - wp_posts, wp_users, wp_options. Every modern bot guesses those names when trying to exploit SQL injection vulnerabilities. Changing the prefix to an unpredictable value does not block SQLi, but it makes generic exploits useless.

Why this matters

SQL injection vulnerabilities in WordPress plugins are published several times a month. In many of them, the attacker can run a UNION SELECT but does not automatically get the table names - they have to guess. If the prefix is wp_, the first guess is wp_users (to grab password hashes) or wp_options (to read site secrets). With a random prefix like xyz_ or sk29_, the attacker needs an additional vulnerability just to enumerate the table names. For a large share of automated probes this is enough for the bot to give up and move on. Changing the prefix is classic security-through-obscurity - it does not stop a targeted attacker who profiled your site, but it reduces the success rate of automated scans. The cost is one careful migration, the benefit lasts forever.

How to detect

The audit reads $table_prefix from wp-config.php and checks whether it equals wp_ or wordpress_, the two defaults. If yes, the check is red. Manually: open wp-config.php and search for table_prefix - if the value is wp_ or similar, there is room to improve.

How to fix

1. Back up the entire database and wp-config.php. A prefix change interrupted halfway leaves the site broken.
2. Do this on staging first - a copy of production. Confirm staging still works after the change.
3. The easy path: install Brozzme DB Prefix Change or Change DB Prefix. Pick a new prefix (4-6 random characters such as xyz_ or a8b2_), click Run, and the plugin updates wp-config.php and renames the tables in one shot.
4. The manual path: edit wp-config.php from $table_prefix = 'wp_'; to $table_prefix = 'xyz_';
5. Open phpMyAdmin (or SSH into mysql) and RENAME TABLE for all ~12 tables:

   RENAME TABLE wp_commentmeta TO xyz_commentmeta;
   RENAME TABLE wp_comments TO xyz_comments;
   RENAME TABLE wp_links TO xyz_links;
   RENAME TABLE wp_options TO xyz_options;
   RENAME TABLE wp_postmeta TO xyz_postmeta;
   RENAME TABLE wp_posts TO xyz_posts;
   RENAME TABLE wp_termmeta TO xyz_termmeta;
   RENAME TABLE wp_terms TO xyz_terms;
   RENAME TABLE wp_term_relationships TO xyz_term_relationships;
   RENAME TABLE wp_term_taxonomy TO xyz_term_taxonomy;
   RENAME TABLE wp_usermeta TO xyz_usermeta;
   RENAME TABLE wp_users TO xyz_users;

6. Update values that embed the prefix inside table contents:

   UPDATE xyz_options SET option_name = 'xyz_user_roles' WHERE option_name = 'wp_user_roles';
   UPDATE xyz_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'xyz_') WHERE meta_key LIKE 'wp_%';

7. Test the site. Sign in. Verify every plugin functions.

Common mistakes

Do not change wp-config.php without renaming the tables - the site returns 'Error establishing a database connection' because WordPress is looking for xyz_users which does not exist yet. Do not skip the user_roles and usermeta UPDATE - without them admins lose their privileges and appear as subscribers on next login. Do not pick a prefix longer than 8 characters - some databases cap table names at 64 characters, and a long prefix breaks plugins that create tables with long names. Do not use special characters, hyphens or spaces - SQL is picky.

Verifying the fix

Re-run the audit. Manually: SHOW TABLES in phpMyAdmin should list every table with the new prefix. Sign in as administrator - it should work. Confirm posts, comments and media still appear. Exercise the main plugins to confirm they still function.