iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If /wp-admin opens but visitors see a blank page, critical-error notice, 404, redirect loop, timeout, or unstyled page, WordPress itself is only partly healthy. The dashboard can load while front-end PHP, the active theme, a plugin, rewrite rules, or the web server fails. Start with Tools > Site Health, record the exact public error, and export the Info report. Then isolate plugins and the theme, refresh permalinks, inspect logs, and involve your host for PHP, permissions, extensions, or server-module problems.
Why wp-admin can work when the public site is broken
The administration area and the public site do not execute exactly the same request path. A login request can reach the database and load the dashboard even when a front-end request invokes a faulty template, a plugin hook, a missing PHP extension, or a rewrite rule that never reaches WordPress.
Recommended Free Tools
Common explanations include:
- A fatal PHP error in a plugin, theme, or custom code. The dashboard may still load if the failing code runs only on front-end requests.
- Theme rendering failure. A newly changed or incompatible theme can fail while the administrator interface remains usable.
- Broken rewrite rules. WordPress can serve the dashboard URL while posts and pages return HTTP 404 errors.
- Web-server or PHP configuration problems. PHP limits, required extensions, filesystem permissions, or Apache modules can affect public requests.
- Loopback or HTTP-request failures. Scheduled jobs and Site Health checks may fail even though a browser can reach the login page.
- Cache, redirect, or CDN behavior. A stale or misdirected cache can make the public result differ from an authenticated administrator session.
Do not assume that a successful login proves the installation is sound. Treat the dashboard as a valuable diagnostic foothold, not as proof that every request path works.
First response: capture evidence before changing anything
Changing several settings at once makes the cause harder to identify. Capture the symptom and the environment first, preferably while the failure is occurring.
- Open the public URL in a private browser window or a browser in which you are logged out. This avoids administrator cookies and cached responses.
- Write down the complete URL, including the path that failed, and the UTC date and time of the test.
- Record exactly what appears: a blank page, “There has been a critical error,” HTTP 500, HTTP 404, a redirect loop, a timeout, or a page without styles.
- Try the home page and one known post or page. A home page that works while individual URLs fail points more strongly to rewrite or permalink rules.
- Take a screenshot or copy the browser’s visible error. Do not replace the original error with a generic maintenance page before recording it.
Keep this evidence for your host or developer. A URL, timestamp, status code, and log excerpt can distinguish an application error from a web-server failure much faster than a description such as “the site is down.”
Use Site Health as the first diagnostic report
In the dashboard, go to Tools > Site Health. The Status tab checks overall health, update state, PHP and software requirements, and configuration errors. The Info tab exposes details that are difficult to infer from the front end, including server architecture, PHP variables, cURL, pretty-permalink support, the .htaccess rules WordPress can see, filesystem permissions, installed plugins, and themes.
Free tools Windows power users keep installed
One-click scans. No signup required.
Export the Info report
- Open Tools > Site Health > Info.
- Review the sections for WordPress, server, database, PHP, active plugins, active theme, and filesystem permissions.
- Use the report’s copy or export control to save the diagnostics before editing settings.
- Redact passwords, API keys, database credentials, private paths, and other secrets before sending the report to anyone.
Site Health was added in WordPress 5.2. Its purpose is to reveal update, configuration, and environment problems that may not be visible on the dashboard home screen. Pay particular attention to warnings about loopback requests, REST API access, PHP versions or limits, writable directories, and pretty permalinks.
Match the symptom to the safest next test
| Symptom | Best first test | Access needed | What the result tells you | Reversibility |
|---|---|---|---|---|
| Blank page or critical-error message | Recovery Mode, then plugin and theme isolation | wp-admin | A named component or a controlled deactivate/reactivate test identifies a likely fatal error | High; components can be reactivated |
| HTTP 404 on posts or pages | Settings > Permalinks, then Save Changes | wp-admin | Regenerates WordPress rewrite rules; persistent failures point to server rewrites or .htaccess | High |
| HTTP 500 or timeout | Review PHP and web-server logs; check Site Health limits and loopbacks | wp-admin, then host support | Server logs can identify memory, timeout, module, permission, or fatal-PHP causes | Depends on the server change |
| Missing styles or scripts | Test logged out, inspect the generated URL, and check HTTPS, cache, and theme/plugin output | wp-admin; sometimes host/CDN access | Separates asset URL, mixed-content, cache, and theme-rendering faults | Usually high |
| Failed scheduled tasks or loopback checks | Isolate plugins and test the active theme through SFTP if needed | wp-admin or SFTP/FTP | Shows whether the site can make HTTP requests back to itself | High when renamed temporarily |
Choose one controlled test at a time. A visible error notice is stronger evidence than a guess; a Site Health result is useful corroboration; and a timestamped server log is usually the most decisive evidence for HTTP 500 and timeout failures.
Recover from a white screen or critical error
Use Recovery Mode when WordPress offers it
WordPress introduced Recovery Mode in version 5.2. When WordPress detects a fatal error, it may send the site administrator a recovery link or display a link on the error screen. Follow that link and sign in. Recovery Mode pauses the faulty plugin or theme for your administrator session and shows an error notice identifying the component that failed.
- Open the Recovery Mode link while it is valid and log in.
- Read the notice carefully; note the plugin or theme name, file, line number, and error message.
- Update the named component if a compatible update is available, or deactivate it temporarily.
- If the failure began immediately after an update, restore the previous known-good version only if you have a trustworthy backup and understand the security trade-off.
- Exit Recovery Mode and test the public URL in a private window. A component paused only for your session may still fail for visitors until it is fixed or deactivated normally.
A fatal error is often caused by a plugin, theme, or custom code and can prevent normal site operation. Do not edit a vendor file blindly from the error line; first confirm compatibility, PHP requirements, and whether another component supplied the function or class that is missing.
Deactivate all plugins from the dashboard
If no component is named, use a controlled isolation test. Go to Plugins > Installed Plugins, select all plugins, choose Deactivate, and apply the action. Open the public site in a private window.
- If the site works, reactivate plugins one at a time, testing the same failing URL after each activation.
- When the failure returns, the last plugin activated is a strong suspect. Check its compatibility, settings, PHP requirements, and recent update history.
- If the site remains broken with every plugin inactive, leave them inactive while testing the theme; otherwise you will lose a clean baseline.
Plugin compatibility is a common white-screen cause. Deactivation normally preserves each plugin’s settings, so you can reactivate it after diagnosis. Do not delete a plugin as a first test; deletion may remove data or configuration that is useful for recovery.
Switch temporarily to an installed default theme
If plugins are not responsible, go to Appearance > Themes and activate an installed WordPress default theme. Test the same front-end URLs.
- If the default theme works, the previous theme, its child theme, or theme-specific custom code is implicated.
- Compare the theme’s stated WordPress and PHP requirements with the current environment shown in Site Health.
- Check recent edits to
functions.php, template files, and custom snippets. A syntax error or call to an unavailable function can stop front-end rendering.
Keep the default theme active only as long as needed for diagnosis if its appearance is unsuitable. Restore the original theme after correcting the cause and retest logged out.
Rank #3
Fix 404 errors and broken pretty permalinks
A dashboard that loads while every post or page returns 404 is often suffering from stale rewrite rules rather than missing content.
- Go to Settings > Permalinks.
- Note the current permalink structure; do not change it unless you intend to change every public URL.
- Click Save Changes, even if no option appears to have changed. WordPress regenerates its rewrite rules.
- Open the home page, a known post, a page, and an archive in a private window.
If that repairs the URLs, no further change may be needed. If not, inspect the .htaccess rules reported in Tools > Site Health > Info and verify that the web server is actually using them.
When saving permalinks does not help
- On Apache, confirm that
mod_rewriteis enabled and that the virtual host permits overrides for the WordPress directory. - Confirm that the WordPress rewrite block has not been removed, placed in the wrong directory, or made unreadable by permissions.
- On a different web-server stack, ask the host how equivalent rewrite rules are configured; do not paste Apache directives into an incompatible configuration.
- Check whether a security, cache, or redirect rule is intercepting only certain paths.
Ask the host to verify the effective server configuration if you do not control it. A dashboard user cannot repair a disabled server module or a virtual-host rule from WordPress settings alone.
Investigate HTTP 500 errors, timeouts, and server limits
HTTP 500 responses and timeouts usually need log evidence. Review the PHP error log and the web-server error log for entries at the exact time you recorded. Look for fatal errors, out-of-memory messages, maximum execution-time messages, permission denials, missing extensions, upstream timeouts, and failed database connections.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows 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 reinstallEnable debugging safely
If logs do not identify the problem, WordPress debugging can add detail. Enable WP_DEBUG only in a controlled, non-public way, such as logging to a file while suppressing on-screen display:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Place these definitions according to your host’s documented WordPress configuration process, reproduce the failure once, then inspect the log and turn debugging off when finished. Public debug output can disclose filesystem paths, SQL details, function names, and other sensitive information. Never leave error display enabled on a production site.
Check environment requirements
Site Health and the exported Info report can show PHP variables, cURL availability, filesystem permissions, and server details. Compare those values with the requirements of WordPress, the active theme, and the suspect plugin. A low memory limit, short execution timeout, unavailable PHP extension, incompatible PHP version, or unwritable directory may require a host-level change rather than an admin setting.
Do not repeatedly raise limits without evidence. A memory error may reflect a runaway plugin or theme query; increasing the limit can hide the symptom while making the server less stable. First identify the request and component named by the log.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What to do if wp-admin becomes unavailable
If a plugin change locks you out of the dashboard, use SFTP, FTP, or the hosting file manager. Keep a backup of the current names before changing them.
- Connect to the WordPress installation’s document root.
- Open
wp-content. - Rename
pluginsto a temporary name such asplugins.off. This makes WordPress treat all plugins as inactive while preserving their files and settings. - Test the public site and attempt to sign in.
- If access returns, create a new empty
pluginsdirectory if WordPress requires it, then restore the original directory name after you have a plan for reactivating plugins individually.
Renaming the directory is a diagnostic measure, not a permanent fix. Once the culprit is found, update, replace, or remove it using a supported process. If the site remains broken with plugins unavailable, repeat the isolation idea for the active theme by renaming its directory only after confirming that another installed theme can serve as a fallback.
File names and paths are case-sensitive on many servers. Rename only the intended directory, and do not alter the WordPress core directories while troubleshooting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check loopbacks, cron, and REST-related failures
WordPress uses loopback requests to contact itself for scheduled tasks and other internal operations. A site can render a page in your browser while loopbacks fail because of authentication, DNS, firewall, SSL, redirect, or server-timeout rules.
- In Tools > Site Health > Status, note any failed loopback or REST API tests.
- Check whether scheduled posts, background updates, or cron-driven tasks are also failing.
- Deactivate plugins and test the active theme as described above; security, caching, HTTP-authentication, and redirect plugins are frequent sources of self-request failures.
- If the dashboard remains available but the loopback warning persists, give the host the Site Health result, the failing URL if shown, and the timestamp.
Do not dismiss a loopback warning merely because the home page opens. It can explain delayed publishing, missed maintenance tasks, and update failures that are not visible in a normal browser test.
Use a repeatable isolation workflow
When the first test does not identify the cause, use a binary, reversible workflow rather than changing everything.
- Establish a baseline: test logged out, capture the status and URL, export Site Health Info, and note active versions.
- Remove one class of code: use Recovery Mode, deactivate all plugins, or switch to a default theme.
- Retest the identical request: use the same browser state and URL so the comparison is meaningful.
- Narrow the cause: reactivate plugins one at a time or restore the theme after confirming plugins are not responsible.
- Confirm: reproduce the failure once more after the suspected change, then test several page types.
- Apply the durable fix: update, replace, reconfigure, or remove the component, or ask the host to change the server setting identified by the evidence.
- Clean up: turn off debugging, restore intended plugin and theme states, clear only the relevant caches, and retest as a visitor.
This sequence preserves evidence and makes each result interpretable. If several components are changed between tests, you cannot tell which change repaired or caused the behavior.
When to contact the hosting provider
Escalate when the evidence points below WordPress’s control or when an outage affects production traffic. Hosting support may need to change PHP limits, enable extensions, load web-server modules, correct virtual-host rewrites, repair filesystem ownership or permissions, inspect upstream timeouts, or read logs unavailable to your account.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Send a concise incident packet:
- The public URL and one or two failing paths.
- UTC timestamps and the exact HTTP status or browser message.
- The exported Site Health Info report with secrets removed.
- The relevant PHP or web-server log excerpt, including the first error and surrounding lines.
- What you tested: Recovery Mode, all plugins inactive, a default theme, and saving permalinks.
- Whether the issue affects logged-in administrators, logged-out visitors, or both.
Ask the provider to confirm the active PHP version, required extensions, memory and execution limits, rewrite-module status, effective .htaccess or virtual-host rules, filesystem ownership, and whether firewall, DNS, SSL, or rate-limit rules are blocking loopback requests. This is more actionable than requesting a generic “restart.”
Quick Recap
Common mistakes that prolong the outage
- Testing while logged in only: administrator cookies and cache bypasses can hide a visitor-facing failure.
- Deleting before isolating: deletion can remove settings or data needed to identify the cause.
- Editing .htaccess without a backup: one syntax error can turn a 404 problem into a 500 error. Save the original first.
- Leaving debug output public: error messages can expose private implementation details.
- Changing permalinks repeatedly: repeated changes can create new URL and redirect confusion. Save the existing structure, refresh it once, then inspect rewrites.
- Assuming a 404 means content was deleted: test rewrite rules and the exact URL before restoring backups.
- Raising PHP limits blindly: confirm the logged failure and component first.
- Clearing every cache immediately: preserve the original response and timestamp; clear the relevant page or object cache only after recording evidence.
- Updating many components during an outage: batch updates destroy the before-and-after comparison and may introduce a second incompatibility.
Prevent a repeat incident
- Keep WordPress core, themes, and plugins supported and update them in a staging environment or during a monitored maintenance window.
- Maintain tested backups of both the database and
wp-content; verify that a restoration is usable rather than assuming a backup exists. - Know how to access SFTP or the host file manager before an emergency, and record the document-root path.
- Monitor the public home page and representative content URL from outside your login session.
- Review Site Health regularly, especially after PHP, theme, plugin, DNS, SSL, or server changes.
- Keep a short change log with the time, component, version, and setting changed. It often reveals the trigger immediately.
- Use least-privilege accounts and remove temporary debug files, recovery links, and exported reports after they are no longer needed.
A concise decision path
- If you see a named fatal component, use Recovery Mode and fix that component.
- If the error is blank or critical with no name, deactivate all plugins, then test a default theme.
- If only content URLs are 404, save Settings > Permalinks; then verify rewrite support and
.htaccess. - If the response is 500 or times out, read PHP and web-server logs and check Site Health limits and permissions.
- If scheduled tasks or loopbacks fail, isolate plugins and the theme, then ask the host to check self-request restrictions.
- If wp-admin fails, rename
wp-content/pluginsthrough SFTP/FTP to regain a clean test state. - If the evidence points to PHP, extensions, modules, permissions, or virtual-host configuration, provide the incident packet to the hosting provider.
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.
