Real Cookie Banner - WordPress Plugin

Real Cookie Banner for WordPress Setup Guide

Real Cookie Banner is not there just to show visitors a polished popup with a few buttons. On a live WordPress site, it becomes the control center for consent management: it helps you document services, block external embeds until consent is given, store proof of the visitor's choice, and verify that third-party scripts are not loading too early on the page.

In this guide, we will look at the plugin as a practical tool rather than a formal banner. We will start with preparation and installation, then configure service groups, the service scanner, content blockers, appearance, Google Consent Mode, multilingual behavior, and result verification. We will also walk through a site scenario with YouTube videos and analytics, because that is where issues tend to surface most often.

This material is not legal advice. It explains the technical logic behind the setup: where to find the right sections in WordPress, which decisions require deliberate judgment, how to verify that the banner works properly, and what to do if the consent window reappears on every page or does not show up in a specific browser.

What Problem the Plugin Solves and Why a Simple Popup Is Not Enough

Real Cookie Banner belongs to the Consent Management Platform class for WordPress. In everyday language, tools like this are often called cookie banners, but in practice the job is broader: the site must explain which services process data, obtain informed consent, avoid loading non-essential services before that consent is given, and keep a record of the visitor's choice.

The product's key distinction is that it is installed like a standard WordPress plugin and runs on your own site. According to its WordPress.org page, consents are processed and stored on your server rather than loaded from an external cloud into the visitor's browser. For a site owner, that changes how verification should be done: you need to look not only at the banner itself, but also at the REST API, cookies, cache, local consent storage, and theme compatibility.

What the Working Setup Includes

In a working setup, there are four layers. The first is the service list, for example Google Analytics, Google Tag Manager, YouTube, Vimeo, Google Maps, Meta Pixel, or a form with reCAPTCHA. The second is service groups, so the visitor sees clear categories and can give partial consent. The third is the content blocker, which holds back an iframe, script, link, or other element until the related service is accepted. The fourth is the consent log and the technical cookies used by Real Cookie Banner itself.

If you configure only the banner text and appearance but do not connect services to the actual scripts and embeds, the site may look "compliant" while still loading unnecessary resources before the visitor has made a choice. That is why throughout this guide we will keep connecting each action in the admin panel to a verification step on the public site.

How the Service Scanner Differs from a Cookie Scanner

The official documentation highlights an important limitation: Real Cookie Banner uses a service scanner and does not claim to magically discover every cookie. The scanner checks the sitemap, crawls pages, analyzes external URLs, scripts, iframes, inline @font-face, installed plugins, and certain special systems such as Cloudflare. If a detected item matches a known pattern, the plugin suggests a ready-made configuration; if not, it shows the finding for manual setup.

This is a strong feature, but not a reason to switch off your judgment. The scanner may miss a service that appears only after JavaScript loads, such as a video opened in a lightbox after a click. It also does not replace reviewing the processing purpose, the provider's policy, the technical description of cookie-like storage, and the site's actual behavior. The correct way to frame it is this: the scanner speeds up inventory work, but the final responsibility for the service list and the accuracy of the descriptions stays with the site owner.

Who Real Cookie Banner Is a Good Fit For and When Another Approach May Be Better

The plugin is especially useful for sites that rely on external embeds, analytics, advertising pixels, maps, videos, spam-protected forms, marketing tags, or multilingual content. On a simple blog with no analytics, external fonts, embeds, or marketing stack, setup will be easier, but even there it is worth checking whether the theme or another plugin loads third-party resources.

When the Product Is a Good Choice

Real Cookie Banner is a good fit for WordPress sites where the administrator wants to manage consent inside the CMS rather than through a separate external platform. It works well for agencies, content sites, WooCommerce stores, corporate websites, and multilingual projects when it matters to see a consent list, work with ready-made templates, create custom services, and configure content blockers for specific embeds.

Another strong use case is a site that already uses Google Tag Manager or Google Consent Mode. The devowl.io documentation includes dedicated guidance for Google Consent Mode, Google Tag Manager, and Matomo Tag Manager. That does not mean everyone should turn them on. But if your site genuinely uses marketing tags, the plugin gives you the technical foundation to pass consent signals and verify them through Tag Assistant or the data layer.

When the Plugin May Be More Than You Need

