Ask a WordPress site owner which cookies their site sets and you will usually hear the list from the day the consent banner was installed. The site has moved on since then. Plugins updated, a video got embedded, a chat widget arrived for a campaign and never left. The banner still describes the old site.
Cookies are inventory, and inventory drifts without counting. Scanning is the stock take. It is unglamorous, repeatable, and the only way the consent experience can claim to describe the site it actually runs on.
What changes cookies without telling you
Plugin updates are the biggest source. A plugin that set two cookies can set five after an update that adds analytics or a new feature, and the changelog may not mention it. Theme changes, new embeds, and marketing tools installed through tag managers do the same.
Even content edits matter. One blog post with an embedded video or social post can introduce third party cookies that the rest of the site never sets, which is why scanning must cover real content pages, not only the homepage.
A scanning rhythm that works
Scan after every plugin or theme change, however small, because small changes are exactly the ones nobody associates with cookies. Add a standing monthly scan to catch drift from updates applied automatically and embeds added in content.
Keep scan results dated and filed with the site's privacy records. When a visitor or regulator asks what the site set at a given time, a scan history answers with evidence instead of reconstruction.
Handling what the scan finds
Every new cookie gets three decisions: what is it, which consent category does it belong to, and should it exist at all. The third question is the valuable one. Scans routinely find leftovers from removed campaigns and abandoned tools that should be deleted, not categorized.
Update the banner configuration and the cookie policy page together, from the same scan. A banner that blocks correctly beside a policy page listing last year's cookies is a half finished job that readers can see.
Automating without going blind
Automated scanners inside consent plugins make the rhythm cheap, but review their findings like an editor, not a rubber stamp. Auto categorization guesses wrong on unfamiliar cookies, and a wrong category can block a necessary cookie or wave through a marketing one.
Pair automation with one manual pass per quarter using browser tools on key journeys: checkout, account, and a content page with embeds. The manual pass catches behavior scanners miss, like cookies set only after an interaction.
Related reading
These earlier guides go deeper on connected questions: Moving a WordPress Consent Setup From Staging to Production Without Losing Records Consent setups break quietly during launches: settings copied by hand, IDs changed, records split across environments. A migration checklist that keeps banners, blocking, and records intact., WordPress Consent on Multisite: One Setup, Many Sites, Real Differences Multisite networks promise one consent setup for many sites. Subsidiary sites differ in language, tools, and legal duties, so a network consent plan needs shared defaults plus per site checks., and WordPress Consent After a Theme Change: The Settings That Silently Reset Theme changes are the quiet consent killer on WordPress. Header scripts move, plugin hooks change, and the banner that worked in January is firing after the analytics by March. A post-theme consent checklist prevents it..
Frequently asked questions
How often should a WordPress site scan for cookies?
After every plugin, theme, or embed change, plus a routine monthly scan. Automatic updates make change constant even on quiet sites, so a rhythm based only on remembered changes will miss drift.
Why is scanning only the homepage not enough?
Many cookies appear only on specific pages or after interactions, such as embedded videos in posts, checkout tools, or account features. A homepage scan gives a partial inventory that misses exactly those cases.
What should happen when a scan finds an unknown cookie?
Identify its source, usually a plugin or embed, decide its correct consent category, and check whether it should exist at all. Then update the banner and cookie policy together. Unknown cookies left in place are a finding waiting to happen.
Can a consent plugin scan and categorize automatically?
It can scan reliably and categorize common cookies well. Human review still matters for unfamiliar cookies and for the decision about whether a cookie should exist. Automation sets the rhythm, judgment closes it.