Start with the API's real role
The official WordPress.org WP Consent API page describes it as a plugin that standardizes how accepted consent categories are communicated between plugins. It is not a consent banner and it does not decide what your site may load. It needs a banner plugin and at least one other plugin that supports the API.
That distinction matters for WordPress teams. The API is useful when a supporting plugin can ask whether a category such as statistics or marketing has consent before it sets storage or starts tracking. The banner still has to present clear choices, store the visitor's decision, and update the API when the decision changes.
Map banner categories deliberately
WP Consent API uses categories including functional, preferences, statistics, statistics-anonymous, and marketing. Most WordPress banners use a similar but not identical category model. Do not assume names line up automatically. Decide which banner category controls each API category, then test a reject path and a custom path.
ACookies maps required functionality as allowed, preferences to the preferences category,
analytics to statistics and statistics-anonymous, and marketing to marketing when
wp_set_consent is available. The same banner choice can also update Google Consent
Mode signals such as analytics_storage, ad_storage,
ad_user_data, and ad_personalization.
Do not confuse signaling with blocking
The WP Consent API page is clear that the API provides a framework for plugins to know whether they are allowed to place cookies or track data. It does not block every third-party iframe, external script, or hard-coded theme snippet by itself. Those still need blocking, delayed loading, or replacement behavior from the consent management implementation.
Google Consent Mode has a separate job. Google explains that consent mode adjusts how Google tags behave based on consent choices, and its website setup guide lists additional v2 signals for advertising user data and personalization. That makes it complementary to WP Consent API, not a replacement for WordPress plugin-to-plugin communication.
Use a WordPress-first review workflow
Treat WP Consent API support as one part of a broader site review. Check which WordPress plugins support the API, which scripts are managed by the banner, and which tags still need manual rules. Then scan a real page, inspect cookies and network requests, and verify Google signals with Tag Assistant when Google tags are present.
- Confirm the WP Consent API plugin is present only if your stack needs that bridge.
- Map banner categories to API categories before publishing copy.
- Test accept all, reject optional, and custom choices.
- Scan the public site again after changing plugins, cache, GTM, or theme code.
- Document remaining scripts that require manual blocking rules.
Frequently asked questions
Does the WP Consent API replace a cookie banner?
No. The official WordPress.org plugin page says WP Consent API needs a cookie banner plugin and another plugin that supports the API. It standardizes communication; it does not collect consent by itself.
Does the WP Consent API block every third-party script?
No. The API lets supporting plugins read consent categories, but third-party scripts and iframes still need blocking or delayed loading from the consent management setup.
How does ACookies use WP Consent API signals?
When the API is available, ACookies maps its visitor categories to WP Consent API categories such as functional, preferences, statistics, statistics-anonymous, and marketing.