When you deploy a change, it does not always appear on the live page the instant you save. Content platforms have to republish the page, and content delivery networks (CDNs) serve a cached copy for a short while before they pick up the new version. So instead of checking once and giving up, SuperSchema re-checks your page several times over a few minutes and waits for the schema to show up.
How the re-checking works #
Verification starts with an immediate check, then spaces out follow-up checks so quick setups pass fast while slower ones still get caught. Each attempt re-crawls the live page from scratch. The moment an attempt finds your schema, it stops and reports Verified. It only settles on Not detected after every attempt in the schedule comes back empty.
- The first check runs immediately, which catches instant-publish setups (for example HubSpot pages that go live right away).
- Follow-up checks run at widening gaps so a page that needs a few seconds to republish or clear its CDN still gets picked up.
- The gaps widen on purpose: a page that has not appeared after a minute usually needs longer, so there is no point hammering it every second.
- As soon as any check succeeds, verification stops early and shows Verified.
Why the wait exists #
- Republish delay
- Your CMS may need a few seconds to rebuild and serve the page after you save and publish. Until it does, the old version is what the crawler sees.
- CDN and cache propagation
- CDNs like Cloudflare serve a cached copy of your page at edge locations. New markup only appears once that cache refreshes, which can take a little time.
- One re-crawl per attempt
- Every attempt fetches the live page fresh rather than reusing an earlier read, so a check that lands after the cache clears sees the real, current page.
If verification still comes back empty after a fresh run, it is no longer a timing issue. At that point the troubleshooting guide covers the real causes: the code not being on the live page, a wrong URL, a blocked crawler, or a redirect.