Zero impressions on one ad unit: six causes to check

When one ad unit shows zero impressions and the rest of the site serves, look at six causes: a renamed div, a changed ad unit path, a slot never displayed, a deactivated ad unit, an expired line item, or ads.txt no longer authorizing you. The ad requests column tells you which three to check first.

Below is the order we would check them in, with the exact screen or console message for each.

Why a dead ad unit is easy to miss in Ad Manager reports

A unit at zero does not look like a drop. It looks like nothing. In the reports we pull every day, an ad unit with no activity in the date range has no row at all, so a sorted table of ad units by revenue never shows it at the bottom with a zero. It is just gone, and nobody notices that a list of 40 units now has 39.

Google's own release notes show how much report rows depend on filtering. The notes dated 19 October 2026 include a reporting change: rows where a ratio such as CTR is 0% will no longer be dropped when they carry dependent data like impressions. Google says no action is needed. If you keep a spreadsheet of ad-unit rows to spot zeros, expect a few more rows than before, and do not mistake them for new units.

The practical point: a zero is only visible if you compare the report against the list of ad units you expect to see. Keep that list.

Start with one number: ad requests

Run a historical report for the last seven days with Ad unit and Date as dimensions, and Ad requests and Impressions as columns. Filter to the unit in question and its neighbours on the same pages. Then read the requests column.

What you see	What it means	Causes to check
Ad requests are zero (or the row is missing)	The page never asked Ad Manager for this unit	1, 2, 3
Ad requests are normal, impressions are zero	Ad Manager got the request and had nothing eligible to serve	4, 5, 6

That split cuts the search in half before you open a single line item.

When ad requests are zero: the page stopped asking

These three live in the page code or the tag manager, and the Google Publisher Console names each one. Open any page that carries the unit and add ?google_console=1 to the URL, or run googletag.openConsole() from the browser's developer tools.

1. The div was renamed or removed

A template change renames the container, or a redesign drops it from one page type. GPT then cannot place the slot. The Publisher Console logs this as an error, "could not find div with id" followed by the div ID and the ad unit path. Fix the ID in the template so it matches the one in defineSlot() and display(), character for character.

A related error appears when two slots claim the same div: "Div element ... is already associated with another slot". That one usually follows a copy-pasted block in a template.

2. The ad unit path in the tag changed

Someone edits the tag and the path no longer matches the ad unit in Ad Manager. A malformed path gives the console error "Invalid ad unit path provided". A path that is valid but different (a typo in a child unit name, a section renamed in the CMS) fails more quietly: the requests go somewhere else, and this unit drops to zero. Check the report for a new ad unit name that started getting requests on the same day yours stopped.

3. The slot is defined but never displayed

This is the tag manager and lazy-loading case. The head of the page defines the slot, but the body never calls display() for it, because a trigger stopped firing or a lazy-load script was swapped out. Google's help page on building GPT tags says the Publisher Console shows the warning "googletag.defineSlot was called without a matching display call" and that the slot will not serve. A page that is tagged correctly shows "Page tagged correctly!" on the Page Request tab.

If ad tags failing to load is a pattern on your site rather than a one-off, the checks in how to know when your ad tags stop loading go further.

When ad requests arrive but nothing serves

Here the page is doing its job. Ad Manager receives the request and has nothing eligible to put in the slot.

4. The ad unit was deactivated or archived

Someone tidies up the inventory list and deactivates a unit they think is unused. Google's help page is precise about what happens: line items targeted directly to that ad unit stop delivering to it, line items targeted to its child units keep delivering, and run-of-network and house line items still deliver if the unit is still in your GPT tags. So a deactivated unit with only directly targeted demand goes to zero, while one that also gets run-of-network line items just drops.

Check the ad unit's status in Inventory. Deactivated units still appear in the default table; archived ones need the status filter. Changes are saved at once but, per the same page, can take up to 180 minutes to reach ad serving, which matters when you are trying to match the drop to a change in the history.

5. The only line item on it reached its end date

Sponsorship slots and special placements often have exactly one line item. When its end date passes, Ad Manager marks it Completed and it stops delivering. If nothing else targets that unit, impressions go to zero the next morning.

Open the line items that target the unit and sort by end date. For anything that looks like it should be running, the line item's Troubleshoot tab shows "Non-delivery causes" and a "Health history" of recent changes, per Google's troubleshooting page. A backfill line item or an Ad Exchange rule on the unit keeps it from going fully dark the next time a campaign ends.

6. ads.txt stopped authorizing your seller account

An ads.txt edit removes your Google publisher line, or a CMS migration replaces the file with a default. Google's help says that errors such as "Unauthorized seller (Ads.txt)" can prevent line items from spending. Open Admin, then Ads.txt management, and read the Status column for the domain. The labels are "No ads.txt/app-ads.txt file found", "No seller accounts authorized", "Some seller accounts authorized" and "All seller accounts authorized". Anything short of the last one needs a fix.

This cause usually hits every ad unit on the domain at once, and mostly the programmatic side. If only one ad unit is at zero, ads.txt is the least likely of the six, which is why it comes last. Our post on ads.txt 1.1 and the OWNERDOMAIN and MANAGERDOMAIN lines covers the file itself.

A zero-impressions check you can run tomorrow morning

1. Export the list of active ad units from Inventory. This is your expected list.
2. Run yesterday's report by Ad unit with Ad requests and Impressions.
3. Join the two. Every expected unit with no row, or with requests but no impressions, goes on the list.
4. For each one, read the requests column and go to causes 1 to 3 or 4 to 6 above.
5. Note what you found and when it started. The start date is what the editor and the sales lead will ask for.

It takes about 20 minutes the first time and five once the expected list exists.

Catching it on the day instead of the week after

The manual check above works, but it runs when someone remembers to run it. PubPilot has a zero-activity condition for exactly this case, so a rule on ad requests or impressions for the units you name sends a Slack or email alert when one goes to zero, and on the Pro plan the GAM checks run every 15 minutes alongside the on-page script and the ads.txt watch.