How to fix "The preview could not be loaded" in Elementor

Elementor shows this when the page it loads inside the editor comes back without Elementor's scripts in it. An error, a redirect, another plugin's page or a template with no footer call does that. The line under the heading and one look at the preview address tell you which.

By: WP Ministry
Published: October 8, 2026
Tested on: WordPress 7.1.3, PHP 8.3.35

In short

Nothing is lost. The message is about loading the page into the editor, not about what is saved in it.
Read the line under the heading. A status such as "Not Found 404" or "Internal Server Error 500" names the cause.
Click "Click here for preview debug". The new tab shows what the editor was given in place of your page.
A 404 is fixed by saving the permalinks again. A redirect, a coming-soon page or a firewall rule has to let the preview address through.
Safe Mode loads the editor without your theme and other plugins, for you alone. If it loads, one of them is the cause.
An editor that stays on its loading screen with no message is a different fault. Check the two site addresses and the frame headers.

Elementor's editor is two pages in one. The panel belongs to the dashboard. The page you edit is loaded from the front of the site into a frame, at its own address with ?elementor-preview= and the page's ID added. When the frame has loaded, the editor looks inside it for Elementor's front-end script. If the script is not there, the editor shows "The preview could not be loaded".

So the frame came back as something other than your page in edit mode: an error page, another page after a redirect, a page another plugin put in its place, or your page without its scripts. Nothing has been lost. The design is saved with the page, and this message is only about loading it.

What the box says

The heading is always "The preview could not be loaded". The line under it is the first clue.

Under the heading	What came back	Where to go
"We’re sorry, but something went wrong. Click on 'Learn more' and follow each of the steps to quickly solve it."	A page that loaded, with no Elementor script in it	The check below
"Not Found 404"	No page at that address	Save the permalinks again
"Internal Server Error 500"	PHP stopped before the page began	Read the PHP error
"Forbidden 403", or a 401	The server refused the request	Let the preview address through
"Service Unavailable 503"	A maintenance page, or a server too busy to answer	Find the plugin with Safe Mode
"Your site's .htaccess file appears to be missing." and the file's path	Safe Mode is on, and Apache has no `.htaccess` to pass addresses to WordPress	404 errors on pages that exist has the file's standard content
"Some of your theme files are missing."	The active theme's folder is gone or incomplete	Install the theme again, or activate another

A status line is the server's own words and then the number. Read the number.

While WordPress itself is being updated, the dashboard answers 503 too, so the editor does not open at all. You see "Briefly unavailable for scheduled maintenance" and not this message.

See what the preview address answers

In the browser. Click "Click here for preview debug" in the box. It opens the preview address in a new tab, logged in as you. What the tab shows is what the frame was given: a "not found" page, a login form, a coming-soon page, another page of the site, or your own page. If PHP stopped partway, Elementor prints the error at the very end of that tab. An old static page on the home address means an index.html file sits beside WordPress in the site's main folder, and the server is choosing it over WordPress: rename it.

With curl. The address is the page's own, with ?elementor-preview= and the page's ID, which is the number after post= in the editor's address bar. A blog post is previewed at the short form, /?p=123&elementor-preview=123. Use your own domain, path and ID:

bash

curl -sI 'https://example.com/landing-page/?elementor-preview=123'

-I asks for the headers alone and -s hides the progress meter. The first line is the status. A Location: line is a redirect, and says where to.

curl is not logged in, so it gets what a visitor gets at that address. That is enough to show a 404, a redirect, a refusal or a header. A 200 from curl does not prove that the editor is given the same page. The debug link does.

Without a terminal. The redirect checker shows the status of an address and every redirect on the way.

The message itself appears only in a browser. What is tested on this page is what the preview address answers before and after each fix, which is what the editor depends on.

When the editor stays on its loading screen instead

Two faults often listed under this message do not produce it. In both, the browser will not let the editor read the frame, so the editor never learns that loading has ended, and its loading screen stays. Chrome's console, opened with F12, says that access to the frame was blocked, or that the page refused to be shown in a frame. Elementor's notes for an editor that fails even in Safe Mode list both.

If you would rather hand it over, a one-time WordPress fix covers one issue on one site and starts with a free diagnosis.

Where it goes wrong

