How the check works

WP Front Door looks at a WordPress site the way a stranger would: from outside, logged out, with ordinary requests. This page covers exactly what it asks for, what it refuses to do and what it cannot see.

The five requests

Every request is a GET, sent with the user agent WPFrontDoor/1.0 (+https://hamzaahmadaslam.com/work/wp-front-door) so a site owner can see who asked. It never logs in, never tries a password and never submits a form.

The address you gave: the page itself: its HTML, response headers, redirects and time to first byte
/wp-json/: whether the REST API answers, which helps confirm WordPress
/wp-json/wp/v2/users?per_page=1: whether account names are listed to visitors
/xmlrpc.php: whether the XML-RPC endpoint answers
/readme.html: whether the stock readme names the version

Each request gets 8 seconds and reads at most 1.5 MB. Redirects are followed one hop at a time, five at most. The checker runs on Vercel, currently in its Washington, D.C. region, which is where the first-byte time is measured from.

Addresses it will not check

Only http and https addresses on the standard ports, with no user name or password in them and no .local host names.

Before anything is fetched, the host name is looked up and refused if it points at a private, loopback or link-local address. The same check runs again inside the connection's own lookup, so a name that changes its answer between the two cannot slip through. Each redirect is checked the same way, which stops a public site bouncing the checker into a private network.

One address can run ten checks a minute, and one site can be checked twenty times in ten minutes. Both limits count per server instance.

What it cannot see

Anything behind a login: the dashboard, members' pages, a store's account pages.
Plugin versions and known vulnerabilities. It sees plugin folder names in the page's file paths, and plugins that load no files on the page stay invisible.
Other pages. It reads the one address you give, so a slow product page or a heavy blog post needs its own check.
What visitors experience in the browser. There is no rendering, no image weight and no Core Web Vitals, only the HTML and the first byte.
Speed from where your visitors are. Every request comes from one place, so distance to your host is part of the first-byte time.
A warm cache. It asks once, so a page that was just purged can miss. Run the check a second time before trusting a cache miss.

If a firewall or bot challenge answers instead of the site, the report says so, because every other finding then describes the challenge page.

How the scores add up

Security, caching and page weight each start at 100. A problem takes 25 points off its area and a warning takes 10. Notes cost nothing. The overall score weights security at 40% and the other two at 30% each.

The fix-first list takes the problems and warnings that have a fix, problems first, and keeps five. The full list of checks, with the thresholds each one uses, is spread across the fix guides.

What happens to the page it reads

Nothing is written anywhere. The report is built from the responses in memory and discarded once the page is sent. Reloading a report runs a fresh check.

One optional step sends text out. When the site owner has switched on Jev, the page's title, description and the start of its visible text go to it once, to read whether the site is a store, a publisher, a business or a blog. The fix-first list is then ordered for that kind of site. Jev is asked only when the check is started from the form on this site; a shared report link or the JSON API is read without it. A page containing text written to steer AI readers is never sent, and the report says so.

Who built it

Hamza Ahmad Aslam, a WordPress and WooCommerce developer. The WP Front Door case study covers why it exists and how it was built. For scripts and dashboards there is a JSON API with the same report.