What you’ll learn

By the end of this lesson you will:

• Think like a troubleshooter: isolate the cause, change one thing at a time, and document.
  
• Use core WordPress tools to gather facts before touching anything.
  
• Capture errors safely to a log (instead of showing them to visitors).
  
• Recover access if a fatal error locks you out of wp-admin.
  

Why the “method” matters

Most WordPress outages come from a small change that introduces a big side effect—an update, a new plugin, a theme tweak, a PHP setting, or a server rule. Guessing makes outages longer. A repeatable method makes them shorter and safer.

Your baseline toolkit (built into WordPress)

1. Site Health (Tools → Site Health)
   Start every investigation with Site Health to see Status (critical issues, recommendations) and Info (server, database, constants, filesystem permissions). It’s a fast way to spot misconfigurations and next steps. WordPress.org

2. Debug logging (never on-screen in production)
   Enable debug logging to capture notices, warnings, and fatal errors to a file you can review:

// wp-config.php (above the "That's all, stop editing!" line)

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_DISPLAY', false ); // keep errors off-screen for visitors

define( 'WP_DEBUG_LOG', true ); // writes to /wp-content/debug.log

This configuration is the recommended pattern for diagnosing issues without exposing errors publicly. Logs are written to /wp-content/debug.log. Turn it off when you’re done. WordPress Developer ResourcesLearn WordPress

1. Recovery Mode (for WSOD/critical errors)
   If WordPress detects a fatal error, it sends a special Recovery Mode link to the site admin email. Use that link to log in to a safe session where the offending plugin/theme is paused, so you can update, replace, or deactivate it—without touching code or taking the whole site down. Make WordPressHostinger

2. Database repair (when you see DB errors)
   If you hit “Error establishing a database connection” or suspect table corruption, WordPress includes a repair script you can temporarily enable:

// wp-config.php

define( 'WP_ALLOW_REPAIR', true );

Visit /wp-admin/maint/repair.php to run Repair or Repair and Optimize. Remove the constant after you finish; the page is intentionally accessible without login to help when you can’t authenticate. Always back up first. WordPress Developer Resources

1. Site Health & object caching hint
   For performance-related troubleshooting, Site Health may suggest enabling a persistent object cache (e.g., Redis/Memcached) when your site would benefit from it. That recommendation is generated by WordPress’s Site Health logic. WordPress Developer Resources

A safe, repeatable workflow

1. Stabilize first. If the front end is down, enable Recovery Mode from the email link or temporarily disable the last change (rename the affected plugin/theme folder via SFTP if needed). Then log the error with WP_DEBUG_LOG. Make WordPressWordPress Developer Resources

2. Gather facts, don’t guess. Check Tools → Site Health (Status & Info). Note PHP version, database server, filesystem permissions, and any critical items WordPress already surfaced. WordPress.org

3. Check the logs. Open /wp-content/debug.log and skim for timestamps matching the incident. Capture the stack trace or function names that appear repeatedly. WordPress Developer Resources

4. Isolate the variable. Reproduce the issue and change one thing at a time (deactivate the suspected plugin, switch to a default theme temporarily, clear caches). Re-test after each change.

5. If errors mention the database, run a backup and (if indicated) the database repair page, then re-test. Remove WP_ALLOW_REPAIR afterward. WordPress Developer Resources

6. Write it down. Note what you observed, what you changed, and the result. This becomes your remediation record and speeds future fixes.

Good habits that prevent escalations

• Keep debugging off-screen in production (WP_DEBUG_DISPLAY false) and turn logging off when finished. WordPress Developer Resources

• Use staging to test updates safely before production (especially major plugin/theme updates).

• Treat Site Health as your pre-checklist before big changes: fix what it flags to reduce surprises. WordPress.org

What’s in the next lesson?

• Lesson 1.2 teaches you to classify symptoms fast (downtime, slow performance, 404/500, WSOD, DB errors) so you can pick the right diagnostic path immediately.

• Module 2 applies the method to real fixes (performance triage, common HTTP/DB errors).

• Module 3 turns your notes into a maintenance routine that prevents repeat incidents.

References

• WordPress Site Health: where to find Status & Info (Tools → Site Health). WordPress.org

• WordPress debugging constants (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY) and behavior. WordPress Developer Resources

• Learn WordPress: built-in debugging options (example configuration). Learn WordPress

• Recovery Mode (fatal error protection; safe admin access with paused extensions). Make WordPressHostinger

• Database repair (WP_ALLOW_REPAIR) and the maintenance endpoint; remove after use. WordPress Developer Resources

• Site Health persistent object cache suggestion logic. WordPress Developer Resources