Platform & operations

Automatic cookie scanning,
on a schedule you set

Automatic cookie scanning is a scheduled crawl of your own website that finds the cookies it sets. Kukie loads your pages in a real browser, records every cookie, localStorage and sessionStorage entry that appears, matches each against a database of 3,400+ known cookies, and repeats on a schedule so the list stays current.

Start free → Scan a site without an account

Why a cookie list goes out of date on its own

The cookie list you write on the day you set up consent describes the site as it was that day. Nobody sets out to make it wrong. It goes wrong quietly, because websites change and cookie settings do not change with them. The four causes below account for most of the drift, and none of them involve anyone opening the consent settings.

Somebody adds a tag

A marketing colleague drops a new pixel into the tag manager on a Tuesday afternoon. It works, it reports numbers, everyone is pleased. It also writes cookies that appear nowhere in your policy, and the person who added it had no reason to think about that.

A plugin updates itself

Themes, plugins and site builders ship new versions constantly, and a new version can introduce storage the previous one never used. This is the most common way a site that nobody edited still ends up setting something new.

A third party changes its own cookies

You do not control what an analytics provider, a chat widget or an ad platform writes into a visitor's browser. When they rename a cookie or add one, your site starts setting it without a single line of your own code changing.

An embed lands in one blog post

A video, a map or a social card gets pasted into one article, on one page, months after launch. Checking the homepage will never reveal it, which is exactly why a crawl beats a spot check.

The practical consequence is not dramatic, which is part of the problem. Your cookie policy lists cookies you no longer set and says nothing about ones you do, so the document that is supposed to describe your site describes a past version of it. Kukie provides the technical infrastructure for finding and categorising what your site sets. Whether your site is compliant depends on how you configure it and may require additional legal measures specific to your organisation.

What does an automatic cookie scan actually look at?

A scan is not a read of your page source. Reading the HTML tells you which scripts a page asks for, not what those scripts do once they run, and almost every cookie on a modern site is written by JavaScript after the page has loaded. So Kukie does not read your markup. It opens your site.

Each page is loaded in a real headless Chromium browser driven by Playwright, the same engine class a visitor uses. Scripts execute, embeds initialise, storage gets written, and the scanner watches all of it happen rather than inferring it.

Scan specification

The browser: Real headless Chromium, driven by Playwright. The page loads the way a visitor loads it, rather than being parsed as static HTML.
What gets recorded: Cookies, localStorage entries and sessionStorage entries, in one inventory. Tracking that has moved out of the cookie jar is still tracking.
Two passes, not one: The first pass captures every cookie with nothing held back, so the inventory is complete. The second isolates the trackers, so the analysis is clean.
While it runs: Progress updates in real time, so you can watch pages being worked through instead of waiting at a blank screen.
Afterwards: Every run is kept as scan history, so the current picture always has previous ones to sit against.

Checking by hand against scanning on a schedule

You can do this yourself. Open your site, open the browser's developer tools, read the storage panels and write the list down. It works, and for a five-page site it may be all you need. Here is what the two approaches actually differ on.

A manual browser check compared with automatic scheduled cookie scanning
What you are trying to find out	Checking by hand	Automatic cookie scanning
Which pages get looked at	The ones you remember to open, which in practice means the homepage and maybe the checkout	The pages the crawl reaches, every time it runs, including the ones you have forgotten exist
Which storage types	Cookies are obvious; localStorage and sessionStorage sit in separate panels people forget to open	Cookies, localStorage and sessionStorage recorded together as one list
What each cookie is for	You search the name and take your best guess from a forum post	Matched against 3,400+ known cookies, with a category proposed for you to confirm
Cookies carrying a unique suffix	Look like one-offs nobody has ever documented, because the identifier in the name is yours alone	Normalised before lookup, so a per-installation variant still matches its known cookie
Keeping it current	Requires you to remember, at a point in the future, that this needs doing again	Runs weekly or monthly on its own, or on demand when you know something changed
A record of what it looked like before	Whatever notes you kept, wherever you kept them	Scan history, retained run by run

Doing it by hand is a perfectly reasonable way to start, and it is worth doing once so you understand what your own site sets. The argument for automating it is not that a person cannot do it. It is that a person will not do it every week for two years.

How does a scanner know what a cookie is for?

Finding a cookie is the easy half. A cookie called _gid means nothing to a site owner until somebody says which category it belongs in, and a consent banner cannot act on a decision about a category nothing has been sorted into. This is the part that turns a list of names into something usable.

Step one

The name is matched against the known-cookie database

Kukie keeps a database of 3,400+ cookies that have already been identified: what sets them, what they are for and which consent category they belong in. Most of what a scan finds on an ordinary website is already in there, so most of your list arrives with a category attached rather than blank.

Step two

Names with a unique suffix are normalised first

Plenty of cookies carry an identifier that is unique to your installation, so the name on your site is not the name anybody else would ever see. A straight lookup would miss every one of them and report a site full of mysteries. Kukie strips the changing part before it looks the name up, so a per-installation variant still matches the known cookie it actually is.

Step three

Whatever is left over comes to you

Nothing is quietly guessed at and filed away where you will not see it. Cookies the database does not recognise are surfaced as uncategorised and wait for a decision from you. You also have the final say on the ones that were categorised automatically, because the person who knows why a cookie exists on your site is you.

Step four

Your decision improves the database for everyone

