If you’re seeing a white screen only on certain pages (while the rest of your site loads normally), you’re dealing with one of the most confusing versions of the “WordPress white screen of death.” The good news: when it’s limited to specific URLs, it usually points to something page-specific—like a shortcode, page builder module, template file, cache fragment, or a memory/timeout spike triggered by that page’s content.

This guide walks you through a proven, step-by-step troubleshooting flow—from quickest checks to deeper server-level fixes—so you can narrow down the root cause and restore the affected pages without breaking the rest of your site.

If you’d rather hand this off and get it fixed quickly, WP Fix It has 24/7 WordPress help here: https://www.wpfixit.com/ and you can reach their team directly here: https://www.wpfixit.com/contact-our-wordpress-experts/

What “white screen only on certain pages” usually means

A totally blank page (no error message) is most often caused by:

  • A PHP fatal error that is not being displayed (common when WP_DEBUG_DISPLAY is off)
  • A memory limit issue triggered by a heavy page (large queries, builder layouts, many blocks, big sliders)
  • A plugin conflict that occurs only when a specific shortcode/block/widget runs
  • A theme/template issue tied to a particular page template, custom post type, or conditional logic
  • A caching/minification conflict that breaks rendering for certain routes
  • A corrupt post content (rare, but it happens with malformed block markup or builder JSON)
  • A server rule (WAF/security rule, ModSecurity) triggered only by certain strings or parameters

When the whole site is white, you suspect core/theme meltdown. When it’s white screen only on certain pages, suspect “the thing that runs only on that page.”

Step 0: Confirm it’s truly blank (and not just “looks blank”)

Before changing anything, check:

  1. Open the page in an incognito/private window
  2. Try another browser
  3. Disable browser extensions (ad blockers can sometimes hide output)
  4. View Source (right click → “View Page Source”)
    • If the source is totally empty or stops abruptly, you’re likely dealing with a fatal error.
  5. Check DevTools → Network
    • If you see a 500 status on that page request, it’s almost certainly server/PHP-level.

If you’re getting a 500 on the affected URL(s), jump straight to enabling logs (next section).

Step 1: Turn on WordPress debugging (the fastest way to identify the cause)

Most “blank page” mysteries end the moment you capture the fatal error.

Enable logging (recommended: log to file, don’t show on screen)

In wp-config.php, add or set:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

This writes errors to wp-content/debug.log. WordPress documents these debug options here: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/ and here: https://developer.wordpress.org/advanced-administration/wordpress/wp-config/

Now reload the problem page. Then open:

  • /wp-content/debug.log

What you’re looking for:

  • “Allowed memory size exhausted…”
  • “Call to undefined function…”
  • “Class not found…”
  • “Cannot redeclare…”
  • “Uncaught Error…”
  • “Maximum execution time…”
  • “Fatal error…”

If you do this and the log is still empty, the crash may be happening before WordPress can write (or the server is not letting PHP write to that location). In that case, check server logs (Step 2).

If you want a quick overview of white screen troubleshooting from WP Fix It, these are relevant reads:

Step 2: Check server/PHP error logs (often more reliable than WP logs)

If your host provides a control panel (cPanel, Plesk, etc.), there’s usually an “Errors” section. Otherwise:

  • Apache error log is often in a host-specific location
  • Nginx error log is commonly /var/log/nginx/error.log (varies by server config)
  • PHP-FPM logs depend on pool configuration

PHP’s own documentation explains error logging directives and why some fatal errors won’t appear on-screen even if display_errors is enabled: https://www.php.net/manual/en/errorfunc.configuration.php and guidance on secure error display/logging here: https://www.php.net/manual/en/security.errors.php

If your affected pages are producing a 500, your server error log will usually show the exact fatal error line and file path.

Step 3: The single most common cause: memory exhaustion on “heavier” pages

When it’s white screen only on certain pages, those pages are often the ones that are heavier:

  • A page builder landing page
  • A product category archive loading lots of variations
  • A page with several sliders/videos
  • A complex search/results page
  • A page with a heavy query via a plugin (related posts, filters, faceted search)

WordPress has two memory concepts:

  • WP_MEMORY_LIMIT (front-end)
  • WP_MAX_MEMORY_LIMIT (often used for admin and heavy tasks)

WordPress notes how memory limits work and that WordPress can raise PHP memory if permitted: https://developer.wordpress.org/advanced-administration/performance/php/

