Joomla administrators have a component called Privacy sitting in their control panel, complete with consent logging and data-request handling. It is easy to assume it covers cookies. It does not, and that assumption is the single most common reason a Joomla site running Google Ads in Europe is quietly losing most of its conversion data.
This article covers what Joomla actually gives you, what Google Consent Mode v2 actually requires, where to put it in a Joomla 5 or 6 site, and the four platform-specific traps that make it appear to work while doing nothing.
Joomla core has no cookie banner, and Privacy is not one
Joomla’s Privacy tool suite arrived in Joomla 3.9 and is still there in Joomla 6.1, released in April 2026. It does real work: it records consent given on forms, it handles subject access and erasure requests, it lets you export a user’s data, and it gives extension developers a way to declare what they store.
None of that touches cookies. The Privacy component displays no banner, sets no consent cookie, and blocks no script. A visitor can land on your Joomla site, have Google Analytics fire immediately, and the Privacy component will neither know nor care.
That gap is deliberate and long-acknowledged in the project. It also means every Joomla site is in exactly the same position: cookie consent is something you add, and the only question is what you add.
What Consent Mode v2 requires
Since March 2024, Google requires advertisers reaching the European Economic Area and the United Kingdom through Google Ads, Google Analytics 4 or Google Tag Manager to send consent signals using Consent Mode v2. Two years on, this is enforced rather than advisory: accounts that do not send the signals see policy warnings and degraded measurement, and remarketing features stop building audiences.
Consent Mode v2 is four parameters, not four settings:
| Parameter | Governs |
|---|---|
analytics_storage | Analytics cookies and measurement |
ad_storage | Advertising cookies |
ad_user_data | Sending user data to Google for advertising |
ad_personalization | Personalised advertising and remarketing |
The two on the bottom row are what v2 added to v1. A banner written before 2024 and never updated will send the first two and omit the others, which Google treats as no consent at all for advertising purposes.
Two details decide whether an implementation works, and both are about ordering rather than about code:
The default must be denied, and it must be set before any Google tag loads. If gtag('config', ...) runs first, the tag has already made its decision. The consent default has to be the first thing in the page.
The update must fire the moment the visitor chooses, not on the next page load. A banner that only applies consent after a reload loses the conversion that just happened.
For the full picture of Basic versus Advanced mode and what conversion modelling recovers, see our Consent Mode v2 setup guide, which covers the mechanics across every platform.
Adding it to Joomla without an extension
Here is the part most Joomla guides get wrong. They send you to the Extensions Directory because that is what one does on Joomla. But Consent Mode is emitted by JavaScript in the browser, not by PHP on the server. Joomla never sees it. An extension gives you a settings screen in the administrator; it does not give you a capability the platform otherwise lacks.
A banner that ships as a plain script tag therefore works on Joomla exactly as it works on a hand-written HTML page. Ours is one line:
<script src="https://weblegal.ai/js/wl-cookie-consent.js"
data-lang="en"
data-privacy-url="/en/privacy-policy/"></script>It sets all four Consent Mode v2 parameters to denied before any Google tag can load, creates the dataLayer and gtag stub itself so that later gtag('config', ...) calls inherit that default, and sends gtag('consent', 'update', ...) the instant the visitor chooses. It also blocks the trackers themselves rather than merely signalling about them, which is what the GDPR requires and what Consent Mode alone does not do.
Where to put it
In the template, if you maintain one. Open System, then Site Templates, and edit index.php. Paste the script before <jdoc:include type="head" /> if you want to be certain nothing Google-related runs ahead of it. On Joomla 5 and 6, do this in a child template rather than the parent, or the next template update will overwrite it.
In a module, if you would rather not touch PHP. Create a Custom HTML module, paste the snippet, publish it to a head position on all pages, and set Menu Assignment to “On all pages”. Two conditions: the module must not have a title displayed, and your template must genuinely render the position you chose — many templates declare positions they never output.
Through Google Tag Manager, if you already run it. Possible, but be careful: the consent default must fire before GTM itself, so it belongs in the page, not in a GTM tag. Putting the default inside GTM is the classic implementation that measures as broken.
Four Joomla traps that break it silently
Each of these produces a site where the banner appears, the console shows no error, and the signals never arrive.
Page caching serving a stale state. Joomla’s System – Page Cache plugin, the Cache system plugin, and every third-party caching extension store rendered HTML. If any part of your consent logic is decided server-side, cached pages will serve one visitor’s state to another. The fix is to keep the decision client-side — a script that reads its own cookie in the browser is immune — or to exclude the banner from caching entirely.
Template edits lost on update. Editing the parent template’s index.php directly works until the day you update the template, which replaces the file. Joomla 5 introduced child templates precisely for this. Use one.
Two banners fighting. If a cookie extension is already installed, even disabled-but-not-uninstalled, check whether its plugin is still enabled. Two scripts both calling gtag('consent', 'update', ...) will overwrite each other in load order, and load order on Joomla depends on plugin ordering that you probably have not looked at in years.
The analytics plugin that runs first. Several popular Joomla analytics plugins inject the GA4 tag through onBeforeCompileHead, which is early. If your consent script is added later in the head, the tag has already loaded with no consent default. This is the ordering problem again, and it is why the snippet belongs above the jdoc head include rather than below it.
What the Joomla extension route costs
The Joomla Extensions Directory has a healthy set of consent tools — Web357’s Cookies Policy Notification Bar, CookieMan, the GDPR component from J!Extensions Store, Cookie Banner Pro, ConsentLab, and free options such as DC Cookies. Several are genuinely good, and if you want the whole thing configurable from the administrator with Joomla-native language handling, they earn their keep.
What you are buying is administration, not capability. Most are commercial with annual renewal, which for a small Joomla site is a recurring cost against a problem that a script tag solves once. And every extension is one more thing to keep updated across Joomla 5.4 and 6.1, on a platform where an abandoned extension is a familiar story.
Our own position is straightforward: the cookie banner is free, with no account and no licence, because it exists to bring people to the documents. It blocks dozens of tracker families before consent rather than only signalling to Google, which is the part that actually matters under the GDPR. The paid product is the legal documents — packs from €19.90, bought once, no subscription.
Consent Mode is not compliance
Worth stating plainly, because a lot of Joomla threads conflate the two. Consent Mode v2 is a Google requirement about signals. The GDPR is a legal requirement about behaviour. Satisfying the first does not satisfy the second.
A Joomla site is compliant when trackers do not run before consent, when refusing is as easy as accepting, when consent can be withdrawn as easily as given, and when a cookie policy documents what is set and why. Consent Mode v2 sits on top of that. It does not replace any of it.
If you are not sure where your Joomla site stands, the fastest check is to look at what actually fires before anyone clicks anything — which is exactly what a scan reports.
FAQ
Does Joomla have a cookie banner built in?
No. Joomla core ships a Privacy component, introduced in Joomla 3.9, but it handles data-subject requests, consent logging on forms, and data export or removal. It displays no cookie banner and blocks no tracker. Cookie consent on Joomla is always something you add.
Do I need a Joomla extension for Consent Mode v2?
No. Consent Mode is emitted by JavaScript in the page, not by PHP, so any banner that ships as a script tag works on Joomla exactly as it does anywhere else. An extension buys you a settings screen, not a capability.
Where exactly do I paste the script?
Before the closing head tag of your template’s index.php, above <jdoc:include type="head" /> if you want to be certain it runs first. If you would rather not touch the template, a Custom HTML module published to a head position on all pages works, provided your template actually renders that position.
Will a template update wipe my change?
It will if you edit the parent template. Joomla template updates replace index.php. Use a child template on Joomla 5 and 6, or the module route, and the change survives.
Why does my banner appear but Consent Mode show no signal?
Almost always page caching. Joomla’s System – Page Cache plugin and most third-party caches serve stored HTML, so the state the browser sees can lag the consent actually given. Keep the decision client-side, or exclude the banner from caching.
Can I run this alongside an existing Joomla cookie extension?
You should not. Two banners both calling gtag('consent', 'update', ...) overwrite each other in an order you do not control. Disable one before enabling the other.
