Cannot preview Google rich search results in the test tool | How to fix rich media search result errors

In simple terms: when you use Google’s official testing tool, it shows “No rich media results detected”;

But when you check Search Console, it prompts “Missing offer fields” (like product price, inventory not properly marked).

Because Google only fully executes JavaScript on less than 40% of pages during crawling, many Product markups dynamically generated by JS weren’t captured by the crawler.

For example, a food e-commerce website didn’t add “nutrition” sub-items (like calories, protein content) to its Recipe markup, resulting in the that could originally be displayed “Recipe cards with nutrition information” direct reduction by more than half (display rate dropped 62%), losing thousands of clicks daily.

Another news website had the “datePublished” in Article markup written in the wrong format (like “2023/12/31” instead of the standard “2023-12-31”), causing breaking news to never trigger “Featured Snippets” (prominent cards at the top of search results), missing much exposure.

Troubleshooting Steps​

From the data, the problem distribution is clear: approximately 65% of preview failures are caused by JSON-LD code errors or missing required properties (like fields that should be marked but aren’t, or incorrect format);

20% is because the page uses JavaScript to dynamically load content, but Google crawler didn’t render it during crawling;

The remaining 15% are due to slow page loading or requiring login, where the crawler didn’t read the markup at all.

The default testing tool may use old cached data, causing 48% of new problems to go undetected; even when testing “real-time preview”, it only covers 35% of JS-generated content, and many dynamic markups cannot be verified.

If the website doesn’t have HTTPS enabled, 18% of structured markup will be directly ignored; if page loading exceeds 5 seconds, 22% of Google crawlers will give up crawling early, naturally failing to read your markup.

Structured Data Syntax and Attribute Validation

Structured data validation needs to focus on JSON-LD syntax accuracy (bracket/quote/comma errors account for 42%-31% of syntax problems), required property completeness (Product missing offers accounts for 38%, Article missing datePublished accounts for 29%) and type nesting standardization (e.g., Recipe not nesting NutritionInformation causes a 57% increase in parsing failure rate).

JSON-LD Syntax Errors

​​Unmatched brackets and quotes​​ (accounts for 42% of syntax errors):

Example error code:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Wireless Headphones”,
“image”: “https://example.com/headphones.jpg”,
} // Missing closing brace}”

Fix method: Use the code editor’s “bracket matching” feature (such as VS Code’s Bracket Pair Colorizer plugin) to check the symmetry of {}, [], "" line by line.

Redundant commas​​ (accounts for 31% of syntax errors):

Example error code:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Redundant comma at the end here
“priceCurrency”: “USD”
},

Fix method: JSON specification does not allow commas after the last property of an object/array. Manually delete or use an online formatting tool (such as JSONLint) to automatically correct.

Data type errors​​ (accounts for 27% of syntax errors):

For example, date format not using ISO 8601 standard (should be "2023-10-05T08:00:00+08:00" instead of "2023/10/05"), or price not using string type ("price": 99.99 should be changed to "price": "99.99").

Schema.org clearly requires that numeric properties must match the format of their corresponding types, otherwise they will be judged as “invalid value”.

Required Property Completeness

Different Schema types have clear requirements for “required properties”, and missing any property will prevent rich results from being generated.

According to Google’s “Rich Media Results Guidelines” (2024), the following are required properties for high-frequency markups and consequences of missing them:

Markup Type	Required Properties	Missing Rate	Consequence Example
Product	name, image, offers	38%	Cannot display price and purchase link
Article	headline, datePublished, author	29%	Does not trigger “Featured Snippet”
LocalBusiness	name, address, telephone	35%	Map card cannot associate location
Recipe	name, description, recipeIngredient	41%	Does not display ingredient list and steps

Case​​: A food website’s Recipe markup was missing recipeIngredient (required property), and the rich result display rate dropped from 12% to 5%.

After repair, the ingredient list was added (such as "recipeIngredient": ["Flour 200g", "Eggs 2"]), and the display rate recovered to 10% within 3 days.

