What a Website's Response Actually Tells You

Updated 6 September 2026 · 10 min read

Every online lookup ends with a server sending back a number and some text. Reading those correctly is the difference between an investigation and a guess — and almost every mistake in automated OSINT comes from treating one kind of answer as though it were another.

The four answers you will actually get

Strip away the detail and a platform can tell you one of four things when you ask about a handle. They are not equally informative, and only two are answers at all.

200 — "here is a page"

The most common response and the least meaningful. It says a page was produced. It does not say the account exists, because the page may be a login wall, an empty application shell, or a branded "not found" screen. Treating 200 as proof of existence is the single most common error in this field.

404 — "there is nothing here"

The most useful response, and rarer than you would hope. A genuine 404 for a profile URL is strong evidence of absence — provided you have confirmed the same platform returns 200 for a handle you know is real. Without that control, you cannot distinguish "this account does not exist" from "this URL pattern is wrong".

That control matters. We tested Clubhouse for a handle a user was certain existed:

clubhouse.com/@rohanseth        200
clubhouse.com/@paul             200
clubhouse.com/@elonmusk         200
clubhouse.com/@<the handle>     404
clubhouse.com/@zzqnope99123x    404   (invented, for comparison)

Real handles resolve; the handle in question behaved exactly like a string we made up. That is a reliable negative. The explanation turned out to be mundane — the handle contained a dot, and Clubhouse usernames do not permit them, so the account could never have existed there.

403 — "not for you"

You have been blocked, usually by a web application firewall reacting to the network you are asking from rather than to anything about the handle. This tells you nothing about the account.

We probed a set of platforms from a datacentre address, using a full set of browser headers, and got 403 from Lemmy, CodeSandbox, Crunchbase, Audius, Mod DB, Nexus Mods and Pexels — for real and invented handles alike. The block was on us, not the handles.

429 — "you have asked too much"

Rate limiting. Also not an answer about the account, and the most dangerous to misread, because it usually appears only after a tool has been working correctly for a while. Results silently get worse the more you use it.

The error shell

The hardest case is a platform that answers 200 while telling you nothing. Instagram is the clearest example we measured.

Requesting profile pages from a blocked network returned this:

instagram.com/nasa               200   612,900 bytes
instagram.com/zzqnope99123xqq    200   612,912 bytes

NASA's account — one of the most followed on the platform — and a string invented for the test, differing by twelve bytes in six hundred thousand. Both pages contained an internal marker reading "httperrorpage", and both echoed the requested handle back inside a routing object roughly 309,000 characters into the document.

That echo is a trap worth naming, because it is exactly the sort of thing that looks like a signal. A tool searching the page for the handle would find it — for every handle, real or not — and report a match every time. The handle appears because we asked for it, not because anyone is there.

Who is asking changes the answer

The same request, sent at the same moment to the same URL, gets different responses depending on the network it comes from. This is not a quirk; it is deliberate anti-abuse design, and it has real consequences for anyone comparing tools.

We ran an identical Instagram lookup from two places:

from a laptop / datacentre address:   401 for every handle
from a hosted server elsewhere:       full profile, 104,000,000 followers

Same code, same endpoint, same minute. Only the source address differed.

The general rule is that residential and mobile addresses are treated far more permissively than datacentre ranges, because that is where abuse comes from in bulk. This is why a check run from a phone frequently succeeds where a cloud-hosted scanner is refused, and why two tools can disagree entirely while both behave honestly.

It also means results are not stable over time. Run enough lookups from one address and you will be throttled, after which your results quietly degrade. If a tool suddenly reports fewer accounts than it did last week, suspect your address before you suspect the accounts vanished.

Redirects: watch where you land

A redirect is not automatically a negative. Reddit answers 301 and YouTube 302 for perfectly real profiles, simply canonicalising the URL. What matters is the destination.

Landing on any of these means the platform has nothing to show you:

• /login, /signin, /accounts/login — an authentication wall
• the site root — the profile was not recognised and you were sent home
• /404, /not-found, /error — a soft error page

We watched Reddit change behaviour mid-investigation. Requests for a well-known, definitely-real account began redirecting to /login/?reason=lor2, returning a 352,259-byte login page — and an invented handle returned the same page at 352,369 bytes. Once that started, no reading of the response could tell the two apart.

Reading the body, not just the number

Because status codes are unreliable, the body matters. Three things worth checking, in order of value:

1. The page title. A profile is titled for its owner: "Linus Torvalds (@torvalds)". A shell is titled for the site: "Twitch". This distinction does most of the work.
2. Explicit not-found phrasing. "Sorry, this page isn't available", "user not found", "couldn't find this account". Present in the body of many soft 404s.
3. Per-account data. Follower counts, join dates, post counts. A site cannot render these without having found the account.

One caution on titles: some platforms echo the handle into the title of their not-found page. Telegram titles every page "Telegram: Contact @<anything>" whether or not the account exists, so the title check alone marks every Telegram handle as a match. Any rule you adopt needs a short list of known exceptions, and the only way to build that list is measurement.

Where the data actually sits

A practical trap for anyone writing their own checks: profile information is often nowhere near the top of the document. Tools commonly read the first few kilobytes for speed, which quietly guarantees they miss everything that matters.

Measured on live Pinterest profiles:

page size                   1,307,070 - 1,523,336 characters
"username" field at         1,036,563 - 1,242,000
profile image URL at        ~90,000 characters further on

A tool reading the first 192 KB reaches none of it and concludes there is no profile. Instagram has the same shape for a different reason: roughly 95,000 characters of inline script arrive before the <title> tag.

Worth knowing before you assume this is expensive: the Pinterest page is about 140 KB compressed on the wire. The full document costs almost nothing extra to download — the limit was only ever on how much got decompressed and searched.

A checklist for verifying anything yourself

1. Open the profile URL in a private browsing window, logged out. This is what an automated tool sees.
2. Check the page title. Does it name the account, or the site?
3. Look for per-account data — followers, posts, a join date.
4. Test an invented handle on the same platform. If it looks the same, the platform cannot answer this question.
5. If you get 403 or 429, stop and try later from a different connection. You have learned nothing yet.

The honest summary

Only two of the four responses are answers. A verified 404 means absent. A 200 with account-specific content means present. A 200 with a generic page, a 403, or a 429 all mean the same thing: you do not know, and any tool that renders those three as a green tick is manufacturing certainty it does not have.

Read next: why username checkers report accounts that don't exist →

← All guides