DPDP-compliant cookie consent on WordPress: what your banner is getting wrong
TL;DR: The cookie bar on most Indian websites says "By continuing to browse this site, you agree to our use of cookies." That is a notice, not consent, and it does not satisfy the DPDP Act. Consent under the Act must be free, specific, informed, unconditional and unambiguous, expressed through a clear affirmative action.
The practical translation for WordPress: a visitor must be able to reject non-essential cookies as easily as accept them, choose categories separately, withdraw later without hunting for a hidden link, and see the choice actually enforced before any tracking script fires. Most banners fail the last one even when they pass the first three, because the plugin displays a choice while Google Analytics has already loaded.
Why cookies fall under the DPDP Act at all
The Act does not contain the word "cookie" as an operative term, which is the source of a great deal of wishful thinking.
What it governs is the processing of digital personal data, meaning data about an identifiable individual held in digital form. The question is therefore not whether a cookie is a cookie. It is whether the cookie processes personal data.
For a session cookie that holds a shopping cart identifier and nothing else, the answer is arguably no. For a Google Analytics cookie that assigns a persistent identifier, records behaviour across sessions and combines it with IP-derived location, the answer is clearly yes. For a Meta Pixel that ties browsing behaviour to an advertising profile, it is not close.
The same reasoning extends past cookies. A tracking pixel, a fingerprinting script, a session-replay tool that records mouse movement and form input, a chat widget that stores a visitor ID: none of these are cookies in the technical sense, and all of them process personal data. A banner that manages only cookies while a session-replay script runs unrestricted is solving a labelling problem rather than a compliance one.
So the working rule is straightforward. If a technology on your site identifies a person, tracks them across pages or sessions, or feeds a profile about them, it needs consent. If it is strictly necessary to deliver the thing the user asked for, it does not.
The DPDP Rules were notified on 13 November 2025, with full compliance required by 13 May 2027. That is the horizon for getting this right, and the reason to start now is that consent is not retroactive. Analytics data gathered without valid consent between now and then does not become lawful in May 2027.
What consent has to look like under the Rules
The Act sets a specific standard. Consent must be free, specific, informed, unconditional and unambiguous, and it must be signified by a clear affirmative action.
Unpack each of those, because every one of them kills a common banner design.
Free means the visitor must have a real choice. If the only way to read your article is to accept tracking, the consent is not free. A reject option must exist and must lead somewhere.
Specific means consent is tied to defined purposes. One blanket permission covering analytics, advertising, personalisation and third-party sharing is not specific. The visitor should be able to accept one and refuse another.
Informed means the visitor knows what they are agreeing to before they agree. Not a link to a 4,000-word policy they will never open, but a plain statement of purposes at the point of decision, with detail available for anyone who wants it.
Unconditional means you do not bundle consent for tracking into acceptance of your terms of service. Two separate things, two separate decisions.
Unambiguous with a clear affirmative action is the one that removes most Indian banners in a single stroke. Continued browsing is not an affirmative action. Scrolling is not an affirmative action. Pre-ticked boxes are not an affirmative action, because the user did not do anything. Closing the banner with an X is ambiguous, since it might mean acceptance or might mean "go away."
Two further requirements sit alongside these. Consent must be as easy to withdraw as it was to give, which means a persistent, findable way to change the decision rather than a paragraph buried in the privacy policy explaining how to clear browser cookies manually. And you must be able to demonstrate that valid consent was obtained, which means logging it.
There is also a language dimension specific to India. The Act contemplates notices being made available in English or in the languages listed in the Eighth Schedule of the Constitution. For a site whose audience is substantially non-English-reading, a purely English consent notice sits uncomfortably against the requirement that consent be informed.
Five patterns that fail
These are the designs currently deployed across most of the Indian web.
The implied-consent bar. "By continuing to use this site, you accept our cookie policy." No button, no choice, tracking already running. This fails on affirmative action, on specificity, and on freedom. It is the single most common pattern in India and it satisfies none of the Act's requirements.
Accept-only. A banner with one button reading Accept and no reject option. The visitor can accept or can live with the banner obscuring the page forever. That is not free consent, it is attrition.
The dark-pattern pair. A large, bright, high-contrast Accept button next to a small grey text link reading "manage preferences," which opens a second screen where rejecting takes four more clicks. Regulators elsewhere have treated asymmetry of effort as invalidating consent, and the reasoning applies directly to the freely-given requirement.
Pre-ticked categories. The banner shows toggles for analytics and marketing, and all of them are already on. Pre-selection is the opposite of affirmative action. The visitor who clicks Save without touching anything has not consented to what the toggles claim they consented to.
The cosmetic banner. This one passes visual inspection and fails in the network tab. The banner offers proper categories and an equal reject button, but the plugin was installed without blocking mode, so gtag.js and the Meta Pixel load in the page head before the visitor sees anything. The consent is recorded correctly and enforced not at all.
The fifth is the most common failure among sites that have genuinely tried. It is invisible from the front end and takes ninety seconds to detect: open DevTools, go to the Network tab, hard-refresh, and look at what loaded before you clicked anything.
Banner patterns and where each one stands
| Pattern | Affirmative action | Reject as easy as accept | Category-specific | Scripts blocked first | Position |
|---|---|---|---|---|---|
| Implied consent, no button | No | No | No | No | Fails |
| Accept-only button | Partial | No | No | Usually not | Fails |
| Accept large, reject buried | Yes | No | Sometimes | Sometimes | Fails |
| Pre-ticked categories | No | Yes | Nominally | Sometimes | Fails |
| Equal accept/reject, no categories | Yes | Yes | No | Sometimes | Weak |
| Equal buttons, categories, blocking on | Yes | Yes | Yes | Yes | Compliant |
| Compliant banner plus consent log | Yes | Yes | Yes | Yes | Compliant and provable |
The bottom two rows are the target. The difference between them is whether you can prove any of it eighteen months later, which is covered further down.
Which cookies actually need consent
Not everything needs a toggle, and over-gating harms usability without improving compliance.
Strictly necessary, no consent required. Session cookies that maintain login state. Cart contents in WooCommerce. CSRF tokens. Load-balancer affinity cookies. The cookie that stores the visitor's consent choice itself, which is necessary and would be absurd to gate behind consent. Security cookies from a firewall or bot-protection layer.
The test is whether the site can deliver the service the user explicitly requested without it. "Our marketing team needs it" is not necessity.
Consent required. Google Analytics in every configuration, including GA4 with anonymised IP, because it still assigns a persistent identifier. Meta Pixel, Google Ads conversion tags, LinkedIn Insight, and every other advertising pixel. Hotjar, Clarity, and other session-replay or heatmap tools, which are among the most invasive things on a typical site and among the least often gated. Embedded YouTube in its default form, which sets advertising cookies on load, though the privacy-enhanced mode reduces this. Third-party chat widgets that persist a visitor identifier. A/B testing tools that bucket users persistently.
The awkward middle. WordPress core sets wordpress_test_cookie and comment-author cookies. Comment cookies store a name and email, which is personal data, and are usually handled by the checkbox WordPress already provides at the comment form. That checkbox, unticked by default, is a decent model for what affirmative consent looks like.
A practical starting move: run your homepage and one product page through a cookie scanner, then reconcile the output against what you believe is installed. Most site owners discover two or three trackers nobody remembers adding, usually left behind by a theme demo or an agency that has since moved on.
Choosing a WordPress plugin
The plugin market is crowded and most options are built for GDPR, which is helpful rather than sufficient. GDPR-shaped consent mechanics overlap heavily with what DPDP requires, so a good GDPR plugin gets you most of the way. What it will not give you by default is India-specific notice content, Eighth Schedule language support, or a grievance officer reference.
What to require, regardless of which plugin you pick.
Prior blocking. The plugin must prevent scripts from executing until consent is given, not merely record a preference. This is the feature that separates real implementations from decorative ones, and it is often gated behind the paid tier. If the free version only shows a banner, the free version does not make you compliant.
Granular categories. Separate toggles for analytics, advertising and functional, each independently rejectable.
Symmetric buttons. Accept and Reject rendered with equal visual weight at the same level. If the plugin's template puts Reject behind a secondary screen and offers no way to change that, pick a different plugin.
A consent log. Timestamped records of what was consented to, in what version of the notice, with an identifier that lets you retrieve a specific record.
A persistent reopen control. A small floating control or footer link that brings the preference panel back. Without this, withdrawal is not as easy as granting.
Google Consent Mode v2 support. If you run Google Ads or GA4, this matters practically, because it lets tags load in a restricted state rather than not at all, preserving modelled conversions while respecting the choice.
Server-side or CDN-friendly caching behaviour. Consent banners and aggressive page caching interact badly. A plugin that renders the banner state server-side into a cached page will show the wrong state to the wrong visitor. Look for one that handles the consent check client-side against a cookie, and test it with your cache warm rather than on a fresh install.
That last point catches people running LiteSpeed or any full-page cache, which is most performance-tuned WordPress sites. Test after configuring, not before.
Configuring it so the choice is enforced
Installation is not configuration. Here is the sequence that produces a banner that actually does something.
Scan first, configure second. Run a cookie scan and get the real inventory. Configuring categories against a guessed list means uncategorised scripts default to unblocked.
Move every tracking script into the plugin's control. Scripts hardcoded into header.php, injected by the theme options panel, or added through a separate "insert headers and footers" plugin sit outside the consent plugin's blocking and will fire regardless. This is the most common reason a correctly-configured banner still leaks. Every tag should either be managed by the consent plugin directly or routed through Google Tag Manager with consent mode wired up.
Set the default state to rejected. Before any interaction, non-essential categories are off. Verify by loading the site in a private window and checking the Network tab before clicking.
Write the notice text yourself. Default plugin copy is written for the EU. Replace it with plain language stating what you collect, why, and who it goes to, and reference your grievance officer. Short sentences. The point is that a person understands it in four seconds.
Configure the reopen control and test withdrawal end to end. Accept, then reopen, then reject, then hard-refresh and confirm in the Network tab that the previously-permitted scripts no longer load. A surprising number of implementations record the withdrawal and keep firing the tags until the cookie expires.
Test with your cache enabled. Purge, load as a new visitor, accept, then load a different cached page and confirm the state carried. Then repeat as a rejecting visitor.
Re-test after every theme or plugin update. Updates reintroduce hardcoded scripts more often than you would expect.
The whole verification loop takes about twenty minutes and it is the only part of this process that produces evidence rather than intent. If you have a staging environment, do it there first; our note on WordPress staging covers setting one up.
Proving consent when someone asks
The obligation is not only to obtain consent. It is to be able to demonstrate that you obtained it.
If the Data Protection Board investigates a complaint, the question will be specific: when did this person consent, to what, and in what version of the notice? A banner with no logging cannot answer that, and "our plugin showed a banner" is not evidence about an individual.
What a usable consent record contains: a consent identifier, a timestamp, the categories accepted and refused, the version of the notice text displayed, the language it was displayed in, and the method of collection. Not the visitor's full IP address stored indefinitely, which creates a new personal data problem in the process of solving an old one. A hashed or truncated identifier is generally sufficient and proportionate.
Two related habits. Version your notice text, so a change to your cookie policy produces a new version number rather than silently rewriting the terms every past visitor agreed to. And set a retention period for consent logs, because a log kept forever is itself a data store you now have obligations over.
Re-consent is the question people ask next. If you materially change the purposes, adding a new advertising vendor, starting to share data with a partner, you are asking for something the visitor did not previously agree to, and prior consent does not cover it. Cosmetic changes to wording do not require re-consent. New purposes do.
What this costs you in analytics, honestly
It costs you data. Anyone who tells you otherwise is selling something.
When visitors are given a genuine, equally-weighted choice, a meaningful share decline. Reported opt-in rates vary widely by audience, sector and design, but the direction is consistent: a properly implemented banner with a real reject button collects less analytics data than an implied-consent bar that collected from everyone.
That is not a bug in your implementation. It is the point of the law.
What you can do about it legitimately: use Google Consent Mode v2 so denied traffic still contributes modelled data rather than vanishing entirely. Lean harder on server-side signals you own, such as order counts, form submissions and revenue, which are not consent-gated in the same way because they are records of transactions the user initiated. Watch trends rather than absolute numbers, and re-baseline after the change rather than comparing against pre-banner figures forever.
What not to do: soften the reject button until it stops working, treat "manage preferences" as the reject path, or set a consent cookie with a one-day expiry so the banner reappears until the visitor gives in. Each of these is a design decision to make consent less free, and each is legible as such to anyone who looks.
The businesses that handle this well decide early that a smaller set of consented data is what they are working with, and adjust their measurement to suit. The ones that struggle spend eighteen months trying to engineer their way back to the numbers they had before.
FAQs
Does the DPDP Act require a cookie consent banner?
The Act does not name cookies, but it requires free, specific, informed and unambiguous consent before processing digital personal data, given through a clear affirmative action. Most analytics and advertising cookies process personal data by assigning persistent identifiers, so in practice a consent mechanism is required. Strictly necessary cookies, such as session and cart cookies, do not need consent.
Is "by continuing to browse you accept cookies" valid under DPDP?
No. Consent must be signified by a clear affirmative action, and continued browsing is not an affirmative action. This implied-consent pattern is the most common cookie notice on Indian websites and it fails the Act's standard on affirmative action, specificity and freedom of choice simultaneously.
Do I need a reject button on my cookie banner?
Yes, in practice. Consent must be freely given, which means refusing must be a real and equally available option. A banner offering only Accept, or one where rejecting requires more clicks than accepting, does not meet the freely-given standard. Reject should sit at the same level, with the same visual weight, as Accept.
Can I pre-tick the analytics and marketing toggles?
No. Pre-ticked boxes are not a clear affirmative action, because the visitor has not done anything to signify agreement. All non-essential categories must default to off, and the visitor must actively switch on what they permit before any corresponding script executes.
Which cookies do not need consent under DPDP?
Cookies strictly necessary to deliver the service the user asked for: session and authentication cookies, shopping cart contents, CSRF tokens, load-balancer affinity, security and bot-protection cookies, and the cookie storing the consent choice itself. The test is whether the site can provide what the user requested without it, not whether your marketing team finds it useful.
Does Google Analytics need consent in India?
Yes. GA4 assigns a persistent identifier and processes behavioural data linked to an identifiable visitor, which is digital personal data under the Act. IP anonymisation reduces the data collected but does not remove the identifier, so consent is still required before the tag fires. Google Consent Mode v2 lets tags load in a restricted state so you retain modelled data from users who decline.
Why does my cookie banner still load tracking scripts?
Because the plugin is recording a preference rather than blocking execution. Prior blocking is a distinct feature, often only in paid tiers, and without it scripts in the page head fire before the banner appears. Scripts hardcoded into the theme or added through a separate header-injection plugin also sit outside the consent plugin's control and must be moved under it.
How do I check whether my banner actually works?
Open the site in a private window with DevTools on the Network tab, hard-refresh, and look at what loaded before you clicked anything. If you see requests to Google Analytics, Meta or a session-replay tool, the banner is decorative. Repeat the test after accepting, then after withdrawing consent, confirming the scripts stop firing.
Do I need to keep a record of consent?
Yes. The Act expects you to be able to demonstrate that valid consent was obtained, which requires a log containing a consent identifier, timestamp, the categories accepted and refused, and the version and language of the notice displayed. Store an identifier rather than a full IP address, and set a retention period for the log itself.
Does a GDPR cookie plugin make me DPDP compliant?
It gets you most of the mechanics, since the consent standards overlap substantially, but not the whole way. You still need India-specific notice content, a reference to your grievance officer, consideration of Eighth Schedule language availability for non-English audiences, and alignment with DPDP's own withdrawal and demonstrability requirements. Treat a GDPR plugin as the engine, not the finished configuration.
Does the banner need to be in Hindi or regional languages?
The Act contemplates notices being available in English or in languages listed in the Eighth Schedule. Consent must also be informed, which is difficult to argue for an English-only notice shown to an audience that largely does not read English. If a substantial share of your traffic is non-English-reading, offering the notice in the relevant language is the safer and more defensible position.
When do I need to ask for consent again?
When you materially change the purposes, such as adding a new advertising vendor or beginning to share data with a partner, because prior consent does not cover a purpose the visitor never agreed to. Cosmetic rewording of the notice does not require re-consent. Versioning your notice text makes it possible to tell the two apart later.
Conclusion
The cookie banner is the most visible piece of DPDP compliance and one of the easiest to get wrong in a way that looks right. A site can display a well-designed panel with four categories and a proper reject button, and still be transmitting behavioural data to three vendors before the visitor has seen it.
Design and enforcement are separate problems. Only one of them is visible from the front end.
The three things that decide whether your implementation is real: non-essential categories default to off, every tracking script sits under the consent plugin's control rather than hardcoded elsewhere, and you can open the Network tab and see nothing fire before a click. Everything else is refinement.
Then log the consent, because obtaining it and proving you obtained it are different obligations, and the second one only exists in the past tense.
You will collect less analytics data afterwards. Plan for that rather than engineering around it, because the workarounds, the buried reject link, the reappearing banner, the asymmetric buttons, are exactly the patterns that turn a compliance question into an enforcement one.
HostCloud runs WordPress on LiteSpeed with server-level caching that plays properly with client-side consent checks, so your banner state does not get baked into a cached page and served to the wrong visitor. Plans start at ₹99 a month at https://hostcloud.in, and free migration is included if you are moving an existing site.