How to Remove the Whitelabel Error Page

Two completely different problems share this name, and people arrive here from both.

• Spring Boot shows a page literally titled "Whitelabel Error Page" — that is Spring's built-in fallback when no error page is defined.
• WordPress shows a completely blank white screen, usually called the white screen of death.

Both are covered below. Jump to the one you have.

Part 1: Spring Boot

The Whitelabel Error Page appears when a request fails and no error page has been configured. It is doing its job — you are seeing the default because nothing else was provided.

First, find out what actually broke

The page usually shows a status code. That tells you which problem you have:

Always read the application console first. The browser hides the exception; the console has it.

Fix 1: A proper error page

The simplest solution, and the right one for most applications. Create src/main/resources/templates/error.html:

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>Something went wrong</title>
</head>
<body>
    <h1>Something went wrong</h1>
    <p th:text="${status} + ' ' + ${error}"></p>
    <a href="/">Back to the home page</a>
</body>
</html>

Spring Boot picks this up automatically. No configuration needed.

For plain static pages without a template engine, use src/main/resources/static/error/404.html and 500.html.

Fix 2: A controller, for APIs

If you are building an API, an HTML page is the wrong answer — the caller wants JSON:

import org.springframework.boot.web.servlet.error.ErrorController;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import jakarta.servlet.RequestDispatcher;
import jakarta.servlet.http.HttpServletRequest;
import java.util.Map;

@RestController
public class ApiErrorController implements ErrorController {

    @RequestMapping("/error")
    public ResponseEntity<Map<String, Object>> handleError(HttpServletRequest request) {
        Object statusObj = request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
        int status = statusObj != null ? Integer.parseInt(statusObj.toString()) : 500;

        return ResponseEntity.status(status).body(Map.of(
            "status", status,
            "error", HttpStatus.valueOf(status).getReasonPhrase(),
            "path", String.valueOf(request.getAttribute(RequestDispatcher.ERROR_REQUEST_URI))
        ));
    }
}

Fix 3: Turn it off entirely

In application.properties:

server.error.whitelabel.enabled=false

This hides the page, it does not fix anything. You now get a bare container error instead. Only use this if you are providing your own handler.

See the real error while developing

server.error.include-message=always
server.error.include-stacktrace=on_param
server.error.include-binding-errors=always

Remove these before production. Stack traces tell an attacker your framework versions, file paths and class names.

Why a 404 on a controller you definitely wrote

Nearly always component scanning. Spring Boot only scans the package containing your main application class, and its sub-packages.

com.example.myapp          ← MyAppApplication.java
com.example.myapp.web      ← found
com.example.controllers    ← NOT found

Move the controller under your main package, or add @ComponentScan with the extra package listed.

Part 2: WordPress white screen

A blank white page with no message means PHP hit a fatal error and error display is switched off.

Step 1: See the actual error

Do this before changing anything. Edit wp-config.php and add above the "stop editing" line:

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

Reload the page, then read wp-content/debug.log. It names the exact file and line.

WP_DEBUG_DISPLAY stays false so visitors do not see the error while you work.

Step 2: Disable plugins

Plugins cause most white screens. If you can still reach wp-admin, deactivate them all, then reactivate one at a time.

Locked out? Rename the folder over FTP or SSH:

mv wp-content/plugins wp-content/plugins-off

If the site comes back, rename it back and move plugins out one at a time until you find the culprit.

Step 3: Switch theme

mv wp-content/themes/yourtheme wp-content/themes/yourtheme-off

WordPress falls back to a default theme. If that fixes it, the theme is at fault — usually after an update, or a PHP version change.

Step 4: Raise the memory limit

A white screen with nothing in the log is often memory exhaustion:

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

If that does nothing, PHP itself is capped lower — raise memory_limit in php.ini or through cPanel.

Step 5: PHP version mismatch

Very common after a host upgrades PHP. An old plugin using removed syntax dies instantly.

The debug log shows something like "syntax error, unexpected". Switch PHP back a version in cPanel to confirm, then update or replace the plugin — do not leave it on old PHP permanently, because it stops receiving security fixes.

Step 6: Corrupted core files

Rare, but it happens after a failed update. Download a fresh copy of WordPress and replace wp-admin and wp-includes only.

Do not touch wp-content or wp-config.php — those hold your site.

Quick reference

How to avoid it next time

• Use a staging copy. Test updates there, not on the live site.
• Back up before updating anything.
• Update one plugin at a time when something is fragile, so you know which one broke it.
• Keep WP_DEBUG_LOG available but with display off, so the next error is already recorded.
• Watch PHP version announcements from your host and test before they switch.

Where to go next

• Install WordPress on your own server — full log access makes this far easier
• Speed up WordPress
• Move to a host with a better PHP setup