WordPress white screen after login: why wp-admin goes blank while the rest of the site works

TL;DR: A blank white screen that appears specifically after logging in, while the public-facing site continues to work normally, means the failure is isolated to code that only executes in the admin context, which rules out most theme-related and general server causes and points specifically at a plugin's admin-side functionality, an admin-area-only script conflict, or in rarer cases a user capability/role issue. This is a narrower, faster diagnosis than a site-wide white screen precisely because half of WordPress's codebase, everything that only runs for logged-in admin views, is automatically excluded as a possible cause.

Why isolating "admin only" narrows this significantly

WordPress's public-facing pages and its admin dashboard share the same core and database but run substantially different code paths: the admin area loads its own set of scripts, its own set of plugin hooks (many plugins have functionality that only initializes when is_admin() returns true), and its own admin-specific theme (independent of your site's actual frontend theme). A public site rendering correctly while wp-admin goes blank tells you immediately that the core WordPress installation, the database connection, and your site's actual theme are almost certainly fine, since all three of those are shared between both contexts and a failure in any of them would typically affect the frontend too.

This narrows the search meaningfully compared to a site-wide white screen: the cause lives specifically in admin-context code, which is a smaller and more identifiable set of possibilities.

Step 1: enable debug logging

Since you cannot see any error on the blank white screen itself (which is the defining characteristic of this failure mode, a fatal PHP error occurring with error display turned off, common on production sites for good reason), the first concrete step is making the actual underlying error visible rather than guessing.

If you can access wp-config.php via FTP or your hosting file manager (you do not need working wp-admin access for this), set define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true);, then attempt to log in again and check wp-content/debug.log for the specific fatal error, which will typically name the exact plugin file and line number responsible. This single step usually resolves the majority of the guesswork immediately, turning "the admin area is blank for unknown reasons" into a specific, actionable error message.

Cause 1: a plugin's admin-side code

This is the most common cause by a wide margin. Many plugins include functionality that only loads within the admin context, dashboard widgets, settings pages, admin notices, and a bug or incompatibility in that specific admin-side code (separate from whatever the same plugin does on the frontend, which may be working fine) can produce a fatal error that only manifests once you are logged in and WordPress attempts to load the admin interface.

This is particularly common immediately after a plugin update that changed its admin interface code, or after activating a new plugin whose admin-side initialization conflicts with something else already active. If the debug log points at a specific plugin file, deactivating that plugin (via FTP, by renaming its folder in wp-content/plugins, since you cannot access the admin plugins page to deactivate it normally) typically restores admin access immediately, confirming the cause directly.

Cause 2: a corrupted or conflicting admin-area script

Less common, but a corrupted core WordPress file (from an interrupted update, similar to the maintenance-mode scenario covered in our maintenance mode guide) specifically affecting an admin-area file, rather than a frontend-facing one, can produce this exact symptom: frontend intact, admin broken. Re-uploading a fresh copy of WordPress core files (excluding wp-content and wp-config.php, which contain your actual site data and should not be overwritten) via FTP resolves a corrupted-core-file cause directly.

Cause 3: a user role/capability issue

If the white screen occurs for one specific user account but not others (worth testing if you have multiple admin accounts, or if you can create a fresh one via database access as a diagnostic step), this points toward a role or capability problem specific to that account rather than a site-wide plugin conflict. This can happen after a role-management plugin misconfigures a specific user's capabilities, or after a manual database edit that leaves a user's role reference pointing at something no longer correctly defined, causing an admin-area check that expects certain capabilities to fail unexpectedly for that account specifically.

Cause 4: a caching plugin caching the admin area incorrectly

Similar to the nonce-related caching issue covered in our nonce error guide, a caching plugin or CDN misconfigured to cache admin-area requests, which should always be excluded from caching, can occasionally serve a broken or partial cached admin page instead of a fresh one, producing an intermittent blank screen that may not correlate cleanly with any specific plugin or user account, since it depends on cache state rather than a consistent underlying code issue.

Recovering access via safe mode or FTP

