GPT bfcache Auto-Refresh Is On by Default in 2026: What Publisher Ad Ops Should Check
Starting September 8, 2026, Google Publisher Tag automatically refreshes actively viewed ad slots when a user returns to a page through back/forward cache (bfcache) navigation. The behavior is on by default. Publishers who need to turn it off do so in GPT with googletag.setConfig({ autoRefresh: { backForwardCache: false } }), not through a Google Ad Manager network toggle.
That is a client-side GPT default, announced in the GPT release notes (week of August 24, 2026) as AutoRefreshConfig.backForwardCache. Google's stated goal is to recapture impressions that used to die when a restored page showed a frozen creative.
For most stacks, leaving the default on is fine. For stacks that refresh their own slots, rewrite key-values before every refresh, or treat every impression bump as a demand problem, it is a one-line config decision plus a morning reporting check. This is the operator checklist.
Table of Contents
What changed (and what did not)
What changed
On bfcache restore, GPT can refresh actively viewed ad slots automatically.
The behavior is on by default (backForwardCache defaults to true).
You opt out through the GPT config API, not through an Ad Manager network setting.
What did not change
Your GAM line items, floors, and Private Auction settings did not flip overnight.
Browser bfcache itself is still a browser feature. GPT is reacting when a restore happens.
This is separate from the older Heavy Ad Intervention auto-refresh path (same autoRefresh config object, different property: heavyAds).
Google's note on related auto-refresh behavior matters here: the refresh reuses the slot's existing targeting. If your integration updates key-values right before every manual refresh(), the automatic path can fire with stale targeting. That is the main technical reason some publishers will opt out and keep ownership of the refresh.
Why ad ops should care this week
bfcache restores look like "the user came back," not like a new page view in the way your team usually thinks about sessions. When GPT refreshes on that restore, you can see:
Impression and request volume tick up without a matching traffic story in analytics
Viewable impressions and Active View rates move in ways that look like a yield win or a QA bug, depending on who is looking
Pacing on direct-sold or Programmatic Guaranteed lines get noisier if refreshes land on inventory you thought was already counted for that visit
Custom refresh logic (viewability timers, SPA route changes, consent re-entry) collide with GPT's automatic refresh
None of that automatically means revenue is wrong. It means your morning exception brief needs a known cause labeled before someone escalates "impressions spiked / eCPM dipped" as a demand incident. Google has not published a revenue estimate for this change - treat reporting moves as something to annotate, not something to invent a percentage for.
Keep the default, or opt out
Use this decision framework.
If you are unsure, leave the default on for a week on a non-critical template, watch GAM vs analytics, then decide. Do not opt out everywhere "just in case" without a test window.
How to disable GPT bfcache auto-refresh
Official pattern from GPT's AutoRefreshConfig (same shape as the documented heavyAds opt-out):
*window.googletag = window.googletag || { cmd: [] };
googletag.cmd.push(() => { // Disable automatic refresh when the page is restored from bfcache. googletag.setConfig({ autoRefresh: { backForwardCache: false, }, });
// ... defineSlot / enableServices as usual });*
Restore Google's default later with:
googletag.setConfig({ autoRefresh: null });
Or re-enable only the bfcache flag:
googletag.setConfig({ autoRefresh: { backForwardCache: true, }, });
Placement notes
Put this in the same GPT bootstrap path as your other setConfig calls.
Call it early in googletag.cmd so it is set before users start navigating.
Treat autoRefresh as one object: if you also manage heavyAds, set both keys in the same call so you do not clear one while setting the other.
Example when you want bfcache off but Heavy Ad Intervention refresh still on:
googletag.setConfig({ autoRefresh: { backForwardCache: false, heavyAds: true, }, });
Ops checklist (run once per major template)
Confirm GPT is official. Load gpt.js from Google's hosted URL, not a long-lived self-cache of an old build.
Inventory refresh owners. Search the codebase / tag manager for pubads().refresh, pageshow, event.persisted, and any CMP "consent updated then refresh" hooks.
Decide default vs opt-out with the table above. Document the choice in the ad ops runbook, not only in a Slack thread.
Ship the config on article, section, and homepage templates (or the shared GPT partial). SPA shells need the same call on boot.
QA a bfcache restore. In Chrome: open an article, navigate away, use Back. Confirm whether slots refresh (Publisher Console / network) matches your intended setting.
Baseline reporting for 7 days. Compare impressions, revenue, eCPM, and viewability for the week after Sep 8 against the prior week on the same templates. Annotate the change date so nobody treats the delta as unexplained demand.
Review publisher refresh declarations. GAM requires declaring inventory that refreshes (Declare inventory that refreshes). Google has not published an explicit mapping of this GPT-managed bfcache path to a declaration trigger type - confirm with your Google account team whether your declarations need an update, and do not invent a trigger label.
Tell sales / yield what "normal" looks like. One sentence in the weekly note beats three days of "is Open Bidding broken?"
How the noise shows up in GAM
You will not get a dimension labeled "bfcache refresh." You will get symptoms:
Higher ad requests / impressions on content templates with heavy back-button use (galleries, multi-page articles, commerce modules)
Session metrics in analytics that do not move 1:1 with GAM impressions
Refresh-heavy sites seeing a smaller relative change (you were already re-requesting)
Practical approach:
Pull a simple Interactive report: date, ad unit (or request type), impressions, revenue, average eCPM, for Sep 1-14 vs the prior 14 days.
Slice the templates you changed (or the ones with known custom refresh).
If you opted out, you should not expect a magical revenue cliff; you should expect fewer unexplained restore-driven requests.
If morning pacing alerts fire harder in the first week, check this change before you rewrite floors.
Manual refresh if you opt out
If you disable GPT's automatic path but still want a fresh ad on restore, own it explicitly. Pattern from web performance guidance: listen for pageshow and check event.persisted, then refresh viewable slots on your terms (including updated targeting).
Sketch only - adapt to your consent and refresh policies:
*window.addEventListener('pageshow', (event) => { if (!event.persisted) return;
googletag.cmd.push(() => { // Update targeting / privacy here if your stack requires it. // Then refresh the slots you intend to remonetize. googletag.pubads().refresh(); }); });*
Do not stack this on top of GPT's default auto-refresh. Pick one owner.
Also remember Google's general refresh guidance: avoid refreshing faster than about every 30 seconds, and prefer refreshing slots that are actually viewable.
Site eligibility still matters
GPT can only refresh on a bfcache restore if the browser actually restores the page. Pages that block bfcache (classic offender: unload listeners) will not see this behavior the same way. That is a site-performance topic more than a GAM trafficking topic, but it explains why Template A got the bump and Template B did not.
If engineering is already cleaning unload to pagehide for Core Web Vitals, expect more restores over time, which means this GPT default covers more sessions - not fewer.
Where ProOps Ads Tracker fits
This change is a classic "looks like demand, is actually tag behavior" event. The daily job is still the same: catch overnight campaign, revenue, and inventory exceptions beside Google Ad Manager before the stand-up, not after the Slack thread.
ProOps Ads Tracker is the read-only Chrome sidepanel coordinator we built for that morning pass - ranked exceptions by 8 AM local, $249/month per GAM network, 30-day trial, no credit card to start. It does not invent a "bfcache alert" product claim. It helps you notice when delivery moved for a reason your team should label.
Frequently Asked Questions
GPT bfcache auto-refresh is on by default in 2026 - what should publisher ad ops check?
Confirm whether you want Google's default (refresh actively viewed slots on bfcache restore), or opt out with googletag.setConfig({ autoRefresh: { backForwardCache: false } }). Then inventory any custom refresh logic, QA a Back navigation in Chrome, and annotate GAM reporting for the week after September 8, 2026 so impression noise is not misread as a demand incident.
Did something break in Google Ad Manager on September 8, 2026?
Not in the trafficking UI. GPT's client library started auto-refreshing actively viewed slots on bfcache restore by default. Line items, floors, and Private Auction settings did not flip overnight.
How do I turn off GPT bfcache auto-refresh?
Call googletag.setConfig({ autoRefresh: { backForwardCache: false } }) early in your GPT bootstrap. Restore defaults later with googletag.setConfig({ autoRefresh: null }).
Will disabling it hurt revenue?
It can reduce restore-path impression recapture. Google has not published a revenue estimate. Whether it matters depends on how often users hit Back/Forward on your templates and whether you already refresh yourself.
Is this the same as Heavy Ad Intervention refresh?
Same config object (autoRefresh), different flag (heavyAds). Configure them deliberately together so one call does not clear the other.
Should we change floors because of this?
No as a first move. Annotate reporting, confirm your GPT setting, then revisit floors only if the economics actually shifted on your templates.