If your site does not use non-essential cookies, external embeds, analytics, ads, or third-party services, a full CMP setup may be more than necessary. In that case, it is often smarter to start with a technical inventory: open the site as a guest, review Sources, Application, and cookies in the browser, make sure there are no external domains involved, and only then decide whether you need a banner at all.

The product may also be a poor fit for a team that wants to manage consent entirely through an external SaaS platform with one shared account across multiple CMS platforms. Real Cookie Banner is built for a WordPress-native workflow. That is a strength if you want local control, but a drawback if your organization already runs a centralized privacy stack outside WordPress.

What to Check Before Installing It on a Live Site

Preparation matters just as much as installation. A consent plugin affects how scripts, iframes, external resources, and cookies are loaded, so it should be enabled deliberately, especially on a site using caching, JavaScript optimization, WooCommerce, forms, and a tag manager.

Your Service List Before First Launch

Before installation, make a draft list of what the site is already using. Do not try to write legally perfect descriptions right away. At this stage, the priority is understanding the technical map:

• Which analytics tools are connected: Google Analytics, Matomo, Microsoft Clarity, Piwik PRO, or other systems.
• Whether the site uses ad pixels, retargeting, Google Ads, Meta Pixel, TikTok Pixel, or similar services.
• Which embeds appear in content: YouTube, Vimeo, Google Maps, Instagram, X, Typeform, SoundCloud.
• Whether forms use external anti-spam protection: Google reCAPTCHA, hCaptcha, or third-party plugins.
• Whether the theme loads external fonts, a CDN, review widgets, chat, or social buttons.

This map matters so that you do not treat the scanner result as a complete audit. If you already know there is a map on the contact page and the scanner does not find it, you will not miss that service just because it loads only after a click or through a separate script.

Cache, Optimization, and the REST API

Problems with a cookie banner often come from the environment rather than the banner itself. Check which caching layers are enabled: page cache, object cache, CDN, JavaScript optimization, delayed script loading, file aggregation. The devowl.io documentation about the banner repeatedly reappearing points to the REST API, cookie path, JavaScript access to the cookie, server-side cookie deletion, and a slow WordPress response as common causes.

Safe practice: before configuring the plugin, clear the site cache, CDN cache, and object cache, then test as a guest in a private window. If you change banner settings and immediately see the old behavior, rule out caching first instead of rewriting the plugin configuration.

Legal Pages and a Link to Change the Choice Later

Real Cookie Banner provides legal shortcodes for changing privacy settings, viewing the settings history, and revoking consent. The documentation notes that these links should be placed in the privacy policy and in the footer so visitors can return to their choice later. This is not a cosmetic detail: the banner should not only collect the initial decision, but also provide a clear way to change it.

Before installation, make sure you have a privacy policy page, a clear place in the footer or menu, and permission to edit those areas. If the site is built with Elementor, Gutenberg, Site Editor, or a custom theme footer, decide in advance where the link for changing settings will live.

Installation and Initial Verification in WordPress

The free version is installed the standard way: in the admin panel, go to Plugins - Add New, search for Real Cookie Banner, then install and activate the plugin. After activation, a Cookies section appears in the left menu, and that is where setup begins.

If you are installing the commercial version over the free one, or working from a purchased archive, do not turn that into a purchase walkthrough inside a setup guide. For practical work, something else matters more: after activation, do not jump straight into design changes. First verify that the plugin dashboard opens, the setup wizard is available, and the WordPress REST API responds normally.

A Safe First Run

On a live site, the most practical route is a controlled one:

1. Create a backup or work on staging if the site is critical for sales and lead generation.
2. Activate the plugin and open Cookies in the admin panel.
3. Go through the guided configuration as far as you can confirm the site's actual facts.
4. Do not enable complex modes such as TCF or advanced tag manager handling unless your stack actually needs them.
5. After saving, open the public site as a guest and verify that the banner appears.
6. Click reject or accept, reload the page, and move to another page to confirm that the choice is preserved.

At this stage, the result is acceptable if the banner appears once for a new visitor, does not reappear after the choice has been saved, and does not break the site layout. If the banner opens again on every page, move straight to REST API and cookie diagnostics rather than changing colors.

What Not to Enable Right Away

