Quick answer
Capture the Content-Security-Policy header and HTML from the same page response, then compare the permitted nonce with the intended inline script's nonce. If only cached responses fail, investigate how markup and headers are generated and cached together. Do not reuse a fixed nonce or add unsafe-inline to hide a response-pairing problem.
Confirm that the browser is blocking the intended script
Read the browser's policy violation for the affected page and identify the script and directive. A missing GA4 event can have several causes, including consent, trigger conditions, network blocking, or a container that never started. This article addresses the specific case where nonce-based script authorization is inconsistent.
Record the page URL without personal query data, the request time, and the relevant policy message. Keep the failure tied to one navigation. Comparing yesterday's console message with today's header can produce a convincing but invalid explanation. Use a clean test session and the same intended consent state for comparison.
Collect headers and markup as a pair
Use the browser's document request and its response, or a controlled diagnostic request that saves both headers and body together. Do not fetch the header once and the HTML later and expect a response-specific nonce to remain identical. Those are separate responses and may legitimately contain different values.
In a local worksheet, replace real nonce values with labels such as response-A-marker after checking equality privately. Preserve which header and script belonged together. Do not publish complete response bodies if they contain account data, private tokens, or personal information. The diagnostic artifact should establish the relationship without exposing unrelated content.
Compare cache paths without guessing their behavior
Test the ordinary anonymous page path and an owner-approved cache-miss path. Record response status, cache-related headers that are actually present, and the matched or mismatched nonce result. Do not assume that a logged-in page is an equivalent control: plugins and markup can differ between authenticated and anonymous visitors.
A fictional failure matrix might show response A with matching header and script markers, response B with a new header marker but older script markup, and response C matching again. This points toward a response assembly boundary to investigate. It does not establish whether WordPress, a plugin, or the CDN is responsible without their configuration evidence.
Identify who generates each part
Map the component that creates the nonce, the component that inserts it into the inline script, and any layer that adds or rewrites the CSP header. Ask the relevant owners how cache hits, conditional responses, and deployment updates affect those components. The map should describe observed configuration, not assumptions from product names.
Google recommends an unpredictable nonce generated individually for each response. A fixed value shared across cached responses is not an acceptable shortcut. Depending on the architecture, the owner may need coordinated per-response substitution, a reviewed hash-based design for stable inline code, or a different caching arrangement. Each option needs security and functional testing.
Do not weaken unrelated protections
Avoid copying an entire permissive policy from a forum or disabling CSP globally. Keep the existing restrictions on other scripts, frames, and connections in view. A container may begin running while a later analytics request still fails under a different directive, so verify those stages separately.
Preserve the site's consent behavior during the repair. A tracking test should not force denied consent into a granted state. Use an approved non-sensitive fixture, the intended measurement destination, and a reviewed container version. Keep rollback information for both the page-generation change and any policy configuration change.
Verify after cache turnover and deployment
Repeat the paired-response test after the affected cache path has been refreshed through the normal deployment process. Check more than one response and the relevant page templates. Confirm that the authorized script runs, permitted requests reach their destination, and unrelated scripts remain subject to the policy.
Keep a regression check that compares same-response pairing rather than literal nonce values across requests. Document the cache path, configuration owners, and test date. Remove diagnostic files with full HTML once their approved purpose is complete. If the fix only works immediately after a purge and fails again as cache warms, the response-generation design still needs attention.
Illustrative diagnostic example, not customer measurements.When to bring in help
Use WordPress cache and tracking diagnostics when origin, plugin, and CDN configuration have different owners. Bring redacted paired-response evidence and the security-policy owner. A durable fix coordinates response generation; it does not simply keep clearing cache.
Related troubleshooting
Separate container execution from blocked GA4 collection.
Helpful references
Google Tag Manager CSP guidance. CSP response-header reference.