A missing CookiePro banner does not always mean the consent tool is broken. A remembered choice can legitimately suppress it. First compare a new visitor with a returning visitor, then check whether the intended OneTrust script actually reaches the published page.
CookiePro is now part of OneTrust.com. The official transition page explains where existing customers access their environment. A website branding change alone is not a reason to replace your installed consent script. For the broader product context, see our CookiePro privacy profile.
Separate four different symptoms
Record the exact public URL, browser, test region, and whether this browser previously made a choice. Use a fresh browser profile for the new-visitor case; opening another tab preserves the same stored state. Do not erase real consent records from the application as a troubleshooting shortcut.
| Observation |
Next investigation |
| New visitor sees the banner, returning visitor does not |
Saved preference and configured redisplay policy |
| Neither visitor receives the CMP script |
Installation, tag manager trigger, or network block |
| Script loads but configuration is wrong |
Published domain configuration and environment identifier |
| Interface exists but cannot be seen or clicked |
CSS, overlays, stacking, and mobile layout |
Find the owner of the script
On a staging copy, inventory the places that can insert the CMP: a WordPress plugin, theme header, custom snippet, and GTM. Keep one intentional installation path. Two copies with different configuration identifiers can make an apparently random problem reproducible.
Open Network before loading the page. Check the script URL, response status, and initiator. Compare the domain-script identifier in the actual response with the published configuration in your authorized OneTrust environment. Do not paste account credentials or full consent records into a public ticket.
OneTrust documents that Auto-Blocking can block GTM itself. If GTM is also responsible for loading the banner, inspect that dependency. Follow the OneTrust GTM integration guidance for the installation you actually use. Do not exempt all marketing scripts or turn consent enforcement off to make the banner visible.
Fresh visitor: Expected banner is visible. Returning visitor: Saved preference respected. Reject: Restricted tracking remains blocked. Reopen: Preferences work on mobile. Explanatory checklist, not a customer test result.
Test the interface and the decision separately
Once the banner appears, test no interaction, rejection, and an allowed category selection. Then reopen preferences and change the decision. Record visible controls and resulting tag behavior independently. A visible banner is not proof that its choice reached the tags.
For a practical handoff, record one row per test: visitor state, page, intended region rule, script response, visible interface, selected choice, and observed tag request. Use synthetic form data. Check the homepage and a landing page with the real form; a header injection may cover one template but omit another.
If the banner works while measurement still fails, continue with our consent and form-tracking checks. That is a different problem from script delivery.
Close the task only after a new visitor receives the intended choice interface, a returning visitor follows the saved preference, and keyboard and mobile users can reopen settings. HandL WP can trace the WordPress consent installation without treating technical testing as a legal compliance certification.
References reviewed October 9, 2026. Examples are explanatory, not customer test results.