TCF, geo restriction, consent forwarding, and advanced Google Consent Mode settings should be enabled only when you understand why they are needed. The devowl.io documentation explicitly warns that TCF adds significant complexity and is disabled by default. Google Consent Mode can also make the banner more detailed because the visitor may need to see additional purposes. On a small site without advertising or a Google Ads audience, these modes often add little practical value.

Detailed Configuration After Installation

Real Cookie Banner should be configured from actual services outward to appearance, not the other way around. First decide what needs to be blocked and explained, then configure groups and text, and only after that move to appearance, legal links, and the consent log. That way, the banner reflects the site's real behavior instead of a polished mockup with no technical control behind it.

Services, Groups, and Templates

In Cookies - Services (Cookies), you work with services. If a template is available, it saves time because part of the legal and technical information is already filled in. But the template still needs to be reviewed. Check the provider, purpose, privacy policy URL, technical cookie information, group, and technical handling. If the service is used through a specific WordPress plugin, make sure that plugin is active: the documentation explains that some templates remain unavailable until the related plugin is installed.

For a typical site, the group logic often looks like this: essential services remain technically necessary, analytics and marketing require separate consent, and external media or content embeds are handled through a content blocker. But do not copy that structure mechanically. A map, an embedded video, and a captcha solve different problems, so their descriptions and the consequences of refusing them should also differ.

How to Verify a Service After Adding It

After adding a service, open the page where it is used. Before consent is given, check the Network, Sources, and Application tabs in developer tools. If the service is YouTube, Vimeo, or Google Maps, the external iframe should not load before consent if you have configured a content blocker. If it is analytics, the corresponding request or tag should appear only after the consent event or according to the selected Google Consent Mode setup.

Content Blocker for Iframes, Scripts, and Elements

The Content Blocker in Real Cookie Banner is needed when the theme, content, or another plugin inserts a third-party resource. The devowl.io documentation describes the manual path: Cookies - the Content Blocker tab - Add content blocker, then choose a template or Create from scratch. Every content blocker must be connected to one or more services, otherwise the visitor may give consent but the blocked content will not know when it should be released.

For simple iframes, a URL-based rule is usually enough. More complex elements may require a CSS selector, an attribute rule, or the additional selector syntax feature. The documentation shows examples for iframes, scripts, links, HTML elements by ID/class/custom attribute, and even a visual parent. But in a practical guide, it is better not to invent selectors by guesswork. Open the real HTML in DevTools, locate the exact iframe, script, or container, test the rule on one page, and only then roll it out site-wide.

Quick takeaway: the service explains to the visitor why data is processed, while the content blocker technically prevents the external resource from loading before consent. If only one layer is configured, the chain is incomplete.

Banner Design and Accessibility

The appearance is adjusted through the WordPress Customizer: Appearance - Customize - Cookie Banner or the Customize banner button in the Cookies section. The official article describes a wide range of settings for colors, text, size, and live preview. But design here is not about decoration. A good banner should be readable, should not hide the reject option, should not break on mobile devices, and should preserve a clear action hierarchy.

Real Cookie Banner emphasizes accessibility and shows an accessibility score in the customizer. Use that as a practical checkpoint: if your brand colors reduce contrast, it is better to adjust button shades than to keep a beautiful but hard-to-read dialog. For the text itself, choose short, clear wording. If visitors do not understand what they are agreeing to, technically careful setup will not save the user experience.

The Consent Log and the Data Stored by the Plugin

The devowl.io documentation explains that consents are stored in the WordPress database and are available in the admin panel in the consents list. The records may include revision, decision, selected services, context, referer, viewport, button clicked, and other technical fields. Some data, such as the full IP address, is disabled by default or handled cautiously because it may be considered personal data.

The practical takeaway is simple: if you change texts, groups, services, or content blockers, consent may be required again because the revision changes. That is normal. But do not restructure the banner every day unless there is a clear reason: frequent changes annoy visitors and make the log harder to interpret.

How to Use the Service Scanner Without a False Sense of Security

The scanner is one of the most useful tools in Real Cookie Banner, but it should be used as the starting point for an audit, not as a "make everything compliant" button. According to the official description, the scanner looks for the sitemap, crawls pages, analyzes HTML, external files, plugins, and a number of special systems. It then matches detected elements against rules and templates.

How to Run a Practical Scan

Before running the scanner, refresh the sitemap, clear the cache, and make sure the pages that use external services are actually included in the sitemap. If an important landing page is excluded from indexing or a map appears only on the contact page, the scanner may never reach it. After the scan, review not only the suggested templates but also the unknown findings.

