Fix It: The Diagnosis Order for Any WordPress Problem
Most WordPress troubleshooting advice is a list of things to try. A list is slow, because it has no order. What follows is an order, arranged so the cheapest checks that eliminate the most possibilities come first.
The short version
- See the actual error before changing anything.
- Establish what changed. Something always did.
- Bisect: plugins, then theme, then core.
- Only then start editing configuration.
Step 1: see the real error
Everything after this is guesswork without it.
// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Reload, then read wp-content/debug.log. Also check the server error log, which catches failures that happen before PHP runs:
tail -50 ~/logs/error_log
tail -50 /var/log/nginx/error.log
And the browser console, which catches everything that fails after the HTML arrives.
Watch out
Keep WP_DEBUG_DISPLAY false on a live site. Errors shown to visitors disclose file paths and sometimes database details.
Step 2: establish what changed
Sites do not break spontaneously. Work backwards:
- What did you update, install or edit most recently?
- Did the host change the PHP version?
- Did an SSL certificate renew or expire?
- Did a scheduled task run for the first time?
- Did traffic spike?
- Did a licence or a DNS record expire?
Check file modification times, which often answer this directly:
find . -type f -mtime -3 -not -path './wp-content/cache/*' -ls | head -30
Step 3: is it caching?
Before investigating code, confirm you are even looking at the current page:
curl -s "https://example.com/?nocache=$(date +%s)" | head -40
Test in a private window, logged out. A surprising share of “broken site” reports are a cached copy of a problem that was already fixed.
Step 4: bisect
In this order, because each step eliminates more than the last:
- All plugins off.
mv wp-content/plugins wp-content/plugins-off. If it works, move them back one at a time. - Default theme. Rename the active theme’s folder to force a fallback. If it works, the theme is the cause.
- Replace core.
wp core download --force. Leaves wp-config.php and wp-content alone. - Check must-use plugins.
ls -la wp-content/mu-plugins/. These load silently and are frequently forgotten.
Step 5: the symptom-to-cause table
| Symptom | Start with |
|---|---|
| Blank white page | Debug log, then plugins |
| 500 error | Server error log, then .htaccess |
| Database connection error | wp-config credentials, then DB_HOST |
| Redirect loop | curl -sIL to see the chain |
| 404 on everything but home | Permalinks, then rewrite rules |
| No styling | Browser console, then site URL |
| Slow admin, fast front end | Autoloaded options, then Query Monitor |
| Scheduled things not happening | WP-Cron |
| Email not arriving | SMTP, then SPF and DKIM |
| Changes not appearing | All six cache layers |
| Upload failures | Disk space, then permissions, then inodes |
Step 6: only now change configuration
Memory limits, execution time, permissions, PHP version. These are real fixes, and changing them before you understand the problem turns a diagnosis into a guess. Change one thing at a time and re-test between each.
What to have ready before trouble
- SFTP or SSH access, tested.
- Database credentials, known.
- A backup from before today, downloaded.
- Your host’s support channel, known.
- A second administrator account with a different email address.
Every recovery route in this cluster depends on filesystem access. If you do not have it, sort that out before you need it.
The whole cluster
Each of these starts from a specific symptom:
- Blank page, 500 error, database connection error
- Redirect loops, both site-wide and wp-admin only
- Memory exhausted, upload failures, HTTP error on images
- 404s on everything but the homepage, missing CSS
- Cron not firing, missed schedules, email not sending
- Caching, slow admin, missing media and menus
Common questions
What if nothing here finds it?
Then it is server-side and your host needs to look at their logs. Give them the exact time and URL.
Should I restore a backup first?
Only if you have a clean one from minutes before and the site is losing money. Otherwise diagnose first — a restore hides the cause and it recurs.
How long should this take?
With the debug log on, most problems are identified within twenty minutes. If you have spent an hour and have no error message, you skipped step one.
Sumit
Writes everything on TechMozz.