Page builders that assemble content from modular blocks sometimes strip out or fail to render JSON-LD schema that was correctly added elsewhere, particularly when the schema was meant to sit in a page’s head section but the builder’s own output structure doesn’t preserve it — the schema was right; the builder broke how it reaches the page.
Check whether your schema disappears specifically after editing in the page builder
View your page source before and after making an edit in your page builder. If valid JSON-LD is present before an edit but missing or altered afterward, that confirms the page builder itself as the point where it’s being lost, rather than an issue with how the schema was originally written.
JSON-LD broken by page builder - repair
Valid schema a page builder strips on save, re-implemented so it actually survives editing.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| JSON-LD schema disappears or breaks specifically after page builder edits | This fix covers it |
| The schema was never correctly implemented in the first place, unrelated to the page builder | The relevant schema-type implementation fix instead |
| A theme and SEO plugin are conflicting, not a page builder stripping schema | SEO plugin vs theme schema conflict |
| The schema is present but shows a validation error, not a page-builder-caused disappearance | Schema validation error fixes |
What you are seeing
- Valid schema present in the page source before editing, missing or broken after editing with the page builder
- The pattern being consistent and reproducible across multiple pages using the same builder
- Google’s Rich Results Test previously passing, now failing without any other apparent change
- The schema’s source code technically still present in the database but not rendering correctly on the front end
Common causes
- The page builder’s rendering process stripping content outside its own recognised block structure
- A conflict between where the schema was originally placed and how the builder outputs the page head
- A page builder update changing its own output handling in a way that broke previously working schema
- Schema added via a method the specific builder doesn’t reliably preserve during its own save process
- A code snippet or custom field inserting the schema into a template location the page builder later overrides
What we do
- Confirm the schema is being lost specifically during the page builder’s process
- Identify a method of adding the schema that the builder reliably preserves
- Re-implement the schema using that compatible method
- Verify the schema now survives a builder edit and re-save
- Test against Google’s Rich Results Test to confirm valid output
- Check other pages built with the same builder for the same vulnerability
What is included
- The page-builder-specific cause of schema loss identified and resolved
- Schema re-implemented in a way that survives the builder’s editing process
- Verified valid output after a test edit and re-save
- A check across other pages for the same vulnerability
Not included
- Implementing new schema types not previously present
- Fixing an unrelated page builder issue not connected to schema output
- Migrating away from the page builder itself, a separate, larger decision
- Ongoing monitoring as the page builder updates in future
Questions about this fix
Why would a page builder update break something that worked fine before?
Page builders periodically change how they render and save content, and schema added in a way that relied on the previous behaviour can be lost or altered without any deliberate intent to remove it.
Will this happen again every time I edit the page in future?
Once implemented using a method the builder reliably preserves, it shouldn't recur from routine editing — though a major future update to the builder itself could theoretically introduce a similar issue again.
How do I know if this is actually the page builder's fault, rather than something else?
Testing directly — checking the page source before and after an edit — is the clearest way to confirm the builder specifically is where the schema is being lost, rather than assuming based on which builder you use.
Does this affect all page builders, or just certain ones?
It's more common with certain builders and certain schema placement methods than others — we identify what's specifically happening with your setup rather than assuming a universal cause.
Is switching to a different page builder a better long-term fix than this?
That's a much larger decision with implications well beyond schema alone — this fix resolves the immediate schema issue within your current builder, which is usually the more proportionate response.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.