Perplexity's Search Filters, Explained

Part of a series on running AI workflows across model providers — this one is about controlling what the search step is allowed to pull from before the model synthesizes an answer.

A generic web search is often too broad for a production application. Perplexity's API exposes real filtering controls over what its search step is allowed to pull from — and using them well is the difference between an assistant that occasionally cites an unreliable source and one that's scoped tightly enough to trust by default.

Domain filtering

The search_domain_filter parameter accepts up to 20 domains, and works in one of two modes: an allowlist (search only these domains) or a denylist (search everywhere except these domains, indicated by prefixing entries with a minus sign). You can't combine both modes in a single request — it's one or the other.

This is the single most useful filter for narrowing scope in a production application. An assistant meant to answer questions using only a company's own documentation site, a specific set of regulatory sources, or a curated list of trusted publications can be scoped to exactly that, rather than searching the open web and hoping the results happen to be reliable.

Narrowing the search space before the model ever sees results — the filtering happens upstream, not after the fact.

Date and recency filtering

Two different approaches are available, and they can't be combined:

The distinction between publication date and last-updated date matters more than it might seem. A page originally published years ago but recently revised will show up under a last-updated filter but not necessarily under a publication-date one, and which behavior you want depends entirely on what you're trying to find.

Location and language

web_search_options.user_location accepts a country code, region, city, and optionally latitude/longitude, letting search results skew toward what's geographically relevant to a specific location rather than defaulting to whatever's globally prominent. search_language_filter accepts up to 10 ISO 639-1 language codes, narrowing results to specific languages — useful for any application serving a specific linguistic market where results in other languages would be noise rather than signal.

Combining filters well

Most of these filters can be combined freely (domain plus recency plus language, for instance) — the two exceptions are the allowlist/denylist split within domain filtering, and recency-filter versus explicit-date-filter within date filtering. Outside those two either/or choices, layering filters is the normal and often correct pattern: a compliance assistant might reasonably combine a domain allowlist (only regulator websites), a recency filter (only the last year), and a language filter (only English), producing a genuinely narrow, high-confidence search scope.

Most filters stack freely — the constraint is only within domain mode and within date mode, not across categories.

A use case that shows the value of scoping tightly

A legal research tool built for a specific jurisdiction was initially returning citations from international sources that used similar terminology but described different legal frameworks entirely — technically relevant-sounding, practically misleading. Adding a domain allowlist scoped to official government and court sources for that jurisdiction, combined with a language filter, eliminated the cross-jurisdiction confusion without requiring any change to the underlying question-answering logic. The fix was entirely in the search scope, not in the prompt or the model choice.

Why this matters more for production than for prototyping

It's easy to skip filtering entirely while building a prototype — an unscoped search often produces reasonable-looking results for a demo. The gap shows up at production scale, where an unscoped assistant will eventually surface a source that's outdated, off-topic, or from a jurisdiction/context that doesn't apply, and there's no way to know in advance which query will trigger it. Filtering isn't a polish step to add later — it's closer to a correctness requirement for anything answering questions that need to be actually right, not just plausible-sounding.

Frequently asked questions

Do these filters work the same way in the new Agent API?

The Agent API's web search tool is described as supporting the same category of controls — domain, recency, date, and language filtering — as part of its built-in web search tool, since it's the same underlying search capability wrapped in the newer request format.

Can I change filters per-request within the same DNotifier workflow?

Yes — since filters are part of the request payload sent through sendAI(), different steps or different users can trigger different filter configurations within the same application.

What happens if I set conflicting filters, like both an allowlist and a denylist?

The API doesn't allow combining domain allowlist and denylist modes in a single request — you have to choose one, so conflicting configurations should be caught at the application layer before the request is sent.

Is filtering only useful for narrowing scope, or can it also broaden results?

Primarily narrowing — these are constraint mechanisms, not expansion mechanisms. If a search is returning too little relevant material, the fix is usually rephrasing the query rather than adjusting these filters.

The Bottom Line

Next in this series: an honest comparison between Perplexity and DNotifier — what each one actually does, and where they compose rather than compete.

Read part eight: Perplexity vs. DNotifier: Where It Fits. Explore dnotifier.com.