Building a Real Cookie Consent Settings Flow in Next.js

I found a small but important compliance UI problem on a Next.js site: the Privacy Policy page told users they could open Cookie/Consent settings, but clicking the link did not show anything.

That is not just a small UI issue. If a site says users can manage consent choices, the control needs to actually work. Otherwise the Privacy Policy looks incomplete, and the consent experience feels fake.

This note documents how I fixed the flow by connecting the Privacy Policy link to a real consent settings panel, then changing the cookie consent behavior so first-time visitors see a normal bottom-right consent panel instead of needing to find the setting inside the Privacy Policy page.

The Privacy Policy page had text like this:

But clicking the Cookie/Consent settings link did not open anything.

The visible issue was:

That made the page look broken because the policy promised a control that the interface did not actually provide.

The first wrong assumption was thinking that a Privacy Policy link alone was enough.

It is not.

A Privacy Policy link can be useful for letting users revisit their choices later, but it should not be the only way users see cookie consent options.

A more normal consent flow is:

The Privacy Policy should support consent management, not hide the only consent control.

After inspecting the implementation, the issue became clear.

The Privacy Policy page had a trigger-style attribute:

But the consent component did not have a matching event listener that opened the settings panel when that trigger was clicked.

So the page had a visible entry point, but no connected behavior.

The simplified bug looked like this:

This was an implementation gap, not expected cookie consent behavior.

The fix needed to solve two separate problems:

Only fixing the Privacy Policy link would still be weak UX because most users will not go to the Privacy Policy page first.

The better direction was to build a reusable consent settings flow:

That turns the consent UI from a dead link into a real site-level control.

The first implementation step was to make the Privacy Policy link actually do something.

Instead of treating the Privacy Policy link as a normal navigation link, I used it as a trigger that opens the existing consent settings UI.

The behavior is:

This makes the Privacy Policy page useful as a place where users can revisit their choices later.

The next fix was changing the first-visit behavior.

The consent panel should not only appear after someone finds the Privacy Policy. It should appear automatically when the user has not made a consent choice yet.

The rule became:

This matches the normal consent banner pattern better than hiding the control inside a policy page.

The settings panel needs real choices, not only informational text.

The panel includes:

Essential cookies stay enabled because they are needed for basic site behavior. Optional categories can be accepted, rejected, or saved according to the user's choice.

This gives the panel real functionality instead of making it a decorative compliance element.

After the user makes a choice, the large first-visit panel should not keep blocking the page.

But the user still needs a way to reopen settings later.

So the flow uses a smaller persistent button:

This keeps the page clean while still giving users access to consent controls.

Saving a consent choice should update more than local UI state.

The selected choice also needs to update Google Consent Mode so analytics and advertising behavior follows the stored preference.

The simplified model is:

The important point is that UI state, saved cookie state, and consent mode state should not drift apart.

After implementing the consent flow, I verified the site at several levels.

The checks were:

This matters because cookie consent is not only a visual component. It touches layout, client-side state, cookies, policy pages, and sometimes analytics behavior.

Before the fix, the consent experience looked like this:

After the fix, the behavior became:

That is a real consent settings flow instead of a dead policy link.

The main gotcha is that a Privacy Policy link is not the same thing as a consent system.

A Privacy Policy can explain what cookies are used and provide a way to reopen settings. But the actual consent flow should usually be visible during normal browsing, especially before the user has made a choice.

The practical lesson is:

All four parts need to work together.

A generic article about cookie consent would probably explain what cookies are, why consent matters, and what a banner usually does.

That would be weak because many sites already say the same thing.

This implementation note is stronger because it includes:

That makes the article a real build record instead of a generic overview.

For a real cookie consent settings flow, I would check:

This checklist is more useful than only asking whether the site has a cookie banner.

The final takeaway is simple:

For this fix, the important change was turning a dead Privacy Policy link into a working consent settings flow. The final implementation supports a first-visit consent panel, saved choices, a persistent Cookie settings button, Privacy Policy re-entry, and build-level verification.

That makes the Privacy Policy and cookie consent UI feel like part of the same system instead of two disconnected pieces.