By default, every WordPress installation names its database tables with the prefix wp_ (for example, wp_users or wp_options). Because this prefix is the same on millions of sites, it is one of the first things automated attack scripts assume when they try to run malicious SQL injection queries against your site. Changing it to something unique does not make your site unhackable, but it removes one easy assumption those scripts rely on, and it is a quick, low-cost hardening step.
This is a precaution, not a replacement for keeping WordPress core, themes, and plugins updated, using strong passwords, and limiting login attempts. Treat it as one layer among several.
The steps below are the same whether your hosting account uses cPanel or DirectAdmin, since you are working inside WordPress's own files and phpMyAdmin rather than a control-panel-specific tool.
Before you start
- Take a full backup of your website files and database first. If anything goes wrong, you want an easy way back.
- Make sure you know how to reach File Manager and phpMyAdmin from your hosting control panel, since you will need both.
- Put your site into maintenance mode if you want to avoid visitors hitting errors while you work.
Step 1: Edit wp-config.php
- Open File Manager and navigate to your site's root folder (usually public_html, or a subfolder if WordPress is installed there).
- Right-click wp-config.php and choose Edit (or Code Editor).
- Find the line that reads:
$table_prefix = 'wp_';
- Change wp_ to a short, unique value of your choosing, such as wpsec427_. Keep the underscore at the end, and avoid special characters other than letters, numbers, and underscores.
- Save the file.
Step 2: Rename the tables in phpMyAdmin
- Open phpMyAdmin from your control panel and select your WordPress database.
- Select every table that currently starts with wp_ (use the checkboxes, or Check all).
- From the With selected dropdown at the bottom, there is no built-in bulk rename, so rename tables one at a time: click a table, go to the Operations tab, and under Rename table to enter the new name using your new prefix (for example, wp_options becomes wpsec427_options).
- Repeat this for every table until none are left with the old prefix.
Step 3: Update the serialized references inside wp_options and wp_usermeta
Two tables store references to the old prefix inside their row data, not just in their table names, and renaming the table alone will not fix these:
- Open your new ..._options table and find the row where option_name is wp_user_roles. Click Edit on that row and change wp_user_roles in the option_name field to your new prefix, e.g. wpsec427_user_roles.
- Open your new ..._usermeta table. Look for rows where meta_key starts with wp_ (commonly wp_capabilities and wp_user_level) and edit each one to use your new prefix instead.
If you skip this step, your site will usually load, but all users (including you) will appear to have no role or permissions, which locks you out of wp-admin.
Step 4: Test your site
- Visit your homepage and try logging into wp-admin.
- Check a few posts, pages, and plugin settings screens to confirm nothing looks broken.
- If something fails to load or you cannot log in, double check Step 3. A mismatched prefix reference there is the most common cause of problems after this change.
If you would rather not edit the database by hand, several WordPress security plugins include a one-click table prefix changer that performs all three steps above automatically. A plugin is the safer route if you are not comfortable working directly in phpMyAdmin.