UK Cookie Rules: Audit Your WordPress Site Against ICO Guidance

If your website is used by people in the UK, every cookie, pixel, script or tag that stores or reads information on a visitor's device needs either a valid exception or the visitor's prior consent. The ICO (the UK data protection regulator) finalised its guidance on these "storage and access technologies" on 29 April 2026, and it is a useful checklist for a cookie audit. You can begin a first audit with a browser and a spreadsheet, but the time needed depends on the number of plugins, embeds, tag-manager rules and third-party services on the site.

Here is the surprising part for many site owners: the ICO says plainly that "continuing to use your website does not constitute valid consent." So that old banner that says "By using this site you accept cookies" with a single OK button does not do the job, even if it looks tidy.

By the end of this guide you will have a dated list of every cookie and third-party script on your site, a decision for each one (keep, ask for consent, or remove), and a review date in your calendar.

Heads up: this is general information, not legal advice. The ICO guidance and the law it explains are the authority. Quotes are from the ICO pages as they read at the time of writing (28 October 2026).

What the UK cookie rules actually are

The rule lives in Regulation 6 of PECR, the Privacy and Electronic Communications Regulations. In plain words: you must not store information on someone's device, or read information already stored there, unless an exception applies or the person has agreed.

Think of a visitor's browser as their coat pocket. A cookie is a note you slip in; a script reading stored data is you checking the pocket. A cloakroom ticket is part of the service they asked for. A tag for someone else's benefit needs their permission first.

The ICO guidance covers more than cookies. At the time of writing, it lists cookies, tracking pixels, link decoration and navigational tracking, device fingerprinting, web storage (like localStorage in the browser), and scripts or tags. So your audit should look at everything that runs in the page, not only the Cookies tab.

What the ICO says about consent

When consent is needed, the ICO says: "You must obtain prior consent to the UK GDPR standard for their use, unless an exception applies." The UK GDPR standard means consent that is freely given, specific, informed and unambiguous.

Three practical points come straight from the guidance:

• Prior means before the cookie is set or the script runs, not after.
• Pre-ticked boxes do not count: the ICO says "nor does the use of a pre-ticked box or equivalent" give valid consent.
• People must be able to refuse non-exempt technologies "as easily as they can accept" them, and to withdraw consent with the same ease they gave it.

You also have to tell people what you use and why. PECR asks for "clear and comprehensive information" about the purposes.

The five exceptions

The ICO's exceptions page names five exceptions where you do not need consent:

• Communication: linked to sending a communication over a network.
• Strictly necessary: needed to provide the service the user asked for.
• Statistical purposes (the ICO also calls it the "analytics" exception): collecting statistics about how your service is used so you can improve it, under strict conditions.
• Appearance: adapting how the site looks or works in line with the user's preferences.
• Emergency assistance: a narrow case that rarely applies to an ordinary website.

Why this matters: two of these exceptions, statistical and appearance, come with conditions. You still have to tell people what you do and give them a simple and free way to object.

What counts as strictly necessary

The ICO gives examples that are likely to fit: remembering goods in a shopping basket or at checkout, identifying a logged-in user for the duration of their visit, and session cookies that store preferences when they are not linked to a persistent identifier.

It also lists things that are not likely to fit. Social media tracking, cross-site or cross-device tracking, and online advertising (including frequency capping, ad measurement and click fraud detection) all need consent.

The statistical and appearance conditions in short

For the statistical exception, the ICO expects the sole purpose to be statistics that improve your service. The data must be aggregated and must not identify people, and tracking or profiling individuals is not allowed without consent. If you use a third-party analytics provider, it must act as your processor (it handles data only on your instructions), not a joint controller, and you must tell users you use it and what it does with the data.

For the appearance exception, likely examples include remembering a chosen language, detecting dark mode, and responsive design based on screen size. It cannot be used to change content based on interests or behaviour, or for advertising. And the ICO says: "You must not solely rely on browser settings" as an indication that a person does not object.

Before you start

Gather these before you open anything:

• Admin access to your WordPress dashboard, and ideally SSH access if you want to use WP-CLI (the WordPress command line tool).
• A desktop browser. The steps below use Chrome DevTools because Google documents the Cookies pane clearly.
• A spreadsheet (Google Sheets, Excel, or LibreOffice Calc).
• A clean browser profile or a private window with no extensions, so your own ad blockers and logins do not hide or add cookies.
• Focused review time that reflects your site's size; a site with many plugins, embeds or tag-manager rules will take longer.
• Risk level: low. You are only looking until Step 5. Deleting cookies in your own browser does not change the site.

Quick tip: before you remove any plugin or script in Step 5, take a full backup of files and database.

Set up your sheet with these columns: Name, Type (cookie, local storage, script, pixel), Set by (your domain or a third-party domain), Purpose, Lifespan, Exception or consent, Action, Notes.

The audit, step by step

Step 1: List every cookie your site sets

The ICO says to identify your technologies "using browser-based tools or server-side code reviews". The browser is the easiest place to start.

