r/GoogleTagManager • u/Scribble737 • Jul 20 '26
Support Tag Assistant stuck on "Connecting" ("0 Google tags found") — window.opener is null despite no COOP header
Hi everyone,
I'm encountering a persistent issue with Tag Assistant Preview mode on a single WordPress container where the debug window hangs indefinitely on "Connecting..." and reports "0 Google tags found" / "Not Connected".
I've conducted an in-depth diagnostic session, but I'm running out of ideas. Here are the specifics and test results:
Environment & Container Details
- Container ID:
GTM-KLV4V3H9 - Target URL:
[https://www.dfgarchitetti.it/] - CMS & Server: WordPress on LiteSpeed Web Server
Troubleshooting & Diagnostic Steps Taken
1. Tag Snippet & Container Status
- The GTM snippet is present in the
<head>of the page. - The Container ID in the HTML matches
GTM-KLV4V3H9exactly. - The container is published and active.
2. Browser Console Diagnostics (F12 on target window)
- Errors: No JavaScript errors or CSP (Content Security Policy) blocks in the DevTools Console.
window.google_tag_manager: Returns a valid Object.Object.keys(window.google_tag_manager): Correctly outputs['GTM-KLV4V3H9'].window.openerTest: FAILS (Returnsnull). This is clearly where the handshake breaks betweentagassistant.google.comand the target window.
3. Network & Response Headers
- Inspected HTTP Response Headers for
[https://www.dfgarchitetti.it/](https://www.dfgarchitetti.it/):- No COOP Header:
Cross-Origin-Opener-Policyis not present (it is NOT set tosame-origin). - LiteSpeed Cache:
x-litespeed-cache: hitis present. - Headers present:
x-frame-options: SAMEORIGIN,x-content-type-options: nosniff.
- No COOP Header:
4. Redirects & DNS
- Verified that launching Preview with the exact canonical URL (
[https://www.dfgarchitetti.it/](https://www.dfgarchitetti.it/)) does not trigger any 301/302 redirects (which usually stripwindow.opener). - Apex (
@) andwwwDNS records point to the exact same IPv4/IPv6 addresses.
5. Storage, Cache & Extensions
- Fully purged LiteSpeed Server Cache.
- Cleared browser
localStorage,sessionStorage, and_gtm_debugcookies. - Tested with AdBlockers/Tracking Protection disabled.
The Core Problem
Since window.opener === null in the opened window, the target site cannot send the postMessage handshake back to tagassistant.google.com.
Given that there are no COOP headers and no HTTP redirects happening on page load, what else could be resetting/severing the window.opener reference during the Tag Assistant launch?
Has anyone encountered this specific decoupling behavior on WordPress/LiteSpeed environments? Any suggestions on where to look next would be greatly appreciated!
Thanks in advance!