> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/getting-started/tagging-pixel-verification.md).

# Tagging Pixel verification

Why the check can report a missing pixel that is actually there, and the two things that fix it.

Once the Tagging Pixel is installed, AdPage checks whether it really loads on your website. This page explains what that check does, and what to do when it reports a missing pixel that you know is there.

## How the check works

The check opens your shop page in a real Chromium browser from Amsterdam, waits for the page to finish loading, and looks for two things: scripts loading from your tagging domain, and the hits those scripts send.

{% hint style="info" %}
Loading the page in a real browser matters. A check that only reads the page source cannot see a script that is added while the page loads, and would report a working pixel as missing.
{% endhint %}

The check runs when you press **Verify pixel** in your container settings, and once a day on its own.

## When the check reports a missing pixel

Two causes are common, and neither of them means something is wrong with your pixel.

### 1. No website URL for this domain

The check needs to know which page to open. If the **Website URL** is empty for this tagging domain, AdPage derives it from the tagging domain itself: `tagging.example.com` becomes `example.com`.

That guess is right for most shops, but not all. If your shop lives somewhere else, the check opens the wrong page, finds nothing, and says so. You will recognise this case by the wording: the result mentions that the URL was derived.

Fill in the website in **Settings → Tagging Pixel** and verify again.

<figure><img src="https://1274044937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FCanPj0PTX5oJhn8KUKjr%2Fcontainer-instellingen-taggingpixel-detail-en.webp?alt=media" alt="Tagging Pixel section in the container settings with website field and verification status"><figcaption><p>Fill in your website and verify the Tagging Pixel again.</p></figcaption></figure>

{% hint style="info" %}
A container can have several tagging domains, and each one has its own Website URL. Filling it in for one domain does nothing for the others — check each domain you use.
{% endhint %}

### 2. Your firewall or bot protection blocks the check

A firewall, WAF or bot protection in front of your shop can refuse visitors it does not recognise. Our check is then turned away before it ever sees your page, and the result looks the same as a missing pixel.

The fix is to allow our check through. Your container dashboard shows the IP addresses it comes from, with a button to copy them.

{% hint style="warning" %}
Copy the addresses from your dashboard, not from this page. The list is kept up to date automatically, and the dashboard always shows the current one. If verification starts failing again later, open the dashboard and compare the list.
{% endhint %}

{% stepper %}
{% step %}

### Open your container dashboard

The list appears under **Automatic verification still pending**, or under the pixel status when a check has failed.
{% endstep %}

{% step %}

### Copy the addresses

Use **Copy list** to put all of them on your clipboard at once.
{% endstep %}

{% step %}

### Allow them through

Send the list to whoever manages your hosting, firewall or bot protection, and ask them to allow these addresses. In Cloudflare this is a WAF rule; in other setups it may be an IP allowlist or an exception for a security rule.
{% endstep %}

{% step %}

### Verify again

Press **Verify pixel** in your container settings. The check should now reach your page.
{% endstep %}
{% endstepper %}

## Confirming the pixel manually

If you cannot change the firewall, you can confirm the pixel yourself with **Confirm manually**. Your container then stops warning about an unfinished setup.

Be clear about what this does and does not do:

* It records that **you** checked the pixel. It does not verify anything on our side.
* AdPage keeps checking in the background. As soon as a check sees your pixel load, your manual confirmation is replaced by a real verification.
* It does not make tracking work. If the pixel genuinely is not installed, confirming it manually only hides the warning — you will still see no data coming in.

{% hint style="info" %}
To check the pixel yourself, open your website, press F12 to open the developer tools, go to the **Network** tab and filter on your tagging domain. Reload the page. If you see requests to that domain, the pixel is loading.
{% endhint %}

## What's next?

With the pixel verified, your container is collecting data. From here you can move on to the tracking rules in your Google Tag Manager containers, or check the data quality of your setup under **Monitoring**.


---

# 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.adpage.io/getting-started/tagging-pixel-verification.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.
