Cookie banner for a personal website or blog

With the WP Consent API plugin active but no consent banner on the site, Jetpack Stats 16.4 still loads its script and sends its pixel on the first page view: nothing refuses, so the gate lets it through. Installing WP Consent API alone does not make Stats wait.

Jetpack can store 21 cookies or browser keys for visitors: eucookielaw, personalized-ads-consent, tk_ai, wp-jp-premium-content-session, jetpack-subscription-modal-on-comment-scroll-to, jetpack-subscription-modal-shown-count, jetpack_blog_subscribe_*, jetpack_comments_subscribe_*, jpp_math_pass, verbum-wp-postpass, jetpack_sso_nonce, jetpack_sso_original_request, jetpack_sso_redirect_to, jetpack_sso_wpcom_gravatar_*, jetpack_sso_wpcom_name_*, jetpack_sso_wpcom_referrer, tk_lr, tk_or, tk_r3d, tk_tc, devicePixelRatio. Cookie Rocks recognises them from 2.9.8 and lists them in the cookie policy, each with its category and purpose, when it sees them.

With WP Consent API active, Cookie Rocks Pro turns on WP Statistics' consent integration by itself, without writing to WP Statistics' settings: no page view is counted before the choice, and one after "Accept all", without a reload.

On a fresh WordPress home page with default settings, Yoast SEO, Rank Math SEO, All in One SEO, Wordfence, Really Simple SSL, WP Armour and Akismet set no cookie for the visitor, keep nothing in the browser's storage and load no known third-party tool, after Accept all.

With Bypass Ad Blockers on (off by default), WP Statistics serves its tracker from an address like /?<6-character key>=<hash>, without the plugin name, and sends hits to admin-ajax.php; only the tag ID wp-statistics-tracker-js stays recognisable.

By default WP Statistics anonymises the IP address with WordPress' wp_privacy_anonymize_ip, then hashes it with sha256 of a salt renewed every day, the IP and the user agent; the full user agent is not stored. Hits are POSTed to the site's own REST route (or admin-ajax.php). Its geolocation database is downloaded by the server from cdn.jsdelivr.net or MaxMind; visitors' browsers contact no other site.

When WP Statistics' JavaScript tracking is turned off (server-side tracking), it records the visit in PHP while the page is built, before any banner can act, conditioned only on its consent integration read with wp_has_consent in PHP; it also cannot work with a page cache. Cookie Rocks 2.5.2 flags this mode on its dashboard with a button to WP Statistics' settings, and the warning disappears when client-side tracking is chosen again.

Koko Analytics defaults to the cookie tracking method. Its inline footer script sends the page view at once by sendBeacon (or fetch) to the site itself, and the server response sets _koko_analytics_pages_viewed (HttpOnly, path /, expires at the next midnight in the site's time zone). The JavaScript writes no cookie or storage, and no third-party host is contacted.

Koko Analytics' cookieless method keeps a server-side session file named by a hash of a daily seed, the user agent and the IP address, deleted after midnight. Since 2.x the tracking script is printed inline in wp_footer, so address patterns on assets/dist/js/script.js no longer match anything. It has no WP Consent API code.

Several Jetpack modules contact WordPress.com without reading any consent signal: Comments loads an iframe from jetpack.wordpress.com, Likes from widgets.wp.com, VideoPress from videopress.com, the Google Fonts module loads from fonts.gstatic.com, and Site Accelerator serves images from i0.wp.com. Jetpack's own visitor cookies (comment_author_*, jetpack_*_subscribe_*, jpp_math_pass) are set only after an action.

Jetpack's Cookie Consent block has a single button that only sets eucookielaw and fires eucookielaw-dismissed; it never calls wp_set_consent. With wordads_cmp_enabled, WordAds loads its own IAB consent tool, sets euconsent-v2 (1 year, server-side through admin-ajax) and disables the Jetpack banner. No gtag('consent') call was found.

WooCommerce Analytics (Jetpack module, on with WooCommerce) checks wp_has_consent('statistics') before each event, on the server and in the browser. Without WP Consent API, consent is assumed and pixel.wp.com/t.gif and stats.wp.com/s-*.js are sent for every visitor.

OMGF 6.3.13 works in its own output buffer (template_redirect, priority 3) and only rewrites <link> stylesheets from fonts.googleapis.com, fonts.bunny.net and fonts-api.wp.com to local copies in uploads/omgf/, removing preconnect, dns-prefetch and preload hints to those hosts; it touches no script or iframe. It sets no cookie and no browser storage; its front script loads only for logged-in administrators. After Save & Optimize it purges known page caches.

With OMGF's free version, fonts loaded by @import, inline @font-face, webfont.js or JavaScript still come from Google, as do fonts inside third-party iframes (maps, videos, reCAPTCHA), which its dashboard lists. If a download fails, the original link is kept (since 6.3.12). In test mode, only administrators get local fonts and visitors still load Google. A request with ?nomgf returns the unprocessed page.

By default Embed Plus for YouTube writes a normal youtube.com/embed iframe carrying no-lazyload and data-no-lazy=1, so lazy-load plugins leave its src in place. In facade mode there is no iframe in the HTML: a div with data-facadesrc and an i.ytimg.com thumbnail load before any choice, a playlist facade fetches youtube.com/oembed from the browser, and a click builds the YouTube iframe in JavaScript. Gallery thumbnails load from i.ytimg.com as CSS backgrounds, before any choice.

Embed Plus for YouTube's own Show Consent Message (off by default) is decided on the server from the cookie ytprefs_gdpr_consent: without the value 1, a message replaces each video and gallery thumbnails. The button sets that cookie for 30 days (path /) and reloads the page, so a cached page keeps showing the message (or the video) whatever the choice unless the cache varies on it. It does not use WP Consent API. The No Cookies option only switches the player host to youtube-nocookie.com.

When a comment or a supported form (Jetpack, Gravity Forms, Contact Form 7, Formidable, Fluent Forms) is sent, the site's server sends rest.akismet.com the visitor's IP address, user agent, referrer, every HTTP header except Cookie, the request URI and all submitted fields. A banner cannot hold this. Akismet's one-line privacy notice under the comment form is off by default.

Akismet sets no cookie and uses no browser storage on visitor pages, and the visitor's browser contacts no Akismet host. Its script, akismet-frontend.js, is served by the site (defer) only on pages with a comment form or a supported form shortcode and only once an API key is set; it records counts and timings of key presses, clicks, mouse, touch and scroll and adds them as hidden ak_* fields when a form is sent, without the typed text. A compatibility run of 5.7.2 without an API key observed nothing.

On a Divi site, OMGF (free version) replaced the Google Fonts stylesheets with local copies by itself on activation: every font, Divi's included, was served from /wp-content/uploads/omgf/ on the site's own domain, and the page sent no request to Google's font servers. OMGF's warning about unused fonts concerns @font-face declarations the browser does not download.