Fix an invalid WordPress block by preserving content before changing its structure.
Duplicate the post, identify the affected block, then attempt automatic recovery first.
Convert only when recovery fails or the saved custom markup must remain.
Use the safest recovery order
Preserve, identify, recover, compare, convert, isolate, and verify.
Each step should retain more original content than the next.
Never start by deleting the only affected block.
Do not save over useful evidence
The invalid block contains saved markup explaining the mismatch.
Saving a converted or recovered version may replace that evidence.
Make a recoverable copy before testing fixes.
Copy important text immediately
Select readable text and store it in a temporary plain-text document.
Copy links, captions, alt text, and button labels separately.
Do not copy passwords, tokens, or private form values.
Duplicate the affected post
Create a private staging copy through an approved workflow.
Preserve the title, content, metadata, template, and plugin state.
Keep experiments away from the live page.
Check revisions before recovery
A recent revision may contain the last valid block representation.
Compare revisions before restoring the complete post.
A full rollback can discard unrelated newer edits.
Check the public page before editing
An invalid editor block may still display useful saved HTML publicly.
Capture screenshots and important visible content for comparison.
Do not assume editor invalidation means public disappearance.
Identify every affected block
Scan the complete document and count validation warnings.
Record block names, locations, contents, and repeated patterns.
One source change may invalidate many similar placements.
Identify the block owner
Core owns standard blocks shipped with WordPress.
A plugin may own specialised blocks and their saved markup.
Ownership determines updates, compatibility, and support routes.
Record what changed recently
Note WordPress, plugin, theme, migration, import, and manual HTML changes. We take that up in when to convert a WordPress block to HTML.
Timing identifies candidates but does not prove one cause.
Keep exact versions for controlled staging comparisons.
Try Attempt Block Recovery first
Select the invalid block and choose Attempt Block Recovery.
WordPress tries rebuilding valid markup from recognised block data.
The official recovery guide recommends this available option.
Review recovery before saving
Compare text, links, media, styles, settings, and nested order.
Automatic recovery can discard custom markup that caused invalidation.
Keep the original copy until every important difference is understood.
Preview the recovered page
Use a staging preview before updating the production post.
Check desktop, narrow layouts, keyboard operation, and visible content.
Recovery is incomplete until the public result remains correct.
Use Resolve when differences matter
The Resolve interface compares original saved markup with converted block output.
Read both sides before selecting either conversion.
Visible differences may contain deliberate custom work.
Convert to Blocks for recognised structure
This option rebuilds validated blocks from content WordPress can recognise. The step-by-step is in how to recover missing WordPress blocks.
It preserves block controls where conversion succeeds.
Inspect every proposed change before accepting it.
Convert to HTML for deliberate custom markup
This option preserves original markup inside a Custom HTML block.
Original block controls and structured settings no longer apply.
Use it only when preserving the markup matters more.
Convert to Classic only with purpose
The Classic block can retain content through older editing controls.
It also abandons the original block’s specialised interface.
Document why that trade-off is acceptable.
Edit as HTML only with confidence
Manual fixes can repair obvious tag or attribute mistakes.
They can also remove data the block needs for editing.
Use a copied block and compare expected markup carefully.
Fix unbalanced HTML tags
Missing, duplicated, or misplaced closing tags can change parsed structure.
Correct only the confirmed syntax error.
Then return to visual editing and recheck validation.
Remove unsupported attributes cautiously
Manual styles or attributes may not belong in that block’s output.
Removing them can restore the expected markup.
First confirm they do not provide required meaning or behaviour.
Move scripts into appropriate implementations
JavaScript inserted inside ordinary block markup can cause validation problems.
It can also create security and maintenance risks.
Use approved plugin or theme asset mechanisms instead.
Clean copied formatting at the source
External editors can add spans, classes, and inline styles.
Paste as plain text when the formatting is unnecessary.
Reapply structure through native block controls.
Do not repair every block manually
Many identical failures suggest a shared code or migration cause.
Manual conversion can destroy evidence and create inconsistent outcomes.
Fix and test the shared source before bulk changes.
Test the owning plugin update
A plugin update may include a missing compatibility migration.
Read its changelog and test the affected content on staging.
Never update production solely to test a theory.
Test a controlled version comparison
Reproduce the valid and invalid versions using the same copied post.
Change only the suspected Core or plugin version.
Keep backups and database compatibility in mind.
Check whether the block type loads
An inactive plugin can make its block type unavailable.
A missing block differs from an available but invalid block.
Restore the owning code before converting important content.
Check the browser console
WordPress logs validation details when a block becomes invalid.
The Edit and Save guide recommends comparing expected and actual markup.
Copy the complete warning without publishing private content.
Read the first meaningful difference
A class, wrapper, attribute, text node, or tag may differ.
The first difference often explains later cascading differences.
Start there before rewriting the entire block.
Developer fixes need block deprecations
Changing a static block’s saved markup can invalidate earlier content.
Block deprecations describe recognised older forms and their migrations.
The Deprecation API guide explains this compatibility path.
Test every supported historical fixture
Developers should keep content examples from earlier block versions.
Open, migrate, save, and reopen every supported fixture.
A current example cannot prove old content remains valid.
Keep save functions deterministic
A save function should depend on the block’s defined attributes.
External values can change after content was saved.
That can make regenerated expectations differ unexpectedly.
Use dynamic rendering for changing external data
Current server data often belongs in a dynamic render callback.
Purely dynamic markup is not stored for static validation.
Choose this architecture for data needs, not as a patch.
Check attribute types
Parsed strings, numbers, booleans, and arrays must match definitions.
Type mismatches can change saved output and dirty state.
Test imported and manually edited content carefully.
Check nested block migrations
Moving attributes into InnerBlocks changes content structure substantially.
Deprecations may need to migrate attributes and descendants together.
Test nesting, order, locking, and allowed block rules.
Check filters modifying saved content
Plugins can filter block registration or saved block elements.
Version changes can alter those modifications.
Isolate suspected filters within a controlled plugin test.
Check sanitisation differences
User capabilities and server sanitisation can remove disallowed markup.
The editor may later compare against a different expected structure.
Test representative roles and permitted markup.
Check imports and migrations
Content migrations may rewrite URLs, classes, attributes, or HTML.
Generic replacements can alter serialized block data incorrectly.
Validate copied samples before migrating the complete site.
Repair reusable sources first
Patterns and templates can distribute the same invalid structure.
Fixing independent placements creates inconsistent future content.
Identify and repair the shared source on staging.
Use batch repair only after proof
Automated changes can affect hundreds of posts quickly.
Test selection, backups, transformations, rollback, and dry-run output.
Review representative results before expanding scope.
Save one repaired staging copy
Update the copied post only after reviewing the chosen recovery.
Close and reopen it to trigger validation again.
A warning that disappears only temporarily is not fixed.
Compare public output after saving
Review content, links, media, classes, spacing, and responsive order.
Check both cached and uncached staging output.
Purge caches only within the approved test scope.
Retest keyboard operation
Conversions can change interactive roles, labels, and focus behaviour.
Navigate the repaired block using keyboard-only controls.
Include editor and public page workflows.
Retest structured data
Conversion may remove plugin-generated schema or structured relationships.
Validate only schema actually rendered on the repaired page.
Do not preserve invalid markup merely for claimed SEO.
Document the final recovery
Record the cause, original version, fix, and affected content.
Add screenshots, console differences, and regression fixtures.
This evidence shortens the next investigation.
Use the Code editor for document context
The full Code editor shows block delimiters around saved markup.
It helps reveal accidental text between related blocks.
Make changes only within a preserved staging copy.
Protect block delimiter comments
WordPress uses comment delimiters to identify blocks and their attributes.
Missing or malformed delimiters can change parsing boundaries.
Do not treat them as disposable formatting comments.
Avoid direct database editing
Database replacements can damage serialised attributes across many blocks.
They can also bypass revisions and editor safeguards.
Use tested WordPress-aware migration tools with verified backups.
Check autosaves for newer content
An autosave may contain text missing from the last revision.
Compare its content without replacing unrelated valid changes.
Copy only the required block when practical.
Coordinate with other editors
Another editor may have an active session or newer revision.
Concurrent changes can confuse recovery and ownership decisions.
Pause editing and agree upon the authoritative copy.
Check post-lock warnings
Post locks protect against overlapping edits on shared content.
Taking over a session can expose unsaved work conflicts.
Contact the current editor before proceeding.
Check media references after recovery
Images and galleries can retain attachment identifiers and URLs.
Conversion may preserve a URL while losing attachment relationships.
Verify captions, alt text, sizes, links, and responsive sources.
Check custom CSS class names
Custom classes can be legitimate when stored through supported controls.
Unexpected class changes may also trigger validation differences.
Preserve documented design hooks while removing accidental markup.
Check role-specific sanitisation
Users can have different permissions for unfiltered HTML.
Saving under another role may remove unsupported markup.
Reproduce with representative permissions on staging.
Check unsupported browser modifications
Browser extensions can alter editable fields or injected markup.
Repeat the recovery workflow within a clean browser profile.
Stored mismatch evidence still remains the deciding source.
Public caches do not repair saved markup
A cache can continue serving earlier valid page HTML.
The editor still validates authoritative post content.
Purge caches only after the stored block is repaired.
Theme switching rarely repairs stored content
The theme primarily controls presentation around saved block markup.
Custom theme filters can still alter block registration or editor behaviour.
Switch themes only as a controlled isolation test.
Export a representative failing example
Developers need a minimal fixture that reproduces the invalid block.
Remove private text, URLs, identifiers, and customer data.
Confirm the sanitised example still fails before sharing it.
Retest the original creation path
Create a fresh block using the same current settings.
Save, close, reopen, duplicate, transform, and edit it.
A fresh valid block narrows the problem toward older content.
Know when to contact the vendor
Report repeated invalidation tied to an actively maintained plugin block.
Include versions, steps, expected markup, actual markup, and safe fixtures.
Do not send credentials or unredacted private content.
Know the honest weak case
Conversion can preserve valuable content while losing original block controls.
That trade-off may be safer than repeated failed recovery.
Document the lost capabilities and future editing method.
Use the invalid block checklist
- Copy important text.
- Duplicate the post.
- Check revisions.
- Capture current public output.
- Count affected blocks.
- Identify block ownership.
- Attempt block recovery.
- Review every difference.
- Resolve or convert deliberately.
- Inspect console details.
- Test versions on staging.
- Save and reopen.
- Verify public output.
- Document the cause.
Frequently asked questions
What should I do before fixing an invalid block?
Copy important content, duplicate the post, and check available revisions.
What does Attempt Block Recovery do?
WordPress tries rebuilding valid markup from the block’s recognised data. We wrote that up in fixing the “not a valid JSON response” error.
Will converting to HTML preserve the original block controls?
No. It preserves markup inside a Custom HTML block instead.
Can a plugin update invalidate existing blocks?
Yes. Changed saved markup without compatibility handling can invalidate older content.
Should I repair many invalid blocks manually?
No. Repeated failures usually need a tested shared-source correction.
The verdict
Reliable blocks need careful compatibility work. Compare the $299 lifetime suite after testing upgrades against copied content.
Leave a Reply