WordPress

Your pages can look fine while the part behind them is broken. When the login page fails, nobody can update the site or handle orders. And some WordPress files tell strangers more than they should.

What WP Moo looks at

The login page. Does it still show the login form? We find it ourselves at the usual addresses, like /wp-login.php, /login or /admin.
The REST API (/wp-json/), which the block editor, WooCommerce and many plugins use to talk to WordPress. One that only answers logged-in users still counts as working.
debug.log, the WordPress error log, which nobody should be able to download.
readme.html, which tells bots the site runs WordPress.

These are plain page visits, once an hour unless you pick a slower schedule. When you add a site, its login page is also checked as a page, every 30 minutes for a Critical site up to every 4 hours for Low (see Adding a site). A login page behind a password is fine: we note that it's protected and leave it alone. When the whole site fails, your page checks report it, not this check. When a firewall or security plugin blocks our checker on the login page or the REST API, we leave that part alone too.

The REST API is only judged once it has answered us properly. Until then, and on any run we leave it alone, the WordPress card on the site overview says "REST API not checked".

What the problems mean

The login page is broken Urgent Open the login page yourself. A PHP error usually names the plugin or theme that broke it; switch that off.

The REST API doesn't answer Important Check whether a security plugin or a server rule switched the REST API off. Locking it for logged-out visitors is fine, switching it off completely is not.

Anyone can download debug.log Important Delete the file and set WP_DEBUG_LOG to false in wp-config.php, or ask your host to block access to .log files.

Readme.html can be opened Notice Block readme.html with a security plugin or a server rule. Deleting it helps only until the next WordPress update puts it back.

Out of the box: Urgent when the login page breaks · Important when the REST API stops or debug.log is public · Notice for readme.html. What each priority means: Problem priority.

How to fix it

The login page is broken

Open it yourself. The error usually names the plugin or theme that broke it. Switch that plugin off with the recovery link WordPress emails to the admin address, or send this page to your developer.

The REST API doesn't answer

A security plugin or a server rule usually switched it off. Locking it for logged-out visitors is fine; switching it off completely is not.

debug.log or readme.html can be opened

Delete wp-content/debug.log in your hosting panel's file manager, then set WP_DEBUG_LOG to false in wp-config.php so WordPress doesn't write a new one. Block readme.html with a security plugin or a server rule: deleting it only helps until the next WordPress update puts it back.

We can't find your login page

Did a plugin such as WPS Hide Login move it? Open Checks & pages and enter its address under Login address in the WordPress check, like /my-login.

For your developer

Each run asks for the login page (all of /wp-login.php, /login, /inloggen, /admin and /beheer until one is found or you entered one), the home page, the first 16,384 bytes of /wp-json/ and the first 1,024 bytes of /wp-content/debug.log (both with a Range header), and /readme.html. For a login page at /folder/wp-login.php, the last three are asked for in /folder. To see what we see:

curl -sL -A 'WPMooBot/1.0 (+https://wp-moo.com/bot)' -o /dev/null -w '%{http_code}\n' https://example.com/wp-login.php
curl -sL -A 'WPMooBot/1.0 (+https://wp-moo.com/bot)' -r 0-16383 https://example.com/wp-json/
curl -sL -A 'WPMooBot/1.0 (+https://wp-moo.com/bot)' -r 0-1023 https://example.com/wp-content/debug.log

The login page is found when it answers 200 with id="loginform" or a pwd field, on the site's own host and not on the home page. A 404 or a blank page without the form is no problem yet: we look for the login page again on the next run, and the card asks for the address if we can't find it. It is broken when it shows a database, critical or PHP error page, or gives no answer or a 5xx on two runs in a row. A 401 or 403 at /wp-login.php or at the address we know, that isn't WordPress's own error page, counts as protected and isn't judged.

The REST API works on a 2xx, 401 or 403 with JSON, and is judged only after it answered like that once at the same address. After that, any other answer, like a 404 or an HTML page, counts on the second run in a row, and a database, critical or PHP error page counts right away. A 401 or 403 without JSON, a block page, WordPress installing updates, or a login page or home page that fails leaves it unjudged.

debug.log is public on a 200 or 206 with a line starting with PHP's log timestamp ([02-Nov-2026 10:00:00) in the first kilobyte, also after a redirect that kept the path and the host, with or without www. readme.html is public on a 200 with WordPress's own logo (wp-admin/images/wordpress-logo.png) in it, under the same redirect rule. Both keep what the last run found when they get no answer, a 5xx or a block page. To block both files on nginx (for WordPress in a folder, add the folder to the pattern):

location ~* ^/(readme\.html|wp-content/debug\.log)$ { deny all; }

Something unclear on this page? Email [email protected]