It's 2026 and the page title isn't in the source code — where does Baidu get the indexed title?

If a page title is not visible in the browser's “View page source” (Ctrl+U) and is instead written by JS after mount, the initial HTML Baidu crawls usually still contains the template default or even an empty value. Google mostly queues JS execution and then reads the DOM again; Baidu is more conservative in its JS rendering coverage and delay, so the same code often produces “Google shows the right title, Baidu shows the default one”. As of 2026 delivery practice, pages meant to be indexed should have title, description and canonical server-rendered in the initial HTML, with JS writes used only as enhancement.

What's the difference between server-rendered HTML and the rendered DOM

Crawling a page usually happens in two steps: request the server and get the raw HTML, then — when rendering is available — execute the page's JS and get the rendered DOM. The problem is that the two can be two different pages: the initial HTML depends on what the server or the build step emitted, and the rendered DOM depends on the result after the front-end scripts run.

TDK is the easiest thing to fall into this gap, because many projects change document.title and meta tags with JS on route change. It looks perfectly correct in the browser, but the initial HTML often still holds the template default.

• Fields that should be server-rendered first: above-the-fold title, description, canonical
• Used for topic judgement: h1 and the key paragraphs of above-the-fold body copy
• Used for discovery entry points: a tags pointing to detail pages and pagination — hrefs must be genuinely clickable, not buttons with JS navigation

What happens to indexing and clicks if you don't server-render

Title is the main copy in search results, description affects willingness to click, and canonical affects how multi-URL content is aggregated. If these three only appear after rendering, you are handing the display slot back to the platform's default policy: some platforms grab the first paragraph of text on the page to assemble a title, others just use the site name as a placeholder.

The more practical impact is the cost of judgement. Baidu's JS rendering coverage and delay have historically been more conservative than Google's; Google does execute JS, but rendering is queued and doesn't happen immediately on every crawl. Dynamic writes only count as enhancement; they can't rescue the path that depends entirely on the initial HTML.

• Result title out of control: the platform assembles it itself, so the position and length of brand terms are unpredictable
• Snippet off-topic: when description is missing the platform cuts the first paragraph, often pulling in navigation text
• Unstable aggregation: canonical written late makes multi-parameter, multi-sort URLs harder to consolidate

Comparing approaches: from pure CSR to isomorphic SSR

Ordered by effort versus payoff, there are four common paths in 2026 projects. The timelines are only experience ranges; actual differences come mainly from the number of templates, whether a build pipeline already exists, and whether you need to handle login state and caching.

• Pure front-end JS injection of TDK: changes stay in the component layer, experience range 0.5–2 person-days (site level); only suitable for post-login pages and admin backends — don't count on indexing.
• Build-time prerendering (prerender / static generation): writes TDK and above-the-fold content into static HTML, experience range 2–8 person-days depending on template count and route parameter complexity; suitable for sites with limited routes and relatively static content.
• Server-side or template-layer injection: modify backend templates or a Node layer, experience range 1–5 person-days; suitable for sites that already have server-side rendering capability, and usually the smallest change surface.
• Isomorphic SSR: experience range 1–4 weeks (including integration testing, caching and fallback changes); suitable for sites with large content volume, real-time data and above-the-fold requirements, at the cost of higher ops and troubleshooting complexity.

You don't have to pick one across the board: within the same site, prerendering entry pages while keeping the admin backend on CSR is a very common combination.

Where it applies and where it doesn't

The test is straightforward: does this page expect traffic from search results? If yes, it's worth server-rendering for it; if no, doing so is pure added cost.

• Worth doing: article pages, product detail pages, help centres and FAQs, explainer campaign pages, paginated list pages
• Not needed: admin backends, data dashboards, internal tools, content visible only after login
• Can be deferred: one-off pages with a very short lifecycle that spread mainly via shared links — a short link or a separate landing page can carry them

If a page doesn't need to be entered from search, adding SSR or prerendering to it is unnecessary investment; don't rebuild the whole site just for “architectural consistency” — making the real entry pages solid first pays off more.

In delivery: one missed prerender config, and the price was another round of revisions

In one delivery with a tight budget, the client only provided APIs, gave no time for template-layer changes, compressed the timeline to under two weeks, and still required the body copy to stay consistent with backend content. Our approach was build-time prerendering for article pages and product detail pages, writing TDK and above-the-fold copy into static HTML, keeping the list pages on client rendering, and only swapping pagination entry points for real a links. After launch, indexed volume grew slowly, and the growth rate depends heavily on domain history — not something to present as any kind of promise; the cost is that every new detail route type requires revisiting the prerender config, and the one time it was missed, a batch of pages kept being crawled with default titles, which meant another round of revisions.

As an experience range, template-level pages usually cover 10–30 templates to capture most of the entry-point benefit. For acceptance, sample 5–10 representative URLs (home page, list page, two detail pages with parameters, one list page with filter parameters), check the source of each with Ctrl+U, confirm the target title, description and canonical are all in the HTML, then verify once more with the platform's crawl tool. This checklist can go into the delivery documentation as a pre-launch verification step.

FAQ

Google executes JS, so do I still need to worry about server-rendering?

Executing doesn't mean it executes every time, or in time. Rendering is queued and crawl budget is limited; server-rendering key fields costs far less than troubleshooting indexing anomalies after the fact.

If I change the title with a front-end head management library, does that count as server-rendering?

No. Those libraries only change the DOM in the browser; the initial HTML is still the default value. It only counts as server-rendering if the same head data is also rendered on the server or at build time.

If the home page has a hard-coded title and inner pages change theirs with JS, does it matter much?

The impact is mainly on inner pages. Most search traffic lands on detail and article pages; when inner-page titles are missing, the result page title is assembled by the platform and its quality is unpredictable.

How do I quickly tell whether a page is server-rendered?

Press Ctrl+U to view the source and search for title, description, canonical and above-the-fold keywords. If they're not in the source, it isn't server-rendered — seeing them in F12 doesn't count.

With a limited budget, which pages should I change first?

Sort by traffic and prioritise template-level pages such as detail pages, article pages and product pages; covering 10–30 templates usually captures most of the entry-point benefit. Do the templates first before talking about going site-wide.

If you're going to act, first run an above-the-fold server-render check, turn the difference list into a table, then prioritise templates by traffic. Sites with large content volume and real-time data can consider isomorphic SSR; sites with limited routes and fairly static content are usually better off with build-time prerendering. Pure admin backends and post-login pages don't need this investment — save the budget for the real entry pages.