> For the complete documentation index, see [llms.txt](https://docs.umbraco.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.umbraco.com/umbraco-engage/marketers-and-editors/settings/block-traffic.md).

# Block Traffic

Use block rules to keep unwanted traffic out of your Engage analytics.

Block traffic helps you keep your analytics clean. Visits you do not want in your reports, such as your own team, an agency, or automated bots, inflate your numbers. A block rule stops matching requests from being counted, so your reports reflect real visitors.

Block traffic does **not** stop anyone from using your website. The page still loads normally. A blocked request is only left out of your Engage analytics.

{% hint style="info" %}
If you used **IP filtering** before, nothing is lost. Your existing filters were moved over automatically and now appear here as **IP address** rules.
{% endhint %}

## Where to find it

Open the Engage section and go to **Settings** > **Block traffic**. The overview lists every rule you have set up. If you don't have any rule set up, it shows "No rules have been added yet."

<figure><img src="https://2164986937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fds5IoWmsX6a6ooVdYthx%2Fuploads%2Fgit-blob-d59ce08de8b2ce193bdffa4e87d385ff19cc6c16%2FSettings-BlockTraffic.png?alt=media" alt="The Block traffic overview listing configured rules"><figcaption><p>The Block traffic overview</p></figcaption></figure>

## Deciding what to block

The [**Suspicious Activity**](/umbraco-engage/marketers-and-editors/settings/suspicious-activity.md) view, next to **Block traffic** in **Settings**, surfaces requests that behave differently from normal visitors, such as automated browsers. Use that view to spot candidates worth turning into a block rule.

## Creating a rule

Select **Create rule**, fill in the below mentioned fields, and select **Submit**:

* **Name**: A short name for the rule.
* **Description**: A short note about what the rule is for.
* **Type**: What part of the request the rule looks at. See [Rule types](#rule-types).
* **Condition**: How the value is compared. See [Conditions](#conditions).
* **Value**: What to match against, for example an IP address or part of a user agent. With the **List** condition this becomes a **Values** field where you add entries one by one.
* **Active**: Whether the rule is switched on. A new rule is active by default, and you can switch a rule off later without deleting it.

The new rule then appears in the overview.

**Example: Exclude your own visits**

1. Set **Type** to *IP address* and **Condition** to *Equals*.
2. Put your office IP address in **Value** (your IT team can tell you the public one).
3. Leave **Active** on.
4. Select **Submit**.

From now on, visits from that address will stay out of your reports.

<figure><img src="https://2164986937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fds5IoWmsX6a6ooVdYthx%2Fuploads%2Fgit-blob-9b5a513877ec72cb169c44edf0d17a48b3d11184%2FSettings-BlockTraffic-CreateRule.png?alt=media" alt="Creating a block rule with the name, description, type, condition and value fields"><figcaption><p>Creating a rule</p></figcaption></figure>

## Rule types

* **IP address**: The visitor's IP address. Enter a single address (for example `203.0.113.10`) or a range that covers a whole network (for example `203.0.113.0/24`). Ask your IT team if you are unsure which to use.
* **User agent**: The text a browser or bot sends to identify itself. Useful for keeping out automated clients.
* **Country**: The country a visit comes from, based on the visitor's detected location. The **Location** report under Analytics shows the country values Engage records.

## Conditions

When you choose a **Type**, the **Condition** list updates to show only the options that apply to it.

| Type       | List | Equals | Contains | Regular expression |
| ---------- | ---- | ------ | -------- | ------------------ |
| IP address | ✓    | ✓      |          | ✓                  |
| User agent | ✓    | ✓      | ✓        | ✓                  |
| Country    | ✓    | ✓      | ✓        | ✓                  |

* **List**: Matches when the value is one of the entries you add.
* **Equals**: Matches when the value is exactly what you provide.
* **Contains**: Matches when the value contains the text you provide.
* **Regular expression**: Matches the value against a pattern. This option is advanced; leave it to a developer if you are not familiar with regular expressions.

## Managing rules

Select a rule's name in the overview to open and edit it. To switch a rule off without deleting it, open it and turn **Active** off. To delete a rule, tick its checkbox in the overview and select **Delete**.

{% hint style="info" %}
**Active applies from the moment you switch it on.** Turning a rule on does not remove data that was already collected. Turning a rule off does not bring back visits that were left out while it was active.
{% endhint %}

## What to expect

Blocked requests do not appear in your reports, so you will not see them there. To check a rule is doing its job, make sure it is **Active** and that the **Value** is correct. The [**Suspicious Activity**](/umbraco-engage/marketers-and-editors/settings/suspicious-activity.md) view is a good place to see what is still coming through.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.umbraco.com/umbraco-engage/marketers-and-editors/settings/block-traffic.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