Quick fix: raise memory in wp-config.php

Add in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

If the host caps memory_limit in php.ini, you may need to adjust it in hosting settings. After increasing memory, reload the problematic URL(s). If the white screen goes away, you’ve found your primary trigger.

Step 4: Isolate plugins (but do it strategically for “certain pages”)

Deactivating all plugins works, but you can often narrow it faster:

Ask: what is unique about the pages that go white?

Examples:

  • They use a specific shortcode from one plugin
  • They use a specific block (Gutenberg) provided by a plugin
  • They use a template from a plugin (events, LMS, directory, etc.)
  • They use a widget in a sidebar that loads only on those templates
  • They load a filter system only on archive pages

Fast isolation method (safe for partial outages)

  1. Temporarily disable caching/minification plugins first (Step 6 below)
  2. Disable the plugin most closely tied to that page content (builder, slider, filter plugin)
  3. Retest

If you must do the “disable all plugins” approach:

  • Rename wp-content/plugins to plugins_old
  • WordPress will deactivate them all
  • If the page works, restore folder name and re-enable plugins one by one

WP Fix It’s white screen guides cover this workflow too: https://www.wpfixit.com/white-screen-of-death-in-wordpress/

Step 5: Switch the theme (page-template issues are real)

When only certain pages are blank, the theme might still be the cause if:

  • Those pages use a custom page template (e.g., template-landing.php)
  • A template part loads only on that post type
  • A conditional statement loads a broken function only on those routes
  • A child theme override exists for a specific template

Quick test

Temporarily switch to a default theme (like Twenty Twenty-Four). If you can’t access wp-admin, do it by renaming the active theme folder in:

  • wp-content/themes/your-theme → your-theme_old

Then reload the affected page.

If the page works on the default theme, the issue is inside:

  • a template file
  • functions.php
  • a theme “includes” file loaded conditionally
  • a theme builder integration

Step 6: Caching and minification (a sneaky cause of “only certain pages”)

Caching issues often show up selectively:

  • Only one URL is cached with a broken HTML fragment
  • Minification breaks a script loaded only on those pages
  • An optimization plugin delays/defers JS that the builder needs
  • Object cache stores a broken query result for a specific key

What to do

  1. Purge all caches
    • Plugin cache
    • Server cache (host-level)
    • CDN cache (Cloudflare, etc.)
  2. Temporarily disable minification and “combine JS/CSS”
  3. Retest the pages

If disabling minify fixes it, re-enable settings one by one:

  • Start with CSS minify only
  • Then JS minify
  • Then “combine”
  • Then “defer/delay”

This is extremely common with page builders and heavy scripts.

Step 7: Page builder-specific fixes (Elementor, Divi, WPBakery, etc.)

A lot of white screen only on certain pages reports boil down to a builder layout that triggers:

  • memory exhaustion
  • recursion
  • a widget error
  • a broken template import
  • an incompatibility after updates

Try these builder-focused actions

  • Update the builder + its pro/addon plugins
  • Regenerate CSS/data files (many builders have a “Regenerate CSS” or “Sync Library” option)
  • Disable 3rd-party builder addons temporarily (very common culprit)
  • If the page is a template: re-save the template
  • If it’s one page: duplicate the page and test the duplicate
    • If the duplicate works, the original content may be corrupted.

If your debug log mentions a builder widget/class, that’s your smoking gun.

Step 8: Corrupted content, broken blocks, or malformed shortcodes

This is less common, but when it happens it’s maddening: one page crashes PHP because the content is malformed.

Signs:

  • Only one page (or a few) are affected
  • Plugins/themes check out
  • Logs show parsing-related issues or specific block rendering failures