When you categorise an unrecognised cookie, that judgement feeds a community signal into the shared database. An unusual cookie that several site owners have independently identified the same way stops being unusual, and the next site running a scan gets it categorised without having to work it out.

What runs on its own, and what needs you

"Automatic" should mean the mechanical work disappears, not that judgements get made on your behalf without telling you. Here is the division of labour.

Happens without you

The rescan itself, on your chosen weekly or monthly cadence, with no reminder in your calendar and nobody to nag.
Loading each page in a real browser, waiting for the scripts to do their work, and recording the cookies and browser storage that result.
Normalising names, looking each one up and proposing a category for everything the database recognises.
Keeping the run in scan history, so the site's cookie picture has a past and not just a present.

Stays your decision

How often it runs. Set it per site, because a site that changes weekly and a site that changes yearly do not need the same rhythm.
Which category anything unrecognised belongs in. The scanner will not invent an answer it does not have.
Whether a proposed category is right for your context. A cookie that is functional on one site can be doing something else on another.
What you do about a cookie you did not expect. Finding it is the scanner's job; deciding whether it should be there at all is not.

Where the results go once a scan finishes

A scan report you read once and close has not saved you anything. What makes scanning worth automating is that the output is wired into the things that have to stay accurate, so keeping the scan current keeps them current too.

Your site's cookie list

The working record. Every cookie, localStorage and sessionStorage entry the scan found, each sitting in a category, each editable by you. This is the list everything else reads from.

Your cookie policy

The legal document generator pre-fills from what the scan found, which is the difference between a policy describing your site and a policy describing a template.

Your script settings

Results feed the script centre, where a third-party tag is tied to the consent category it belongs to. See script blocking for how that enforcement side works.

Want to see the output before you sign up for anything?

The free cookie scanner runs the same headless browser against up to 10 pages of any site, with no account and no card. It is the fastest way to find out what you are dealing with. What it does not do is come back next month, remember the categories you chose or feed your cookie policy, and that is the whole difference between a one-off look and automatic cookie scanning.

Scanning is included on every plan. Compare plans to see how scheduled rescans and scan volume differ, or read the public cookie database to look up a specific cookie by name right now.

When scheduled scanning earns its place

A single static page you built yourself and never touch is genuinely fine with one manual check. These are the situations where the drift is fast enough that a schedule pays for itself.

More than one person can add scripts

The moment a tag manager exists, or a marketing team has access, your cookie list stops being something one person can hold in their head. A schedule tells you what got added without anyone having to confess.

You run WordPress, WooCommerce or a site builder

Plugin and theme updates change storage behaviour without touching your content. See Kukie for WordPress and WooCommerce for the platform specifics.

You look after sites for clients

Manually re-auditing twenty client sites every quarter is a job nobody wants and everybody postpones. Scheduling it per site turns it into something that reports to you. See agencies and teams.

Somebody may ask you to justify the list

A customer, a partner's security review or a regulator's enquiry all end with the same question: how do you know that is what your site sets? Scan history is a dated answer rather than a recollection.

Related features

Scanning tells you what is there. These are the features that act on what it finds.

Script blocking

Tags wait for consent

Legal documents

Cookie and privacy policies

Analytics

Consent rates and records

See the full feature set

Cookie scanning questions

What site owners ask before they set a scan running.

What is automatic cookie scanning?

Automatic cookie scanning is the process of loading your own website in a browser, on a schedule, and recording every cookie and browser storage entry that gets set. Instead of you opening developer tools and reading the list by hand, a scanner walks the site, writes down what it finds, and compares that against a database of cookies it already recognises so most entries arrive with a category already proposed.

How often should I rescan my website for cookies?

It depends on how often the site changes. A brochure site that nobody touches for months can sit on a monthly rescan. A site where marketing adds tags, or where plugins and themes update themselves, is better on a weekly one. Kukie lets you set the frequency per site to weekly or monthly, or turn scheduling off and scan manually when you know something has changed.

Does a cookie scanner find localStorage and sessionStorage too?

Kukie records localStorage and sessionStorage entries alongside cookies. This matters because a lot of tracking has moved out of cookies and into browser storage, and a check that only looks at the cookie jar will report a clean site while identifiers sit in localStorage. Both appear in the same result list so you are looking at one inventory rather than three.

What happens when the scanner finds a cookie it does not recognise?

It is listed as uncategorised and waits for you. You decide which category it belongs in, and that decision applies from then on rather than being overwritten by the next scan. Your categorisation also feeds a community signal into the shared cookie database, so an unusual cookie that several site owners have identified the same way becomes easier for everyone to categorise later.

Do I need an account to scan a website for cookies?

Not to try it. Kukie runs a free public scanner that checks a limited number of pages on any site with no signup at all, which is enough to see what a site is setting today. An account is what turns that into something ongoing: scheduled rescans, a stored scan history, saved categorisations that survive the next run, and results that flow into your cookie policy.

Is scanning cookies the same as blocking them?

No, and this is a common source of confusion. Scanning is a survey: it tells you what your site sets. Blocking is enforcement: it stops those cookies being set until a visitor has agreed. You need both, and they work together, because knowing which category a cookie belongs to is what lets the blocking rules act on a visitor decision correctly.

Find out what your site sets, then keep knowing

Free plan, no card required. Run a scan today and put it on a schedule in a couple of clicks.

Start Free → View pricing