Why does a crawler get only empty divs when the body text looks fine in the browser in 2026—is JavaScript adding that text?

Body text that reads fine in the browser but appears as empty divs in the HTML a crawler receives is usually not a “rendering method chosen wrongly” problem; rather, above-the-fold body content, discoverable links, and independent URLs exist only in the browser. In practice in 2026, both Google and Baidu execute some JavaScript, but rendering has to queue and consumes crawl budget, and new and small sites are more likely to stop at the stage where only the empty shell is crawled. Based on delivery experience, completing the three checks first and filling in source readability and entry-point discoverability commonly costs an order of magnitude less than changing the rendering approach.

The HTML a crawler gets is an empty shell—at which step is the body text lost?

First separate crawling from rendering: the crawler first gets the HTML returned by the server, then decides whether to put the page into the rendering queue to execute scripts. Queuing introduces delay and has a budget cap; the more pages there are and the heavier the scripts, the more likely only the first half of the process is completed. So “users can see it in the browser” and “engines can read it” are two different conclusions, and the former cannot be used to infer the latter.

The differences between the two engines come down to three checkable points

• Rendering trigger: Google sends a substantial share of pages to its rendering service, and crawling and rendering may happen in two separate passes; Baidu’s coverage of JS rendering depends more on page authority and crawl quota, so new sites are more likely to get only the initial HTML.
• Queue time: For pages whose above-the-fold content must wait for an API response and whose body text appears only after a few seconds, both engines may judge the above-the-fold area as having no valid content.
• Verification method: Both search resource platforms provide crawl diagnostics and URL inspection tools that show the crawled HTML and the rendered HTML, with differences written directly in the report—more reliable than guessing.

One more point: betting “whether it gets indexed” on the other party’s rendering budget is inherently uncontrollable. In public documentation, Google has long advised that critical content should not appear only after script execution, and Baidu also emphasizes that important content should be readable in the source code where possible. Both are improving, but for new sites, this uncertainty is not worth gambling on.

Run the three visibility checks in order before making changes

Rather than debating engine capabilities, run a self-check in a fixed order: check the source, check rendering, and check entry points. The order cannot be reversed, because each step down noticeably raises the cost of change—copy and small structural edits can be done the same day, build changes require scheduling, and framework changes require a round of regression.

1. Check the source: Open the page source and search for the core above-the-fold copy. If it cannot be found, the initial HTML has no body text, and this is the layer to fix first. Experience range: the main above-the-fold heading, the first 100–200 characters of body text, and main section names should be directly readable in the source.
2. Check rendering: Disable JS in the browser and look again. If only a logo and empty containers remain, the content depends entirely on scripts. Minimum bar: with JS off, core information and at least one set of internal links are still readable.
3. Check entry points: Check whether lists, detail pages, and pagination link to each other with real anchor tags (a div with onclick does not count). Minimum bar: main section pages are reachable within three clicks from the home page, and the links are visible in the source.

The third step is often missed. Some teams add SSR for above-the-fold content, but internal links are still button-based navigation; pages can render yet are not discovered, and indexing still does not move. The value of the three checks is to separate “cannot render” from “not discovered,” avoiding a framework change at the outset only to find after the work that the problem was not there.

Four approaches side by side: where do the costs differ?

Choose an approach only after confirming that the build must change; choose by page scale and update frequency, not by framework popularity. The timelines below are experience ranges and are affected by page count, data dependencies, and the deployment environment, so variation can be large.

• CSR with an above-the-fold skeleton: Smallest change; suitable for post-login systems, admin back ends, and low-frequency marketing pages. It basically does not solve the problem for public content pages; it only gives the empty shell a different shape.
• SSG prerendering: Generates static HTML at build time; suitable for official sites, campaign pages, help centers, and similar content that updates infrequently. The onboarding experience range is commonly 2–8 person-days, at the cost of build time growing with page count.
• SSR (server-side rendering): Above-the-fold content served directly and real-time data; suitable for public pages that update frequently, such as product detail pages and news lists. The typical range for the change is 1–4 weeks, plus caching, fallbacks, and operations.
• Dynamic rendering with UA-based routing: Returns a static version only to crawlers. Google’s public documentation states that it is a stopgap and not recommended as a long-term dependency; there is also risk in users and crawlers seeing different pages, so it is generally only for temporary emergencies.

One caveat: SSR only solves above-the-fold visibility, not content quality or internal-link structure. If a site with no internal links and thin body text is moved to SSR, indexing will most likely not change noticeably. The sensible order is content and structure → entry points and URLs → rendering method; reversing it easily wastes budget.

Delivery case: the rework after launching first and adding SEO later

A typical constraint: the client required launching first and adding SEO later, the data came from a third-party CMS, the integration window was only two weeks, and the field definitions were still unresolved on their side. The approach was to pick two low-risk tasks first: the list page output static entry links from the server, the detail page used prerendering to generate above-the-fold body text, and the build script reused the existing pipeline without adding a new server. After launch, body snippets began appearing on Google within two to three weeks, while Baidu still indexed only titles.

Later investigation found that detail-page URLs carried a string of parameters, and the site had no anchor-tag interlinking; in effect, pages could render but could not be discovered. Improvement came only after adding static paths and a sitemap, costing about 5–8 person-days of rework; this number varies considerably across projects, with a typical range of roughly 3–10 person-days depending on page count and parameter structure. The real cost is not technical but scheduling: changing the build means going through testing, regression, and release windows again.

Applicability and non-applicability boundaries

Sites suitable for this round of changes: Official sites targeting public search traffic, product and news detail pages, help centers, and campaign landing pages—pages whose content has search value and whose URLs can be shared independently. For these pages, one change can often bring traffic to a group of pages, and the ROI is relatively clear.

Those that do not need it: Post-login admin systems, highly interactive tool pages, and pages whose content all comes from private user data do not need to be indexed by search engines in the first place; spending SSR cost there is a waste. For sites with very low traffic and content that rarely changes, static generation and internal linking are usually more cost-effective than adopting SSR, and lighter to maintain.

There is another case where you should stop first: If the body text is thin and highly homogeneous, or independent URLs cannot be obtained (for example, everything runs through route parameters plus hash), changing rendering at this point means putting budget in the wrong place; fix content and URL structure first.

Common questions

If the body text is invisible with JS disabled, is SSR mandatory?

Not necessarily. For sites whose content updates infrequently, prerendering or static generation is enough; SSR is more suitable only when detail pages update frequently and above-the-fold content must be served directly.

Will an above-the-fold skeleton be treated as an empty page?

It can be, which means leaving the judgment to the engine. Beyond the skeleton, keep a static piece of core copy or explanatory text so the initial HTML already contains readable content.

Does returning static HTML only to search engines still work?

It is a stopgap. Google does not recommend relying on it long term, and there is also risk when users and crawlers see different pages; if you can prerender, do not stay on this path long term.

Can changing only the title and description fix indexing?

Limited effect. The title is an entry point, not content; when body text is not readable in the source, title changes usually bring little change. Adding body text and links first is more practical.

If you have a set of pages that look normal in the browser but come back as empty shells in the crawled HTML, run the three checks first, fill in source readability and entry-point discoverability, and then evaluate whether the build needs to change. This sequence fits teams that have public content pages and are willing to invest one or two iterations; for purely internal systems or single pages that almost never update, static generation and internal linking are enough.