Your WordPress site just crashed, white screen, database error, or a plugin conflict that took the whole thing down. You don’t need a developer to fix most of these. Here’s the real playbook I use when a WordPress site breaks, no fluff, no «it depends.»
Repairing WordPress is mostly about isolating the cause fast. The WordPress repair process isn’t magic, it’s a sequence of checks that eliminate suspects one by one until the site loads again. If you skip the diagnosis and start randomly updating things, you’ll make it worse.
Before You Touch Anything: Back Up WordPress
I’ll say it bluntly: if you start repairing WordPress without a backup, you’re gambling. A broken site can usually be recovered; a site you overwrote with no backup is gone. So the first move is always a full backup of files and database.
The lazy but effective way is a plugin. UpdraftPlus, Jetpack, or BackWPup all work. Install one, set a schedule, and push the backup to remote storage like Google Drive or Dropbox, not just your own server. If the server dies, a backup stored on that same server is useless.
If you prefer manual control, do it via FTP and phpMyAdmin. Download the entire WordPress folder, then export the database to a .sql file. Keep both in a folder you can actually find later. I’ve seen people make backups they couldn’t locate when things went south, that’s the same as having none.
Check PHP Errors: The Real Diagnostic Tool
When WordPress shows a white screen or a fatal error, the answer is almost always in the PHP error log. Most hosting panels (cPanel, Plesk) have a section for this. If not, you’ll need FTP or SSH access.
To turn on proper logging, edit wp-config.php and add these lines right before the «stop editing» comment:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
@ini_set(‘display_errors’, 0);
This writes errors to a file called debug.log inside /wp-content/. That file tells you exactly which plugin, theme, or line of code is breaking. Fixing WordPress without reading this log is guessing. Once fixed, set WP_DEBUG back to false or you’ll fill your server with junk logs.
Plugin and Theme Conflicts: The Usual Suspect
Nine out of ten WordPress repairs I do end up being a plugin conflict. The method is simple and non-negotiable:
- Deactivate all plugins from the dashboard (or rename the plugins folder via FTP if the dashboard is unreachable).
- Reload the site. If it works, the problem is a plugin.
- Reactivate them one by one, reloading after each. The moment it breaks, you’ve found the culprit.
If deactivating every plugin doesn’t fix it, switch to a default theme like Twenty Twenty-Five. If the site comes back, your theme is the problem. At that point, contact the developer with specifics: what you did, what error appeared, what you already ruled out. Vague reports get vague help.
Reset File and Folder Permissions
Wrong permissions cause upload failures, plugin install errors, and sometimes a full lockout. WordPress has a standard: files at 644, folders at 755. Anything at 777 is a security hole waiting to be exploited.
Connect via FTP with something like FileZilla, select the WordPress root, right-click, and choose File Permissions. Set 644 for files, 755 for folders, and tick Recurse into subdirectories so it applies everywhere. Apply to files and folders separately. After that, reload the site and check if the error’s gone.
Update WordPress Core, But Do It Right
Outdated WordPress versions are a magnet for exploits and bugs that have already been patched. But updating a broken site blindly is a rookie move. Backup first, then update.
Do minor updates automatically, but for major version jumps (like 6.x to 7.x), test on a staging site first. Hosts like SiteGround, Kinsta, and WP Engine offer one-click staging. If your host doesn’t, install WP Staging and test there before pushing live. I’ve watched people update core on a Friday afternoon and lose a weekend rebuilding.
When to Stop DIY and Call for Help
There’s a point where repairing WordPress yourself costs more than hiring someone. If the database is corrupted, if you’re seeing SQL errors you don’t understand, or if the site was hacked and files are injected with malicious code, stop. A WordPress developer or a security service like Sucuri will save you hours and probably your reputation.
The honest truth: most WordPress repair jobs are backups, plugin isolation, and permission fixes. Master those three and you’ll fix 80% of breakages on your own. The other 20% deserve a professional, and pretending otherwise is how small problems become catastrophes.