1. Open a fresh private window or a clean Chrome profile.
2. Visit your home page, but do not click anything on the cookie banner yet.
3. Open DevTools and go to Application > Storage > Cookies.
4. Select your site's origin, for example https://example.com.

You will see a table with the columns Name, Value, Domain, Path, Expires / Max-Age, Size, HttpOnly, Secure, SameSite, Partition Key and Priority. Copy Name, Domain and Expires / Max-Age into your sheet for every row.

Why this matters: anything listed at this point was set before the visitor made a choice. If one of those is not exempt, that is the first thing to fix, because the ICO says you "must not pre-enable" non-exempt storage and access technologies.

Now repeat the visit in three states and note any new rows:

1. After clicking "Reject" (or your banner's equivalent).
2. After clicking "Accept".
3. On a few key pages: a blog post, the contact page, the checkout if you have one, and a page with an embedded video or map.

Quick tip: click Clear all in the Cookies pane between runs so each starts clean. The Filter box matches cookies by name or value.

Also check Local storage and Session storage under Application > Storage, since the ICO guidance covers web storage too.

Heads up: Chrome's documentation says the Cookies pane shows third-party cookies, those with the SameSite=None attribute, with a warning icon next to them. You can also select a request in the Network panel and open its Cookies tab to see which request set a cookie.

Step 2: Recognise WordPress core cookies

WordPress itself sets a small, well-documented set of cookies. According to the WordPress developer documentation, at the time of writing they are:

• wordpress_[hash]: stores authentication details, used only in the admin area.
• wordpress_logged_in_[hash]: shows when and who is logged in, for most interface use.
• wp-settings-{time}-[UID]: remembers your dashboard view preferences, keyed to your user ID.
• comment_author_{HASH}, comment_author_email_{HASH} and comment_author_url_{HASH}: remember a commenter's name, email and website so they do not retype them. The docs say these expire a little under one year from when they are set.
• wordpress_test_cookie: a temporary cookie that probes whether WordPress can set cookies.
• wp_lang: a session cookie that stores the language chosen on the login screen.

The login cookies match the ICO's example of identifying a user once they have logged in, for the duration of their visit, which is listed as likely strictly necessary. wp_lang stores a chosen language, which matches the ICO's appearance example, so the information and objection conditions apply. The commenter cookies deserve a closer look: they last almost a year and hold personal details, so make sure your privacy information mentions them.

Quick tip: the WordPress docs say the login cookie lifetime "can be adjusted with the auth_cookie_expiration hook." The ICO asks you to justify the lifespan of persistent cookies, so note the lifetime you see in the Expires column and write down why it fits.

Step 3: Recognise plugin and theme cookies

Anything not on the core list came from a plugin, your theme, or a third-party script.

First, get a clean list of active plugins. If you have SSH access and WP-CLI installed, this command lists only active plugins with their versions:

wp plugin list --status=active

You should see a table with the columns name, status, update, version, update_version and auto_update. If you prefer a file you can paste into your sheet, this command prints the same list as CSV:

wp plugin list --status=active --format=csv

No SSH? Go to Plugins > Installed Plugins and click the Active filter.

Then check each plugin's documentation for the cookies it sets and match them to your sheet. Do not guess a purpose from a cookie name alone. If a plugin does not document its cookies, disable it on a staging copy and see which cookies disappear.

Made-up example: Priya runs a small Manchester bakery site. Her sheet shows nine cookies before anyone clicks the banner: two she cannot place yet, three from her shop basket, and four from a social sharing plugin she forgot about years ago. The basket cookies have a strong strictly necessary case; the social plugin goes to the top of her Step 5 list.

Step 4: Find the scripts and third-party domains in your page source

A tracking pixel or fingerprinting script may not show up as a cookie at all, so you also need to see which scripts load.

Open your browser's view-source option on your home page and search for <script. Write down every external src address and pay attention to the domain. Anything not on example.com is a third party.

If you have a terminal, this command fetches your home page and prints every script tag that loads a file from somewhere:

curl -s https://example.com/ | grep -o '<script[^>]*src="[^"]*"'

You should see lines like <script src="https://example.com/wp-includes/js/..."> for your own files, plus any third-party domains. Run it on a few page types, because some plugins only load scripts on certain pages.

Heads up: view source and curl show only the HTML the server sent. Scripts injected later by a tag manager will not appear. For those, open the Network panel in DevTools, reload, and note the request domains.

Why this matters: the ICO asks you to "identify whether any third parties are setting" storage or access technologies on your site. You are responsible for what you embed, even when another company's code does the storing.

To watch which domains load scripts over time, our Content Security Policy report-only guide shows how to collect reports without breaking anything.

Step 5: Decide what to do with each item

Give each row one of three decisions: keep under an exception, get consent before it runs, or remove it. Use this list as a starting point and check the ICO exceptions page for your exact case:

• Login and authentication cookies (like wordpress_logged_in_[hash]): likely strictly necessary. Keep.
• Shopping basket or checkout cookies: likely strictly necessary. Keep.
• Security cookies tied to a service the user requested: possibly strictly necessary. Check the ICO examples and document your reasoning.
• Language choice or dark mode preference: possibly the appearance exception. Keep, but tell users and give a simple, free way to object.
• First-party analytics that only produce aggregated statistics, with any provider acting as your processor: possibly the statistical exception. Keep only if every condition is met, and tell users how to object.
• Analytics that track individuals, link to advertising, or let the provider use data for its own purposes: consent required before it runs.
• Advertising, retargeting, social media pixels, cross-site tracking: consent required before it runs.
• Embedded videos, maps or fonts from third parties: check what the provider stores or collects. The ICO notes an external font library may fit the appearance exception if users are informed and can object.
• Anything you cannot explain, or no longer use: remove it.

The ICO's audit steps include "identify any you no longer need and remove them." This is often the quickest win.

For items that need consent, the script must not run until the visitor agrees, which usually means a consent tool that blocks it until then. You have to configure that tool yourself: put each script in the right category, make "Reject" as easy as "Accept", and let people change their mind just as easily. Then test it with Step 1 again.

Quick tip: give each row a short reason in the Notes column, like "ad pixel, consent, blocked until Accept".

Step 6: Document the review and set a date

The ICO asks you to "document your findings and follow-up actions" and to schedule your next audit. It also says you should undertake regular reviews.

At the bottom of your sheet, add:

• The audit date, for example 28 October 2026.
• Who did it.
• The list of follow-up actions and who owns each one.
• The next review date. A sensible habit is to review whenever you add a plugin, theme, embed or marketing tag, and on a fixed cycle as well.

Save a copy of the sheet; it is your record that you looked, decided and acted. If you also serve India, the same habit fits the privacy work in our India DPDP rules small website checklist.

How to check it worked

Once you have made changes, repeat the browser test from Step 1 in a fresh private window.

1. Load the home page and do not touch the banner. In Application > Storage > Cookies, you should only see cookies you marked as exempt.
2. Open the Network panel and reload. You should not see requests to advertising or social media domains you put behind consent.
3. Click "Reject". Reload and check again. Nothing new and non-exempt should appear.
4. Clear all cookies, reload, click "Accept". Now the consented cookies and scripts should appear.
5. Find the way to change your choice (a footer link or a small button). Withdraw consent and confirm the consented scripts stop loading on the next page.
6. Run the curl command from Step 4 again and compare the list of third-party domains with your sheet.

Expected result: your sheet, your banner categories and what you see in the browser all match.

Troubleshooting

Tracking cookies appear before anyone clicks the banner

Symptom: an advertising or analytics cookie is in the Cookies pane on first load. Likely cause: the script is hard-coded in the theme, added by a plugin outside your consent tool, or loaded by a tag manager that fires on page load. Fix: find where it is added (theme header, plugin setting, tag manager) and move it under the consent tool's control, or remove it.

The banner has "Accept all" but "Reject" is hidden in a second layer

Symptom: accepting takes one click, refusing takes three. Likely cause: the default design of the consent tool. Fix: change the settings so refusing is as easy as accepting, which is what the ICO asks for. Then re-test.

A cookie has no obvious owner

Symptom: a cookie name you cannot match to any plugin. Likely cause: a theme feature, an embed, or a script loaded by another script. Fix: in the Network panel, select requests one by one and open their Cookies tab to see which response set it. If that fails, disable plugins one at a time on a staging copy until it disappears.

Your list changes from visit to visit

Symptom: different cookies on each run. Likely cause: you were logged in, extensions were active, or pages load different scripts. Fix: use a clean profile, use Clear all between runs, and test the same pages each time.

"Cookies are blocked or not supported by your browser" at login

Symptom: this exact message after you tighten cookie settings. Likely cause: wordpress_test_cookie could not be set, often because a consent tool or caching rule is blocking cookies on the login page. Fix: make sure your consent tool never blocks WordPress core login cookies, then test the login again in a private window.

When to ask for help

Ask a developer if scripts are injected by theme code or custom functions. If your business depends on advertising or profiling, talk to a data protection adviser, because that is where consent rules matter most.

On penalties: the ICO's enforcement page says it will "reserve monetary penalties for the most serious infringements of PECR". It does not list fine amounts on that page, so be wary of anyone quoting a scary number to sell you a tool.

Outside the UK, the same audit habit still helps, but the legal tests differ by country. If you also serve India, see our India DPDP WordPress privacy notice, export and erase setup for that side of things.

The one message worth forwarding

Send this to whoever looks after your website:

"Hi, I am doing a cookie audit against the ICO's storage and access technologies guidance (finalised 29 April 2026). Could you help me with three things this week? First, list every plugin, theme feature, tag manager tag and embed that sets cookies, uses local storage, or loads a third-party script on our site. Second, confirm that nothing outside strictly necessary or a documented exception runs before a visitor clicks Accept, and that Reject is as easy as Accept. Third, make sure visitors can withdraw consent as easily as they gave it. I have started a sheet with what I found in the browser, and I will share it with you. Thanks."

The short version: list everything your site stores or reads, keep only what you can justify, ask before the rest runs, and write down when you checked.