Your WordPress site is throwing database errors, the admin panel is sluggish, and you’re already Googling hosting companies. Stop. Before you panic-migrate everything, there’s a built-in tool most people never touch: the WordPress database repair screen. It’s hidden, it’s ugly, and it works more often than you’d think.
This isn’t some plugin trick. It’s core WordPress functionality that’s been sitting there for years, quietly waiting for you to type the right URL. Let’s walk through how to repair the WordPress database without touching a single line of SQL, and when that approach is actually the wrong move.
How to Access the WordPress Database Repair Tool
Forget the dashboard menu. There’s no button for this. You access it by manually appending /wp-admin/maint/repair.php to your site’s URL. So if your site is yoursite.com, you go to yoursite.com/wp-admin/maint/repair.php.
You need to be logged in as an administrator. If you’re not, WordPress will bounce you to the login screen first, and then bring you back. That’s it. No plugin installation, no FTP, no cPanel diving.
Once you’re there, you’ll see a stripped-down page with two buttons that look like they were designed in 2008. They were. One says Repair Database, the other says Repair and Optimize Database.
Repair vs. Repair and Optimize: Which One Do You Actually Need?
Here’s where most tutorials get vague and useless. Let me be blunt about the difference.
Repair Database runs a MySQL REPAIR TABLE command on every table in your WordPress installation. It fixes corrupted indexes, broken table structures, and crashed tables. This is what you want when you’re seeing errors like «Table ‘./database/wp_options’ is marked as crashed and should be repaired.»
Repair and Optimize Database does all of the above, but also runs OPTIMIZE TABLE, which defragments the physical storage. It reclaims wasted space from deleted posts, revisions, and transient options. On a bloated site with thousands of post revisions, this can shave real time off your queries.
My take: if you’re troubleshooting an actual error, use the plain repair first. Optimize is maintenance, not emergency medicine. Running optimize on a massive database during peak traffic hours can lock tables and cause the exact downtime you’re trying to avoid. Do it at 3 AM or on a staging copy.
Back Up Your Database Before You Touch Anything
I don’t care how confident you are. Repair operations write directly to your tables. If something goes sideways mid-process, you want a rollback point. Period.
Use a plugin like UpdraftPlus, WPvivid, or All-in-One WP Migration to export a full database dump. Or, if you have SSH or cPanel access, run a quick mysqldump. It takes two minutes and saves you from a very bad afternoon.
Also: deactivate your plugins before running the repair. Not because the repair tool will break them, but because a broken plugin is often what caused the corruption in the first place. Deactivate everything, repair, then reactivate one by one and watch for the culprit. It’s tedious. It’s also how you find the actual problem instead of just patching symptoms.
Common Errors and How to Get Past Them
If the repair page times out or throws a fatal error halfway through, your PHP memory limit is probably getting choked. You can bump it in wp-config.php:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
Add that line above the /* That’s all, stop editing! */ marker. After the repair finishes, remove that line. Leaving a 256M memory limit in place on a shared host that only allocates 128M can cause weird cascading failures later. I’ve seen it happen.
If repair runs clean but your site is still broken, the problem isn’t table corruption. It’s data-level. Now you’re into phpMyAdmin territory, where you can inspect specific tables, look for orphaned rows in wp_postmeta, or check whether wp_options has a bloated autoloaded payload. That’s a different job. Don’t just randomly run repair commands in phpMyAdmin and hope for the best.
Prevention Beats Repair Every Single Time
The WordPress database repair tool is a bandage. It’s a good bandage, but you don’t want to need it weekly.
The biggest hidden killer of WordPress databases in 2026 is post revisions and autoloaded options. Every time you hit save on a post, WordPress stores a revision. Thousands of revisions later, your wp_posts table is drowning. Limit revisions in wp-config.php with define(‘WP_POST_REVISIONS’, 5); and watch your database breathe again.
Second: audit your plugins. Every plugin that writes to wp_options with autoload set to «yes» adds weight to every single page load. Query your database for autoloaded options and see what’s hogging space. You’ll be shocked. Some themes and page builders dump megabytes of serialized data into autoload without ever cleaning up.
Third: keep WordPress core, themes, and plugins updated. Not because updates are magic, but because the security patches close the doors that attackers use to inject malicious code into your tables. A hack can trigger database errors that look identical to corruption, so rule that out before you start repairing tables.