For each detected item, ask three questions:

• Which service or plugin loaded this resource.
• On which page and in which user scenario it appears.
• Whether it needs a service, a content blocker, both layers, or removal from the site.

If the scanner finds Google Fonts but you can host the fonts locally in the theme, removing the external request may be a better choice than adding another consent item. If it finds a YouTube iframe, a content blocker is usually required. If it finds Google Tag Manager, the correct decision depends on whether it launches only essential tags or also analytics and advertising.

Manual Verification After the Scan

The official article "How do I find all services" recommends manually checking external embeds, invisible content, local storage, session storage, cookies, and pixel trackers through browser tools. In practice, that means opening the site in a private window, disabling ad blockers for the test, walking through key pages like a normal visitor, opening Sources and Application, and then comparing the detected domains and cookies with the service list in Real Cookie Banner.

The most common mistake is checking only the homepage. On a blog, the external YouTube embed may be inside an article. On an online store, a third-party checkout script may appear only on the checkout page. On a form, reCAPTCHA may load only after a modal opens. The scanner helps, but a manual path through important pages is still required.

Google Consent Mode, Tag Manager, TCF, and Multilingual Setup

Real Cookie Banner's advanced modes are not needed on every site, but they often determine how well the plugin fits a marketing-heavy or multilingual project. Turn them on because the use case requires them, not because "more features must be better."

Google Consent Mode and Google Tag Manager

The Google Consent Mode documentation recommends enabling it through Cookies - Settings - Google Consent Mode. If you use Google Tag Manager, the separate integration option should also be enabled, because that is what allows additional consent types to be passed into Tag Manager and lets tags fire only when a valid legal basis exists. For Google services, the service configuration includes a section where the requested consent types are specified.

Do not enable Google Consent Mode just because the name sounds important. The devowl.io documentation recommends it for scenarios involving Google Ads, business-critical analytics, Google Tag Manager, or Google services where data processing must be restricted until consent is granted. If you do not have those needs, a slimmer banner may be easier for visitors to understand.

How to Verify the Tag Manager Setup

If you use the older event-based approach with ga-opt-in and ga-opt-out, the documentation describes the data layer variable realCookieBannerOptInEvents. For a newer setup, devowl.io recommends the Google Tag Manager integration for Google Consent Mode. In both cases, verification should be technical: open Tag Assistant, grant consent, inspect events, variables, and fired tags. If a tag fires before the visitor makes a choice, the setup has failed the test.

TCF: Only for Sites That Truly Need It

Transparency & Consent Framework adds vendors, purposes, and a standardized consent string. In Real Cookie Banner, TCF is disabled by default because it makes the banner more complex and is usually unnecessary for most sites. It makes sense when the site works with advertising vendor chains and must pass consent according to the IAB Europe standard.

If you enable TCF, follow the official path: Cookies - Settings - Transparency & Consent Framework (TCF), accept the legal documents, specify the country, load the Global Vendor List, and then create the TCF vendor configuration in Services (Cookies). After that, review the design and wording again in the customizer: the banner becomes more complex, which increases the risk of a confusing interface.

Multilingual Sites

Real Cookie Banner supports WPML, Polylang, TranslatePress, and Weglot, but the logic differs depending on the data type. The documentation for WPML and Polylang explains that shared settings apply to all languages, while the name, provider, purpose, description, and privacy policy for services and content blockers depend on the admin language you are using when editing the item. TranslatePress and Weglot have their own translation and indexing nuances.

If the multilingual plugin was installed after Real Cookie Banner, check initialization. For WPML and Polylang, the documentation recommends briefly deactivating and reactivating Real Cookie Banner so all languages are initialized. If the banner or content blocker starts showing the wrong language, do not manually rewrite everything right away: first check the site language, the user's backend language, and the multilingual plugin's sync state.

Practical Scenario: A Site with YouTube Videos, Google Analytics, and a Form

Imagine a content-driven WordPress site: articles include YouTube videos, Google Analytics runs site-wide, and the contact form uses reCAPTCHA. The goal is to show the visitor a banner, prevent YouTube and tracking from loading before consent, save the choice, provide a way to change it in the footer, and verify that everything works.

Preparation

