Skip to content
WPArenaWPArena is a premium online resource site of WordPress and is focused on providing excellent WordPress Tutorials, Guides, Tips, and Collections.
Recovery guideUpdated 11 October 2026

WordPress troubleshooting

WordPress Troubleshooting: Diagnose, Isolate, and Recover

A broken WordPress site is a recovery problem. Record what failed, preserve the data you cannot recreate, then isolate plugins, themes, cache, and the host. Do not start with SEO tips or a random plugin install.

Published
Editorial update

What this page actually checked

A sitewide claim that every product is tested is weaker than the record on the article. Collective bylines stay when the newsroom owns the page. We do not invent named testers to decorate schema.

Responsible
Editorial Staff
Relevant experience
Recovery desk. A broken site is isolated in a safe order, not optimized for SEO first.
Product version in scope
Current WordPress Site Health / troubleshooting mode, not the old standalone Health Check plugin
Facts checked
11 October 2026
Method
Document the error, preserve data, then isolate plugins, themes, cache, and the host. The backup guide is the restore answer.
Limitations
This is not a claim that every symptom was reproduced on a named host in 2026. Compromised sites need security work, not only a plugin toggle.

Calm recovery order

  1. 1.Record the exact error, URL, time, user state, and last known change.
  2. 2.Check whether DNS, TLS, the host, the CDN, and the database are reachable.
  3. 3.Preserve files, database, logs, and current orders before you replace data.
  4. 4.Use recovery mode, staging, or WP-CLI to isolate plugin and theme conflicts.
  5. 5.Verify permalinks, PHP errors, memory, cron, and external services.
  6. 6.Retest the original journey and write down the cause and rollback.

Symptoms

Start from the failure, not a tip list

White screen or 500 error

First: Preserve the site, then check the PHP error log and the latest plugin or theme change.

Then: Disable plugins via recovery mode or by renaming the plugins folder. Switch to a default theme only after you have a backup.

Error establishing a database connection

First: Confirm the database service is up and that wp-config.php credentials match the destination.

Then: This is often a host or cutover problem, not a theme setting. Ask the host if the database is on a different hostname after a migration.

404s on posts or wp-admin paths

First: Visit Settings → Permalinks and save. That flushes rewrite rules.

Then: If the site just moved, also check nginx/Apache rules and the hosts-file or DNS target. See the permalinks guide.

Stale or “still broken” page after a fix

First: Purge the page cache, object cache, CDN, and your browser cache.

Then: A caching plugin can hide a successful fix. WP Rocket and host caches are different layers.

Locked out of wp-admin

First: Use a password reset or a WP-CLI user update from an SSH session you already control.

Then: If the lockout followed a security event, restore from a known-good backup and rotate credentials. Do not keep debugging on a compromised admin.

Safe isolation

Use Site Health or staging before you gut a live store

WordPress Site Health includes troubleshooting mode. That is the current core path for plugin and theme isolation. A default theme such as Twenty Twenty-Five is a diagnostic tool, not a redesign. Enable WP_DEBUG_LOG rather than printing errors on a public page.

If you need to restore, use a tested backup on an isolated destination. Restoring yesterday’s database over a live store can erase today’s orders. The backup guide covers that boundary.

FAQ

Troubleshooting questions

Should I deactivate every plugin on the live site?

Not as the first move on a store or membership site. Prefer Site Health troubleshooting mode, a staging copy, or WP-CLI so visitors are not sent to a half-disabled site. If you must disable plugins on production, take a backup first.

Is the Health Check plugin still the right tool?

WordPress now includes Site Health under Tools → Site Health, including troubleshooting mode. The standalone Health Check plugin has not been a required install since those diagnostics moved into core. Use the core screen first.

When should I call the host instead of editing files?

Call the host for database connection failures, disk-full errors, TLS or DNS problems, and 500s that appear in server logs rather than WordPress debug output.

Does troubleshooting start with SEO settings?

No. A broken site is a recovery problem. Search visibility matters after the site responds, the canonical is correct, and the original user journey works.

WordPress backup plugins

Take an independent copy before you replace files or the database.

How to migrate WordPress

Many “broken site” tickets are incomplete cutovers.

Permalink structure

The actual 404 and rewrite-rule answer.

WordPress security guide

If the site was compromised, recovery is not only a plugin conflict.

WordPress hosting guide

When the failure is resource limits, PHP version, or missing backups.

WP Rocket review

If cache, minify, or delay-JS settings are the suspect.