Why I built my own WordPress consent plugin
I built my own consent plugin, Consentimental, for my WordPress sites because consent was becoming a recurring product decision, not a one-time plugin setting. Across several sites, the licences for third-party consent tools add up. So does the work of fitting each tool around the same analytics, embeds, languages and publishing process.
Good consent management matters to me beyond the cost calculation. I operate websites in the EU and am bound by the GDPR. I want the choice visitors make to match what actually loads, the information they see to reflect the services in use, and withdrawal to have a real effect. That takes more than a banner that looks right.
Custom development has a cost too: I have to build, test and maintain it. For the number of sites I operate, that investment makes sense. I can use one codebase, change it when a real site needs something different, and remain responsible for the whole product instead of working around a vendor’s roadmap.
I also find it a little absurd that some consent plugins put Google Consent Mode v2 behind a premium tier. Passing a visitor’s choice to Google’s widely used analytics and advertising tools is a basic part of a consent setup on my sites, not an exotic extra. Consentimental supports both Basic and Advanced Consent Mode v2.
The behaviour I wanted to own
A consent banner is only useful when the page follows the decision behind it. Consentimental holds back configured scripts, iframes, images and pixels before they reach the browser. Visitors can accept or reject all optional services, decide by category, or make a choice for an individual service. Necessary stays active; optional categories start off.
When someone grants consent, the relevant content is released. Blocked embeds can show a placeholder with a way to allow that service. If consent is withdrawn, the plugin reblocks embeds, cleans up known cookies and browser storage, and normally reloads the page when a revoked script has already run. Changes also reach other open tabs on the same site.
That control extends into publishing. I can prepare changes to categories, services and scripts as a draft, preview them, and publish them together. If a published change makes an earlier choice outdated, visitors are asked again. Optional consent logs can retain the decision alongside an immutable snapshot of what was disclosed at the time.
Why a first-party route matters
There is another practical gap between a valid consent choice and a working measurement setup. A visitor may explicitly allow analytics, yet an ad blocker still blocks a familiar third-party script or endpoint. Consentimental has an optional first-party proxy for scripts managed through the plugin. I use that route for services including Umami and GA4 where the site’s configuration calls for it.
The proxy does not replace consent or guarantee that every blocker will allow every request. It gives me control over how an allowed service is delivered, so an explicit “yes” is less likely to disappear at a known tracking URL. A “no” remains a “no”. I wrote more about that distinction in this article on consent and ad blockers.
A setup I can verify
The plugin includes starting definitions for common services, but those definitions are only a starting point. Each site owner still has to confirm what the site actually uses and check the purposes, providers, domains, matching rules and cookie information. Custom services can be added where the built-in list does not fit.
A guided setup and site scanner help identify likely services and unknown external hosts. Configuration checks flag gaps such as unassigned scripts, incomplete disclosures, invalid proxy settings and unpublished changes. The status page separates configuration, discovery, proxy availability, browser enforcement and vendor receipt, instead of compressing all of that into one green light. Browser and vendor checks still need to be performed on the actual site.
The trade-off
Owning the code removes recurring licence dependence and lets me adapt the plugin without worrying that a vendor update will undo a workaround. It also means I own the maintenance burden. That is a good trade for my sites because the same core work can be reused and improved across them. It would not automatically be the right calculation for a single small site.
Some third-party consent plugins are technically very good. But I have seen major updates break even their own saved configurations more than once. Fixing that means investigating a product change I did not choose, at a point where consent behaviour needs to be dependable. With Consentimental, I decide when a change ships, test it against my sites and can fix the entire product myself. For my setup, that control makes it the more stable solution.