First identify the pages involved: one article with YouTube, the homepage with analytics, and the contact page with the form. Clear the cache, open the site as a guest, and see which external domains load before consent. If Google Analytics has already been inserted manually in the theme or through another plugin, decide what will be responsible for loading it. Duplicate code is one of the most common reasons tracking fires before Real Cookie Banner can control it.

Configuration Steps

1. Run the service scanner and check whether it detects YouTube, Google Analytics, Google Tag Manager, or reCAPTCHA.
2. In Services (Cookies), add services from templates when available, then review the provider, purpose, privacy policy, and technical handling.
3. For YouTube, create or verify a content blocker connected to the YouTube service.
4. For Google Analytics, choose the right mode: through Google Consent Mode, through Tag Manager, or through the service's technical handling if your setup allows it.
5. For the form with reCAPTCHA, check whether a template exists for the form plugin you use and confirm that the captcha does not load before user interaction.
6. In Consent - Legal Shortcodes, add a link for changing settings in the privacy policy and footer.
7. In the customizer, configure a readable layout, high-contrast buttons, and clear text without unnecessary pressure on the visitor.

Expected Result

Before consent, the YouTube video should be covered by a content blocker with a clear message. The analytics tag should not send its normal event before permission is granted if you are using an opt-in setup. After consent, the video should open and analytics should run according to the selected mode. The footer should contain a link that allows the visitor to change privacy settings or revoke consent.

A Detail That Often Gets in the Way

If YouTube still loads before consent, check not only the content blocker but also how the video is embedded. Some page builders or gallery plugins load the iframe only after a click or inside a lightbox. The scanner may miss that scenario, and a simple URL-based content blocker rule may never target the right container. In that case, inspect the HTML after the interaction and refine the rule, or reach out through a template request or support channel if the service is a common one.

How to Verify the Result After Configuration

Verification should move in two directions: what the visitor sees and what happens technically behind the scenes. A banner may look correct, but if network requests are sent before consent, the setup is not complete. The opposite can also happen: everything gets blocked too aggressively, and after consent the form or video never comes back.

Public-Side Verification

Open the site in a private window as a guest. On the first visit, the banner should appear according to your chosen settings. Click reject, reload the page, and confirm that external embeds remain blocked. Then clear cookies or open a second private window, grant consent, and verify that content blockers are released and the choice persists as you move between pages.

Make sure to test the mobile viewport as well. Support discussions around cookie plugins often reveal issues with cache, delayed JavaScript, and buttons that do not appear immediately. Real Cookie Banner has an official article about accessibility and the customizer score, but a real mobile check is still necessary because the theme, optimizer, and sticky elements can all affect the banner.

Verification in Browser Tools

In Network, filter by external domains and the word consent. After the consent button is clicked, a request related to saving the decision should appear. In Application, check cookies and local storage. If the choice is not being saved, inspect the path, HttpOnly, server headers, and whether wp-json is reachable. If Google Consent Mode or Tag Manager is involved, use Tag Assistant and the data layer rather than relying on visual checks alone.

After a check like this, you understand not just whether "the banner showed up," but whether the whole chain worked: configuration - blocking - consent - storage - follow-up verification.

Safe Improvements Without Editing the Plugin Core

With Real Cookie Banner, code should not be your starting point. The product already includes a customizer, templates, service configuration, content blocker rules, legal shortcodes, and a developer API. If there is no confirmed hook, filter, or stable CSS structure for your specific task, it is safer to use the built-in options and document the limitation than to invent a custom snippet.

Improvement Through Legal Links

The most useful no-code improvement is adding links for changing privacy settings in places where users expect to find them. The documentation points to Cookies - Consent - Legal Shortcodes, where Change privacy settings, Privacy settings history, and Revoke consent are available. Place them in the privacy policy and footer. After publishing, click each link as a guest and confirm that it opens the correct screen.

Improvement Through Cache Configuration

If an optimization plugin delays JavaScript or combines files and the banner starts appearing late, first disable the questionable optimization only for testing. If the problem disappears, configure exclusions in the cache or optimization plugin, or consult that optimizer's documentation. Do not delete Real Cookie Banner files and do not edit its bundled JavaScript: plugin updates will overwrite those changes, and a mistake there can break consent collection.

Improvement Through Localization

