How deployment verification works

After you deploy, SuperSchema re-crawls your live page, finds its own install block, and confirms the exact schema package you generated is really published. It matches by version id first, then by a content hash, then by schema type, and reports one clear status so you know whether you are done.

Verification is how SuperSchema confirms the schema you generated is really on your live page, not just saved in your Library. When you verify, SuperSchema visits the exact URL, reads the JSON-LD it finds, looks for its own install block, and compares what is live against the package on file. It reads your public page the same way a search or AI crawler would. It never logs in and never changes your site.

What verification checks, in order #

A page counts as verified only when every part of the deployed package is present and current. SuperSchema runs these checks each time it looks:

Reach the page: it fetches your live URL and confirms the page loads, is not blocked, and did not redirect somewhere else.
Find the install block: it looks for the SuperSchema install block you pasted into the page head.
Match the schema package: it compares the live schema against the package you generated.
Check the AI-readable files: if your package includes Markdown and plain-text alternate versions, it confirms those <link rel="alternate"> tags are present and point at the current files.

Note If your deployment is schema only (no AI-readable alternate files in the package), the alternate-file check is skipped and verification passes on the schema alone.

How the schema match is made #

SuperSchema tries the most precise signal first and falls back to broader ones. This is why a page can verify even when your CMS reformats or adds to your markup:

Version id (most precise): Every install block SuperSchema generates carries a version id. If the live block carries the version id of the package on file, that is an exact, unambiguous match.
Content hash: If the version id is not present, SuperSchema hashes the live schema content and compares it to the hash of your generated package. A matching hash means the same schema is live even if the id was stripped.
Schema type match: As a final fallback, SuperSchema checks that every schema type you generated is present on the page. Because some platforms auto-emit a broader parent type (for example Article on top of BlogPosting, or WebPage), a compatible parent or subtype still counts as a match.

Tip The type match is bidirectional. If you generated BlogPosting and HubSpot or WordPress also emits a generic Article, verification still recognizes them as the same thing rather than flagging a mismatch.

What each result status means #

Verified: Your exact generated package was found on the page, matched by its version id or content hash, and any AI-readable files are present and current. You are done.
Verified (compatible): A matching schema is on the page from a compatible older install block. It still works. Re-deploy the current package if you want an exact, version-matched result.
Schema is live, AI-readable files still being confirmed: Your schema matched, but the hosted .md or .txt file could not be fetched during this check. This is usually a short CDN or cache delay. Wait a moment and check again.
Schema found, but it is not the current package: A SuperSchema block with the right types is on the page, but the content differs from the package on file (an older version is deployed). Re-deploy the current package, then verify again.
Not detected: After re-checking, the expected schema was not found on the live page. Nothing was matched. The troubleshooting guide walks through the usual causes.

Warning Verification confirms your schema is published and readable. It does not by itself score how good the schema is. Your schema quality score is a separate measure of completeness and correctness.

What happens after a page verifies #

When a page verifies, SuperSchema captures the live page as a baseline. That baseline is the reference point for monitoring: later crawls compare the current page against it and open a drift event if your schema changes or disappears. On a subscription, verifying is also the point where you can activate monitoring on the page, which starts regular re-checks.

Note The crawler that verifies (and later monitors) your page identifies itself as SuperSchemaBot, with the user agent Mozilla/5.0 (compatible; SuperSchemaBot/1.0; +https://superschema.ai/bot). Allow it in robots.txt and any CDN, firewall, or security plugin so verification can read the page.