Fix: 'This Page Is Not Authorized for This Landing Page' Error

If your landing page's embed script throws "Error: This page is not authorized for this landing page" in the browser console, and the lead form submission fails with an HTTP 403 — the fix in almost every case is to re-copy the tracking script from the CRM and paste it in fresh. This is not usually a sign your allowed-origin setting is wrong; it's a browser privacy default quietly hiding information the check used to rely on.

What's actually happening

Every landing page you register in the CRM is locked to one exact URL, checked against two signals sent by the browser on every form submission: the request's Origin (which domain the request came from — this is the real security boundary, and it can't be spoofed by JavaScript) and, until recently, the specific page path the visitor was actually on.

Modern browsers — Chrome, Firefox and Safari all default to this — apply a privacy policy called Referrer-Policy: strict-origin-when-cross-origin. In plain terms: when a page on yoursite.com makes a request to a different domain (like the CRM's API), the browser strips the page path out of the referrer information it sends, leaving only the bare domain. A check that was written to compare the full path against the registered landing page URL suddenly has no path to compare — and rejects the request as unauthorized, even though the origin, the script, and the setup are all completely correct.

The fix: re-copy the embed script

The current embed script reports the page path explicitly, as a normal field in the form submission, instead of relying on the browser's referrer header for it. If your site is still running an older copy of the script, it doesn't send that field, and the browser's stripped referrer is all the CRM's check has left to go on.

1. In the CRM, go to Marketing → Landing Pages, open the landing page in question, and copy its embed script again — don't reuse a version saved in a text file or a page template from before.
2. Replace the entire script tag on your live page with the freshly copied one. A partial edit (just changing one line) risks missing the updated fields.
3. Clear your browser cache or hard-refresh (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) before testing — a cached copy of the old script will keep failing even after you've updated the page source.
4. Submit a real test lead and confirm it appears in Leads in the CRM.

If it's still failing after that

Check these, in order:

• The allowed origin doesn't exactly match. https://yoursite.com and https://www.yoursite.com are different origins as far as this check is concerned — if your site redirects between the www and non-www version, make sure the allowed origin in the CRM matches the version visitors actually land on.
• The script is on the wrong page. Each landing page registration is tied to one URL. If you've pasted the same script onto a second page without registering that page separately, the second page will fail this check even with a perfectly current script.
• A page builder or cache plugin is serving a stale version. Some site builders (page caching plugins, CDN edge caches) can keep serving an old cached copy of your page — and the old script embedded in it — for minutes to hours after you've saved changes. Purge the relevant cache if your platform has one.

If none of that resolves it, the CRM's console error itself is the most useful next diagnostic — a message about the origin being wrong (rather than the page) points at the allowed-origin setting specifically; see creating a landing page and installing the tracking script for the full setup from scratch if you'd rather start over cleanly.