The Soft 404 Epidemic

In the early web, determining whether an account existed was relatively straightforward: an existing page returned 200 OK, while an absent one returned 404 Not Found. Many legacy open-source intelligence tools were built entirely on this assumption.

Today, that mental model is broken. Modern web applications built on client-side frameworks routinely return 200 OK along with a generic HTML shell on every requested route, whether the username exists or not.

Transport signal vs. resource signal

Single-page applications (SPAs) shift routing from the web server to client-side JavaScript. When a request arrives at /user/johndoe, the edge server simply delivers index.html containing a skeleton layout and a script tag. The browser then executes the script, queries an API asynchronously, and decides whether to render a user profile or a "User not found" screen.

To an automated HTTP client, the HTTP status code is merely a transport signal confirming that the web server successfully delivered the application bundle. It tells you nothing about whether the profile itself exists. A scanner checking only HTTP response codes will report that every username exists on every SPA platform.

The anatomy of positive proof

Because response codes cannot be trusted in isolation, PROBE evaluates layers of evidence before classifying a result:

• Paired negative baselines. A check rule is tested against random, synthetic handles known not to exist. If the site returns the exact same HTML structure and status code for a nonsense handle, status alone cannot serve as an existence marker.
• Body guards and negative patterns. When a platform returns an in-page 404 message within a 200 response (e.g., "Page not found", "User does not exist", or a redirect to an onboarding flow), PROBE matches source-specific absence patterns.
• Positive corroboration. For platforms prone to generic shells, PROBE requires verifiable positive markers—such as the username appearing in the page <title>, OpenGraph metadata tags, or specific server-rendered profile elements—before emitting a found verdict.

When evidence is missing: abstain

What happens when a modern web app serves a minimal app shell without server-side rendering, and the client-side JavaScript refuses to render in a plain HTTP request? The response contains no positive profile markers, but also no clear error signal.

Many tools guess, or worse, mark it as positive based on the status code. PROBE classifies these responses as unknown. When web architecture obscures the presence of an account, an honest abstention is always better than a fabricated lead.