When embedding Marketing Cloud Next forms on external sites, you may run into a variety of issues. See common issues and resolutions below. This article is a companion article to the help documentation Prepare Your Salesforce Org to Embed a Marketing Cloud Form on an External Site.
Framing 'https://yourorg.my.site.com/' violates the following ContentSecurity Policy directive: "frame-ancestors 'self'"
Cause: The Experience Cloud site's clickjack protection still restricts external framing.
Resolution:
Verify that the Clickjack Protection Level is updated per Step 2 (Option A or Option B).
If using "Good protection", verify that your external domain is listed under Trusted Domains for Inline Framing.
Confirm that you published the Experience Cloud site after making the change (Step 4).
Clear your browser cache or test in a private browsing window to rule out cached CSP headers.
Cause: The Experience Cloud site is blocking the iframe that Lightning Out creates to bootstrap the form.
Resolution: Complete all configuration steps (1 through 4) and verify that the site is published. If you have multiple Experience Cloud sites in your org, confirm that you updated the correct site — the one connected to your Marketing Cloud forms.
Cause: Some website platforms — such as Google Sites — render custom HTML embeds inside multiple layers of intermediate sandboxed iframes, each served from a different origin. For example, Google Sites routes embed content through a loader frame on www.gstatic.com and then executes it inside a sandbox on a site-specific *.atari-embeds.googleusercontent.com subdomain. The browser's frame-ancestors check requires every origin in the ancestor chain to appear in the Trusted Domains for Inline Framing list. Because these intermediate origins are dynamically generated and platform-specific, they can't be reliably added to the trusted list.
Resolution:
For standard web hosts where you control the HTML directly, use "Allow framing of site pages on external domains (Good protection)" and add your domain to Trusted Domains for Inline Framing (Step 2). This is the recommended configuration.
For platforms that use intermediate sandbox iframes (such as Google Sites), select "Allow framing by any page (No protection)" in Step 2 instead. This setting removes frame-ancestors restrictions entirely and allows the form to render regardless of the ancestor chain. Evaluate the security implications before using this option.
Cause: Your Salesforce org may have other Experience Cloud sites (such as an Embedded Service Deployment for messaging) that load in the same iframe chain as the form. If those sites have stricter clickjack protection settings, their commcsp (Content Security Policy) endpoints produce errors in the console even though the form itself loads successfully.
Resolution: These errors are non-blocking and don't prevent the form from rendering or accepting submissions. If you want to eliminate the console errors, apply the same clickjack protection settings to all Experience Cloud sites referenced in the error messages. Look for the site path in the commcsp URL to identify which site needs updating (for example, yourorg.my.site.com/SiteName/_/commcsp).
Cause: Some website platforms wrap embedded HTML inside sandboxed iframes with restrictive attributes. These platform-level restrictions can prevent Lightning Out from functioning, even when your Salesforce org is configured correctly.
Resolution: Test your embed code on a basic HTML page hosted on a standard web server. If the form renders correctly there but not on your target platform, the issue is with the hosting platform's embed restrictions, not your Salesforce configuration.
Cause: The data-web-tracking attribute is set to true on the form fragment, but the Data Cloud Web SDK connector isn't configured in your org.
Resolution: Either configure the Data Cloud Web SDK connector, or set the data-web-tracking attribute to false on the fragment element if tracking isn't needed.
Prepare to Use Forms on an External Site
Embed a Form on an External Site
Using a Form on External Sites
005321446

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.