Many access decisions start with the source IP. A service can map the address to a country, ASN, provider type and known network category, then compare it with allow-lists, deny-lists, licensing rules and abuse history. ISI makes these differences visible by running the same check from multiple countries and exit paths.

• VPN, proxy and datacenter ranges are commonly challenged because they are frequently reused by automation, scraping, spam infrastructure and other abusive traffic.
• Geo policy, sanctions, fraud controls or licensing rules are often the reason access is limited before useful content is returned.

Before a real page is returned, the server can inspect the TLS handshake. The ClientHello exposes protocol versions, cipher ordering, extensions, ALPN, SNI and supported groups. ISI compares browser-based and non-browser checks because they can be treated differently even when they request the same URL.

• JA3 or JA4 style fingerprints can raise bot scores before the application layer is reached.
• A claimed browser identity can still conflict with the TLS fingerprint, which is why User-Agent spoofing alone is not always convincing.

Once the HTTP request reaches the site, the header set becomes another decision point. Sites compare User-Agent, Accept, Accept-Encoding, Accept-Language, Sec-Fetch headers, cookies and referrer data for consistency. This is why a simple reachability check and a real browser screenshot can produce different evidence.

• Missing fetch headers, incomplete language preferences or impossible header combinations can trigger alternate responses.
• Many systems score the whole header profile, not just one field like the User-Agent string.

A site can score request timing and sequence before a visible block appears. It may track concurrency, burst size, navigation order, repeated access to the same path, missing asset fetches and whether the journey resembles a real page visit. ISI helps separate a country block from throttling, temporary limits or behaviour-based challenges.

• Too many requests in a short window can produce `429`, temporary throttling or hidden slowdowns.
• Jumping directly into deep URLs without a believable navigation trail can be treated as suspicious behaviour.

Many modern sites return a basic page first and fetch the useful content afterward. Translation bundles, feature flags, GraphQL endpoints, JSON APIs and background requests may all be required before the page becomes complete. Screenshots matter here: the first HTML response can succeed while the visible page remains partial, empty or regionally reduced.

• Successful HTML does not guarantee the browser was allowed to retrieve the data needed to finish rendering.
• Translation keys, empty modules and half-rendered layouts often originate from this stage rather than the first response.

While the page starts, client-side scripts can measure browser and device signals directly. These include viewport size, screen dimensions, timezone, locale, platform, font availability, canvas and WebGL behaviour, media capabilities, input timing and automation indicators. Interactive sessions help verify whether the observed result is a real regional variant or an automation-sensitive response.

• A site can serve a reduced page, withhold modules or trigger a soft challenge instead of issuing a hard block.
• This is often where a real interactive browser session succeeds while automated rendering receives a degraded variant.

After combining network, request and browser signals, the site decides which version of the experience to return. That response may be the full page, a reduced shell, an interstitial, a consent wall, a login wall or a challenge page. In other words, HTTP 200 does not always mean the user received the intended service.

• This is the stage where the user first notices that a page has loaded but is not actually complete.
• The transport and request may succeed while the meaningful application content is still intentionally withheld.