A page request passes through each of these in turn. This one comes from a plugin.

Browser
DNS
HTTPS
CDN or firewall
Web server
PHP
WordPress (this error comes from here)
Database and files

What causes it

The preview address answers 404
Common
Elementor previews a page at its ordinary address. If WordPress's list of address rules is out of date, or the server no longer passes addresses to WordPress, that address answers "not found" and there is no page to load.
Fix: Save the permalinks again
Another plugin answers with a page of its own
Common
A coming-soon, maintenance-mode or membership plugin puts its own page, or a login form, where your page should be. The frame loads without an error, and what loads is not your page.
Fix: Find the plugin or theme with Safe Mode
A plugin or the theme stops Elementor's scripts
Common
The page arrives, and Elementor's front-end script never runs in it. Another plugin's script fails first, or a plugin delays, combines or removes scripts on the page.
Fix: Find the plugin or theme with Safe Mode
PHP fails while the page is built
Common
An error in a plugin or the theme, or too little memory, stops PHP. If it stops before the page starts, the address answers 500. If it stops partway, the status stays 200 and the page is cut off above the footer, where the scripts are printed.
Fix: Read the PHP error behind a 500 or a cut-off page
The preview address is redirected to another page
Sometimes
A redirect plugin, a rule in .htaccess or a login wall sends the request somewhere else on the site. The frame loads that page, which is not in edit mode.
Fix: Remove the redirect on the preview address
A firewall or a password refuses the request
Sometimes
A security plugin's firewall or the host's ModSecurity rules answer the preview request with 403, often because of the words in its address. Password protection on the site's folder answers 401.
Fix: Let the preview address through a firewall or a password
The theme's template has no footer call
Sometimes
Elementor's scripts are printed where the template calls wp_footer(). A custom page template that leaves the call out produces a page that looks complete and carries no scripts.
Fix: Give the theme's template its footer call
A cache or a script optimizer changes what the editor receives
Sometimes
A page cache or CDN hands the editor a stored copy of the page, or a feature that defers JavaScript, such as Cloudflare's Rocket Loader, holds Elementor's script back until after the editor has looked for it.
Fix: Keep caches and script optimizers away from the preview
The preview is on another form of the address, or may not be framed
Rare
When WordPress Address and Site Address differ, or a header forbids showing the page in a frame, the browser gives the editor nothing it can read. The editor then usually stays on its loading screen and shows no message at all.
Fix: Make the two site addresses agree, or Let the site show its own pages in a frame

How to fix it

Save the permalinks again

Easy
No risk
About 5 minutes
Steps tested on WordPress 7.1.3

A page, or an item of a custom content type, is previewed at its pretty address, so the preview depends on WordPress's list of address rules. The list goes out of date when a plugin adds a kind of content, such as products, events or a portfolio, without rebuilding it.

Step 1: Open Settings, then Permalinks
Change nothing, and click Save Changes. WordPress rebuilds its rules. On Apache it also rewrites its block in .htaccess, and says "Permalink structure updated." when it could write to the file.
Step 2: Open the page in Elementor again
The editor loads, and the check above answers 200.

With WP-CLI the same rebuild is one command. It ends "Success: Rewrite rules flushed."

bash

wp rewrite flush

If the address still answers 404, and what comes back is the web server's own short "Not Found" page and not your theme's, the .htaccess file is missing or the server ignores it. 404 errors on pages that exist covers both.

To undo it: Nothing to undo. WordPress rebuilds the same list from its settings.

Read the PHP error behind a 500 or a cut-off page

Takes care
Low risk
About 15 minutes
Steps tested on WordPress 7.1.3

PHP can fail in two places. Before the page starts, the address answers 500 and the box says "Internal Server Error 500". Partway through, the status has already gone out as 200, the page is cut off above its footer, and the box shows the general sentence. curl reports 200 for the second kind, so use the debug link.

Step 1: Click "Click here for preview debug" and go to the end of the page
For a page that was cut off, Elementor prints PHP's last error there: the message, the file and the line.
Step 2: Read the file's path
A path through wp-content/plugins/ names a plugin by its folder. A path through wp-content/themes/ names the theme. "Allowed memory size of … bytes exhausted" is the memory limit. Elementor asks for at least 256 MB: see "Allowed memory size exhausted".
Step 3: Switch that plugin off
On the Plugins screen, click Deactivate under its name. Then open the page in Elementor again.