If the debug log points at a specific plugin and you need admin access restored quickly, renaming that plugin's folder within wp-content/plugins via FTP (adding any character to the folder name, which WordPress treats as effectively deactivating it since it can no longer find the plugin's main file at its expected path) is the fastest recovery method without needing working admin access at all. Some current WordPress versions also include a built-in "recovery mode" that emails a special login link allowing access with problematic plugins automatically paused, worth checking your admin email (and spam folder) for if a fatal error occurred, since WordPress core has built increasing resilience for exactly this scenario in more recent versions.

A diagnostic table

Symptom	Likely cause	Fix
Blank on all admin accounts, debug log points to a specific plugin	Plugin admin-side code error	Deactivate that plugin via FTP
Blank on all accounts, debug log shows a core file error	Corrupted core file	Re-upload fresh WordPress core files
Blank only for one specific user account	Role/capability issue for that account	Check that user's role assignment, or create a fresh admin user via database if needed
Blank intermittently, no consistent plugin correlation	Caching plugin/CDN caching admin area	Exclude wp-admin from all caching
Debug log shows nothing useful	Error display/logging misconfigured, or a non-PHP failure	Check server error logs directly (not just WordPress's own log)

FAQs

The frontend works but every admin account shows a blank screen. Does that rule out a role issue?

Yes, if every admin account is affected identically, a role/capability issue specific to one account is unlikely to be the cause; this pattern points more strongly at a plugin or core file issue affecting the admin context universally rather than anything account-specific.

I don't have FTP access, only hosting control panel file manager. Does the same fix apply?

Yes, the underlying fix (accessing wp-config.php and the plugins folder directly at the file system level, bypassing the broken admin interface) works identically through a hosting control panel's file manager as it does through FTP; the specific tool does not matter, only that you can reach the site's files directly without going through wp-admin itself.

Can a theme cause an admin-only white screen, given themes are usually frontend-focused?

Less commonly than a plugin, since a site's actual theme mostly governs frontend rendering, but some themes include admin-side functionality (custom dashboard widgets, theme options pages, onboarding wizards) that can fail in the same way plugin admin code can; if deactivating all plugins does not resolve the issue, switching to a default WordPress theme temporarily as an additional isolation step is worth trying.

Is WordPress's recovery mode email always sent when this happens?

Not always; it depends on the WordPress version and whether the specific type of fatal error is one the built-in fatal error protection mechanism successfully catches and reports on, which has improved over successive WordPress versions but does not cover every possible failure scenario, so checking for the recovery email is worth doing but should not be your only recovery plan.

How do I create a fresh admin user if I'm locked out and can't access wp-admin at all?

This requires direct database access (via phpMyAdmin or a similar tool through your hosting control panel), where you can either modify an existing user's role directly in the wp_usermeta table, or in more involved cases, insert a new administrator user directly into the wp_users and wp_usermeta tables; this is more advanced and worth doing carefully or with support from your host if you are not comfortable with direct database editing.

Does raising the PHP memory limit ever fix this, similar to the memory exhaustion error?

If the underlying cause happens to be a memory exhaustion fatal error specifically occurring only in the admin context (which is plausible, since the admin area often has higher memory demands than the frontend), then yes, this is effectively the same fix as covered in our memory exhausted error guide; the debug log will show explicitly if this is the specific error type versus a different kind of fatal error from a plugin conflict.

Will this happen again after I fix it once?

Not from the same specific cause once resolved, but the underlying category of issue (a plugin update introducing an admin-side bug) can recur with different plugins over time; keeping plugins updated promptly and testing significant updates on a staging site first, where available, reduces how often this specific failure mode recurs going forward.

Conclusion

An admin-only white screen is a narrower diagnostic problem than a site-wide failure, since the working frontend already rules out core WordPress, the database, and your actual theme as likely causes, pointing specifically at admin-context plugin code, a corrupted admin-specific core file, a role/capability issue, or admin-area caching misconfiguration. Enabling debug logging and checking wp-content/debug.log turns this from a guessing exercise into a specific, actionable error in most cases.

If a specific plugin's admin code is the cause, deactivating it via FTP (bypassing the broken admin interface entirely) is the fastest path back to a working dashboard, after which you can investigate an update or alternative for that specific plugin with working admin access restored.

HostCloud's managed WordPress hosting includes file manager access that lets you recover from exactly this scenario without needing FTP client software, and our support team can help trace a specific admin-area fatal error if the debug log alone isn't enough. Plans start at ₹99 a month at https://hostcloud.in.