On a multilingual site, check not only the banner language but also the language of services, content blockers, and legal links. If part of the text appears in the wrong language, use the built-in WPML, Polylang, TranslatePress, or Weglot mechanisms and the documented reset text options. Do not try to fix the issue with mass string replacements in the database unless you understand exactly which language contexts the site is using.

Diagnosing Common Real Cookie Banner Issues

Below are problems that are especially common with consent plugins and are confirmed either by the official Real Cookie Banner knowledge base or by typical WordPress support scenarios. It is best to run diagnostics in a private window, with cache cleared and developer tools open.

The Banner Reappears on Every Page

Symptom: the visitor clicks accept or reject, but when they move to the next page, the banner is open again. In the official devowl.io article, the listed causes include an unavailable or misconfigured WordPress REST API, an incorrect cookie path, the HttpOnly flag, server-side cookie deletion, and a slow WordPress response.

What to Check

• Clear page cache, object cache, and CDN cache.
• Open Network, filter for consent, and inspect the response after clicking the button.
• Open Application - Cookies and check the path and HttpOnly values.
• Open your-domain.com/wp-json as a guest and make sure the REST API responds.

How to fix it: restore REST API availability for guest users, correct the site URL under Settings - General, remove forced HttpOnly behavior for Real Cookie Banner cookies, and configure the CDN so cookies with the real_cookie_banner prefix are not dropped. If the cause is a slow WordPress response, optimize the server response first rather than the banner.

The Banner Does Not Appear in Certain Browsers

Symptom: the banner is visible on one device but missing on another. The official article explains that this can happen because of Do Not Track: if the visitor has already signaled that they do not want tracking, Real Cookie Banner may apply a minimal decision without showing the banner. The setting is located under Settings - Consent - Respect "Do Not Track" and is enabled by default.

What to do: check the browser's Do Not Track setting, test in another private window, and do not disable respect for that signal without a good reason. If the banner does not appear for anyone at all, the issue is more likely geo restriction, cache, a JavaScript error, or a theme conflict, not Do Not Track.

The Content Blocker Shows a Spinner or Never Opens the Content

Symptom: the placeholder is there, but after consent the video, map, or form does not appear. In the devowl.io article about language switching, an endless spinner is mentioned as a sign that the connection between the service and the content blocker is missing or incorrect.

What to check: open the specific content blocker, make sure the correct service is connected to it, verify the selector or URL rule, and see whether the page builder changes the HTML after load. If the content appears only after a click inside a lightbox, a standard rule based on the original HTML may not work.

Analytics or a Pixel Loads Before Consent

Symptom: an analytics request is visible in Network or Tag Assistant before the visitor makes a choice. A common reason is duplicate code outside Real Cookie Banner: tracking has been inserted in the theme, another plugin, Google Tag Manager, PixelYourSite, or custom HTML at the same time.

How to fix it: keep a single responsible loading path. For Google Tag Manager, use the mode described in the Real Cookie Banner documentation, and for PixelYourSite, enable the integration and create a service for each pixel. If the service is not created, the integration may not stop the pixel from loading.

Text Gets Mixed Up After a Language Switch

Symptom: the site is in one language, but service groups, services, or the content blocker display another one. The cause is often tied to the installation order of the multilingual plugin and Real Cookie Banner, or to incorrect WPML or Polylang synchronization.

How to fix it: first check the site language under Settings - General and the user's backend language. For WPML and Polylang, if the multilingual plugin was installed after Real Cookie Banner, the official documentation recommends briefly deactivating and reactivating Real Cookie Banner to initialize languages. If full text reinitialization is needed, use the documented reset texts or reset all options instead of manually editing database tables.

When Real Cookie Banner Is the Right Choice

Real Cookie Banner is worth using if you need a WordPress-native tool for real consent management rather than just a visual cookie notice. It is especially strong on sites with external embeds, analytics, a tag manager, advertising pixels, forms, multilingual content, and a need for a consent log. A good setup takes time, but when it is done properly, the site gets a clear chain: the service is documented, the content is blocked until consent is granted, the choice is stored, and the result is verified.

Before rolling it out on a live site, verify three things: the scanner did not leave any unknown services unresolved, content blockers really do prevent external resources from loading before consent, and the visitor's choice is preserved when moving between pages. If those checks are complete, you can download the latest version of Real Cookie Banner and use this guide as a checklist for a careful test launch.