With WP-CLI, use the plugin's folder name in place of plugin-name:

bash

wp plugin deactivate plugin-name

If the debug tab shows only "There has been a critical error on this website.", PHP failed before Elementor could report it. The critical error page shows how to get the real line from the debug log, and 500 Internal Server Error covers a 500 with no WordPress message at all.

To undo it: Activate the plugin again once it has been updated or repaired.

Remove the redirect on the preview address

Takes care
Back up first
About 15 minutes
Steps tested on WordPress 7.1.3

The check answers 301 or 302 with a Location: line. Elementor switches off WordPress's own tidying redirect for the preview, so a redirect here was added by something else. Elementor's troubleshooting notes say the page must have no 301 or 302 from a redirection plugin or a server rule.

Step 1: See who sends it
Look for X-Redirect-By: in the answer. X-Redirect-By: WordPress, or a plugin's name, means the redirect comes from inside WordPress. No such line means the server, the host or a CDN sent it.
Step 2: If it comes from inside WordPress
In a redirect plugin, delete the entry for this page's address. A membership or login plugin that sends the page to a login form has to leave this page alone, or be switched off while you edit. The Safe Mode fix below finds which plugin it is.
Step 3: If it comes from the server
Run the command under these steps in the site's main folder. The three RewriteRule lines between # BEGIN WordPress and # END WordPress are WordPress's own. Keep a copy of the file, then delete the line that names this page's address.
Step 4: Check again
The address answers 200 and the editor loads.

bash

grep -n -i -E "^[[:space:]]*(Redirect|RedirectMatch|RewriteRule)" .htaccess

A redirect that is in neither place is set in the hosting panel or at the CDN. One that never ends is a different fault: see ERR_TOO_MANY_REDIRECTS.

To undo it: Put the rule back in .htaccess, or activate the plugin again.

Find the plugin or theme with Safe Mode

Easy
Low risk
About 20 minutes
Steps tested on WordPress 7.1.3

Safe Mode opens the editor and its preview with a blank theme and with only Elementor, Elementor Pro and WooCommerce running. It applies to the browser that switched it on and to nothing else, so visitors see the site as before. Only an administrator can use it.

Step 1: Switch Safe Mode on
Open Elementor, then Editor, then Tools. On the General tab, set Safe Mode to Enable and click Save Changes. Or wait about thirty seconds on the failed editor: a box headed "Can't Edit?" has a button, "Enable Safe Mode".
Step 2: Open the page in Elementor
A box in the corner says "Safe Mode ON". If the editor loads, the cause is a plugin or the theme. If the message is still there, the cause is outside both: go back to what the address answers.
Step 3: Switch Safe Mode off, then find which plugin
Click "Disable Safe Mode". Deactivate one plugin, open the page in Elementor, and repeat. Begin with plugins that decide what a visitor is shown or how scripts load: coming soon, maintenance mode, membership, redirects, caching, optimization and security.
Step 4: Set the plugin up, or leave it off
In a coming-soon or membership plugin, look for the setting that says who gets past it, and let your own role through. Otherwise keep the plugin off while you edit.

WP-CLI lists what is active, and wp plugin deactivate, shown above, switches one plugin off:

bash

wp plugin list --status=active

Safe Mode cannot switch off must-use plugins, the ones a host installs in wp-content/mu-plugins. It says so: "Please note! We couldn't deactivate all of your plugins on Safe Mode." If every plugin is cleared, the theme is next. How to find and fix a WordPress plugin conflict has the full method for testing plugins one at a time.

To undo it: Set Safe Mode back to Disable, and activate the plugin again.

Give the theme's template its footer call

Advanced
Back up first
About 30 minutes
Steps tested on WordPress 7.1.3

Elementor prints its scripts where the template calls wp_footer(), and WordPress leaves that call to each theme. A custom page template without it gives the editor a page with no scripts. A template that leaves out the_content() is a different fault with its own message, "Sorry, the content area was not found in your page."

