Fix an invalid WordPress block without losing the original content

Recognize the warning and identify what it affects

The editor displays a notice saying that a block contains unexpected or invalid content. The text or image may still appear on the public site even though the block has become difficult to edit. The goal is to recover complete content that you can edit and save correctly, so check the result after the warning disappears.

For some blocks, WordPress compares the saved structure with the structure the block can generate. A difference can trigger the validation warning. This might happen after a manual edit to the HTML, an unusual paste, or a change to the component that provides the block. HTML is the markup that describes the elements of a page. The warning alone is insufficient to diagnose database corruption.

An invalid JSON response during a save concerns communication with the server. If you see that error as well, preserve your work and investigate it separately. A block marked as unavailable, a block lock, or a JavaScript error also calls for a different diagnosis.

Keep a copy before attempting recovery

Keep access to the original document and prepare a local text file and a separate draft. This copy protects the content while you test. Keep a site backup for changes that affect more than the document.

1. Leave the original tab open. In the editor’s main menu, look for the command to copy all content, then paste it into the local file. Verify that the copy includes the beginning, the end, and the affected part before relying on it.
2. If copying everything fails, select the affected block and look for **Copy** in its three-dot menu. Save the accessible text, media URLs, and a screenshot of the layout separately. A screenshot helps reconstruct the appearance. Keep the saved content as your reference for interactive settings and block structure.
3. Go to **Posts** or **Pages** and use **Add New** to create a working draft. Paste the content there and confirm you are in the new document before attempting a fix. Keep it as a draft so visitors continue to see the original. Media and site components are still shared.
4. Keep the first file and save converted versions separately. Give each test version its own name. You should be able to recover the starting text even if the draft becomes unusable. Keep that copy as a safeguard alongside the editor’s undo command.
5. Before updating a plugin or making a broader change, confirm that the database and files have been backed up and that you know how to restore them. If that protection is missing, pause changes to components. A text copy cannot restore a plugin or its configuration.

Check permissions and identify the scope of the block

You need permission to edit the affected content. Operations on plugins require separate permissions. Note your WordPress version, the theme, the block name, and the change that preceded the error. Record whether you use self-hosted WordPress, WordPress.com, or a multisite network. Hosting access and available menus vary by environment.

Open **List View** from the document overview at the top of the editor. Expand the group containing the block and identify its exact position. Selecting the whole group when you mean to select a paragraph can convert much more content than intended.

Check whether the content belongs to a synced pattern, formerly called a reusable block. Editing the original can affect every use of that pattern. A copied page can still be linked to the same original. For a local test, detach the pattern if the option is available and you have permission. Otherwise, ask the person responsible for the pattern to help before continuing.

Choose one of the three approaches

Start with targeted recovery if a single block shows the warning after a change to its content. The aim is to compare a small repair with your saved copy and leave the rest of the document intact.

Use revisions when you know a working version was previously saved and want to recover its content. This is particularly helpful if block recovery removes important elements. A revision restores saved content. An incompatible block provider still needs its own fix.

Investigate the third-party block if several older pages are affected after an update or if the block depends on a missing plugin. In that case, converting blocks on every page can hide the cause and remove features. You can follow all three approaches with the tools already available.

Approach 1: Try recovery on the copy

Use a separate working draft and a verified copy stored outside WordPress. This approach suits an isolated block whose provider is still available. The expected result is complete content that stays editable after saving.

1. Open **List View** in the draft, select only the affected block, and check its position. Avoid selecting the group or the whole page. A successful recovery on a paragraph tells you little about a gallery or an e-commerce block.
2. Click the recovery button in the warning once. Depending on the language and version, it may be labelled **Attempt Recovery**. Compare the result immediately with the original file and screenshot.
3. Check the wording, links, images, and presentation settings you need. Recovery can remove unrecognized markup. If something is missing, use **Undo** before trying again. If you cannot return to the state you want, start again from the original copy in your draft.
4. If the content looks complete, save the draft, leave the editor, and reopen it. Check that the block remains editable and the warning stays gone. Reopening confirms what was saved beyond the editor’s initial display.
5. Record whether the fix held or the error returned, and whether it happened immediately, after saving, or on reopening. If recovery fails, keep the original intact and compare a conversion or revision in the sections below. Wait until a representative block passes before attempting recovery elsewhere.

