Verification says "not detected": how to fix it

If SuperSchema cannot confirm your schema on the live page, it is almost always one of a handful of causes: the code is not published yet, a wrong URL, a blocked crawler, a redirect, or an older package on the page. Work through them in order using the exact status message SuperSchema showed you.

A failed verification means SuperSchema visited your live page and could not confirm the expected schema package. The status message tells you which check failed, and each one points at a different fix. Start with the message you saw, then work down this list roughly in order of likelihood.

Tip Publishing and CDN caches can lag, so first re-run verification once. It re-checks several times over a few minutes on its own. If it still fails after a fresh run, it is a real issue and the causes below apply.

The schema is not on the live page yet #

This is the most common cause. If the message is "Schema was not found" or notes that no JSON-LD was found on the page, the install block is not reaching the live HTML.

Confirm you both saved and published the page in your CMS, not just saved a draft.
Open the live page, view its source, and search for "SuperSchema" or "application/ld+json" to confirm the block is really in the <head>.
If your CMS or a security plugin strips inline scripts, the block may be removed after you paste it. Re-paste it and re-check the source.

You verified the wrong URL #

Verify the exact URL you deployed to. A trailing slash, http versus https, or a www versus non-www difference can point at a different page that does not carry your block.

Note If the message is "We checked a different page," the URL redirected somewhere else, so the schema was not found at the address you entered. Verify the final destination URL that the redirect lands on.

SuperSchema cannot access the page #

If the message is "SuperSchema can’t access this page yet," the crawler never got to read your HTML. This is a robots.txt, CDN, firewall, or bot-protection issue, not a schema problem. The verification screen shows the robots.txt it checked and whether the crawler was allowed. Common variants:

Blocked by robots.txt: Your robots.txt disallows the crawler for this page path. Add a rule that allows SuperSchemaBot (see the exact rule below), then verify again.
HTTP 401, 403, or 429: The page returned an authentication, forbidden, or rate-limit response. A firewall, security plugin, or rate limiter is blocking automated readers. Allow SuperSchemaBot in those rules.
Bot challenge (Cloudflare or similar): A challenge or captcha page blocked the crawler even though the page loads fine in a normal browser. Allow SuperSchemaBot through the challenge, or lower bot protection for that URL.
The page timed out: A very slow page can exceed the read window. Retry in a moment, and check your site’s performance if it keeps timing out.

To let the crawler through, allow the SuperSchemaBot user agent in robots.txt and in any CDN, firewall, or security plugin bot rules:

text

User-agent: SuperSchemaBot
Allow: /

# Full crawler user agent:
# Mozilla/5.0 (compatible; SuperSchemaBot/1.0; +https://superschema.ai/bot)

Warning If you cannot allow the crawler (for example on a locked-down staging or gated site), use the copy-paste deploy method and confirm the schema another way, such as Google’s Rich Results Test. SuperSchema still cannot auto-verify a page it is not allowed to read.

An older package is on the page #

If the message is "Schema found, but it is not the current package," SuperSchema found its block with the right schema types, but the content differs from the package on file. An earlier version is deployed. Copy or deploy the current package from SuperSchema once more so the live block matches, then verify again.

Note This can also show as an older install block id in the details. Re-deploying the current package resolves it and turns the result into a clean, version-matched Verified.

The AI-readable files need attention #

If your schema matched but the message mentions the AI-readable files, the schema is live and only the Markdown or plain-text alternate versions failed the check.

Files still being confirmed: The <link rel="alternate"> tags are on the page, 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, then verify again.
Links missing or stale: The alternate links are absent or point at outdated content. Re-deploy the current package, which includes the up-to-date Markdown and plain-text link tags.

The page has unrelated schema #

If SuperSchema found JSON-LD on the page but none of it matches the types you generated, the block may never have been pasted, or your CMS replaced it with its own schema. Re-deploy the SuperSchema package into the page head so your generated types are present.

Tip Still stuck after a fresh verification and these checks? Reach out to support with the URL and the exact status message you saw. The specific wording tells us which check failed and how to help fastest.