If you can sign in to /wp-admin but visitors see a blank page, critical-error notice, 404, redirect loop, timeout, or unstyled page, WordPress itself is only partially healthy. The dashboard can load while front-end PHP, the active theme, a plugin, rewrite rules, or server configuration fails. Start with Tools > Site Health, record the exact public error, then isolate plugins and the theme before changing server settings. The sequence below lets you identify the failing layer while preserving a path to undo each change.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Why wp-admin can work while the public site is broken
The administration area and the public site do not execute exactly the same requests. A login may reach a working WordPress core and database while a home page request also loads the active theme, front-end plugins, template files, rewrite rules, stylesheets, and additional PHP code. A failure in any of those layers can affect visitors without preventing an administrator from logging in.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
A dashboard that loads therefore does not prove that front-end PHP execution, theme rendering, pretty-permalink rules, filesystem access, or the web server is healthy. WordPress documentation describes a fatal error as something often caused by a plugin, theme, or custom code that prevents normal login or site operation; when only front-end code reaches the failing path, wp-admin may remain usable.
Do not immediately reinstall WordPress or edit files at random. First capture evidence, then make one reversible change at a time. That preserves the clue that identifies the fault and gives your host or developer useful information if the problem is outside WordPress.
Capture evidence before changing settings
1. Export Site Health information
- Sign in and open Tools > Site Health.
- Read the Status screen for critical and recommended issues, update state, PHP requirements, and configuration errors.
- Open the Info tab and use its copy or export function to save the report.
- Keep the export unchanged. It can show server architecture, PHP variables, cURL support, pretty-permalink status, the rules WordPress sees in
.htaccess, filesystem permissions, installed plugins, and themes.
WordPress says the Site Health feature helps ensure that a website gets and stays healthy. Treat its report as a baseline: save it before deactivating anything, and save a second copy after a fix so the difference is visible.
2. Reproduce the public failure privately
Open the affected URL in a private or incognito window, while logged out. Record the complete URL, UTC date and time, and the exact result. Useful categories are:
Recommended Free Tools
- A completely blank or white page.
- A message saying there has been a critical error.
- HTTP 500 or another server error.
- HTTP 404 on the home page, posts, or selected paths.
- A redirect loop or a request that times out.
- HTML that loads but has missing styles or scripts.
Test the home page and one known post or page. If only certain URLs fail, note their pattern; that points toward a template or rewrite rule rather than a site-wide outage.
Use the error message and Recovery Mode first
When Recovery Mode is offered
WordPress introduced Recovery Mode in version 5.2. When WordPress detects a fatal component and offers a recovery link, follow that link and authenticate. Recovery Mode pauses the faulty plugin or theme for your administrator session and displays an error notice naming the component and, where available, the file or line involved. Visitors may still see the failure while you investigate, because the pause is tied to the recovery session.
- Enter Recovery Mode from the link WordPress provides.
- Read the notice and identify the named plugin, theme, or extension.
- Update it if a compatible update is available, or deactivate it from the notice or the Plugins/Themes screen.
- Exit Recovery Mode, open a fresh private window, and test the same URLs.
- If the error returns after exit, keep the component deactivated and continue with the isolation steps below.
Do not delete the named component before preserving its settings and confirming that it is the cause. A fatal message identifies the failing execution path, not necessarily the permanent remedy; an update, rollback, replacement, or configuration change may be safer than removal.
Isolate plugins without losing their settings
Deactivate all plugins from wp-admin
If no component is named, plugin compatibility is a common white-screen and critical-error cause. Go to Plugins > Installed Plugins, select all plugins, choose Deactivate, and apply the action. This is a temporary diagnostic state; deactivation normally preserves each plugin’s stored settings.
Open the public URL in the private window again. If it now works, the core, database, and active theme can render the tested request without the plugins. Reactivate plugins one at a time, testing the same URL after each activation. The plugin whose activation brings back the failure is your primary suspect. Leave it deactivated while checking its version compatibility, recent changes, configuration, and support documentation.
Interpret an inconclusive test
- If the site remains broken with every plugin deactivated, plugins are not the only cause; continue to theme, rewrite, log, and server checks.
- If the home page works but a feature page fails when one plugin is reactivated, test the plugin’s shortcodes, widgets, blocks, or custom endpoints separately.
- If two plugins are individually harmless but fail together, reactivate them in different orders and inspect logs for a shared PHP function, memory limit, or request conflict.
Do not reactivate everything at once. That removes the evidence you just collected and makes the next failure ambiguous.
Switch to a default theme to test rendering
If plugin isolation does not restore the front end, activate an installed default WordPress theme from Appearance > Themes. A newly activated, incompatible, or damaged theme can produce a white screen or fatal error even though the dashboard remains accessible.
- Confirm that a default theme is installed before switching.
- Activate it temporarily; do not delete the current theme.
- Test the home page, a post, and a page that previously failed.
- Restore the original theme only after recording whether the default theme changed the result.
If the default theme works, review the original theme’s recent updates, custom code, template overrides, required plugins, and PHP compatibility. If the default theme fails in the same way, the cause is more likely a rewrite problem, server limit, extension, permission, or database-level error than theme presentation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Repair 404s and broken pretty URLs
Save the permalink settings
A dashboard can work while Apache or another web server has stale or missing rewrite rules. For a 404 on posts, pages, categories, or other pretty URLs, open Settings > Permalinks and click Save Changes without changing the structure. WordPress regenerates its rewrite rules during the save.
Test the home page and a previously failing pretty URL in a private window. Do not assume that a successful save proves the server accepted the rules; it only confirms that WordPress attempted to write them.
If saving permalinks does not fix the 404
- In Tools > Site Health > Info, inspect the pretty-permalink and
.htaccessdetails. - On Apache hosting, ask whether
mod_rewriteis enabled and permitted for the site directory. - Check that the web server is reading the intended
.htaccessfile and that filesystem permissions allow WordPress to write or the host to read it. - Provide the host with one failing URL and one URL that works, rather than only reporting that “the site is down.”
Do not overwrite .htaccess with a rule set copied from an unrelated installation. Preserve the current file first and have the host confirm the server type and document root.
Distinguish missing styles, redirects, timeouts, and server errors
HTML loads but the design is missing
When text appears but styles or scripts do not, inspect the page source or browser network panel for the exact asset URLs and status codes. A theme or optimization plugin may be generating incorrect paths, while a URL or HTTPS mismatch can cause assets to be blocked. Temporarily isolate plugins and switch to a default theme as above; the change that restores the assets identifies the layer to investigate.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchRedirect loop
A loop usually involves conflicting URL or HTTPS handling between WordPress, a plugin, and the web server. Record the URL that loops and stop after a few redirects rather than repeatedly refreshing. Disable recently changed redirect or security plugins, test with a default theme if necessary, and ask the host to check server-level redirects and proxy settings.
Timeout or HTTP 500
A timeout can indicate a long-running PHP request, a blocked loopback, or a host resource limit. An HTTP 500 generally requires the PHP or web-server error log to identify the failing process. Capture the timestamp and status code, then correlate it with the log instead of repeatedly submitting the request.
Read logs and enable debugging safely
Review the PHP error log and the web-server error log for entries at the time you reproduced the failure. Look for the component name, file path, line number, memory or execution-time message, permission denial, and upstream or rewrite error. A log excerpt containing the first relevant error is more useful than an entire unfiltered log.
WordPress notes that both PHP and database errors can manifest as a white or blank screen. If the normal logs do not identify the cause, enable WP_DEBUG only in a controlled, non-public way and turn it off after collecting the evidence. Debug output can disclose file paths, queries, credentials in poorly written extensions, or other sensitive information; never leave verbose errors visible to visitors.
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 →- Back up the relevant configuration before changing debug settings.
- Enable logging without displaying errors publicly, using your host’s documented method.
- Reproduce the failure once, record the timestamp, and read the resulting entry.
- Restore the prior setting and remove or protect any log that contains sensitive data.
If you cannot safely change the setting, ask the host to enable temporary server-side logging and provide only the public URL and reproduction time.
Check loopbacks when scheduled work fails
WordPress uses loopback HTTP requests for scheduled posts, cron tasks, some editor checks, and parts of Site Health. A failed loopback can leave the public site apparently normal while scheduled work is unreliable, or it can expose a firewall, DNS, SSL, authentication, or plugin problem.
If Site Health reports failed loopbacks or scheduled tasks are not running:
- Record the exact loopback warning in the Site Health export.
- Isolate plugins and test again; security, caching, and maintenance plugins are common places to investigate.
- If the warning persists, move or rename the active theme temporarily through SFTP/FTP and retest.
- Ask the host to check whether the server can connect to its own domain and whether a firewall, proxy, DNS record, or TLS certificate blocks the request.
Do not treat a loopback warning as proof that every front-end error has the same cause. Use it as a separate symptom and correlate it with logs and URL tests.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What to do when wp-admin stops working
If a diagnostic change makes the dashboard unavailable, use SFTP, FTP, or your host’s file manager. WordPress documents renaming wp-content/plugins as a way to deactivate all plugins while preserving their settings.
- Connect to the site files and locate
wp-content. - Rename
pluginsto a temporary name such asplugins.disabled. - Try wp-admin and the public URL again.
- If the site returns, restore the folder name and deactivate or remove the offending plugin from the dashboard one at a time.
- If renaming the folder changes nothing, restore its original name before testing the theme or other files.
Use the same reversible principle for a theme: rename the active theme directory only after confirming that a default theme is installed, or ask the host to switch the theme in the database. Never rename or delete core directories as a first diagnostic step.
Know which fix fits the symptom
| Action | Access required | Best match | Reversibility | Evidence produced |
|---|---|---|---|---|
| Site Health Status and Info export | wp-admin | Any front-end failure; baseline collection | Read-only | Checks, server details, permissions, plugins, themes, and rewrite information |
| Recovery Mode | wp-admin plus WordPress recovery link | Named fatal plugin or theme | Session-level pause; component can be reactivated | Error notice identifying the failing component |
| Deactivate plugins, then reactivate individually | wp-admin | Blank page or critical error with no named cause | Temporary; settings preserved | Activation that reproduces the failure |
| Switch to a default theme | wp-admin | Theme-rendering white screen or fatal error | Temporary | Whether the front end works without the custom theme |
| Save Settings > Permalinks | wp-admin | 404s on pretty URLs | Configuration change that can be changed again | Whether WordPress can regenerate rewrite rules |
| Rename the plugins folder | SFTP, FTP, or host file manager | wp-admin unavailable | Temporary; restore the folder name | Whether all plugins are responsible |
| PHP and web-server log review | Hosting panel or host support | HTTP 500, timeout, permission, or module errors | Read-only | Server-side error at the reproduction time |
Escalate limits, extensions, permissions, and modules
Some failures cannot be corrected from WordPress. Site Health can reveal PHP variables, cURL and filesystem details, but the host may control PHP memory or execution limits, required extensions, web-server modules, document-root permissions, and security policies. A failed rewrite, denied file operation, missing PHP extension, or exhausted resource limit needs provider-level access.
Send support a compact evidence package:
- The exact public URL and a second URL that works, if available.
- UTC timestamp of a fresh reproduction and the observed HTTP status or message.
- The exported Site Health Info report.
- The relevant PHP or web-server log excerpt, with secrets removed.
- Which plugins were deactivated, whether a default theme was tested, and whether saving permalinks changed anything.
Ask the provider to verify the PHP version and limits, required extensions, web-server modules such as Apache’s rewrite support where applicable, filesystem ownership and permissions, SSL and DNS routing, and loopback connectivity. This is more actionable than requesting a generic “WordPress reset.”
A disciplined recovery order
Use this checklist when you need a single runbook:
- Open the public URL privately and classify the symptom.
- Export Tools > Site Health > Info and record Status warnings.
- Use Recovery Mode if WordPress supplies a link naming a fatal component.
- Otherwise deactivate all plugins, test, and reactivate them one by one.
- Switch to an installed default theme if plugins are not responsible.
- For 404s, save Settings > Permalinks, then inspect rewrite and
.htaccessinformation. - Correlate the timestamp with PHP and web-server logs; use controlled debugging only.
- Check loopbacks separately if Site Health or scheduled tasks report them.
- If wp-admin is unavailable, rename
wp-content/pluginsthrough SFTP/FTP or the host file manager. - Escalate host-controlled limits, extensions, modules, permissions, and network behavior with the evidence package.
At each step, test the same URLs, note the result, and undo changes that do not provide useful evidence. This keeps a working dashboard available for further diagnosis and avoids turning a front-end outage into an administration outage.
Quick Recap
Prevent the next front-end outage
- Keep a current backup and know how to restore both files and the database before updates.
- After updating a plugin, theme, PHP version, or server configuration, test the home page, a post, a page, and a logged-out private window.
- Review Site Health periodically and export the Info report when a warning first appears, not only after a failure.
- Keep at least one default theme installed so a theme failure has a safe comparison.
- Document the host’s PHP limits, log locations, SFTP access, and escalation contact.
- Remove temporary debug output and restore normal plugin/theme activation only after the public URLs remain stable.
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.