Step 1: Confirm that it is the theme
The editor loads in Safe Mode, and fails with every other plugin off. To be certain, activate a default theme for a minute, under Appearance, then Themes, or with the first command under these steps. If the editor loads, switch back and go on.
Step 2: Find the template this page uses
Template, in the page's settings, names it. The file is in the theme's folder. Look in it for wp_footer(), or for get_footer(), which loads the theme's footer.php.
Step 3: Add the call just above the closing body tag
Add the line in the second block. The matching call in the head, <?php wp_head(); ?> just above </head>, is needed in the same way.

bash

wp theme activate default-theme-folder-name

footer.php

<?php wp_footer(); ?>

A theme update replaces the theme's files, and the line with them. Make the change in a child theme, and report the missing call to the theme's developer.

To undo it: Remove the line you added, or activate the theme you had.

Let the preview address through a firewall or a password

Takes care
Low risk
About 20 minutes
Steps tested on WordPress 7.1.3

A 403 means the server understood the request and refuses it. A 401 means it wants a username and password first. Elementor names the host's ModSecurity rules and password-protected folders as the usual sources.

Step 1: Ask for the same page without the preview part
Run the first command under these steps. If the plain address answers 200 and the preview address answers 403, a rule refuses the request because of what is in its address. If both answer 403, the page itself is blocked: see 403 Forbidden.
Step 2: Look for a rule of your own
If a security plugin with a firewall is active, find the request in its log of what it blocked, and allow it. In .htaccess, the second command lists every line that names Elementor. Keep a copy of the file, then delete the condition and the rule under it.
Step 3: Ask the host about a rule of theirs
If nothing on the site refuses it, send the host the preview address and the time you tried. Ask which firewall rule blocked the request, and to have that rule switched off for your site.
Step 4: For a 401, turn off the password protection
It is set in the hosting panel or by a security plugin. Turn it off, or edit on a copy of the site that has none.

bash

curl -sI 'https://example.com/landing-page/'

bash

grep -n -i "elementor" .htaccess

The part tested here is the part on the site: a refusal by a rule in .htaccess, found with these commands and gone once the rule is deleted. A host's firewall is outside what a sandbox can run.

To undo it: Put the rule back, or turn the password protection on again.

Keep caches and script optimizers away from the preview

Takes care
Low risk
About 20 minutes

Elementor tells caching plugins not to store the preview, and marks its scripts so that Cloudflare's Rocket Loader leaves them alone. A cache or optimizer that ignores those marks can still get in the way.

Step 1: Clear the caches
Clear the page cache in the caching plugin, then at the CDN, and open the page in Elementor again.
Step 2: Keep the preview out of them
In the caching or optimization plugin, exclude addresses that contain elementor-preview from the page cache and from any option that delays, defers, combines or minifies JavaScript. Cloudflare does not cache HTML by default. If you added a rule that caches everything, give the preview a rule of its own: Elementor suggests matching your site's address followed by /*elementor*.
Step 3: Turn Rocket Loader off to test
In Cloudflare, open Speed, then Optimization, and switch Rocket Loader off. Cloudflare's own advice for JavaScript trouble is the same: disable Rocket Loader and test again.
Step 4: Try a private window
A browser extension that blocks ads or scripts can stop Elementor's files. A private window runs without them.

To undo it: Turn the cache or the optimizer back on.

Make the two site addresses agree

Takes care
Back up first
About 15 minutes
Steps tested on WordPress 7.1.3

The editor runs at the WordPress Address (URL). The preview is loaded from the Site Address (URL). If the two differ by http and https, or by www, the frame belongs to another origin, and a page may not read a frame from another origin. An https dashboard will not load an http frame at all: see mixed content.

Both are under Settings, then General, and are identical unless WordPress has a folder of its own. WP-CLI prints them, Site Address first:

bash

wp option get home
wp option get siteurl

When they differ, asking for the preview at the dashboard's form of the address answers 301, with a Location: line on the other form and X-Redirect-By: WordPress.

Set both to the form the site is served at, with no slash at the end:

bash

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

The check then answers 200, and the editor loads.

To undo it: Set the address back to its earlier value with the same command.

Let the site show its own pages in a frame

Takes care
Low risk
About 20 minutes
Steps tested on WordPress 7.1.3

Two headers decide whether a page may be shown in a frame. Run the check and look for them in the answer.

