By Pranoti Kshirsagar · AI Integration & Automation Specialist

A WordPress page broke. I had a WP Engine backup from two days before. The standard fix — restore the whole site — would have wiped 48 hours of content I couldn’t get back.

So I didn’t do that.


The problem with full-site restores

WP Engine’s backup system is excellent. But it restores everything or nothing. There is no “restore this one page” button. If you trigger a restore, your database reverts to the snapshot state — which means anything created or updated after that point is gone.

For a static brochure site, that’s manageable. For a site with active content, posts, and reader-facing pages being updated daily, it’s not a real option.

The page I needed back was a single landing page. Its content existed in the backup. I just needed to get it out — and back in — without touching anything else.


What I did instead

Step 1 — Downloaded the database dump from WP Engine

WP Engine lets you download a full database export from any backup checkpoint. This is a .sql file — essentially a text file containing every table, row, and value from your WordPress database at that point in time.

These files are large. The important content is buried in thousands of lines of SQL INSERT statements.

Step 2 — Fed the dump to Claude and asked it to find the page

I pasted the relevant sections of the dump into Claude and asked it to locate the row in wp_posts matching the page I needed — by slug and title. Claude extracted the post_title, post_content, and post_name fields from the INSERT statement.

This is the part that would have taken an hour to do manually, scanning through raw SQL. Claude did it in seconds.

Step 3 — Pushed the recovered content back via WordPress MCP

With the WordPress MCP already connected to my site, Claude called get_pages to find the current page ID on the live site, then called update_page with the recovered content.

No REST API setup. No curl commands. No credential formatting. Just a tool call.

The page was restored — title, content, slug intact — without a single other page, post, or setting being touched.


Why this works

The content you need is already in the backup. It hasn’t gone anywhere. A full-site restore is just the blunt instrument WP Engine gives you by default — but the underlying data is readable, structured, and extractable.

Claude’s role here is parsing the SQL dump (something a human can do but not quickly) and executing the write-back through MCP (something that used to require fiddling with REST API auth). Together they make a task that felt risky and complex into something routine.

Time saved: 8 hours. Pages affected beyond the one I intended: zero.


What you need for this to work

  • A WP Engine account with access to backup exports
  • Claude (with file or paste access for the SQL dump)
  • WordPress MCP connected and authenticated to your site
  • The slug or title of the page you need to recover

The MCP connection is the one prerequisite that requires setup upfront. Once it’s there, this workflow takes minutes.


Download the case study

The one-page PDF version of this workflow — with the full before/after breakdown, blockers, architecture, and tech stack — is available on my portfolio.

Download the case study →


Published on The Science Talk · thesciencetalk.com