The GDPR Kit scans your website, detects your cookies and trackers, and generates four ready-to-use compliance documents: a privacy policy, cookie policy, consent banner code and data processing record — all tailored to what your site actually uses.
The GDPR Kit scans your website URL and detects all cookies and third-party trackers present. It categorises them as essential, functional, analytics or marketing. It then generates all four compliance documents pre-populated with the actual trackers found on your site — not a generic template.
Create two new pages on your website: /privacy-policy and /cookies. Paste the generated content into each page. Add links to both pages in your site footer — they must be accessible from every page.
Paste the consent banner HTML as the first element inside your body tag. Test it on a fresh browser session — you should see the banner before any analytics fires. Check in your browser developer tools (Network tab) that GA4 or your analytics platform does not appear until after you click Accept.
If you use Google Tag Manager, create a Custom Event trigger listening for the consent_accepted event fired by the banner. Move all non-essential tags (analytics, advertising, heatmaps) to fire only on this trigger.
Keep the generated RoPA in your internal documentation. You do not publish this — it is an internal record required under Article 30 that you must produce on request from the ICO.
Nearly every non-compliant site already has a cookie banner. The banner is not the problem. The problem is that the trackers fire anyway, because a banner only asks — it does not block. Unless something actively prevents those scripts from executing, they run on page load exactly as they always did, and the banner becomes an expensive piece of theatre that documents your non-compliance rather than curing it.
There are three ways to make consent actually control what loads, and they are not equivalent.
Move every non-essential tag out of the page source and into your tag manager, then fire them only on a consent event. Nothing is in the HTML, so nothing can run on load. This is the approach the deployment steps above describe, and for most sites it is the right one.
Change <script src="..."> to <script type="text/plain" data-src="...">. The browser will not execute a script of an unknown type. On consent, rewrite the type to text/javascript and the script runs. This works for hard-coded third-party scripts you cannot move into a tag manager.
Do not emit the script tags at all unless the consent cookie says you may. The most robust option, because there is no client-side race condition, but it requires control of the templating layer.
If you use Google's advertising products in the UK or EEA, Consent Mode is no longer optional — since March 2024 Google requires Consent Mode v2 signals for personalised advertising features to function. It confuses a lot of people, so it is worth being precise about what it does.
Consent Mode does not block Google's tags. The tags load, and they adjust their behaviour according to four consent signals you set:
| Signal | Governs |
|---|---|
| analytics_storage | Whether analytics cookies may be set |
| ad_storage | Whether advertising cookies may be set |
| ad_user_data | Whether user data may be sent to Google for advertising |
| ad_personalization | Whether data may be used for personalised advertising |
Two details decide whether an implementation is correct:
denied, and it must be set before any Google tag loads. Get the ordering wrong — a default that arrives after the tag — and the tag runs in granted mode. This is the most common Consent Mode implementation error and it produces a site that appears compliant and is not.The deployment steps above describe checking the Network tab, and that is the right instinct. Here is the full procedure, in the order a regulator or a complainant would run it.
A cookie policy is a factual inventory. It has to list, for every cookie: name, provider, purpose, type, and retention period. Vagueness is what makes most cookie policies non-compliant — "we use cookies to improve your experience" is not a purpose, and "some cookies come from third parties" is not a provider.
A cookie policy is accurate on the day it is generated and starts decaying immediately. Every one of these silently invalidates it:
None of these events prompts anyone to update the policy, and the policy is the document you will be asked to produce. Re-scan on a schedule — quarterly is a reasonable default — and re-scan after any site change, plugin update or campaign launch. The consent categories in the banner must match the cookies actually present; a category that no longer corresponds to anything real, or a cookie that belongs to no category, is a defect in both documents at once.
The RoPA is internal — you never publish it — but it is the first document the ICO asks for, and "we don't have one" is a poor opening. Article 30 sets out what a controller's record must contain:
Article 30 exempts organisations with fewer than 250 employees — but the exemption falls away if the processing is not occasional, is likely to result in a risk to rights and freedoms, or involves special-category data. A website running analytics and marketing continuously is not processing occasionally. Most small businesses that assume the exemption covers them are wrong about it.
The RoPA also has a use beyond compliance: it is the only document that answers, in one place, "what personal data do we actually hold and where is it?" — which is exactly the question you cannot afford to be researching from scratch when a subject access request arrives with a one-month clock running, or a breach with a seventy-two-hour one.
The GDPR Kit generates four documents: a Privacy Policy covering UK GDPR requirements including data categories, legal bases, retention periods and user rights; a Cookie Policy listing every cookie detected with name, provider, purpose and retention; a Cookie Consent Banner in ready-to-paste HTML and CSS; and a Record of Processing Activities (RoPA) as required by Article 30 of UK GDPR.
The generated documents follow current UK GDPR requirements and ICO guidance. For most small and medium businesses, they provide a solid compliance foundation without legal review. However, if your business handles sensitive data categories (health, financial, children's data), processes data at scale, or operates in regulated industries, legal review is advisable.
The consent banner is provided as self-contained HTML and JavaScript. Paste it as the first element inside your body tag — before any other scripts. It will appear on every page load for new visitors and store consent in a cookie. Connect your analytics and marketing tags to fire only after the user accepts. The banner code includes instructions for connecting to Google Tag Manager.
No. A banner only asks — it does not block. Unless something actively prevents non-essential scripts from executing, they still fire on page load and the banner documents your non-compliance rather than curing it. Trackers must be gated: moved into a tag manager and fired only on a consent event, given a script type the browser will not execute until consent is granted, or not rendered into the page at all until the consent cookie permits it.
Almost always because the tag is hard-coded in the page source rather than gated behind the consent event, so it executes on load regardless of what the banner reports. Test it directly: open a private window, clear site data, load the page, click Reject all, then check the Network and Application tabs. The reject path is the one that most implementations fail, because they were built and tested against Accept.
No. The tags still load and adjust their behaviour according to four signals — analytics_storage, ad_storage, ad_user_data and ad_personalization. The default state must be set to denied before any Google tag loads; if the default arrives after the tag, the tag runs in granted mode. Note also that advanced mode transmits cookieless pings before consent is given, whereas basic mode sends nothing until consent — many sites are running advanced mode without having chosen it.
No — it is an internal document, produced on request by the ICO. Article 30 exempts organisations with fewer than 250 employees, but the exemption is lost if the processing is not occasional, is likely to result in risk, or involves special-category data. A website running analytics and marketing continuously is not processing occasionally, so most small businesses do not qualify for the exemption they assume applies to them.
Run the GDPR Kit and get actionable results in minutes. Pay as you go.
Generate GDPR Kit →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.