The header says	For the editor
`X-Frame-Options: DENY`	Blocked. The page may not load in any frame, the site's own included.
`X-Frame-Options: SAMEORIGIN`	Allowed, as long as the two site addresses agree.
`Content-Security-Policy` with `frame-ancestors 'none'`	Blocked.
`Content-Security-Policy` with `frame-ancestors 'self'`	Allowed. A list with neither `'self'` nor the site's own address blocks it.

Elementor's requirements ask for the two values that allow it.

Step 1: Find where the header is set
A security plugin can send it. The command under these steps lists the plugin and theme files that mention either header, and the folder in each path names the plugin. On Apache it can be a Header line in .htaccess. On nginx it is an add_header line in the server's configuration. A hosting panel or a CDN can add it too.
Step 2: Change the value
Change DENY to SAMEORIGIN, and 'none' to 'self', in the plugin's settings or in the file. How to add security headers to a WordPress site has the lines for Apache and nginx.
Step 3: Check again
The header shows its new value, and the editor loads.

bash

grep -r -l -i -E "x-frame-options|frame-ancestors" wp-content/plugins wp-content/themes

What is tested here is a header sent by a plugin: found with these commands, and gone when the plugin is switched off. A header set by the server or a CDN is changed where it is set, which a sandbox does not have.

To undo it: Set the header back to its earlier value.

When to get help

If the preview address answers 200 with your own page in Safe Mode and in a private window, and the editor still will not load, or the status is a 403 that your host cannot explain, the cause is in the server's configuration or a firewall's log. Reading those takes access to the hosting account.

Common questions

Have I lost the page I was building?

No. The message is about loading the page into the editor. The design is saved in the database with the page, and none of these fixes touches it. Once the preview loads, the editor opens the page as you left it.

Why does the page load for visitors and not in the editor?

The editor asks for something different. It asks while logged in, at an address with elementor-preview in it, and it needs Elementor's edit-mode scripts in what comes back. A firewall rule can refuse that address alone, and a plugin can treat a logged-in user differently from a visitor.

Does Safe Mode change the site for visitors?

No. Safe Mode applies to the editor, its preview and its own background requests, in the browser of the administrator who switched it on. Everyone else gets the site with its theme and every plugin, as before.

What does "Click here for preview debug" do?

It opens the preview address in a new tab with &preview-debug added. Elementor then prints PHP's last error, if there was one, at the end of the page. The rest of the tab is the page the editor was given, so it is the quickest way to see a login form, a coming-soon page or a redirect.

Why do I get it on the shop page or the blog page?

Those are archives: lists that WordPress or WooCommerce builds, not single pages. Elementor's help says that opening one with "Edit with Elementor" gives a preview error, and that such a layout is edited as a template in the Theme Builder.

In short

What the box says

See what the preview address answers

When the editor stays on its loading screen instead

Where it goes wrong

What causes it

The preview address answers 404

Another plugin answers with a page of its own

A plugin or the theme stops Elementor's scripts

PHP fails while the page is built

The preview address is redirected to another page

A firewall or a password refuses the request

The theme's template has no footer call

A cache or a script optimizer changes what the editor receives

The preview is on another form of the address, or may not be framed

How to fix it

Step 1: Open Settings, then Permalinks

Step 2: Open the page in Elementor again

Step 1: Click "Click here for preview debug" and go to the end of the page

Step 2: Read the file's path

Step 3: Switch that plugin off

Step 1: See who sends it

Step 2: If it comes from inside WordPress

Step 3: If it comes from the server

Step 4: Check again

Step 1: Switch Safe Mode on

Step 2: Open the page in Elementor

Step 3: Switch Safe Mode off, then find which plugin

Step 4: Set the plugin up, or leave it off

Step 1: Confirm that it is the theme

Step 2: Find the template this page uses

Step 3: Add the call just above the closing body tag

Step 1: Ask for the same page without the preview part

Step 2: Look for a rule of your own

Step 3: Ask the host about a rule of theirs

Step 4: For a 401, turn off the password protection

Step 1: Clear the caches

Step 2: Keep the preview out of them

Step 3: Turn Rocket Loader off to test

Step 4: Try a private window

Step 1: Find where the header is set

Step 2: Change the value

Step 3: Check again

When to get help

Common questions

More on this subject

Would you rather we fixed it?