Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →If /wp-admin loads but your public pages do not, WordPress itself is only partly healthy. The dashboard can work while front-end PHP execution, a theme, a plugin, rewrite rules, or the web server fails. Use the dashboard to collect evidence first, then isolate the failing component before changing several settings at once.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The safest order is: record Site Health information, reproduce the exact public error, use Recovery Mode when offered, isolate plugins and the theme, refresh permalinks for 404s, inspect logs, and send a complete evidence package to your host when the problem is below WordPress.
As an Amazon Associate I earn from qualifying purchases.
Why wp-admin can work while the site is down
The administration area and the public site do not execute exactly the same requests. A login page may complete successfully while a visitor request invokes a broken template, a fatal plugin hook, a failed database call, or a web-server rule that never affects the dashboard.
A working dashboard therefore does not prove that front-end PHP execution, theme rendering, pretty-permalink rules, filesystem permissions, PHP extensions, or the web-server configuration are healthy. Treat the two observations separately: “I can log in” is useful evidence, not a diagnosis.
What the visible symptom tells you
- Blank or white page: PHP or database errors may be occurring without being displayed. WordPress documentation notes that both types of errors can appear as a blank screen.
- “There has been a critical error on this website”: a fatal PHP error is usually associated with a plugin, theme, or custom code.
- HTTP 500: the server or PHP process rejected the request; a fatal error, limit, permission problem, or server configuration issue is possible.
- HTTP 404 on existing pages: rewrite rules or the web-server module that applies them may be wrong, even though the homepage or dashboard works.
- Redirect loop: URL, HTTPS, proxy, or plugin redirect logic may be conflicting.
- Timeout: the PHP process, database, external request, or host may be taking too long to finish.
- Missing styles or scripts: the HTML may load while asset URLs, HTTPS handling, permissions, or a theme enqueue fails.
Collect evidence before changing settings
1. Export Site Health information
In the dashboard, open Tools > Site Health. The Status view checks overall health, update state, PHP and software requirements, and configuration errors. Open the Info tab and use its export function before you alter plugins, themes, or server settings.
The Info report can show the server architecture, PHP variables, cURL support, pretty-permalink status, the .htaccess rules WordPress can see, filesystem permissions, active and inactive plugins, and installed themes. Save the export with the date and keep it available for your host or developer. Remove secrets before sharing it publicly; server reports can contain paths, environment details, or other sensitive values.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →2. Reproduce the public failure
Open the public URL in a private browser window, or use a browser in which you are not logged in. Record the complete URL, the date and time in the site’s time zone, and the exact result. Capture whether the failure is a blank page, critical-error notice, 500, 404, redirect loop, timeout, or page with missing styles.
Test the homepage and one known working inner URL. If only one route fails, note that route exactly; a single template or rewrite rule may be involved. Do not refresh repeatedly while a host is investigating a timeout or resource limit, because a burst of requests can obscure the original event in the logs.
Use Recovery Mode when WordPress offers it
WordPress introduced Recovery Mode in version 5.2. When WordPress detects a fatal error and can identify the component, it can send an administrator a recovery link or show a link on the error screen. Enter Recovery Mode from that link while you are logged in.
Recovery Mode pauses the faulty plugin or theme for your administrator session and displays an error notice naming the component. This lets you reach the dashboard without making a site-wide change. Open the notice, update or correct the named component, and test the public URL in a separate private window. When the fix is complete, exit Recovery Mode and test again as a normal visitor.
If the same error returns after leaving Recovery Mode, the component is still incompatible, another component is involved, or the underlying server problem has not been fixed. Do not assume that a successful Recovery Mode session means every visitor request is healthy.
Isolate plugins and themes
Plugin and theme isolation is the quickest practical way to identify many white-screen and critical-error causes. Change one category at a time and test after each change so that the result is attributable.
Deactivate plugins from the dashboard
- Go to Plugins > Installed Plugins.
- Select all plugins, choose Deactivate, and apply the bulk action.
- Open the public homepage and the failing URL in a private window.
- If the site now loads, reactivate plugins individually, testing after each activation.
- When the failure returns, leave the last plugin inactive and record its name and version. Check for an update or contact its developer with the exact error and timestamp.
Deactivation normally preserves a plugin’s settings, but it can temporarily remove features such as caching, forms, redirects, or security checks. Tell your host which components you disabled so a log entry is not mistaken for permanent configuration.
Switch to an installed default theme
If all plugins are inactive and the front end is still broken, activate an installed default WordPress theme under Appearance > Themes. A newly activated or incompatible theme can produce the same white screen or fatal error as a plugin.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Test the homepage and the failing URL. If the default theme works, the original theme or its custom code is implicated. Keep the default theme active while you update or repair the original; do not edit production theme files until you have a recoverable copy.
When neither isolation test changes the result
A failure that survives all plugins and a default theme points more strongly to rewrite rules, PHP limits or extensions, permissions, a database or web-server error, or code outside the normal plugin and theme load. Move to the logs and server checks rather than repeatedly toggling extensions.
Rank #3
Repair 404s and broken pretty URLs
For existing posts, pages, or custom URLs that return 404 while the dashboard works, first regenerate WordPress’s rewrite rules:
- Open Settings > Permalinks.
- Leave the selected permalink structure unchanged.
- Click Save Changes, even if you did not edit the setting.
- Test the homepage and several previously failing URLs in a private window.
Saving this screen rebuilds the rewrite rules WordPress uses for pretty URLs. It is reversible and does not require changing the visible permalink choice.
Free tools Windows power users keep installed
One-click scans. No signup required.
If 404s persist, inspect the .htaccess rules shown in Tools > Site Health > Info and verify that the Apache mod_rewrite module is available when the site runs on Apache. A host may need to correct the file or enable the module; do not paste a rule set from an unrelated server configuration.
When only one custom post type or one language path fails, record its exact URL and compare it with a normal post URL. That distinction helps a developer decide whether the problem is a rewrite rule, registration code, or a single content route.
Read PHP and web-server logs safely
Logs provide stronger evidence than a generic browser message. Check the PHP error log and the web-server error log for entries at the timestamp you recorded. Look for the first fatal error, uncaught exception, memory or execution-limit message, missing PHP extension, permission denial, or rewrite failure. The first relevant entry is usually more useful than a later cascade of errors.
If you need additional WordPress logging, enable WP_DEBUG only in a controlled, non-public way. A typical temporary configuration is:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchdefine( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );With display disabled, visitors do not see stack traces or filesystem paths. Restrict access to the resulting log, reproduce the problem once, copy the relevant excerpt, and turn debugging back off after diagnosis. Never leave raw debug output visible on a public site.
If the host controls PHP or the web server, you may not have permission to change logging or limits. Ask support to inspect the logs for the exact URL and timestamp rather than sending only a screenshot of the browser.
If wp-admin becomes unavailable during testing
You can deactivate plugins without dashboard access by using SFTP, FTP, or the hosting provider’s file manager. This method preserves plugin settings while preventing WordPress from loading the plugin directory.
- Connect to the site files and locate
wp-content. - Rename the
pluginsdirectory, for example toplugins.off. - Request the public URL again. If it loads, a plugin is responsible or involved.
- Rename the directory back to
pluginsafter the test, then restore plugins in a controlled manner. If the dashboard is still inaccessible, leave the directory renamed long enough for your host or developer to inspect the logs.
Use the same SFTP/FTP access to move or rename the active theme when you need to test a theme and cannot enter the dashboard. Keep a record of every filename change and reverse it after the test. Avoid deleting files: isolation should be temporary and reversible.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsCheck loopback requests and scheduled work
WordPress uses loopback requests for tasks such as scheduled posts, cron jobs, and some Site Health checks. A failed loopback can leave publishing or background processing broken even when ordinary page requests appear normal.
If Site Health reports a failed loopback or scheduled tasks are not running, first isolate plugins. Redirect, caching, security, and HTTP-request plugins can block a request back to the same site. If the warning remains, move or rename the active theme through SFTP/FTP as a test. Give your host the loopback error text, URL if shown, and timestamp so it can check firewall, DNS, SSL, or PHP restrictions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Know when the problem belongs to the host
Some fixes cannot be completed from WordPress. Hosting providers may control PHP memory and execution limits, required PHP extensions, web-server modules, filesystem ownership and permissions, and the error logs. Site Health can identify a requirement or configuration concern without granting you permission to change it.
Escalate when the failure persists with all plugins inactive and a default theme, when permalinks still return 404 after saving and the rewrite configuration looks wrong, when logs show a PHP extension or permission error, or when requests time out before WordPress can respond. Include:
- the complete public URL and one failing path;
- the timestamp and time zone of a fresh reproduction;
- the exact HTTP status or browser message;
- the exported Site Health Info report, with secrets removed;
- the relevant PHP or web-server log excerpt; and
- the isolation steps already performed, including whether plugins and the theme were tested.
This package lets support distinguish a WordPress component from a server-level fault without asking you to repeat the same tests.
Choose the least disruptive diagnostic option
| Action | Access required | Best symptom match | Reversibility | Evidence produced |
|---|---|---|---|---|
| Export Site Health Info | wp-admin | Any front-end failure | Read-only | Server, PHP, permalink, permission, plugin, and theme details |
| Enter Recovery Mode | wp-admin and a WordPress recovery link | Critical error or fatal component | Temporary pause for the admin session | Named plugin or theme and its error notice |
| Deactivate plugins one at a time | wp-admin | Blank page or critical error | Temporary; settings remain | The activation that reproduces the failure |
| Activate an installed default theme | wp-admin | Blank page or fatal theme error | Temporary theme switch | Whether the active theme is implicated |
| Save Settings > Permalinks | wp-admin | 404 on existing pretty URLs | Rebuilds rules without changing the selected structure | Whether WordPress rewrite regeneration resolves the route |
Rename wp-content/plugins |
SFTP, FTP, or host file manager | wp-admin unavailable | Temporary filename change | Whether all plugins are involved |
| Inspect or change PHP, modules, and permissions | Host support may be required | 500, timeout, persistent 404, or log-reported server fault | Depends on the host change | Server logs and configuration confirmation |
Symptom-specific decision paths
Blank page with no message
Record the timestamp, export Site Health, and inspect logs. Enter Recovery Mode if WordPress provides a link. Otherwise deactivate plugins, then switch to a default theme. If neither changes the blank page, investigate PHP and database logs, memory or execution limits, permissions, and server configuration.
Critical-error notice
Use the supplied Recovery Mode link first because it can identify and pause the fatal component for your session. Update or repair the named component, retest outside Recovery Mode, and then investigate other plugins or the theme if the error returns.
404 on pages that exist
Save Settings > Permalinks, test again, and then inspect .htaccess and Apache mod_rewrite when necessary. If the site uses a different web server, ask the host to verify that server’s equivalent rewrite configuration rather than assuming Apache rules apply.
Recommended Free Tools
HTTP 500 or timeout
Use the exact timestamp and URL to find the server and PHP log entry. Test plugins and the theme from the dashboard if possible. Persistent 500 responses or timeouts after isolation usually require the host to inspect PHP limits, extensions, worker capacity, permissions, or web-server errors.
Missing CSS or JavaScript
Check whether the document itself returns successfully and whether asset requests fail with their own statuses. Record one missing asset URL for the developer. A theme, HTTPS or redirect rule, filesystem permission, or server configuration can affect assets even when the main HTML request works.
How to finish the repair without creating a second outage
- Keep the Site Health export and original error details so you can compare the result after each change.
- Apply one change at a time and retest both the homepage and the originally failing URL while logged out.
- When a plugin or theme is identified, update it only after confirming that the update addresses the compatibility problem; otherwise keep it isolated and contact its developer.
- Restore temporary directory names, the original theme, and normal debugging settings only after the public site works.
- Ask the host to confirm any PHP, module, permission, or rewrite change and to provide the corresponding log entry.
The key distinction is between a WordPress component you can isolate and an infrastructure fault you cannot safely repair from wp-admin. A functioning dashboard gives you the access needed to gather that evidence; it is not proof that the visitor-facing application is healthy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
