A polished cookie banner can still sit above a page that has already loaded analytics, advertising or embedded content. Consent is therefore a behaviour to verify, not a visual component to install.
This WordPress cookie consent workflow helps agencies identify technologies, configure categories, block optional scripts before the required choice and maintain the setup as the site changes.
This article is operational guidance, not legal advice. Requirements depend on jurisdiction, technology, purpose and the client’s processing. Obtain appropriate legal advice for the specific site.
Start with a technology inventory
Do not configure categories from memory. Inspect the production site and list:
- WordPress and plugin cookies;
- analytics and tag-management scripts;
- advertising and remarketing technology;
- embedded video, maps, chat and social widgets;
- payment and fraud-prevention services;
- external fonts and content delivery services;
- personalisation and testing tools;
- local storage and similar browser technologies;
- scripts injected by the theme, plugins or hosting platform.
For each item, record provider, purpose, data behaviour, duration, source location, owner and intended consent category.
Distinguish necessary and optional technology
Do not label a service “necessary” merely because the marketing team wants it.
The client’s legal assessment should determine which technologies are essential for a service requested by the visitor and which require a choice. Categories commonly include necessary, preferences, analytics and marketing, but labels do not decide the legal position.
Document the reason for each classification and the person who approved it.
Use one implementation workflow
1. Approve the inventory and categories
Resolve unknown technologies before launch. An unclassified script cannot be blocked reliably.
2. Map every optional script
Identify how it enters the page: direct theme code, plugin output, tag manager, embed, API or dynamic injection.
3. Keep optional scripts inactive before consent
Configure the site so restricted technology does not execute until the corresponding category is allowed.
4. Present a clear choice
Provide understandable information and routes to accept, reject or choose categories according to the approved legal design.
5. Store and publish the decision
Make the choice available to consent-aware components and retain only the evidence required by the approved policy.
6. Allow preference changes
Visitors should be able to reopen settings and change a previous choice.
7. Test real behaviour
Inspect network requests, cookies and storage before choice, after rejection, after granular consent and after withdrawal.
8. Monitor change
Repeat the inventory and tests when plugins, tags, embeds or campaigns change.
Block execution, not only cookies
Deleting a cookie after a script has transmitted data is not equivalent to preventing the script from running.
A blocking method may keep a script inert, omit it from the server response, intercept dynamic insertion or rely on a consent-aware integration. Test the chosen method with page caching, delayed scripts and tag managers.
If a tag manager loads before consent, its contained tags still need effective rules. If a video embed contacts a third party immediately, a visual placeholder may be required until the relevant choice.
Make the user interface honest
The banner and preference panel should reflect actual behaviour.
Check:
- category names match the site’s documentation;
- reject and granular controls behave as described;
- necessary items cannot be presented as optional if they are technically required;
- no preselected optional categories undermine the approved choice model;
- the settings link remains accessible after dismissal;
- keyboard and mobile interactions work;
- translations communicate the same choice accurately.
Avoid dark patterns or wording that disguises the effect of rejection.
Handle consent records proportionately
Consent logging can help demonstrate the system’s operation, but the log itself may involve personal data.
Define:
- what is recorded;
- why it is required;
- how identifiers are minimised or anonymised;
- retention period;
- access permissions;
- deletion or export handling;
- incident and backup treatment.
WordPress’s privacy guidance emphasises minimisation, retention and transparency. Do not retain detailed visitor records indefinitely merely because the plugin permits it.
Test a complete scenario matrix
At minimum test:
| Scenario | Expected result |
|---|---|
| First visit, no choice | Only approved default technology operates |
| Reject optional categories | Optional analytics and marketing remain inactive |
| Accept analytics only | Analytics can operate; marketing remains blocked |
| Accept all | Approved optional services can operate |
| Withdraw consent | Future optional activity follows the new choice |
| Clear browser storage | Site returns to the approved first-visit state |
| Cached page | Behaviour remains correct regardless of a previous visitor’s choice |
| Logged-in administrator | Testing is not distorted by admin-only exclusions |
Use a clean browser profile or private session and inspect network activity, not only visible cookies.
Review caching and performance features
Full-page caches can serve the same HTML to visitors with different consent states. Optimisation plugins may combine, delay or relocate scripts after the consent system has classified them.
After enabling caching, minification or script delay:
- purge caches;
- repeat the complete choice matrix;
- verify the first response contains no prematurely active optional code;
- confirm allowed scripts can still activate correctly;
- test desktop and mobile variants.
Use WpAgencyKit Cookies within the approved design
WpAgencyKit Cookies provides consent categories, script blocking, consent logging and WordPress Consent API integration. Its configuration must still reflect the client’s verified service inventory and legal decisions.
Use the plugin to implement and evidence the chosen behaviour. Do not present installation alone as compliance.
Ongoing maintenance checklist
- rescan after plugin, theme or campaign changes;
- review tag-manager containers;
- test first visit and every category combination;
- verify the preference panel and withdrawal path;
- check caching and optimisation interactions;
- update visitor information when services change;
- review retention and log access;
- record the test date, environment and result;
- escalate unknown technologies before approving release.
Treat consent as a maintained control
A cookie banner is a front end for a larger operating process. The agency must understand the technologies, implement the approved categories, prevent premature execution and retest after change.
The outcome to prove is not “the banner appears”. It is “the site behaves according to the visitor’s choice and the client’s approved policy”.