In October 2026 I migrated my WordPress site to a new host. The migration looked successful — every public page loaded, the design was intact — until I opened the homepage in the editor and got a critical error. The most important page on my site could no longer be edited, and the error message said nothing about why.

This is the story of what was actually wrong (it was not a plugin), how I proved it before touching anything, and the fix — which involved deleting 504 rows from my database, on purpose, as a non-developer.

The symptom: editor dead, site alive

The split was the first clue. The homepage rendered perfectly for visitors. Only the editor died, every time, on that one page. Other pages opened fine. Whatever was wrong was specific to loading that post for editing.

My environment, for context:

  • WordPress on shared hosting (PHP 8.2, PHP memory limit 256M)
  • Homepage built with a page builder over many editing sessions
  • The page itself was not huge — about 152 KB of content

Ruling out the obvious

The standard advice for a critical error is: deactivate plugins, switch to a default theme, check the PHP version. I worked through the suspects, and the error survived all of it. That process wasn't wasted — it told me the fault was in the data of that specific post, not in the code running the site.

The test that cracked it: I cloned the homepage. The clone — identical content, zero history — opened in the editor instantly.

Same content, same builder, same everything… except the clone had no revisions.

The real cause: revision bloat vs. a memory limit

WordPress stores a revision every time a post is saved. My homepage, built and re-edited across weeks of page-builder sessions, had accumulated 529 stored revisions totalling roughly 134 MB in the database. Loading the editor meant loading that history, and on a 256M memory limit, PHP simply ran out of road — a memory exhaustion error that surfaced as a generic "critical error."

You can check any post's revision load with a query like this (adjust the prefix and post ID):

SELECT COUNT(*) AS revisions, SUM(LENGTH(post_content)) AS bytes FROM wp_posts WHERE post_type = 'revision' AND post_parent = 986;

In my case the revision count — not the page content, not a plugin — was the problem.

Safety first: back up before you delete anything

Deleting revisions is irreversible. My host's support had already declined to help with WordPress debugging or database changes on my shared plan, so the choice was mine to make carefully:

  1. Full database backup first (I used UpdraftPlus). If the prune went wrong, the site was recoverable. No backup, no surgery — that rule is the whole reason this story has a happy ending.
  2. Decide what to keep. I kept the newest 25 revisions — recent enough to undo a bad edit, small enough to never threaten the editor again. Twenty-five was a judgement call; I found no authoritative guidance for builder-heavy pages, and I'd rather defend a chosen number than an accidental 529.

The fix: prune to the newest 25

With the backup verified, I pruned the homepage's revisions from 529 down to 25 — 504 revisions deleted. (Whether you do this with a revision-cleanup plugin or carefully constructed SQL, the safety steps are the same: back up, target one post, keep a sensible tail, and verify the backup exists before you run anything.)

Verification

  • The editor opened the homepage immediately afterwards.
  • The public page was unchanged — I checked it like a visitor, not like an owner.
  • The database was ~134 MB of revision history lighter.

The fix itself took minutes. The diagnosis took the better part of a day. That ratio is normal, and it's why "the editor shows a critical error" is such an expensive sentence to search for.

Prevention

Two habits came out of this:

Limit revisions in wp-config.php so no page can quietly grow another 529:

define( 'WP_POST_REVISIONS', 25 );

Add revision cleanup to routine maintenance, especially if you build pages with a visual builder. Builders make revision bloat faster because every small styling session is another save — and revisions are invisible until the day they break something.

Lessons

  1. "Editor dead, site alive" points at the post's data, not your theme or plugins. Test with a fresh clone before you start disabling things at random.
  2. Revisions are a feature with a storage cost. WordPress keeps them forever by default; on shared hosting, "forever" has a memory limit attached.
  3. A backup converts a scary fix into a routine one. The prune was only a calm decision because restoring was possible.

If your editor dies on one page only, count its revisions before you blame anything else. It might be the cheapest fix you make all year.

Masood Ahmad is the Editor of Dentist in Pico Rivera, a local lead-generation website he built, migrated and maintains himself.