I opened a client’s contact page last week and the form wasn’t there. In its place sat a grey box asking the visitor to accept cookies before the form would load. That page is how they win new business, and a fair share of the people landing on it were getting a cookie prompt instead of a way to get in touch.
If you have seen the same thing, you are in good company. Teams on HubSpot, Klaviyo, JotForm, Monday and Typeform all hit it. The HubSpot community has long-running threads asking why Cookiebot blocks their forms, and the complaint underneath never changes: a visitor does not accept cookies, the form never appears, and the lead is gone.
The short version. Your embedded form loads from someone else’s domain, so your consent tool blocks it like a tracker until a visitor accepts cookies. Patch it in your consent tool today. Deliver the form first-party from your own domain to fix it for good.
What is actually happening
Your contact form is almost certainly an embed. You did not build a form on your own site. You pasted a snippet that pulls one in from the provider, something like form.jotform.com or js.hsforms.net.
You have probably got a cookie consent tool running too. Cookiebot, Usercentrics, OneTrust, Termageddon. Most of them ship an auto-blocker that holds back third-party scripts until the visitor agrees to cookies, which keeps the site on the right side of privacy rules like GDPR, UK GDPR and the Australian Privacy Principles. Those same rules carry privacy obligations on the contact form data itself, separate from the cookie question.
Here is the collision. The auto-blocker decides what to block by the domain a script loads from. Off your domain means third-party, and third-party gets held until consent. Your form loads from the provider’s domain, so the blocker treats it like a tracking pixel and keeps it hidden.
The form is innocent. It gets caught because it comes from someone else’s domain, and the blocker cannot tell a contact form from a tracker.
Why this costs more than it looks
Most visitors never touch the cookie banner. They scroll past it, ignore it, close it without accepting. No accept means no consent, and no consent means the form stays hidden for the whole visit.
So this is not some fringe problem affecting a handful of privacy diehards. It can hit a large slice of everyone who reaches your contact page, and those are your warmest visitors. They came to talk to you. The form was the one thing the page had to get right.
It is also quiet. The people it hits often are not tracked in the first place, so nothing spikes in your analytics. The enquiries just stop, and nothing tells you why.
The visitors this hits came to contact you. Not browsers killing time. They reached the contact page on purpose, and the page failed at its one job.
The quick fix, and where it falls short
The fastest fix is free and lives in your consent tool. Mark the form’s service as functional or essential rather than marketing, or allowlist the form’s domain so the blocker leaves it alone.
There is a fair argument that this is the right setting anyway. Consent rules are about tracking and marketing cookies, not a contact form someone is trying to use. Showing the form sends no data. Data only leaves when the visitor clicks submit, and that click is the permission. A form should not sit behind a consent gate.
Know your way around the dashboard? It takes about five minutes. Do it today.
It has limits, though, and they are worth being straight about:
- It repeats on every site and every new form. For an agency running a stack of client sites, that is an ongoing job, not a one-off.
- It can quietly revert. A consent-tool update, a settings re-import, or a new starter can flip the blocking back on, and the forms go dark with no warning.
- Some blockers stay aggressive. A few keep catching a provider’s assets even after you think you have allowed them, so the patch does not always hold.
It is a patch, and patches lift. Which raises a better question: what if the form never looked like a third party to begin with?
The permanent fix: first-party forms
All of this traces back to one thing. The form loads from a domain that is not yours. Remove that and the blocker has nothing to catch.
A first-party form loads from your own domain, say forms.yourcompany.com, not the provider’s. To the consent tool, the form is now part of your site, because it is. No foreign domain to flag, so it renders for everyone, banner or no banner.
That fixes the problem in the architecture, not in a settings panel:
- It works by default. No per-site setup to configure or remember.
- It survives consent-tool changes. There is no third-party domain for an update to start blocking.
- It holds against tracker blockers and Safari’s Intelligent Tracking Prevention. Those also work by spotting third-party domains.
- It keeps your posture clean. You are not bending the rules. You are removing a consent question that should never have applied to a contact form, which keeps you aligned with GDPR, UK GDPR and the Australian Privacy Principles.
It is the same first-party move good teams already use to keep their lead tracking and lead source data out of reach of trackers and ITP. Bringing your forms onto your own domain is the obvious next step. Lead Source does exactly that; see how it works.
What to do next
If your forms vanish when someone declines cookies, work it in this order:
- Patch it today. Allowlist the form’s domain, or mark it functional, in your consent tool. That stops the immediate bleeding.
- Check it properly. Open the contact page in a private window, decline cookies, and confirm the form still loads. Do not call it fixed until you have watched it render with consent refused. This is the step most people skip, and it is how the problem creeps back unnoticed.
- Fix it for good. Move to first-party form delivery so it cannot return, on this site or the next one.
A contact form has one job: let people reach you. If a cookie banner is standing between your best visitors and that form, it is not protecting anyone. It is costing you business.