🔍 Why schema markup can revert
An approved LocalBusiness schema correction may appear to revert when a later OTTO deployment action replaces, undeploys, or reprocesses the page-level schema. A mass undeploy or domain-level deployment change can remove a previously applied correction. In some cases, stale schema records with an invalid status can also block a new deployment.
The live page may continue serving older schema if the previous markup was not fully removed or if another deployment source is still active. Approval confirms the proposed correction; it does not prevent later deployment changes from updating the live markup.
📋 Audit the deployment history
- Open the affected project and identify the exact URL where the schema changed.
- Review the OTTO schema deployment history for that URL and the domain around the time of the reversion.
- Look for page-level undeployments, mass undeploy actions, domain-level changes, failed deployments, or records marked stale or invalid.
- Compare the last approved schema with the schema currently shown on the live page.
- Record the event time, affected URL, schema type, deployment status, and any error or validity message.
This audit identifies whether the change came from an intentional deployment action, a cleanup process, or a stale schema record that prevented the correction from being applied.
✅ Restore accurate structured data
- Confirm the business facts first, including the business name, address, phone number, hours, URL, and location details.
- Remove or resolve the stale or invalid schema record through the OTTO schema workflow. Do not change valid business facts just to work around a deployment error.
- Submit the corrected LocalBusiness schema for approval when required.
- Deploy the approved schema through OTTO using the affected page or domain deployment workflow.
- After deployment, verify the live page source and a structured-data testing tool to confirm that the intended schema is present and outdated markup is gone.
Using the OTTO workflow preserves the approved facts and creates a traceable deployment record. Avoid manually adding replacement schema to the site while an OTTO deployment is being repaired, because multiple sources can cause conflicting or duplicate markup.
🧪 Verify deployment integrity
- Confirm the schema record is valid and no longer marked stale.
- Check that the deployment status shows completed rather than stuck or failed.
- Verify the live page contains one consistent LocalBusiness definition where appropriate.
- Recheck the page after caching has cleared, since the live result may not update immediately.
- Keep the deployment event details if the schema changes again.
💡 Prevent future reversions
Before approving or deploying a correction, confirm the target URL and deployment scope. Review recent domain-level and page-level actions before running bulk changes. When a deployment is stuck, resolve the stale schema status first instead of repeatedly submitting the same correction. This protects valid business information and makes the deployment history easier to trace.
💬 Need help?
If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.