Cookie consent after leaving Framer

When you convert a Framer site, its cookie banner comes along: a banner from Framer's marketplace arrives as source code in src/vendor, and a consent platform loaded through Framer's custom code is carried into the layout with that code. What needs checking is the order in which scripts run. Tracking scripts in custom code run as the browser parses the page, before React hydrates any banner, so a banner component alone can't hold them back. After converting, confirm that nothing sets non-essential cookies before a visitor consents, and fix the order where it does.

This post explains what carries over, how to test it, and three ways to set consent up properly in code. It's a technical guide, not legal advice: what your site must ask for depends on where you and your visitors are, and a privacy professional should confirm your setup. If you are still planning the move, what to do before you cancel your Framer plan puts this check in context. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.

What carries over from Framer

Site-level custom code is placed so the browser runs it in the same order as on Framer: head code at the start of the body, before any content, and body code at the start or end of the body. That's deliberate: tag loaders and consent platforms expect to run early.

Why script order decides whether consent works

There are two kinds of banner, and they behave differently:

• A consent platform loaded as a script. It runs early, blocks or rewrites other scripts until the visitor chooses, and often sets Google Consent Mode. Because it's a script in custom code, it keeps working the same way after conversion, provided it still runs before the tags it controls.
• A banner built as a React component. It renders after the page hydrates. By then, any tracking script placed directly in custom code has already run. A component banner can only control scripts that wait for it: scripts it loads itself, or tools configured to start in a "denied" state.

So the question to answer after converting is not "is the banner there?" but "does anything track before the visitor says yes?"

How to test it

Use a fresh browser profile or a private window, and don't click the banner.

1. Open the site, then the browser's developer tools.
2. In the Application (Chrome) or Storage (Firefox) panel, look at cookies and local storage for your domain and third-party domains.
3. In the Network panel, filter for your analytics and ad endpoints, such as google-analytics.com, googletagmanager.com, facebook, plausible, posthog.
4. Now accept the banner and watch what starts.

Before consent, you should see only strictly necessary cookies and no requests to tools that need consent. If you use Google Consent Mode, requests may still go out before consent in a cookieless "denied" form; that's how Consent Mode is designed, so check the gcs parameter or your platform's documentation rather than the request alone.

Do the same test on the old Framer site. If it tracked before consent there, converting doesn't fix it; it's a setup problem to fix either way.

Option 1: keep your consent platform

If you used a consent platform through custom code, the simplest path is to keep it.

1. Confirm its script is still the first thing in the carried-over custom code, before analytics and tags.
2. Add your new domain in the platform's dashboard if the domain changed. Most platforms only run on domains you've registered.
3. Run the platform's own scan on the new site, if it has one, so its cookie list matches what the site actually sets.
4. Re-run the test above.

Option 2: Google Consent Mode with your existing tags

If you use Google tags, set the default consent state before any tag loads, then update it when the visitor chooses. The default must come first in the document:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', analytics_storage: 'denied'
  });
</script>

Your banner then calls gtag('consent', 'update', { analytics_storage: 'granted', … }) when the visitor accepts. Check Google's current Consent Mode documentation for the parameters that apply to your setup.

In the converted project, put the default block before the Google tag in the carried-over custom code. Search for it with:

grep -rn "gtag\|googletagmanager" src | head

Option 3: load tracking only after consent, in code

If you'd rather not depend on a platform, make your banner the gatekeeper:

1. Remove the tracking snippets from the carried-over custom code, so nothing loads unconditionally.
2. Store the visitor's choice in a first-party cookie or local storage when they click.
3. Load scripts only when the choice allows it, from a client component in the root layout:

"use client";
import Script from "next/script";
import { useEffect, useState } from "react";

export function ConsentedScripts() {
  const [analytics, setAnalytics] = useState(false);
  useEffect(() => {
    const read = () => setAnalytics(localStorage.getItem("consent-analytics") === "yes");
    read();
    window.addEventListener("consent-changed", read);
    return () => window.removeEventListener("consent-changed", read);
  }, []);
  return analytics ? <Script src="https://plausible.io/js/script.js" data-domain="example.com" strategy="afterInteractive" /> : null;
}

4. Have the banner set the value and dispatch consent-changed when the visitor chooses.
5. Add a way to change the choice later, such as a "Cookie settings" link in the footer that reopens the banner.

If your marketplace banner already stores the choice, read its value instead of inventing a new one: open its source in src/vendor to see what it stores.

The other frameworks

The same principles apply in TanStack Start, Astro, React Router and Vite projects. Custom code is carried into each framework's document (in Astro and React Router, the site's own tags are in src/site/head.ts), so check the order there. For option 3, load scripts from a component in the root route or layout, the same way as above.

Cookieless analytics can simplify this

Some analytics tools are designed to work without cookies or personal data, and their makers say they don't need a consent banner in many jurisdictions. Whether that holds for your site is a legal question, so check with someone qualified. If it does, moving to such a tool can remove the banner for analytics entirely; analytics after moving off Framer compares the options.

Before you launch

1. Test with a fresh browser before consent, after accepting and after rejecting.
2. Check the privacy policy names the tools the new site actually uses.
3. Register the new domain with your consent platform and analytics tools.
4. Make sure the "change settings" link works on every page.
5. Add this test to your migration checklist.