A broken WordPress database can make your site feel like it vanished overnight. Pages throw errors, the dashboard stalls, or a familiar “Error establishing a database connection” message takes over.
The good news is that WordPress database repair doesn’t have to mean sacrificing posts, orders, user accounts, or hard-won SEO work. You need a calm sequence, a current backup, and a repair method that matches the problem.
Start by protecting what is still there. Then fix only what needs fixing.
Stop New Changes Before Repairing Anything
Database damage gets worse when new writes keep landing in a failing system. Pause the activity first, then work from a safe copy.
Put the site in a quiet state
If the dashboard still works, enable maintenance mode or temporarily discourage editors from publishing. Pause WooCommerce orders, form submissions, imports, and scheduled campaigns if possible.
Don’t update plugins or WordPress core during this moment. Don’t install a “database cleaner” because it promises a quick fix. A corrupted database is not the time for extra moving parts.
We’ve seen small issues turn into long recovery jobs because somebody kept clicking around and saving changes. Slow down for ten minutes now. It can save hours later.
Create a backup you can restore
Make a full database export before you repair a single table. Your hosting control panel may include backup tools, or you can export the database through phpMyAdmin.
Save the .sql file somewhere off the server, such as secure local storage or cloud storage. If your host provides automatic backups, check the timestamp and confirm that a usable restore point exists.
A database backup protects content such as:
- Posts, pages, comments, and media attachment records
- WordPress users, passwords, roles, and settings
- WooCommerce products, customer records, and order data
- Form entries, SEO settings, and plugin configuration
A repair can fix table structure, but it cannot recreate data that was already missing before the backup.
Reliable hosting backup tools make this step far less stressful. At ZADiC, our WordPress hosting plans are built for business owners who need dependable backups, security monitoring, and real human support when a site starts acting up.
Confirm That Corruption Is the Real Problem
Not every database error means damaged tables. A wrong password, exhausted server resources, or a down database service can produce similar symptoms.
Watch for common corruption warnings
WordPress may show messages such as “one or more database tables are unavailable” or “the database needs to be repaired.” phpMyAdmin might label a table as crashed. Posts may disappear from the dashboard even though the site is still partly online.
Other signs include blank pages, failed logins, missing plugin settings, and errors that appear only when WordPress queries a certain feature. A useful overview of database corruption warning signs can help separate a table issue from a general site failure.
A single broken plugin screen may point to that plugin’s own table. A broken dashboard, front end, and login screen suggests a wider issue.
Rule out connection errors first
Open your wp-config.php file and review the database name, username, password, and host. A recent migration, password change, or server move can leave old values behind.
Also check whether your hosting account has reached disk, inode, or database resource limits. If the database server is unavailable, repairing WordPress tables won’t fix it.
Contact hosting support if the database service itself appears down. Database access is a hosting-level issue, not something a WordPress plugin can solve.
Find the Database and Its Table Prefix
Before you open phpMyAdmin or use a command line, identify the exact database WordPress uses. Guessing here can put the wrong site at risk.
Read the right lines in wp-config.php
In your site’s main WordPress folder, open wp-config.php. Look for the constants named DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.
You also need the $table_prefix value. Most sites use wp_, but many use a custom prefix such as site_ or abc123_. That prefix identifies the WordPress tables belonging to this installation.
Never paste your database password into a ticket, chat, or screenshot. Support teams can usually verify access without asking you to expose it.
Know which tables hold your content
Core WordPress content usually lives in a few familiar places:
| Table | What it stores |
|---|---|
wp_posts | Posts, pages, revisions, menus, and attachments |
wp_postmeta | Extra data connected to posts and products |
wp_users | User accounts and login details |
wp_usermeta | User roles and preferences |
wp_options | Site settings, plugin settings, and transients |
wp_terms and related tables | Categories, tags, and taxonomies |
The prefix may differ, but the table endings remain the same. Knowing this helps you target a repair without touching unrelated databases in the same hosting account.
Built-In WordPress Database Repair Starts Simply
The built-in WordPress tool is often the cleanest first move when the site can’t load normally. It doesn’t require a plugin or a working dashboard.
Add the temporary repair setting
Open wp-config.php through your host’s File Manager or SFTP. Add this line above the comment that says “That’s all, stop editing”:
define( 'WP_ALLOW_REPAIR', true );
Then visit https://yourdomain.com/wp-admin/maint/repair.php in a browser. Replace yourdomain.com with your real domain.
You’ll see options for “Repair Database” and “Repair and Optimize Database.” Start with Repair Database. Optimization can wait until the site is stable.
Run the repair and read the results
WordPress will check its tables and report what it repaired. Let the page finish. Closing the tab mid-process is a bad idea, especially on a larger site.
If you want a screen-by-screen reference before starting, this WordPress repair process guide shows the same repair path and related options.
Once the process ends, test the front end, the login page, and the dashboard. Don’t assume success because the repair screen says it completed.
Remove the setting immediately
Delete the WP_ALLOW_REPAIR line from wp-config.php as soon as you’re done.
That setting makes the repair page accessible without normal authentication. Leaving it active creates an unnecessary security risk. Fix the database, remove the switch, move on.
Repair Selected Tables in phpMyAdmin
phpMyAdmin is useful when WordPress identifies a particular damaged table or the built-in repair tool doesn’t resolve the error. Most cPanel hosting accounts offer access through the Databases section.
Select only the affected database
Open phpMyAdmin from your hosting control panel, then click the database name listed in wp-config.php. Check that the table prefix matches your WordPress site.
If phpMyAdmin flags a table as crashed, select that table. You can select all WordPress tables when the error is broad, but avoid selecting tables from another site.
At the bottom of the table list, choose Repair table from the actions menu. phpMyAdmin will run the repair and report the result.
A visual phpMyAdmin table repair example can be helpful if this is your first time inside the database interface.
Respect storage engine limits
The repair function is most useful for MyISAM tables. Many modern WordPress databases use InnoDB, and REPAIR TABLE may return a message that repair isn’t supported for that engine.
That does not mean your content is gone. It means you need a different path, often a backup restore or help from your host’s database team.
Don’t delete a table because it looks suspicious. A table can appear unfamiliar because a plugin created it. Deleting it can erase plugin settings, orders, forms, or custom content for good.
Use WP-CLI When Server Access Is Available
WP-CLI is fast and practical for developers or site owners with SSH access. It runs from the command line in your WordPress installation folder.
Run the repair command
The command is straightforward:
wp db repair
According to the official WP-CLI database repair documentation, the command uses the database credentials in wp-config.php and runs MySQL’s repair process.
Run it from the correct site directory. On servers with several WordPress installs, working in the wrong folder can repair the wrong database.
Save a command-line backup first
Create a database export before the repair:
wp db export before-repair.sql
Keep that file off-server once it finishes. A local copy gives you a clean rollback point if the repair changes something unexpectedly.
WP-CLI may report individual table results. Read them. A successful command with one unsupported table still needs follow-up.
For many hosting customers, phpMyAdmin is easier than SSH. That’s fine. The safest tool is the one you understand well enough to use carefully.
Restore a Backup When Repair Cannot Save the Site
A repair fixes structural trouble. It does not reverse deleted records, malware changes, or a failed update that wrote bad data across multiple tables.
Choose repair or restore based on the damage
Use this quick guide before taking the next step:
| Situation | Best next move |
|---|---|
| One or two crashed tables | Repair the affected tables |
| Database connection credentials changed | Correct wp-config.php values |
| Several tables report errors after repair | Restore a known-good backup |
| Content disappeared after an update or attack | Restore the cleanest recent backup |
| Database service is unavailable | Contact hosting support |
The difference matters. Repair versus restore guidance is useful when a repair appears to work but the site still has missing or incorrect content.
Restore with a clear recovery point
Pick a backup from before the problem started. If you know the site worked at 9 a.m. and broke after an afternoon update, choose the 9 a.m. restore point.
For ecommerce sites, check recent orders before restoring. You may need to record order details created after the backup, then recreate them after recovery.
A partial restore can work when only the database is damaged. If files, plugins, or themes were also compromised, restore both the WordPress files and the database from the same backup date.
Test the Site Before Calling It Fixed
A homepage that loads is encouraging. It is not the finish line.
Check the pages that matter most
Log in as an administrator. Open a recent post, a page, and the Media Library. Then test the contact form, search, navigation menus, and any member or store functions.
For WooCommerce, add a product to the cart and reach the checkout page without placing a test order. Confirm that customer accounts and recent orders appear correctly in the dashboard.
Clear your caching plugin and server cache after repairs. Cached pages can hide a problem or make a fixed page look broken.
Review errors and site health
Check wp-content/debug.log if WordPress debugging was already enabled. Review your host’s error logs too. Repeated MySQL errors can point to a server problem that needs attention.
WordPress Site Health may flag loopback, REST API, or scheduled task issues after a database failure. Address those one at a time.
Run another backup once the site passes its checks. Your first healthy backup after recovery is worth keeping.
Close the Door on the Original Cause
A repaired database needs protection, not wishful thinking. Sudden server interruptions, failed updates, storage limits, malware, and unreliable plugins can all lead back to the same stressful screen.
Keep updates controlled
Update WordPress, themes, and plugins in manageable batches. Take a backup first, update one major component, then test the site.
Remove plugins and themes you no longer use. Inactive software can still create security and compatibility problems.
Use security scanning to catch malicious changes early. A detailed database repair and security recovery guide explains why cleanup matters when malware may be involved.
Choose hosting built for WordPress workloads
Cheap hosting can look fine until the database is under pressure. Then slow queries, overloaded resources, poor backups, and delayed support become your problem.
ZADiC WordPress Hosting and Web Hosting Plus give small businesses a steadier foundation, with performance-focused hosting, security tools, backups, SSL, and 24/7 human support. You get room to grow without treating every error message like an emergency.
Good hosting doesn’t eliminate every problem. It gives you better recovery options when something breaks. That difference is huge when your site supports real customers and real revenue.
Keep Content Safe During WordPress Database Repair
A careful WordPress database repair starts with a backup and ends with testing. Repair the smallest possible area first, then restore a known-good backup if the damage runs wider.
Don’t rush to delete tables or install random cleanup plugins. Protect the database, identify the failure, use the right repair path, and remove temporary access settings afterward.
Your content is the hard part to rebuild. Treat it like it matters, because it does.