Quick tests

  • Switch the page to “Text/Code editor” view and look for:
    • unclosed shortcodes: [shortcode ...
    • nested shortcodes that don’t make sense
    • broken HTML comments that Gutenberg uses (<!-- wp:... -->)
  • Remove the last content section you added
  • If you have revisions enabled, roll back to a prior revision

If the page renders after removing a block/shortcode, you’ve isolated it.

Step 9: Restore the missing error message (“Critical error” vs white screen)

Newer WordPress versions often display “There has been a critical error on this website,” but sometimes you still just get a blank page depending on server config and error handling.

WP Fix It has a current guide on the “critical error” message and what causes it (plugin conflicts, theme conflicts, server/PHP mismatches, custom code mistakes, etc.): https://www.wpfixit.com/how-to-fix-critical-error-on-this-website/

If your site shows a white page instead of that message, it’s still usually the same root problem—just hidden.

Step 10: Check file permissions (when logs won’t write and pages die silently)

Incorrect permissions can cause strange, partial failures:

  • WordPress can’t write cache files
  • Plugin can’t write generated assets
  • Debug log can’t be created
  • Upload-based assets fail and break builder rendering

Typical safe defaults:

  • Folders: 755
  • Files: 644

If wp-content is not writable where it needs to be, some plugins can fail in unpredictable ways.

Step 11: Security/WAF rules that block certain URLs or content

Sometimes it’s not WordPress “crashing”—it’s a security layer blocking and returning an empty/blank response:

  • Web Application Firewall (WAF)
  • ModSecurity rules
  • Host malware scanner quarantining a file mid-request
  • CDN/WAF blocking a pattern in query strings

Clues:

  • Happens only on pages with certain words (e.g., “select”, “union”, “base64”, “eval” in query strings or form fields)
  • Only happens for logged-out users (or only logged-in)
  • Server logs show “Access denied” or security rule IDs

Fix:

  • Temporarily disable the WAF rule (if you can)
  • Whitelist the affected route
  • Check if a plugin is injecting suspicious strings

If you suspect malware, WP Fix It has malware cleanup resources here: https://www.wpfixit.com/remove-wordpress-malware-and-infections/ and an overview here: https://www.wpfixit.com/wordpress-malware-cleanup-service/ (even if you don’t buy services, the pages outline common infection patterns).

A practical diagnostic flow (printable checklist)

Use this exact order for fastest results:

  1. Confirm it’s a true blank response (DevTools → Network → status 500?)
  2. Enable logging (WP_DEBUG_LOG) and reproduce the white page
  3. Check server error logs for fatal errors (PHP docs on error logging: https://www.php.net/manual/en/security.errors.php)
  4. Increase memory (WP_MEMORY_LIMIT) and retest
  5. Purge caches + disable minify/combine temporarily
  6. Disable the plugin most tied to that page (builder/filter/shortcode provider)
  7. Switch to a default theme to rule out template-specific bugs
  8. Inspect the page content for broken blocks/shortcodes
  9. Consider WAF/security rules if logs don’t match a PHP crash

This flow is designed specifically for white screen only on certain pages so you don’t waste time doing “whole site” fixes that aren’t relevant.

Common log messages and what they mean (quick decoder)

“Allowed memory size exhausted…”

  • Increase memory limits
  • Reduce page complexity (heavy builder layouts, giant galleries)
  • Look for plugins that load huge datasets on that page

“Maximum execution time exceeded…”

  • Increase PHP max execution time
  • Optimize slow queries (common on product/category pages)

“Call to undefined function / Class not found”

  • Plugin update mismatch
  • Autoloader conflict
  • Missing/corrupted plugin file

“Cannot redeclare function…”

  • Two plugins (or theme + plugin) defining same function
  • Conflicting custom snippets

Prevention tips (so it doesn’t come back)

Once you fix the immediate issue, these reduce future “white screen only on certain pages” incidents:

  • Keep WordPress, theme, and plugins updated (but test updates on staging first)
  • Avoid stacking multiple “optimizer” plugins (minify + cache + combine + delay scripts)
  • Limit 3rd-party addons for page builders (they’re a frequent conflict source)
  • Monitor PHP memory usage and raise limits before you hit the ceiling
  • Keep a backup/restore plan (daily at minimum)

When it’s faster to have an expert fix it

If you’ve confirmed a fatal error but it points to a tangle of plugin/theme code (or you’re locked out of wp-admin), it can be quicker to have a WordPress tech resolve it safely—especially when revenue pages are affected.

You can start with WP Fix It’s main site here: https://www.wpfixit.com/ and contact their team here: https://www.wpfixit.com/contact-our-wordpress-experts/
They also have targeted guides worth referencing:

Recap

When you see a white screen only on certain pages, don’t treat it like a whole-site outage. It’s usually triggered by something that runs only on those pages: a shortcode, block, template, builder widget, cache/minify setting, or a memory spike.

Start by capturing the fatal error with WP_DEBUG_LOG, then work through memory, caching, plugin isolation, and template checks. In most cases, you’ll pinpoint the cause in under an hour—often in minutes once logs are enabled.