Elementor not loading: Step-by-step solutions for infinite loading, preview errors, and failure to save

How do you fix the Elementor preview could not be loaded and gray screen errors?

The “Preview could not be loaded” error means that the editor cannot generate a live preview of the page; a gray screen is usually another manifestation of the same blockage. Elementor’s preview error documentation lists the causes as low memory, plugin or theme conflicts, broken permalinks, the server firewall, Cloudflare Rocket Loader, and an index.html file left in the root directory.

Permalinks and .htaccess

Broken rewrite rules prevent the editor from reaching the page address. The first step is to save the settings again on the Settings › Permalinks screen. If the problem continues, the documentation explains deleting .htaccess and saving again from the same screen to generate a clean file; make a copy of the existing file before doing this, because security and redirect rules may also be stored in that file.

Cloudflare, index.html, and archive pages

• Rocket Loader: This Cloudflare feature changes the order in which scripts run; Elementor recommends turning it off and clearing the cache completely.
• index.html in the root: If an old index.html exists in public_html, the server gives it priority over WordPress’s index.php file.
• Blog and shop pages: Dynamic archives such as the WooCommerce shop page are not edited directly; these templates are edited through Elementor › Theme Builder.

X-Frame-Options and the editor loading method

The editor opens the preview inside an iframe; if the server’s security headers block this frame, the screen stays gray. Elementor’s requirements call for X-Frame-Options to have the value “same origin” and Content-Security-Policy frame-ancestors to be set to ‘self’. On servers with limited resources, enabling Switch Editor Loader Method under Elementor › Settings › Advanced is another solution recommended in the documentation.

Elementor not saving: What should you do if the Publish button keeps spinning?

If Elementor is not saving and the Publish button keeps spinning, the server has been unable to complete the save request; the most frequent causes are a 403 block, insufficient memory, and server parameters. Elementor’s Publish/Update button documentationrecommends checking the server’s PHP error log for the underlying cause and requesting that log from the hosting provider.

Opening the browser’s developer tools (F12) and looking at the Console or Network tab reveals the status code returned by the save request. This code directly guides the diagnosis:

• 403 Forbidden: A security plugin such as Wordfence or a ModSecurity rule on the server has blocked the request. Elementor recommends enabling the security plugin’s learning mode or asking the hosting provider to allowlist Elementor requests in ModSecurity; folder permissions should be 755 and file permissions should be 644. Details are provided in the 403 Forbidden error guide .
• 500 Internal Server Error: PHP memory has been exhausted or a script has produced a fatal error; for diagnosis, consult the 500 Internal Server Error guide .
• 401 Unauthorized: Password protection applied to administration directories is stopping the request.

The documentation describes two more practical approaches: temporarily delete potentially problematic sections and try saving, then restore the deleted sections from the revision history. If many revisions have accumulated in the database, reducing their number also relieves memory pressure; nevertheless, always take a backup before cleaning up revisions.

What are the CSS Print Method and Clear Files & Data tools used for?

If a change made in the editor is saved but does not appear on the website, the problem is usually outdated CSS files and is resolved with the Clear Files & Data tool. Elementor’s Clear Files & Data documentationstates that the tool is located on the Tools screen in the Elementor menu, was named “Regenerate CSS & Data” in earlier versions, and requires a backup before use.

The same operation can also be performed using Clear Cache in the Edit with Elementor menu on the black administrator bar at the top of the website. Afterward, clear the caches of the caching plugin, the hosting server, and the CDN if one is present; check the result in an incognito window.

The CSS Print Method option in the Performance section of Elementor settings determines whether styles are written as a separate stylesheet or embedded inside each page. Elementor recommends the separate file method. On servers with file write permission problems, temporarily switching to the embedded method can help diagnose cases where styles do not load at all; the permanent solution is to correct the file permissions.

Site URL and mixed content: When the editor will not open after moving to HTTPS

If the editor will not open after SSL has been added to the website, the WordPress address and site address must be updated to HTTPS and made identical. Elementor’s editing after SSL documentationstates that the “WordPress Address (URL)” and “Site Address (URL)” fields on the Settings › General screen must match, and that a backup should be taken before making the change.

Old http:// links may remain in the content after the address has been updated; the browser regards this mixed content as insecure and blocks images and files. Elementor recommends the following sequence for this situation:

