Thanks for the framing — this was a real UX gap and you are right that the workaround of deleting GTM rows by hand is lossy because the scanner re-adds them on the next run.
Quick context on what was actually happening, because the backend was further along than the UI suggested. The settings sanitiser already accepted Necessary as a valid category for custom script-blocking rules — the eight built-in blocker templates that ship with the plugin (Cloudflare Turnstile, Gravatar, reCAPTCHA, hCaptcha, Wordfence, WPForms, Ninja Forms reCAPTCHA, WooCommerce Attribution) are stored as Necessary rules and they survive a save without issue. The hole was strictly in the admin JS that builds the dropdown for the Custom Blocking Rules table: that array hardcoded analytics, marketing, functional, performance, and Necessary was silently absent from the picker even though the backend would have persisted it.
In version 1.13.17 (out now) Necessary is in the dropdown. You can mark googletagmanager.com or any other always-on script as Necessary and it loads unconditionally regardless of consent state. The auto-scanner already respects the rule (it categorises only into the categories you have not pre-claimed via custom rules), so a rule that points googletagmanager.com at Necessary will keep being honoured across re-scans rather than being moved back into Analytics. The same applies to gtm.start and the inline GTM bootstrap once you point them at Necessary by URL pattern or handle.
I considered pre-populating googletagmanager.com, gtm.start and dataLayer as Necessary out of the box and decided against it for now — those identifiers genuinely belong in Analytics on many sites (the GDPR-cautious posture is “load GTM only after consent”), and shipping them as Necessary by default would silently override that consent boundary for installs that did not opt into it. The right move is to expose Necessary in the dropdown — which 1.13.17 does — and let each admin pick the trade-off explicitly for their site.
Best,
Fabio
Quick follow-up: version 1.13.17 is out now on wordpress.org and the Necessary category is in the Custom Blocking Rules dropdown.
So your GTM workflow is now this: open Settings, Script Blocker, Custom Rules, add a rule that matches googletagmanager.com (or any other always-on script you need to keep alive), and pick Necessary in the dropdown. From that point on the script loads unconditionally, regardless of consent, and the auto-scanner will not move it back into Analytics on the next run because rules you set explicitly always win over what the scanner detects.
I decided not to ship googletagmanager.com or dataLayer as Necessary out of the box. On many sites the GDPR-cautious choice is to load GTM only after the visitor accepts, and shipping it as Necessary by default would silently override that boundary for installs that did not opt in. With the dropdown change you can pick the trade-off explicitly for your site, which felt like the right line to draw.