Compare a conversion without losing content

If recovery is unsuitable, open the warning’s three-dot menu. If it offers **Resolve**, compare the existing content with the expected version. Identify any proposed removals before choosing to convert the content to blocks. If the differences are unclear, leave the comparison without accepting the conversion.

Converting to a **Custom HTML** block is another option, especially when you need to preserve a fragment of markup for someone to inspect. A Custom HTML block cannot expose the original block’s settings. It is most useful when someone can review the HTML. Beginners may find it easier to maintain a simple paragraph rebuilt in a native block.

Avoid pasting unfamiliar code to clear the warning. WordPress may filter some HTML when it saves, depending on permissions and the environment. A correct preview before saving needs to be confirmed afterward. Keep the existing permissions and filtering in place.

Stay in the working copy while comparing the results. If a conversion removes text, changes links, or replaces the content with an empty block, stop and use the saved original to rebuild the block or find a useful revision.

Decide when to use the Classic block or rebuild the block

Some interfaces offer a conversion to a **Classic** block. It is built into the block editor and provides tools similar to the older editor. You can try it without installing the Classic Editor plugin or switching editors across the site.

Try this conversion on the copy if the option is available. Check what was preserved before making another change. Converting the Classic block back into multiple blocks is a further conversion. Inspect the intermediate result before deciding whether to take that step.

For simple content, you can instead add a **Paragraph**, **Heading**, or **Image** block beside the damaged block. Re-enter the text without the problematic formatting, recreate the links, and choose the images from the Media Library. Compare both versions before removing the affected block from the copy. If the rebuilt block works after reopening, you have a targeted repair you can apply to the original page.

Approach 2: Find a usable version in the revisions

You need a version saved before the error and permission to view the document’s history. Preserve the current state outside WordPress first. A full restore can replace recent edits and immediately change a published page.

1. In the original document, open the settings, then the **Post** or **Page** tab and **Revisions**. Depending on the version, inspect the visual preview or the HTML comparison. Confirm the document title before browsing the dates.
2. Select a version from before the problem appeared and leave **Restore** untouched. Note the author, time, and passage you need. Autosaves provide a limited history, so recovery depends on the content having been saved and retained.
3. Compare recent changes elsewhere in the page that you need to keep. Prefer extracting only the affected block as described in the next section. On WordPress.com, **Restore** can put the revision back on the public site immediately. Have the person responsible for publishing decide whether to restore the whole document.
4. Leave the revision history without a full restore until the choice is approved. At this point you should have an identifiable version and know how much you intend to recover. If no useful version is available or you lack access to the history, report that limitation to an authorized editor.
5. Check the recovered fragment in the draft. If you selected the wrong passage, set aside that copy and extract it again from the preserved version. If the same block becomes invalid after reopening, investigate its provider. Restoring a series of older revisions cannot resolve an incompatibility in that component.

Recover part of a revision without restoring the entire page

If the visual revision history lets you select blocks, copy the part you need and leave the history without restoring the whole document. Paste it into the working draft and check it. This method is documented on WordPress.com. The available commands can differ in older interfaces.

If you have only an HTML comparison, use it to identify the passage. Select complete blocks, including any group boundaries. If necessary, ask someone familiar with the markup to extract the fragment correctly, or rebuild simple content using the text you recovered.

Save and reopen the recovered copy. If the same block becomes invalid again, the earlier content alone is insufficient. The problem may lie in the current version of the component. Move to the third approach before restoring any more dates on the public page.

Approach 3: Identify the third-party block provider