Type Nesting Standards

Complex Schema types need to implement semantic associations through nesting, and incorrect nesting will cause Google to fail to identify property ownership.

Schema.org 2023 data shows that ​​nesting errors account for 49% of attribute validation failures​​, with typical scenarios including:

​​Recipe nutrition information​​: Must be nested under the NutritionInformation type, not as a direct attribute of Recipe:

// Error (not nested)
“calories”: “350 kcal”

// Correct (nested NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Event location information​​: Must nest Place type, including address, geographic coordinates and other sub-properties:

“location”: {
“@type”: “Place”,
“name”: “Conference Center”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Verification method​​: Use Schema.org validator’s “Nested Entities” tab to check if nesting levels comply with standards (e.g., NutritionInformation must be a direct child type of Recipe).

Google and Schema.org Dual Verification

​​Google structured data testing tool​​: Focuses on “rich result compatibility”, and will prompt “This markup cannot generate rich results” with specific reasons (such as “Missing offers field”). ​​Schema.org validator​​: Focuses on “semantic standardization”, checking if property values comply with Schema definitions (such as whether priceCurrency is an ISO 4217 currency code).

Limitations of Testing Tools

Google testing tools are limited by cache mechanism (48% old data residue), real-time test coverage (35%-50% of dynamic content). Data shows that relying solely on testing tools may miss 22% of real problems. (49 characters)

Cache Mechanism

Google structured data testing tool caches page markup by default, ​​48% of test results will display data from 48 hours ago​​ (Search Console Help Center, 2023).

If you recently modified JSON-LD markup but didn’t clear the cache, test results may still show errors from before the modification.

Case​​: An education website updated course information Course markup, but the testing tool still prompted “Missing description field” – after clearing the cache, results returned to normal.

​​Countermeasures​​:

• Manually click “Clear cache” in the tool’s upper right corner (trash icon) before each test to avoid interference from historical data.
• For frequently updated pages (such as e-commerce product pages), it is recommended to attach a timestamp parameter when testing (such as ?v=20240315) to force the tool to crawl the latest version.

Real-time Testing

The real-time testing function (after entering URL, switch to “Real-time test” tab) simulates Googlebot crawling and executing page JavaScript, but its capabilities are limited: ​​it can only capture 35%-50% of dynamically generated markup​​ (Google Engineer Blog, 2024).

Reasons for uncaptured content:

• JS execution delay: Markup generated by asynchronous requests (such as fetch), testing tool’s wait time is insufficient (default timeout 3 seconds).
• Framework compatibility: React/Vue and other SPA framework hydration processes may not be fully simulated, causing markup not to be injected into DOM.

A news site used React to generate Article markup, real-time testing showed “No rich results”, but markup existed after actual page rendering – because JS execution took 4.2 seconds, exceeding the tool’s default wait time.

Countermeasures:

• Check page JS execution time (using Lighthouse or Chrome DevTools Performance tab), ensuring markup loads within 3 seconds.
• For SPA sites, use window.__INITIAL_STATE__ and other pre-rendering techniques, or manually trigger JS execution in testing tool (such as clicking page interaction buttons).

Coverage Report

The testing tool’s “Coverage” report (located at the bottom of results page) shows Google’s understanding of the page, but only provides ​​superficial conclusions​​ (such as “No qualifying markup found”), without explaining specific errors in depth.

​​Common ambiguous prompts and meanings​​:

​​Case​​: A recipe website testing showed “Some markup was ignored”, Schema validator found that Recipe‘s nutrition field was not correctly nested under NutritionInformation type. After correction, coverage report updated to “All markup valid”.

Supplementary Third-party Tools

Relying solely on Google testing tools may miss 22% of real problems (HTTP Archive, 2023), requiring cross-verification with other tools:

• ​​Schema.org validator​​: Checks semantic standardization (such as whether priceCurrency complies with ISO 4217 codes). A cross-border e-commerce website mistakenly used “US” instead of “USD” for priceCurrency, Google testing tool didn’t report error, but Schema validator caught the problem. After fixing, rich result display rate increased by 19%.
• ​​curl command testing​​: Simulate Googlebot crawling through curl -H "User-Agent: Googlebot" URL to see if markup in original HTML is correctly output (especially applicable for server-side rendered pages).

Page Accessibility and Crawling

Page accessibility is the “foundation” for rich media result generation – if Googlebot cannot crawl or access the page, markup won’t be recognized either.

Google’s 2023 “Search Quality Guidelines” clearly state that 60% of rich result preview failures are strongly related to page accessibility issues

Public Accessibility

Pages must be fully public to Googlebot, without login walls, membership restrictions or geographic blocks.

Data shows that ​​15% of preview failures stem from pages only accessible to specific users​​ (Search Console Help Center, 2024).

Scenarios​​:

• A membership-based food website set Recipe detail pages to “view after registration”, causing Googlebot unable to crawl recipeIngredient and other required fields. Testing tool always showed “No results”; after removing login restrictions, rich result display rate recovered from 0 to 8% within 3 days.
• A cross-border beauty brand hid price information from Southeast Asian users, causing Product markup’s offers field (containing price) to be uncrawlable. After fixing, Southeast Asia rich result clicks increased by 25%.

Verification methods​​:

• Access page using Chrome incognito mode (disable cookies and login status), confirm content is fully visible;
• Use AccessiBe to simulate different region IPs, check for geographic targeting restrictions (such as “only visible to US users”).

Page Load Speed

HTTP Archive 2023 report shows that ​​pages with load time exceeding 5 seconds, 22% of crawlers will terminate crawling early​​.

​​Specific impacts​​:

• If Product markup is at the bottom of the product page, load timeout will directly cause Googlebot to miss this content;
• Asynchronously loaded Article markup (such as AJAX-generated author info) will also be ignored if takes too long.

​​Verification​​:

• Use PageSpeed Insights to test “LCP (Largest Contentful Paint)” metric for mobile/desktop – needs to be controlled within 2.5 seconds (Google’s performance requirement);
• Optimization actions:
  • Compress images: Use WebP format instead of JPG/PNG, can reduce file size by 50% (e.g., 1MB JPG converted to WebP becomes only 400KB);
  • Lazy load non-critical resources: Set bottom ads, sidebar comments etc. to “load when scrolled into view”;
  • Enable Gzip compression: Through server configuration (such as Nginx’s gzip on;) to reduce HTML/CSS file size.

​​Case​​: An electronics e-commerce page had initial load time of 6.2 seconds, LCP of 3.8 seconds. After optimization, load time dropped to 3.5 seconds, LCP <2 seconds, Googlebot crawl success rate increased from 75% to 92%, and Product rich result display rate increased by 19%.

HTTPS Encryption

All URLs related to structured data (images, detail page links, offers.url) must use HTTPS.

Google clearly requires that ​​non-HTTPS resources may be judged as “unsafe”, causing 18% of preview failures​​ (Google Developer Documentation, 2023). ​

Common errors​​:

• Image links use HTTP (such as http://example.com/headphones.jpg), causing Product‘s image field invalid;
• Article‘s url attribute points to HTTP version (such as http://blog.example.com/post-123), being ignored by Google.

​​Verification​​:

• Manually check all URLs in markup, ensure they start with “https://”;
• Use SSL Labs to test website SSL certificate – need to ensure no expiration, no configuration errors (such as not enabling TLS 1.2 or above).

​​Fix​​: A fashion website fixed all HTTP image links, and Product rich result display rate increased from 12% to 30%, and “Markup resource invalid” error messages in Search Console completely disappeared.

Fixing Common Error Types​

Fixing common errors needs to target four major categories:

• JSON-LD syntax errors (38%)
• Missing required properties (29%)
• Non-standard nesting (22%)
• Dynamic content not captured (11%)

Data shows that after fixing one by one, rich result preview success rate can increase from 45% to 82% (Google 2024 case)

JSON-LD Syntax Errors

JSON-LD syntax errors account for 38% of structured data problems, mainly including unmatched brackets (42%), redundant commas (31%), data type errors (27%). After fixing, markup recognition rate can increase to over 95% (Google 2024 data).

Google 2024 “Structured Data Error Report” shows that ​​38% of rich result preview failures stem from JSON-LD syntax errors​​

Unmatched Brackets and Quotes

Unmatched brackets ({}) and quotes ("") are the most common syntax problems, accounting for 42% of all JSON-LD errors (Schema.org 2023 verification data).

These errors usually stem from oversight during coding, such as missing closing symbols or unpaired quotes.

Specific case​​: An online education platform’s Course markup once had a missing closing brace, causing Google testing tool to show “Invalid JSON”:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Digital Marketing Basics”,
“description”: “Learn SEO and SEM techniques” // Missing the final “}”

Fix methods:

• Use code editor’s “symbol matching” feature (such as VS Code’s Bracket Pair Colorizer plugin), different colored brackets will visually display unclosed positions;
• Use online tools (such as JSONLint) to paste JSON code, tool will directly mark error locations (such as “Expected ‘}’, got ‘EOF'”).

​​Fix effect​​: After the platform corrected it, Course markup was successfully parsed, rich result display rate recovered from 0 to 7%, and “Invalid structured data” error messages in Search Console disappeared.

Redundant Commas

Redundant commas refer to having an extra comma after the last property of an object ({}) or array ([]), accounting for 31% of syntax errors (Google Developer Documentation, 2024).

Typical scenario​​: An e-commerce website’s Offer markup had an extra comma after the price field:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Redundant comma at end
“priceCurrency”: “USD”
}

When the parser encounters this comma, it thinks there are more properties following, but there aren’t, so it judges the entire offers object invalid.

Fix methods​​:

• Use tools like JSONLint to automatically format code, which will delete redundant commas;
• Manual check: there absolutely must not be commas after the last property of an object/array (JSON specification strictly requires this).

A fashion e-commerce website once had redundant commas causing 30% of product markup invalid. After fixing, valid markup rate increased to 95%, and Product rich result display volume increased by 22%.

Data Type Errors

JSON-LD requires property values to strictly match the data types defined by Schema.org. These errors account for 27% of syntax errors (Schema.org 2023).

Common errors include:

• ​​Date format error​​: Not using ISO 8601 standard (should be "2023-10-05T08:00:00+08:00", not "2023/10/05" or "October 5, 2023");
• ​​Numeric type errors​​: Price, rating and other properties used numbers instead of strings (such as "price": 99.99 should be "price": "99.99", "ratingValue": 4.5 needs to keep string format).

​​Case explanation​​: A food blog’s Article markup had datePublished correctly written as "2023-10-05", but reviewRating.ratingValue mistakenly written as number 4.5 instead of string "4.5".

Google testing tool prompted “Invalid rating value”, preventing Featured Snippet from being generated.

After fixing, rating value changed to string, Featured Snippet display rate increased from 10% to 28%. ​​

Verification basis​​: Schema.org clearly specifies that ratingValue must be “Text” type (string), even if content is a number, it must be wrapped in quotes – this is a detail many developers easily overlook.

Missing Required Properties

Missing required properties accounts for 29% of structured data errors, with different markup types having varying missing rates (Product missing offers accounts for 38%, Article missing datePublished accounts for 29%). After fixing, over 80% of rich results can resume display (Google 2024 cases), by completing fields according to Schema standards.

Product

Product is the most commonly used markup for e-commerce, and its required properties are name, image, offers (Schema.org definition).

Among them, offers (product offer) is the core – needs to include sub-properties like price (price), priceCurrency (currency), availability (inventory), etc. Missing rate is as high as 38% (Google Search Console 2023 data).

After missing: A fashion e-commerce website’s Product markup was long missing offers, causing:

• Testing tool showed “No rich results”;
• Search results only displayed title and description, no price, purchase button etc. information;
• Click rate was 40% lower than competitors (all competitors displayed complete product cards).

Fix action: Supplement offers field, clearly specify price and inventory:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
}Within 3 days, rich result display rate recovered from 0 to 15%, search click rate increased by 22%, and conversion volume increased by 18%.

Article

Article (article/blog) required properties are headline (title), datePublished (publication date), author.

Among them, datePublished is the key for Google to judge content “freshness” – missing rate is 29% (Google 2024 Content Ecosystem Report).

​​After missing: A tech blog’s Article markup didn’t include datePublished, causing:

• Cannot trigger “Featured Snippet”;
• Article ranking in search results falls behind competitors published at the same time (all competitors displayed publication date);
• User trust decreases – content without date is considered “outdated”.

Fix action: Supplement ISO 8601 formatted publication date:

“datePublished”: “2024-03-15T10:00:00+08:00”Featured Snippet display rate increased from 10% to 35%, article click rate increased by 25%, and the probability of ranking in top 3 positions increased by 19%.

LocalBusiness

LocalBusiness (local business) required properties are name, address, telephone. Among them, address (detailed address) is the core for Google to associate map cards – missing rate is 35% (Google My Business 2023 data).

After missing: A coffee shop’s LocalBusiness markup didn’t fill in complete address (only wrote city), causing:

• No map card in search results;
• Users cannot directly navigate to the store;
• Local traffic was 50% lower than nearby competitors.

Fix action: Supplement detailed address of PostalAddress type:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
}Map card went live within 24 hours, local search traffic increased by 40%, and store visit conversions increased by 28%.

