What does Miscellaneous or Unknown mean in Zscaler?

It is the category Zscaler Internet Access assigns to a URL its classification database has no entry for yet. New domains, small business sites and short-lived phishing sites all land here. Many organizations block or caution it by default, so legitimate new sites get blocked until someone reviews them.

Can I ask Zscaler to recategorize a URL through the API?

No. Recategorization requests go through the Zscaler Site Review web form at sitereview.zscaler.com, which opens a support case. To change how a URL is treated in your own tenant right away, add it to a custom URL category used by a URL filtering rule and activate the change.

Why does traffic to an isolated URL still get through?

A ZIA ISOLATE rule only matches web browser user agents. Apps, scripts and other non-browser traffic skip it and fall through to your later rules. Pair the isolate rule with a BLOCK rule directly below it for the same category, so that only browser traffic, inside isolation, can reach the site.

How to handle uncategorized URLs in Zscaler ZIA

By Ashu Arun Sethi, Zscaler-certified (Zscaler ACE), HuCortex · Updated 5 November 2026

When Zscaler Internet Access (ZIA) can't classify a site, it puts it in the Miscellaneous or Unknown category. Investigate the host first, then choose: keep it blocked, allow it through a custom URL category, allow it only through Cloud Browser Isolation, or ask Zscaler to categorize it via Site Review. Every ZIA change needs an activation to take effect.

What "Miscellaneous or Unknown" means

ZIA classifies URLs against Zscaler's own database. A URL with no entry comes back as MISCELLANEOUS_OR_UNKNOWN from the URL lookup API. That covers brand-new domains, small or regional business sites, and short-lived phishing sites, which is why many organizations block or caution the category. The result is a steady stream of "this site is blocked, can you unblock it?" requests.

An uncategorized site is not necessarily dangerous, and a categorized one isn't necessarily safe. The category only tells you Zscaler hasn't seen enough of it yet.

Your four options in ZIA

Option	How it works	Use when
Keep it blocked	Leave your uncategorized policy in place	The evidence is weak or suspicious
Allow it	Add the host to a custom URL category, reference it in an ALLOW URL filtering rule placed above the rule that blocks uncategorized traffic, then activate	You've confirmed the site is legitimate and needed
Allow through isolation	Same, but with an ISOLATE rule and a Cloud Browser Isolation profile, so the page renders remotely and nothing runs on the device	Users need the site but you're not sure about it
Request recategorization	Submit the URL at sitereview.zscaler.com. Zscaler opens a support case and emails you when it's reviewed (how Site Review works, and how to override the category meanwhile)	Always, for sites you allow, so the exception can be removed later

There is no API for recategorization requests: Site Review is a web form, and Zscaler gives no turnaround time. The custom category is what changes treatment in your own tenant straight away. See Zscaler Site Review: how to check and change a URL's category.

How to investigate an uncategorized host

These checks separate the overwhelming majority of legitimate sites from risky ones. None needs a paid service.

Domain age. Look up the registration date through RDAP (the successor to WHOIS). Domains registered in the last 30 days are the single strongest phishing signal. Some registries have no RDAP server (for example .io), so fall back to WHOIS; a few, like Germany's .de, don't publish creation dates at all.
Is it registered at all? If the registry has no record and DNS returns NXDOMAIN, the domain doesn't exist. That's usually a typo or a taken-down domain, not a site to allow.
Hosting platform. Check whether the host is a subdomain on a shared platform such as github.io, pages.dev, web.app or duckdns.org (the private section of the Public Suffix List). Anyone can create a site there in minutes, so the platform's age, popularity and even its Zscaler category say nothing about whoever runs the subdomain.
Brand impersonation. A well-known brand on a domain the brand doesn't own (microsoft-login-verify.example), especially with words like login, verify or account, or lookalike letters from another alphabet (pаypal.com with a Cyrillic "а"), is a strong red flag.
DNS and mail posture. Real businesses usually have MX, SPF and DMARC records. Their absence isn't proof of anything, but their presence adds a little confidence.
Reputation lists. Check Google Web Risk and, if you have a commercial licence, VirusTotal. A clean result on a brand-new site means little: fresh phishing pages are often clean for their first hours.
The page itself. If it asks for a password and shows a brand it doesn't belong to, it's credential phishing whatever the other signals say. Look at it in an isolated browser, never on a workstation.

Licensing matters if you automate this. The free tiers of VirusTotal's public API, Google Safe Browsing, urlscan.io, OpenPhish and AlienVault OTX all restrict commercial or business use. For an organization, use Google Web Risk (which allows commercial use and has a free monthly quota) or paid tiers.

The isolation gotcha: add a companion block rule

A ZIA ISOLATE rule only matches web browser user agents. Desktop apps, scripts and update agents skip it and fall through to your later rules. Today your uncategorized-block rule catches them, but once Zscaler categorizes the site, that traffic may be allowed in full. Put a BLOCK rule for the same category directly below the ISOLATE rule so the site stays isolation-only, whatever category it gets later.

Order the rules from strictest to most permissive: explicit block, then isolate, then the companion block, then allow. If a host lands on two lists by mistake, the stricter rule wins.

Clean up exceptions once Zscaler catches up

Custom-category exceptions pile up. Once Zscaler categorizes a site you allowed, your normal policy can take over again, so re-check allowed hosts regularly and remove the ones that no longer need an exception. If a re-check shows a security category, block the host.

How Zmate does this from Slack

/zmate investigate-url <host> checks the host and returns a verdict with a trust score and the reasons behind it. Buttons on the same message scan the page in an isolated browser, block the site, allow it, or allow it only through isolation. Nothing changes until a Zmate admin clicks Confirm. /zmate allowed re-checks every exception and flags the ones Zscaler has since categorized.

See URL triage in Zmate

FAQ

What does Miscellaneous or Unknown mean in Zscaler?: It is the category Zscaler Internet Access assigns to a URL its classification database has no entry for yet. New domains, small business sites and short-lived phishing sites all land here. Many organizations block or caution it by default, so legitimate new sites get blocked until someone reviews them.
Can I ask Zscaler to recategorize a URL through the API?: No. Recategorization requests go through the Zscaler Site Review web form at sitereview.zscaler.com, which opens a support case. To change how a URL is treated in your own tenant right away, add it to a custom URL category used by a URL filtering rule and activate the change.
Why does traffic to an isolated URL still get through?: A ZIA ISOLATE rule only matches web browser user agents. Apps, scripts and other non-browser traffic skip it and fall through to your later rules. Pair the isolate rule with a BLOCK rule directly below it for the same category, so that only browser traffic, inside isolation, can reach the site.