Your WordPress plugins load trackers before anyone clicks accept

You installed a consent plugin. Your other plugins never asked it for permission.

The setup everyone trusts

A typical client site: a theme from the marketplace, a page builder, a forms plugin, an analytics plugin, a chat widget, maybe a tag manager. Then a consent plugin, configured once, with a banner that looks right.

The banner decides what happens after the click. But each plugin enqueues its own scripts, and many of them load with the page, before anyone clicks anything. On the WordPress.org support forums the complaint is word for word: analytics cookies "are being loaded before the user has given consent" (WordPress.org support, Apr 24, 2025).

Why WordPress makes this easy to miss

On WordPress, many hands load scripts. The theme loads Google Fonts from Google's servers. A page builder bundles its own libraries. A plugin adds a tracking pixel with one checkbox in its settings. The consent plugin only blocks what it was told to block, and a plugin update can add something new without telling anyone.

The site looks the same after every update. Nothing on screen says a new domain started receiving requests on page load.

What the report shows on a WordPress page

SiteMerit opens the page in a real browser, scrolls to the end and clicks nothing. Everything it records happened before the visitor chose anything. The full report shows:

• Tracking before consent. Requests to advertising, analytics and social media domains, tracking cookies and storage keys, session recorders, and Google Fonts fetched from Google before any choice. We detect signals of tracking before the choice; whether that is a problem where your client operates is a question for their counsel.
• Every cookie written on load, by the company that owns its domain, with its attributes and how long it lasts.
• The plugins we saw running, named by the files they load from /wp-content/plugins/, with a version when the plugin's own files agree on one. WordPress itself is named too, each with the evidence behind it.
• JavaScript libraries with a public security advisory, loaded in an identifiable version, with the advisory and the version that fixes it. Plugins often bundle an old copy of a library.
• The privacy policy link: whether the page links to the site's own policy, and whether that link opens.

The report lists what ran next to which third-party domains received requests. Tying a tracker to the plugin that loaded it is usually one step from there: the Initiator column of the browser's Network panel.

What to do with it

Start with the domains you can't explain. Find the plugin or theme setting that loads each one, and move it behind consent or turn it off. Host Google Fonts with the theme. Update or replace the plugin that ships a library with an advisory. Then run the audit again after the next round of plugin updates, because that is when new scripts appear.

The theme, while you are there

The same report checks the page's accessibility in the browser, after the JavaScript runs: text contrast, accessible names for fields, links and buttons, image text alternatives, page regions and ARIA. Page builders are a common source of icon buttons with no name and text that fails contrast on hover states. In the 2025 accessibility lawsuit data, 20.5% of the sued sites ran on WordPress (EcomBack, 2025 annual report).

We detect risk signals, with evidence. We don't certify compliance, we don't assess your consent banner, and we don't give legal opinions. Each report covers one page, the address you give us.

The same problem on any site: your site sets cookies before anyone clicks accept

It runs 8 checks on your page, 2 per area. Tracking before consent is not one of them: it needs the real browser of the full report. The full report runs all 45 checks, with evidence and a fix guide, for US$ 29.70, once, and your card is charged only when the report is delivered.