Feature Requests

Several third-party security rating tools (e.g., SecurityScorecard) flag published Framer sites for "Unsafe Implementation of Subresource Integrity" because the scripts Framer's platform injects automatically don't include integrity/crossorigin attributes. This includes things like: https://events.framer.com/script?v=2 https://framerusercontent.com/sites/<site-id>/script_main.[hash].mjs (the main site bundle) https://app.framerstatic.com/chunk-[hash].mjs (editor/runtime chunks) These are emitted by Framer's own publishing pipeline, so site owners have no way to add SRI attributes ourselves. The Custom Code panel only lets us inject scripts we author, not modify what Framer itself outputs. This is becoming a real business problem, not just a cosmetic scan finding: security ratings like SecurityScorecard are increasingly used by companies during vendor/procurement due-diligence, and this specific finding has already come up as a concern from prospective customers evaluating sites built on Framer. It reflects on Framer's platform for every site built on it, so a fix here would benefit the whole customer base, not just individual sites. A few things that would help: Adding SRI hashes to platform-served scripts where the content is stable enough to support it. For dynamic/frequently-updated assets where a fixed hash isn't practical (e.g., bundle files that change on every publish), some official guidance on how customers should represent/respond to this finding in security reviews would be useful. Visibility into whether this is already on a roadmap. Happy to be pointed to an existing thread if this has been raised before. Given how commonly this shows up in vendor security scans, I'd expect other Framer customers are hitting the same friction with their own customers/partners. Would appreciate this getting prioritized or at least acknowledged with a public status. Thanks,

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.

Put the comment history in the email alert when a response is received. Scanning my inbox, this seems to be default behavior from apps like Figma and Google Docs

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

Add media library functionality specifically for docs/pdfs.

As a user I would like to be able to password protect individual pages and its nested children in order to limit access to particular content of the website.

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.

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.