You have read this far without dismissing anything. No overlay slid up from the bottom of the screen. No panel offered you a bright “accept all” button next to a grey link to a settings page designed to make accepting all feel easier.
That is not an oversight, and it is not a legal risk we are quietly running. There is nothing here to ask you about.
Which is worth explaining, because the reason is not idealism about privacy. It is the same engineering argument we apply to everything else we build.
A banner is not a requirement, it is a consequence
The law does not say that every website must show a cookie notice. It says you need permission before storing or reading things on someone’s device that are not strictly necessary for the thing they came for. Analytics is not strictly necessary. An advertising pixel is not strictly necessary. A session recorder is not strictly necessary.
So the sequence runs the opposite way to how most people experience it. Nobody is compelled to display a banner. Somebody decided to track, and the banner is the receipt for that decision.
Usually nobody decided it in one sitting, either. Analytics went on in week one, because analytics always goes on in week one. A pixel arrived later for a retargeting campaign that was discussed and never ran. A heatmap tool came in during a redesign and outlived the redesign by three years. By the time anyone reviews the site there are more third parties running in the browser than the team can name, and the cheapest available fix is a banner that makes the pile lawful, rather than an afternoon spent asking which of them anybody still reads.
Most cookie banners are not a privacy decision. They are the cost of never having made one.
What this site does instead
Nothing loads from a domain we do not own. No analytics script, no tag manager, no advertising pixel, no embedded video, no map, no chat widget, and no typeface served from somebody else’s network. The fonts sit on our server. The one form on the site posts to our server.
A normal visit sets no cookies at all. Not one. WordPress issues them for people who log in to administer the site, which is us, and that is the end of the list.
There is therefore no consent to collect, no preference to store, no banner to maintain and nothing to keep in sync when a vendor changes their terms. It also means the privacy policy can describe the whole arrangement in a few paragraphs that a person can read without a lawyer present, which is a fair test of whether a site is doing anything strange.
The obvious objection: then how do you know anything works
Fair question. Flying blind is not a virtue, and “we care about your privacy” is what people write when they mean they never got round to it.
Search Console does most of the work. It runs no script on the site and sets no cookies, because it reports from the search engine’s side rather than from the visitor’s browser. It also answers the question that actually matters for a site like this one: which searches put us in front of somebody, which pages they chose, and where we sit in the results. For a business site that needs to be found, that is a more useful signal than a bounce rate ever was.
Server logs cover the basics. Requests, referrers, which pages get read, what is a person and what is a crawler. Those logs exist for security regardless, so looking at them collects nothing new.
Where on-site behaviour genuinely matters, there is cookieless first-party measurement that runs on the client’s own server and never calls a third party. It needs no banner because it stores nothing on the device and identifies nobody. That is what we reach for when a site is large enough that visitor behaviour is a real question rather than a rounding error.
And then the unglamorous one. On a business site, the number that decides everything is how many enquiries arrived and what they were about. Counting those has never required a tag manager.
That last number has one failure mode worth naming, because it is the reason we ended up building a separate tool instead of a smarter dashboard. A contact form that quietly stops sending produces exactly the same figure as a month when nobody wanted us. Zero. The page still returns 200. The server still looks healthy. Analytics, if we ran any, would cheerfully report every visitor who filled that form in and got nothing back. You find out weeks later, from a client mentioning they emailed twice and never heard from you.
So the thing worth watching is not traffic. It is whether the parts the business actually depends on are still doing their job: the form still handing mail to the server, the checkout still reaching payment, the certificate still valid, the page behind that 200 still being a real page rather than a white one. That is what GoFirmo does. We wrote it because we maintain other people’s sites and needed it, and it now runs across the ones we look after.
Knowing a site is up is table stakes, and most tools stop there. Knowing it still works is the part that pays for itself the first time it catches something.
Why an engineer objects before a lawyer does
Remove the privacy argument entirely and the case still stands on its own.
Every third-party script is a dependency you do not control, executing in your visitor’s browser, on your domain, with your name on it. It costs render time on the critical path, which is the part of page speed users actually feel. It is a security surface, because that vendor’s supply chain has quietly become yours. It is an availability risk, because when their edge has a bad afternoon your pages get slower and there is nothing you can do from your side. And it is a policy risk, because what they collect can change in a release note nobody on your team will read.
This is the plugin pile argument, moved from the server to the browser. A plugin you do not need is a liability on your server. A script you do not need is a liability on your visitor’s machine, which is worse, because that machine is not yours to fix.
The defensible position is identical in both places. Everything that runs has a reason somebody can say out loud, and everything else is not there.
When you genuinely do need the banner
This is not a purity contest, and a site that sells things has different arithmetic from a site that answers questions.
If you run paid campaigns and have to attribute conversions, you need the tracking, which means you need consent, collected properly and honoured properly, not a banner that quietly records “accepted” whichever button was clicked. If you sell online and want recommendations or abandoned-basket recovery, the same answer applies. And if your business runs on an embedded booking tool or live chat, that third party is in the browser whether anyone likes it or not, and it has to be declared.
We build that layer when it is warranted, and we would much rather build it than pretend the obligation away. Half-implemented consent is worse than an honest banner, because it carries the friction and the legal exposure at the same time.
The point here is narrower and duller than “tracking is bad”. It is that most sites carrying a banner were never asked whether they wanted the thing the banner exists to make lawful. They inherited it one script at a time, and now they pay for it in consent friction, page weight, and a privacy policy nobody in the building could summarise.
The small thing and the large thing
A cookie banner is a small piece of interface. It is also the visible end of a long chain of decisions about whose code runs on your site and what it does with the people who visit it.
Worth choosing deliberately. More often than not, worth choosing less.
If you are looking at your own site and cannot say with confidence what is running inside it, that is one of the first things a maintenance or rescue engagement establishes, and it is usually a short conversation rather than a long audit. Tell us what you have and we will tell you what is in it.
Common questions
Does my site need a cookie banner?
Only if it sets cookies that are not strictly necessary, which in practice means analytics, advertising or embedded third-party widgets. The banner is not a legal requirement in itself. It is the consequence of a decision to track, and that decision is usually made without anyone asking whether the data will ever be read. Take the trackers out and there is nothing left to ask consent for. If you genuinely need them, for instance because you run ads and have to attribute conversions, then you need the consent layer built properly rather than bolted on.
Do you install Google Analytics?
Only when a client asks for it and understands what comes with it: a consent banner, a transfer of visitor data to a third country, and numbers that are incomplete anyway once people decline. For most business sites we start with Google Search Console, which needs no script and no cookies and answers the more useful question of what people searched for before they arrived. Where on-site behaviour genuinely matters, we use cookieless first-party measurement hosted on the client’s own server, so the data never leaves their infrastructure.
How do you find out when something on my site breaks?
Monitoring that watches the business, not just the server. Most tools tell you a site is down, which is the easy case and the rare one. The expensive failures are quiet: a contact form that stops handing mail to the server after an update, a checkout that fails at payment, an expired certificate, a page still returning 200 with nothing on it. We built GoFirmo for exactly that, because we maintain sites for other people and needed it, and it runs across the ones we look after. The point is that we hear about it before you do.
Which SEO plugin do you use?
Yoast, Premium on the larger sites, for titles, meta and sitemaps. Everything else about SEO is structure, content and page speed, which is work, not a plugin.
Can you take over and fix an existing WordPress site?
Yes. A large part of our work is inheriting sites, often after an agency handoff, auditing the plugin pile, and taking it back down to a short list we can maintain for years.