WordPress Cookie Consent via the Consent API: The Enqueue Route
WordPress ships no cookie banner of its own, and no consent defaults, so until you add something, nothing asks for consent and nothing holds a tag back. The Consent API is the hook that lets you build a banner without a plugin, and the enqueue route is the cleanest way to do it: one script, registered in functions.php, loaded in the footer, with the consent state set before any tracker fires.
WordPress ships no banner, and no defaults
WordPress core ships no cookie banner and no consent mode defaults. Until you add a consent management platform, or a banner of your own, nothing asks for consent and nothing holds a tag back. That is the starting point, and it is the reason a WordPress site with Google Analytics and a contact form is already tracking visitors before any of them has been asked. The banner is not a feature to add later. It is the thing that has to be there before the tags are.
The Consent API is the hook that lets you build a banner without a plugin. It is a WordPress interface that lets plugins and themes signal consent states to each other, and it is the mechanism that Site Kit's consent mode toggle expects. It does not show a banner by itself. It is the hook that a banner, or a consent management platform, uses to tell the rest of the site what the visitor chose.
The enqueue route, in plain terms
The cleanest way to build a banner without a plugin is the enqueue route: one script, registered in functions.php with wp_enqueue_script, with a dependency on jQuery if the script needs it, and loaded in the footer. The script should set the consent defaults before any tracker fires, and the banner should be the first thing the visitor sees. A child theme's functions.php with an add_action on wp_head at priority 1 is equivalent to a plugin, and one fewer plugin to update.
The script has three jobs. First, show the banner, with accept, reject, and a settings panel that toggles categories individually, and no pre-ticked boxes, because pre-ticked boxes are not valid GDPR consent. Second, store the choice, usually as a first-party cookie, so the banner does not reappear. Third, load the trackers only after consent, by category, so nothing fires until the visitor gives explicit consent for that category. That is the whole banner, and it is the same banner that the without-plugin hooks post builds from the hooks side. The enqueue route and the hooks route are two ways into the same banner.
The plugin that bypasses your gating
The failure that catches most WordPress sites is a tracking plugin that prints its script straight into the page, without enqueueing it. A plugin that enqueues its script can be tagged with the script_loader_tag filter, so the script carries a type of text/plain and its category, and the consent tool runs it in page order after the visitor accepts. A plugin that prints its script straight into the page never reaches that filter, so it cannot be tagged and held back. The tracking runs before the visitor answers, and the banner is decoration.
The fix is to turn off the tracking output in every plugin that adds it, Site Kit, MonsterInsights, a tag manager plugin, or a pixel plugin, and to paste the snippet yourself, tagged with its category, into the footer code that holds the consent tool. A plugin that enqueues its script and does not offer an off setting needs the script_loader_tag filter. Get the tagged code from the consent tool's documentation, and test it with the network tab open.
The test that catches it
Open the site with the network tab open and a clean profile, and watch what loads before you click anything. If a tracking script fires, or if a cookie is set, the site is not gating it, and the banner is decoration. Then give consent, and watch the trackers load. Then withdraw consent, and watch them stop. That is the whole test, and it takes five minutes.
And clear every cache before you test, because a caching plugin can serve a page with the old, untagged scripts, and the test will pass on a page that is not the one visitors see. The cache is the part of the test that most people forget, and it is the part that makes the test lie.
Frequently asked questions
What is the WordPress Consent API?
The WP Consent API, which is a WordPress interface that lets plugins and themes signal consent states to each other. It does not show a banner by itself. It is the hook that a banner, or a consent management platform, uses to tell the rest of the site what the visitor chose.
How do I enqueue a consent script in WordPress?
Register the script in functions.php with wp_enqueue_script, with a dependency on jQuery if the script needs it, and load it in the footer. The script should set the consent defaults before any tracker fires, and the banner should be the first thing the visitor sees, not the last.
Do I need a plugin for a WordPress cookie banner?
No. A child theme's functions.php with an add_action on wp_head at priority 1 is equivalent, and one fewer plugin to update. The choice is between a plugin that does it for you and a theme function that does it yourself, and the theme function is the one that gives you control over the order.
Can a plugin bypass my consent gating?
Yes, and it is the most common failure. A tracking plugin that prints its script straight into the page, without enqueueing it, never reaches the script_loader_tag filter, so it cannot be tagged and held back. Turn off the plugin's tracking output, and paste the snippet yourself, tagged with its category.