1. On the Replace URL tab of the Elementor Tools screen, replace the old http address with the new https address.
2. Clear the browser, WordPress, hosting, and CDN caches.
3. Run Clear Files & Data.
4. Correct manually entered http:// addresses in custom CSS, code fields, the theme customizer, and third-party plugins.

An address change alone can also produce new problems, such as a redirect loop or inability to access the dashboard. This is why the change is made with a backup and in a single step.

What happens when Elementor and Elementor Pro versions are incompatible?

If Elementor and Elementor Pro are at different update levels, the editor can remain on the loading screen or Pro widgets may not work; the solution is to update both plugins to their latest versions. Elementor’s stuck on the loading screen documentationstates that incompatible versions lead to editor problems because of outdated functions and code incompatibilities.

While the Pro plugin has not been updated for a long time, the free Elementor core may have advanced through automatic updates. The reverse also happens: Pro is updated while the core remains old. If the problem started with an update, you can return to a previous version from the Version Control tab on Elementor’s Tools screen; Elementor requires a backup before this operation as well, and states that the direct download route works only for the core plugin.

Another reason the editor will not open while Pro is active is a corrupted Theme Builder template or popup. Temporarily deactivate Pro and try editing; if editing opens, deactivate templates one by one to find the problematic one. If there is a broader breakdown following an update, the website broken after a WordPress update guide explains the rollback options in detail.

How does the server error log reveal the source of the error?

The error log shows which file and which line generated an error when the Elementor editor will not open or save, reducing trial and error. Logs are read in two places: the server error log in the hosting panel and WordPress’s own debugging log.

According to WordPress’s debugging documentation , when WP_DEBUG is enabled, WP_DEBUG_LOG writes all errors to wp-content/debug.log by default; when WP_DEBUG_DISPLAY is set to false, errors are recorded without being displayed on the page. The same document does not recommend using these tools on live websites, stating that they are intended for local and staging installations. If their use on a live website is unavoidable, keep on-screen display disabled, revert the setting after recording is complete, and delete debug.log.

A line in the log beginning with “Allowed memory” and reporting memory exhaustion indicates insufficient memory, while a fatal error pointing to a particular plugin folder indicates a conflict. ModSecurity block records are often kept only by the hosting provider; Elementor’s widget panel documentation also recommends requesting these records from the hosting company.

Checklist when the Elementor editor will not open

If Elementor is not loading or saving, follow the sequence below; the list starts with the most likely and least risky checks, and the editor is tested again after each step. We use this sequence for Elementor faults in our maintenance process as well:

1. Back up the files and database.
2. Open the editor in an incognito window in a desktop browser.
3. Compare the PHP version and memory limit on the System Info screen with the official requirements.
4. Enable Safe Mode; choose the conflict or server investigation path according to the result.
5. Save the permalinks again.
6. Verify that both Elementor and Elementor Pro are up to date.
7. Run Clear Files & Data and clear every cache layer; disable Rocket Loader if Cloudflare is used.
8. Look for a 401, 403, or 500 code in the browser console.
9. Read the error log and request ModSecurity records from the hosting provider if necessary.

Common mistakes and the correct approach

The most damage during an Elementor fault comes from rushed interventions. Common mistakes include the following:

• Deleting and reinstalling Elementor: This does not resolve the problem and increases the risk of losing settings; check conflicts and memory first.
• Completely removing the security plugin: This removes the 403 block but leaves the website unprotected; the correct approach is to allowlist the rule.
• Leaving debugging mode enabled: Error messages may become visible to visitors, and the debug.log file grows.
• Updating all plugins at the same time: It becomes impossible to identify which update broke the editor.

When should you consult a specialist if Elementor is not loading?

If Elementor is still not loading after Safe Mode, increasing memory, and clearing caches, the problem most likely lies in the server configuration or corrupted content, and specialist support saves time. The intervention should be carried out systematically, particularly if there is no current backup, wp-config.php or .htaccess needs to be modified, technical correspondence with the hosting provider is required, or e-commerce pages cannot be edited.

For one-time faults, the WordPress troubleshooting service diagnoses and resolves the problem. If you want plugin versions kept compatible, updates performed with backups, and the caching setup monitored, the annual WordPress maintenance and updates service makes this an ongoing process. WordPress maintenance costs between 500–2,000 TL per month, depending on the website’s size and scope.

Under the maintenance routine, a backup is taken before every round of updates, and afterward the Elementor editor and critical pages are opened and checked. Because the operations performed are recorded, the next time a fault occurs the records show which change was made and when.