The WordPress troubleshooting order

Why a set order works

WordPress failures share the same ingredients: files, a database, a cache, and code running through hooks. When the site breaks, people tend to fix the last thing they touched, and that is the wrong instinct because several silent layers (cached pages, a half-applied update, a plugin's stale transients) can mask the real cause. A strict order turns the mystery into a sequence with an exit point after every step. Do the checks in this exact order, and the step that stops making a difference is the one that owns the outage.

The order

1. Read the truth first: WP_DEBUG. Start by making the error visible on a copy. In wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WP_DEBUG_DISPLAY false keeps visitors safe while the log captures wp-content/debug.log. If the log is empty, the event skipped PHP, so the web server and PHP error logs are the next read. The order stays: prove the error before touching anything.

1. Check the obvious external culprits. Site URL mismatch, DNS, stale cache, and an active maintenance marker change behavior before any code does. Each is a one-line check:

1. Isolate plugins and theme. Disable every plugin at once (wp plugin deactivate --all, or rename the plugins folder), then the theme, and restore each in halves. The detail lives in isolating a plugin that breaks the site. If the page recovers in a plain state and breaks again when the full set returns, the cause is code, not cache.
2. Rule out runtime boundaries. If the site fails only on wp-admin, or only on a specific post type, confirm the memory limit (WP_MEMORY_LIMIT) and the upload size are not the actual gate; the memory-limit article shows the safe way to check.
3. Clear caches at the point where they can fool you, not first. Caches hide errors and eat debugging time, but they also preserve a working state. The order clears them only after the code world is closed, so a stale cached page does not mask the real answer.
4. Repair the database as the final, deliberate step. After files and plugins are clean, run:

wp db repair

or use phpMyAdmin to check tables, then the optimization growth. Do not run repair as step one: a repair while a plugin half-write is still in progress can compound damage. Database backups cover this in the cleanup tutorial.

Keeping the log as a habit

Turn on the quiet version in production permanently (WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false) and rotate the file so it stays small. Then the next outage starts with the first page of the story in the log, and the order above plus the last lines of debug.log is usually enough.