Feature Requests

Allow users to password protect individual pages, rather than entire sites.

When a custom domain is connected to a Framer site, the default *.framer.app URL remains publicly accessible with a 200 response and cannot currently be disabled or redirected to the custom domain. This can create an SEO/canonicalization problem. In my case, both the custom domain and the framer.app URL correctly declared my custom domain as canonical, but Google still selected the framer.app URL as the Google-selected canonical. As a result, my custom domain was excluded from Google's index as a duplicate. I was able to resolve the issue by adding custom JavaScript that detects the framer.app hostname and dynamically applies: <meta name="robots" content="noindex, nofollow"> Google Search Console confirmed that Googlebot detected the noindex directive. After Google recrawled both URLs, the framer.app URL was excluded by noindex , my custom domain became Google's selected canonical, and the custom domain was successfully indexed and began appearing in Google Search. It would be very helpful if Framer provided a native option when connecting a custom domain to either: * Automatically apply noindex to the default *.framer.app URL, or * Redirect the *.framer.app URL to the configured custom domain. Ideally, the redirect would be the preferred solution, with noindex available as an alternative. This would prevent the Framer staging/default domain from competing with customers' production custom domains in search results and eliminate the need for a JavaScript workaround.

Allow a single Framer project to be mapped to multiple custom domains (e.g., example.nl , example.de ) so it can be used for automatic locale‑based routing, SEO tag management, and domain‑aware internal linking.

Add media library functionality specifically for docs/pdfs.

My setup runs through Cloudflare as a proxy. The site publishes and serves correctly, and I redirect a couple of paths to a Cloudflare Worker without issue. The only problem is that the DNS verification in the publish console sits in a permanent error state. As far as I can tell the check can never pass in this configuration, since a proxied record won't resolve to what Framer expects to see. That's fine by me, I'm not after Framer's advanced hosting and I want Cloudflare handling the routing. But a persistent red error on a working site is a bit of a rough UX. Something like a "verified manually" or "dismiss" option on that check would solve it. Happy to provide any config details if useful.

This would help to reduce the risk of using Google Fonts accidentally.

The editor never actually initiates the deployment request. In DevTools (Network), there are no publish, deploy, or build calls—only tracking requests running in a loop. A new project publishes normally, yet a copy of this project exhibits the exact same behavior. This suggests an issue with the project's internal state or metadata. Could you check if there is a stuck publish job or any corruption in the project state?

Baffled that Framer won't let me protect my site, either with robots.txt or geographic restrictions. Why on earth should I pay $30/month just for the privilege of reducing the number of bots scraping my site? My traffic shows daily visits from Russia and China, which I can guarantee are not potential clients of mine.

I think it's outrageous that adding static files, like robots.txt, is cut off from Basic plans. It's no different than adding custom code blocks to my project and doesn't add any additional strain to Framer's system. We absolutely need the ability to add further protections from data scraping as AI use scales up. I used to be able to add custom files, it's unacceptable to remove features from paid plans and hide them in more expensive tiers.

ability to brand and customize protected pages