What should I do if the Google Schema Testing Tool cannot detect data?

The page already contains JSON-LD code, but when you open the google schema testing tool, it shows “No structured data detected.” There is no need to rush into rewriting the entire markup. This result does not necessarily mean that the Schema is invalid. More commonly, the content retrieved by the testing tool differs from what is displayed in the browser, or there may be issues with markup placement, code syntax, or page accessibility.

In practice, the scenarios most likely to cause misjudgment are: developers see that the code works correctly in the test environment, but the tool cannot retrieve it after publishing; or the website backend has saved fields such as products, breadcrumbs, and articles, but the frontend page does not actually output structured data. First confirm whether the markup exists in the HTML retrieved by the tool, then check whether the markup can be parsed, and finally determine whether the types and properties meet the requirements.

First, distinguish between no data detected and detected data that does not meet rich result requirements

“No data detected” and “data detected with warnings” are two different issues. The former means that the tool has not parsed recognizable Microdata, RDFa, or JSON-LD from the current page; the latter indicates that markup exists but is missing certain recommended fields, which may not affect basic recognition.

Google’s original Structured Data Testing Tool is no longer maintained. When troubleshooting, you can use the Rich Results Test to check whether a page meets Google’s supported rich result display requirements, or use the Schema Markup Validator to check Schema.org syntax and hierarchy. Do not conclude that all structured data on a page is invalid simply because one tool does not show results; different tools place different emphasis on supported types, JavaScript rendering, and validation rules.

Step 1: Confirm that you submitted the final accessible page

First, open the URL to be tested in an incognito window and confirm that it is directly accessible, returns the normal page, and does not require login, CAPTCHA verification, regional restrictions, or special Cookies. Testing tools cannot read content that is blocked, redirected abnormally, or access-restricted.

• Check whether the URL automatically redirects from http to https, or from non-www to www; test the final destination URL.
• Confirm that the page is not a draft, preview link, backend editing page, or test URL visible only on an internal network.
• Check whether multiple redirects occur. If the redirect chain is too long or redirects to a language selection page or error page, the tool is not detecting the intended content page.
• Check whether the server returns different content to crawlers, such as due to security protection, rate limits, 403, 503, or blank pages.

Some websites return different versions based on the visitor’s language, IP, or User-Agent. Normal browser access does not mean the crawling tool receives normal HTML. In such cases, check server logs, CDN protection rules, or page retrieval results to confirm whether the request has been blocked.

Step 2: Find structured data in the page source code

Do not look only in the browser’s “Inspect Element” panel. Developer tools display the DOM after the page runs JavaScript, while testing tools may not execute scripts in the same way. Use “View Page Source” and search for application/ld+json, schema.org, itemtype, or itemscope.

For JSON-LD, the common approach is to place the content inside a <script type="application/ld+json"> tag. If this section is not present in the source code and appears only in the dynamic DOM, the issue is most likely caused by asynchronous frontend injection. Especially for single-page applications, filtered pages, and pop-up product detail pages, structured data may be generated only after an API response is returned. Different crawl timings may then cause the google schema testing tool to fail to detect it.

A more reliable approach is to output JSON-LD for core pages together with the initial HTML, or use dependable server-side rendering or prerendering solutions. The main information on product detail pages, article detail pages, and category pages should preferably be readable in the initial response rather than relying entirely on loading after user interaction.

Step 3: Check JSON-LD syntax instead of looking only at field content

When copying code, it is easy to introduce full-width quotation marks, trailing commas, unescaped double quotation marks, or incomplete brackets. As long as JSON parsing fails, the tool will usually ignore the entire data block. Code that looks like Schema does not mean it is valid JSON.

Also check whether @context is https://schema.org and whether @type is spelled correctly. Property values should remain consistent with visible page content. For example, product prices, inventory, ratings, publication dates, and similar information must not remain in markup long after they have expired or no longer appear on the page. Being parsable by a tool does not mean that search engines will use the information for display.

Issues caused by templates, plugins, and caching are more hidden

When using a website builder or CMS, structured data may still not be detected after selecting “Enable structured data” in the backend. The issue is often not that the Schema type was selected incorrectly, but that the template does not call the corresponding component. For example, an article template may output the title and body but omit the article Schema module; product data may be entered in the product system, but the current detail page uses a custom template and the relevant fields are not passed through.

Another frequent issue is caching. After a page is updated, backend settings may have changed, but the CDN, page cache, or object cache may still return old HTML. The troubleshooting sequence should be: save the settings and publish the page, clear the site cache and CDN cache, use the final public URL to view the source code, and then resubmit it for testing. Seeing new code only on the backend preview page does not prove that the live page has been updated.

Do not output conflicting duplicate data on the same page

Some websites enable both built-in theme SEO markup, e-commerce plugin markup, and third-party SEO plugins. As a result, a single product page may contain two Product entries and two Offer entries, with inconsistent prices or inventory. Such pages may not necessarily display “No data detected,” but they can make subsequent diagnosis confusing and may also reduce the credibility of the markup.

It is recommended to retain the primary entity according to the page’s role: Article or BlogPosting for article detail pages, Product for product detail pages, and BreadcrumbList as a supplement for navigation areas. First remove or disable duplicate sources, then test again. For sitewide entities such as Organization and WebSite, information including the name, website URL, and Logo should also remain consistent. Do not allow different plugins to generate different versions.

Validation sequence after the fix

1. Open the source code of the public page and confirm that structured data has actually been output.
2. Validate the JSON-LD code snippet separately to rule out comma, quotation mark, bracket, and encoding errors.
3. Use a Schema validation tool to confirm that entity types, property hierarchies, and reference relationships can be parsed.
4. Then use the Rich Results Test to check the specific display types supported by Google and any missing fields.
5. Retest the URL after clearing the cache; if the page has been indexed, you can request recrawling in Search Console.

Finally, maintain a clear boundary in your assessment: passing structured data validation only means that machines can understand some page information; it does not guarantee rich result display. Conversely, if a type of Schema is not displayed by a rich result tool, it does not necessarily mean that the markup has no value. For the issue of “no data detected,” prioritizing page accessibility, initial HTML output, JSON syntax, and cache versions is usually more effective than repeatedly adding fields.