WordPress · Elementor · Help

Elementor will not save: admin-ajax.php returns HTTP 500?

Correlate the failed save request with PHP and server logs before treating memory as the cause.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

HTTP 500 when saving an Elementor page indicates a server-path failure, not automatically exhausted memory. Preserve unsaved content and record the time, response and duration of one request. Match it with PHP, web-server and applicable WAF logs. A small control page on staging then helps distinguish a page-specific trigger from a problem affecting the shared environment.

Source basis: Q1 · Q2 · Q3

Applies to
Elementor save requests to admin-ajax.php. The original incident persisted despite generous PHP limits; neither memory exhaustion nor ModSecurity was conclusively established.
How to verify the result
The previously affected page saves and reopens with the intended change, renders correctly publicly and produces no matching recurrence of the server error.
Your first check

Which server error matches the save request at that exact time?

Record the time, page and failed response. Then compare the PHP, web-server and, where applicable, WAF logs for the same event.

Updating an Elementor page stalls or produces HTTP 500 from admin-ajax.php, while the public page may still work. In the reviewed incident, the failure persisted despite already generous PHP limits. Several possible causes were suggested, but the report did not establish a verified resolution. Q1

Understand what the status does and does not establish

The save request failed somewhere on the server path. HTTP 500 does not identify the underlying PHP exception and does not prove that memory is exhausted. Elementor’s guidance points to logs and several possible conflicts. Raising a configuration value therefore needs evidence from the affected request. Q2

Preserve unsaved content where the editor still allows it. Avoid sending a succession of save attempts until you know whether the first attempt was partly processed. Inspect an available revision or the stored page in a separate view before assuming that no change reached the database.

Correlate one failed request

  1. Capture the browser evidence: Open the network panel and perform one controlled test on a page copy. Record the URL, time, status, response text and approximate duration. Do not publish complete request bodies or security tokens.
  2. Match the PHP log: Search the correct web-PHP log for the same time. A specific memory-exhaustion message leads to a different action from an undefined function or an exception in a widget.
  3. Interpret an empty log carefully: An absence of visible PHP messages does not prove that the server is healthy. Ask the host which log belongs to this web process and whether an upstream server or security rule ended the request before PHP could log it.
  4. Save a small control page: If a simple Elementor page saves while the affected copy fails, focus on that copy’s widgets, embedded content and request size. If both fail, investigate the shared environment and plugin configuration first.

Choose the next change from the evidence

For a confirmed resource limit, check the responsible limit alongside actual consumption. For a named plugin exception, update or isolate that component on staging. A Safe Mode comparison can help narrow the editor environment, but it does not test every server-side component. Q3

If a WAF entry matches the failure, inspect the specific rule and request. Permanently disabling the whole protection layer would be a much broader change than the evidence supports. After a correction, saving, reopening and displaying the same page should all work.

Example: Compare the failing page with a small control page

Constructed diagnostic example: In an imagined staging copy, saving a complex page returns HTTP 500 while a small control page saves successfully. Both use the same test environment. This illustrates a comparison; it is not our own reproduced defect.

  1. Identify one attempt: Add a neutral marker such as SAVE-TEST-A to the page copy. Record timestamp, page ID and the response to that individual save request. Preserve unsaved content separately before comparing.
  2. Match the server entry: Find the corresponding PHP or web-server message. If it identifies an extension or function, investigate that call. If it reports exhausted memory, inspect actual consumption and the effective limit. Without a matching entry, the cause remains open.
  3. Reduce the difference: Compare individual elements and their dependencies on the copy. The working control page makes a page-dependent trigger plausible, but does not prove that any particular widget is faulty.

Expected observation: Each attempt links saved content, HTTP response and its server evidence. Assess changes individually.

Success check: Reopen the edited copy after saving. The marker must remain present and appear in the intended preview. The same server error must not recur in the checked flow. A disappearing loading indicator alone does not establish a persisted change.

Technical references: Elementor: 500 error · Elementor: Publish / Update button not working.

Frequently asked questions

Does a 512 MB setting rule out a memory problem?

No. First establish which limit actually applies to the web process and what error it records. Equally, a large value does not prove that memory caused the incident.

Should I delete all of the page content?

No. Use a copy and remove specific elements there. This preserves both the original content and a useful comparison.

Does one successful retry mean the problem is fixed?

Not necessarily. Check the stored content and repeat the previously reproducible workflow in a controlled way.

Information for assistance

Provide Elementor and Pro versions, PHP version, page identifier, timestamp, response and matching log lines. Credentials are not needed in the initial incident description.

KAN KAI WORKS can narrow down the save request, server response and component involved. Get help with this case.

Support with this issue

KAN KAI WORKS can narrow down the save request, server response and component involved.

Describe your case →Related service: Websites & CMS

Sources and scope

Sources checked: 5 November 2026. The original incident has not been independently reproduced.