Recipe

Recipe (recipe) required properties are name, description, recipeIngredient (ingredient list).

Among them, recipeIngredient is the “core content” of recipes – missing rate is 41% (AllRecipes 2024 user survey).

After missing: A food website’s Recipe markup didn’t list ingredients, causing:

• Does not display ingredient list and steps;
• Users cannot determine if recipe meets their needs;
• Collection volume was 60% lower than competitors.

Fix action: Supplement structured ingredient list:

“recipeIngredient”: [
“Flour 200g”,
“Eggs 2”,
“Milk 150ml”,
“Sugar 50g”
]Ingredient list and steps display rate increased from 8% to 25%, collection volume increased by 32%, and the probability of being selected as “Popular Recipe” by Google increased by 21%.

Non-standard Type Nesting

“Type nesting” in structured data is Schema.org’s logic – parent types pass semantic associations by containing child types. For example, Recipe needs to nest NutritionInformation child type through the nutrition field, so Google can understand “calories belong to this dish”.

The Nature of Nesting Errors

Schema.org’s type system is a “tree-like hierarchy”: parent types define core properties, child types extend specific details.

For example:

• Recipe (parent type) is “recipe content”, needs to associate NutritionInformation (child type) through the nutrition field to pass details like “calories, fat content”;
• Event (parent type) is “event information”, needs to associate Place (child type) through the location field to pass location information like “address, coordinates”.

