What should an agency do when a client site shows two cookie banners?
Two banners on one site usually means two systems firing consent prompts while neither one is fully blocking trackers. Find out which banner is actually doing the blocking, check where the consent records live, then consolidate to one system with a single, complete consent record.
Why this happens
Almost every double-banner situation is inherited. A previous developer installed a plugin, the marketing team later added a different tool through the tag manager, and nobody removed the first one. Sometimes the client signed up for a second platform during a panic about a regulation deadline and left the old banner running as a backup. In every version, both banners pop up, visitors click through one or both out of confusion, and the site ends up with overlapping logic: banner A blocks some scripts, banner B records some choices, and no single system has the full picture.
Find out which banner actually blocks
Open the site in a private window and open the browser developer tools before touching either banner. Reload and watch the network tab for analytics, ad, and social scripts firing before any choice is made. Then accept only the first banner and reload again. If trackers still fire, that banner is cosmetic. Repeat for the second. The banner that actually stops non-essential scripts before consent is the one doing real work; the other is a popup with no enforcement behind it. Document which is which with screenshots, because you will need to show the client why one of them has to go.
Check where the consent records live
Blocking is only half the job. The consent records are the proof, and with two systems they are almost always split. Pull the records from both platforms and look at the gaps: dates with no entries, conflicting choices from the same visitor, or one system that records nothing at all. A site with two banners and one incomplete record store is worse off than a site with one banner, because an incomplete trail looks like negligence on inspection. Export whatever records exist from the system you plan to retire before you touch anything, so the historical trail survives the consolidation.
Pick one and retire the other
Keep the system that blocks reliably, stores complete records, and supports the consent categories the client's visitors actually see. The other one gets fully decommissioned, not just hidden. That means removing its script from the site, removing any tag manager templates that reference it, and closing or downgrading the account so it cannot be reactivated by accident. Hiding a banner with CSS while its script keeps running is the most common half-fix, and it leaves the site still loading a dead system on every page view.
Re-test everything after the switch
The tag manager is where double-banner problems come back to life. Triggers and variables from the retired tool often remain referenced by other tags, and consent signals from the old platform can conflict with the new one for weeks. After consolidation, run a full fresh scan of the site: block check on a clean visit, a reject-all choice, an accept-all choice, and a granular choice, with the network tab open each time. Only when all four behave correctly on the single remaining system is the job actually done.