Record the versions and the block name first. Work on plugins requires an authorized administrator. A third-party block comes from a plugin or theme. This approach identifies its provider before any conversion or migration.

1. In the warning and **List View**, record the block name and its technical identifier if one is shown. Save a minimal example without private data. Ask the administrator to match the identifier to installed components before considering replacements.
2. Check whether the block is still present but its older content fails validation, or WordPress reports that the block is unsupported. In the first case, note the provider’s version and recent updates. In the second, check whether the provider is disabled, missing, or unavailable in that environment.
3. Keep the missing blocks while you investigate. Converting to HTML may preserve some content, while features that depend on the provider remain unavailable. On multisite, ask the network administrator to check components managed at that level. On WordPress.com, use the access available to you or contact support.
4. The aim is to identify the provider and form a specific hypothesis to test on a separate copy, as described next. If the provider remains uncertain, stop editing and pass on the block name and versions. The inventory is read-only. Keep the original for the tests that follow.

Check for an incompatibility before migrating

Use a staging site with its own database, a backup, and real payments, notifications, and outgoing messages disabled. An update that happened around the same time as the error is a clue. Reproduce the issue before treating the update as the cause.

1. Consult the provider’s documentation and release notes for the exact block. Record the change you suspect and choose a representative page. Confirm that the error occurs in the staging copy before changing the component.
2. Work with the maintainer to change one thing at a time in staging. Record the starting version and configuration, along with the restoration procedure, then reopen the same content. Leave the production plugins active while you test.
3. Compare the content and features after the test, then restore the previous configuration before testing another hypothesis. If the provider changed the saved format, send them your minimal example. Compatibility with older blocks depends on the provider’s documented migration.
4. Stop if the copy fails to reproduce the issue or you cannot restore its starting state. Leave the provider’s files intact and review security and compatibility before keeping an older version long-term. Once you confirm a cause, choose a repair and test it before applying it more widely.

Migrate to maintained blocks when necessary

If the component has been abandoned or its provider recommends a migration, establish what each block does first. You can often rebuild a piece of text and an image with blocks already available. A form, search box, or calculated display needs a replacement that performs the same function as well as a suitable appearance.

Some blocks generate their output on the server. Their saved content may contain only part of the final result. Preserving HTML alone may leave out information or features. Have the replacement checked for the type of block involved before removing its provider.

On the copy, add the replacement next to the old block, re-enter the data you need, and check the features. Remove the old block after comparing the two and making a backup. If several pages need work, start with one representative instance and keep a list of the affected content. Judge the migration by whether people can still use the content and its features.

Validate the repair before changing the public page

Reopen the draft after saving. Check that the block remains editable and the warning stays gone. Then preview it at wide and narrow widths. Check headings, alt text, the order of elements, links, and any content behind an accordion or tab.

For an interactive element, define a test with no real-world effect. A form can display its fields even when it cannot process responses. Use a suitable test environment for important features, and keep real recipients out of any test submissions.

After the repair is approved, apply only the necessary change to the original content with the required permissions. Before saving an already published page, review what changed and coordinate with other authors to avoid simultaneous edits. Then check the public page and reopen the editor. Keep your copies until both checks pass.

Know when to stop and ask for specific help

Stop converting blocks if content disappears, an essential feature is lost, or several blocks repeatedly fail. Contact the block developer about a specific incompatibility. Ask your hosting provider about backups, staging, or server errors. On WordPress.com, support can direct you to checks relevant to the service.

Share the exact warning, the versions involved, the block name, the steps to reproduce the problem, and the outcome of one documented test. Remove personal information, confidential business data, and credentials from the sample. Share only the material needed for diagnosis when posting to a public forum.

To reduce the chance of the problem recurring, keep a backup before changing components and check a few representative pages afterward. Avoid editing the HTML structure by hand in blocks you still want to edit visually. The repair is complete once you have preserved the useful content and its features and confirmed that the editor can save it correctly.