Fix a live page that won't open in the campaign editor

Your live page couldn’t open earlier, so this copy may look or work a little differently.

This notice means the campaign editor remembers an earlier failed attempt to open your live website. It doesn't tell you which setting caused the failure. Work through the checks below, then choose Try the live page again.

You can keep editing the copy while you investigate. It may look or work differently from your website, so use Preview on your site to check your changes on the actual page before publishing.

Your site blocks being shown inside RightMessage

Ask your web developer to allow your page to be shown inside https://app.rightmessage.com. Keep protection against other sites framing your page.

The campaign editor displays your website inside RightMessage. A page can load normally in your browser but refuse to appear inside another site. A subdomain counts as a different origin: https://app.rightmessage.com and https://rightmessage.com aren't the same origin.

Check your page's response headers

In Chrome or Edge:

1. Open the exact website page you're trying to edit.
2. Open the browser's developer tools and choose Network.
3. Reload the page, then select the main page request, not an image or JavaScript file. If the URL redirects, select the final page request.
4. Open Headers and look under Response Headers.
5. Look for X-Frame-Options and Content-Security-Policy.

These settings block the RightMessage editor:

• X-Frame-Options: DENY blocks all framing.
• X-Frame-Options: SAMEORIGIN allows framing only by the page's own origin.
• An enforced Content-Security-Policy with frame-ancestors 'self' or frame-ancestors 'none' doesn't allow the RightMessage dashboard.

Content-Security-Policy-Report-Only reports problems but doesn't enforce its rules. It also doesn't override a blocking X-Frame-Options header.

Ask your developer to allow the dashboard

Send your developer this request with the page URL:

Please allow this page to be displayed inside the RightMessage campaign editor at https://app.rightmessage.com.

Replace X-Frame-Options: DENY or SAMEORIGIN with an enforced Content-Security-Policy response header that includes:

Content-Security-Policy: frame-ancestors 'self' https://app.rightmessage.com

If the page already has a Content-Security-Policy, update its frame-ancestors directive and preserve the other protections. Check every enforced policy so another policy doesn't still block RightMessage.

Make this change in the response headers, not an HTML meta tag. Don't use X-Frame-Options: ALLOW-FROM. Keep authentication, bot protection, form validation, and other security controls enabled.

Please check the final response after redirects and confirm that our hosting or CDN isn't adding a conflicting header.

X-Frame-Options can't allow one specific external site. The supported replacement is CSP's frame-ancestors directive. Your developer can refer to the frame-ancestors reference (opens in a new tab) and X-Frame-Options reference (opens in a new tab).

If your organization can't allow framing, keep using the page copy. You don't need to remove these protections entirely.

RightMessage isn't installed or hasn't been seen on this page

Check that you're editing a website in the current project and that the project's snippet is installed on the exact page.

1. Open Settings > Domains and check that your website is listed. The editor recognizes a listed hostname and its subdomains.
2. Open JavaScript Snippet and use that project's installation code. See installing RightMessage.
3. Visit the page normally, outside the editor, so the snippet can send activity.
4. Return to JavaScript Snippet and check Snippet Health for the last received time.

The editor normally tries the live page when the hostname belongs to your project and RightMessage has received snippet activity for that project. That activity check is project-wide. It doesn't prove the snippet is installed on every page, so check the exact URL that won't open.

If the website isn't in your project, or RightMessage hasn't received activity, the editor uses a copy. If it can't check the connection, it also uses a copy. Installation troubleshooting helps when no activity arrives.

You haven't published since live editing became available

Publish your project once to update an older published snippet. Older snippets don't know how to open the live editing session, even if they still personalize your website normally.

Choose Publish in RightMessage and review all pending changes before confirming. Publishing applies the whole project draft, not just the update needed for live editing. Don't release unfinished work to fix the notice.

You don't need to replace a correctly installed snippet just because its published version is old.

Your security policy blocks RightMessage scripts

If your site enforces a full Content-Security-Policy, ask your developer to check the browser's Console for blocked RightMessage requests. Allowing framing and allowing scripts are separate settings.

For live editing, these are the RightMessage script hosts:

Your developer should allow those hosts in the applicable script policy, including script-src-elem if the site sets it separately. They should preserve the site's existing nonce or hash requirements for the installation code. Don't replace a complete policy with a blanket allow-all rule.

The live editor receives your draft changes from the dashboard. It doesn't make a separate draft-configuration request from your website, so this live-editing connection doesn't require an additional connect-src host.

Preview on your site is a separate check. Its debugger files load from https://api.rightmessage.com/_/debugger/assets/…, and its draft configuration is fetched from https://api.rightmessage.com/_/PROJECT_ID/draft. If you're using that preview, the API host must also be allowed for those script and connection requests. The page copy uses files from the same asset host; they aren't a separate live-editor download.

Replace PROJECT_ID with your own project ID when checking requests. These are not a complete security policy for your website or every RightMessage feature.

Then choose Try the live page again

Return to the campaign editor and choose Try the live page again in the copy notice. This clears the remembered failure for the current hostname and tries the live connection again.

Failures are remembered for the current project in the browser tab's session storage. Reloading the dashboard can keep that remembered failure. Use the retry control after a fix rather than expecting a reload to forget it.

Use an up-to-date browser. Live editing needs browser security features that older browsers may not support.

If the live page still won't open, send support the page URL, project name, browser version, and the notice you see. Include any blocked-request or framing message from the browser, with sensitive values removed. Don't share cookies or signed preview links.

If neither the live page nor the copy loads, follow campaign editor page-loading troubleshooting for Retry, Reload page, and Open another page.