​​Error consequences​​: If skipping child types and directly placing properties under parent type, Google will judge “property ownership unclear” and thus ignore that part of content.

For example, a food website’s Recipe markup directly wrote "calories": "350 kcal", instead of nesting under NutritionInformation. Google testing tool prompted “Cannot recognize calories field”, causing nutrition information to not display in rich results.

4 Common Nesting Errors

(1) Recipe: Nutrition information not nested under NutritionInformation

​​Error scenario​​: A food blog’s Recipe markup directly wrote calories and fat under the parent type:

{
“@type”: “Recipe”,
“name”: “Tomato and Egg Stir-fry”,
“nutrition”: { // Error: nutrition is parent type attribute, needs to nest child type
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Problem​​：Google cannot recognize that attributes under nutrition belong to “nutrition information”, so they don’t display in rich results.

Fix action​​: Nest nutrition information under NutritionInformation child type:

{
“@type”: “Recipe”,
“name”: “Tomato and Egg Stir-fry”,
“nutrition”: {
“@type”: “NutritionInformation”, // Add child type
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Effect​​: The blog’s recipe rich results, nutrition information display rate increased from 8% to 25%, user collection volume increased by 32% (AllRecipes 2024 data).

(2) Event: Location information not nested under Place and PostalAddress​

Error scenario​​: A conference website’s Event markup directly wrote address as string without hierarchical nesting:

{
“@type”: “Event”,
“name”: “Digital Marketing Summit”,
“location”: “San Francisco Convention Center” // Error: location needs to nest Place and PostalAddress
}
Problem​​：Google cannot parse structured address information, so map cards don’t display.

Fix action​​: Nest Place (location) and PostalAddress (postal address) child types:

{
“@type”: “Event”,
“name”: “Digital Marketing Summit”,
“location”: {
“@type”: “Place”,
“name”: “San Francisco Convention Center”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
}
Effect​​: After fixing, map cards displayed in search results, event click rate increased by 40%, and registration volume increased by 28% (Google Events 2023 data).

(3) Product: Review information not nested under Review or AggregateRating

Error scenario​​: An e-commerce platform’s Product markup directly wrote review score without nesting AggregateRating (aggregate rating) child type:

{
“@type”: “Product”,
“name”: “Wireless Headphones”,
“reviewScore”: “4.5” // Error: reviewScore needs to be nested under AggregateRating
}
Problem​​: Google cannot recognize “4.5 points” as the product’s aggregate rating, so star ratings don’t display.

Fix action​​: Nest AggregateRating child type:

{
“@type”: “Product”,
“name”: “Wireless Headphones”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
}
Effect​​: The product’s rich results, star rating display rate increased from 15% to 50%, and conversion volume increased by 19% (Shopify 2024 data).

(4) Article: Author information not nested under Person

Error scenario​​: A tech blog’s Article markup directly wrote author name without nesting Person (person) child type:

{
“@type”: “Article”,
“name”: “2024 SEO Trends”,
“author”: “John Doe” // Error: author needs to nest Person child type
}
​Problem​​: Google cannot recognize author identity information, so “author” label doesn’t display.

Fix action​​: Nest Person child type:

{
“@type”: “Article”,
“name”: “2024 SEO Trends”,
“author”: {
“@type”: “Person”,
“name”: “John Doe”,
“url”: “https://example.com/author/johndoe”
}
}
Effect​​: Article “author” label display rate increased from 20% to 60%, and user trust increased by 25% (Google Authorship 2023 data).

Dynamic Content Not Captured

Dynamic content refers to content generated in real-time through JavaScript (JS), AJAX or SPA frameworks – such as pages built with React/Vue, infinite-scrolling article lists, or recipe steps loaded after clicking buttons.

Markup for such content (such as Product prices, Article comments) will not appear in the initial HTML, but are dynamically injected by client-side JS.

But Googlebot’s crawling mechanism is “first crawl initial HTML, then execute JS”. If JS execution is too slow or content relies on client-side rendering, rich results cannot be generated.

Google Engineer Blog (2024) points out that ​​40% of dynamic pages have markup not crawled due to no pre-rendering

Dynamic Content Cannot Be Crawled

Googlebot’s crawling process has two steps:

1. ​​Download initial HTML​​: Get the page’s basic structure (without JS-generated content);
2. ​​Execute JS​​: Simulate browser running JS to get dynamic content (needs to wait for JS execution to complete).

But the crawler’s “patience” is limited:

• If JS execution exceeds 3 seconds, Googlebot may terminate early, causing dynamic markup not to be read (Lighthouse 2023 data);
• If content relies on “user interaction” (such as clicking “Load More”), crawler will skip this part of content.

​​Case​​: A news site built with React SPA, and the Article comment section is dynamically loaded by JS.

Testing tool showed “No rich results” – actual comment markup exists, but Googlebot didn’t complete JS execution during crawling, and comment content wasn’t included in the initial HTML.

3 High-frequency Problems

(1) SPA (Single Page Application): Initial HTML is empty, markup not included

SPA is “one page, dynamically replacing content”. Initial HTML is usually empty <div id="root"></div>, and all content is injected by JS.

If no pre-rendering is done, Googlebot’s crawled initial HTML contains no structured data, and markup naturally cannot be recognized. ​​Data​​: A travel website’s Tour markup generated by React, initial HTML is empty.

Search Console showed “No qualifying markup found”, and rich result display rate is 0. After fixing with ​server-side rendering (SSR)​, initial HTML directly contains complete Tour markup, and display rate increased from 0 to 28%.

(2) AJAX loading: Content asynchronously fetched, crawler didn’t wait for loading to complete

AJAX (Asynchronous JavaScript and XML) is used to dynamically load content (such as infinite-scrolling product lists, comments), but crawler won’t wait for AJAX requests to complete – if content loading time exceeds crawler’s “timeout threshold” (about 3 seconds), markup will be missed.

​​Case​​: An e-commerce platform’s “You might also like” product list loaded by AJAX, and Product markup is dynamically generated by JS.

Testing tool showed “Some markup was ignored” – Googlebot’s AJAX request wasn’t completed during crawling, and product information wasn’t included.

After fixing with ​pre-rendering​ tool (Prerender.io) to generate HTML containing complete product list, markup recognition rate increased from 60% to 95%.

(3) Lazy loading: Content triggered to display, exceeds crawler wait time

Lazy loading is used to optimize page speed, such as loading HowTo (instruction guide) steps, Recipe ingredient list when scrolled into view. However, if lazy loading delay is too long (such as exceeding 2 seconds), crawler may miss this content.

​​Data​​: A home furnishing website’s HowTo markup (such as “how to install bookshelf” steps) lazy loaded with 2 second delay.

Google testing tool prompted “Cannot recognize steps field” – crawler didn’t wait for loading to complete.

After fixing by shortening delay time to within 1 second, steps display rate increased from 18% to 43%.

Three Fix Methods

(1) Pre-rendering: Server generates complete HTML, crawler directly crawls

Pre-rendering means running JS on the server side to generate HTML containing complete dynamic content, then sending this HTML to the crawler.

Tools like Prerender.io or Nginx pre-rendering module can automatically identify crawler requests and return pre-rendered HTML.

​​Effect​​: After an e-commerce SPA used Prerender.io for pre-rendering, Product markup crawl success rate increased from 75% to 92%, and rich result display rate increased from 5% to 28%.

(2) Server-side rendering (SSR): Framework directly renders JS content

SSR means using frameworks like Next.js (React), Nuxt.js (Vue) to render JS components as HTML strings on the server side, then sending to client.

This way, the initial HTML contains complete markup, and crawler doesn’t need to wait for JS execution. ​​

Case​​: A news website refactored with Next.js, and Article comment section is generated by SSR.

Googlebot directly obtained comment’s Comment markup during crawling, Featured Snippet display rate increased from 10% to 50%, and comment interactions increased by 35%.

(3) Optimize JS execution time: Ensure markup loads within 3 seconds

If pre-rendering or SSR cannot be done, need to optimize JS execution time to ensure dynamic markup loads within 3 seconds.

Use Lighthouse or Chrome DevTools Performance tab to check markup loading time:

• Compress JS files: Use Webpack or Rollup to compress code, reduce file size;
• Lazy load non-critical JS: Set scripts that don’t affect markup (such as ads, analytics) to async or defer;
• Cache resources: Use CDN to cache JS files, reduce loading time.

​​Data​​: A media website optimized JS execution time from 4.2 seconds to 2.5 seconds, Googlebot crawl success rate increased from 68% to 90%, and Article rich result display rate increased by 22%.

Finally, I want to say: one line of correct JSON, one standard nesting, one timely pre-rendering, can all make rich media results go from “none” to “existent”.