Server-Side vs Client-Side Rendering for Doctor Profiles: A Googlebot Rendering Test

This post is for marketing and SEO teams at hospitals and clinic groups whose doctor profiles are built with a JavaScript framework, and who suspect that what a patient sees is not what a search engine receives. You do not need to be a developer to run the test described here, though you will need someone who can open browser developer tools and run a command line fetch.

The question is narrow: for each doctor profile, which fields exist in the HTML the server sends, which appear only after JavaScript runs, and which never appear at all in a rendered page? The fields that matter most on a profile are the doctor's name, specialty, qualifications, registration number, hospital and location, languages, consultation slots, and the structured data that describes them. If a field is missing from what Google processes, it cannot help the page rank and cannot support a rich result.

We describe a method, not a set of results. The point is that you can repeat it on your own pages in an afternoon and get an answer specific to your build.

How Google handles JavaScript pages

Google's JavaScript SEO basics describe three phases: crawling, rendering and indexing. A page with a 200 status code is queued for rendering, and the queue can take longer than a few seconds. Google's documentation also says that server-side or pre-rendering is still a good idea, because it makes sites faster for users and because not all bots can run JavaScript.

Several other points from that document bear directly on doctor profiles:

• Google discovers links only from <a> elements with an href attribute. A "Book appointment" or "View profile" button wired up with a click handler is not a link to a crawler.
• Titles and meta descriptions can be set with JavaScript, but a canonical tag injected by JavaScript must agree with any canonical in the original HTML, and there should be only one.
• If a page carries noindex in the original HTML, Google may skip rendering, so JavaScript that removes the tag later may never run.
• Content on pages or in files blocked by robots.txt is not rendered. If your profile data comes from an API path that is disallowed, the rendered page will be empty of it.
• Client-side routed apps should return a real 404 status for missing pages, or redirect to a URL that does, to avoid soft 404s.

None of this means client-side rendering never works. Google does render JavaScript. It means that every dependency in the chain is a place the page can fail without anyone noticing.

The test: raw HTML against rendered DOM

Pick 20 doctor profiles. Choose them deliberately: a mix of departments, a few doctors with long biographies, a few with many locations, at least two who were recently added, and at least two with no photograph. If the site has more than one template, such as a flagship hospital and a satellite clinic, include both.

For each URL, capture three views.

View 1: the raw HTML. This is what the server sends before any script executes. Use a command line fetch (curl -s -A "Mozilla/5.0" URL > raw.html) or view-source in the browser. Do not use the Elements panel of developer tools for this; that shows the live DOM after scripts run, which is a different thing.

View 2: the rendered DOM as Google sees it. In Search Console, run the URL Inspection tool on the live URL and open the rendered HTML and screenshot. The Rich Results Test also shows the rendered HTML Google retrieved and any structured data it parsed. These tools use Google's own renderer and are the closest public view of what the indexer receives.

View 3: your own browser, without interaction. Load the page with a clean profile, wait for the network to settle, and save the DOM. This shows what a patient sees without clicking any tabs, which is the baseline for what a renderer that does not click anything could see.

Then compare the three in a spreadsheet with one row per field and one column per view.

The field-by-field checklist

Colour the cells: green if the field is in the raw HTML, amber if it only appears in the rendered view, red if it is absent from both. The red and amber cells are your work list.

Reading the pattern across 20 pages

A single page tells you little. The pattern across 20 tells you which part of the system is responsible.

Everything is amber. The whole profile is built on the client. Google can probably read it, but you depend on the render queue and on every API call succeeding. Moving the main content to server rendering is the structural fix.

Core fields are green, secondary fields are amber or red. This is a hybrid build. Look at which fields are deferred. Slots and reviews are reasonable to load client-side because they change often. Registration number, qualifications and specialty are not.

Some pages are green and others red. The inconsistency often points to data. Profiles with a field missing in the content system render an empty block, so a gap in the CMS shows up as a gap in the HTML. Check whether the red pages share a department or an import batch.

Raw and rendered disagree on canonical or robots. This is the most serious pattern. If the raw HTML says one thing and the rendered DOM says another, Google may take either, depending on which version it processes. Fix the template so the first response is correct.

The Search Console render is empty but your browser's is full. Check whether the scripts or API endpoints are blocked by robots.txt, require a cookie, fail on a geographic restriction, or time out. Compare the "More info" section for resources Google could not load.

Why registration number and specialty are the fields to protect

A doctor profile is a trust page. A patient or a referring doctor wants to confirm that the person is registered, with which council, and in which specialty. If the registration number only appears after a script, a click or a call that fails in the renderer, the page loses the clearest trust signal it has.

There is also a compliance angle. In India, the details shown about a doctor should match what the doctor has approved and what the registration record supports. Keep that content in one source and render it from that source on the server, so there is no second copy that can drift. The clinical and compliance owners should approve any change to what the profile claims; see the NMC compliance handbook for the wider rules on doctor communications.

Fixes, in order of effort

1. Return core content in the first response. Server rendering, static generation or incremental regeneration are all acceptable, provided the first HTML contains the name, specialty, qualifications, registration number, location and links. In a framework such as Next.js, this means fetching profile data in a server component or at build time rather than in an effect after mount.
2. Replace click handlers with anchors. Every link that should be crawled needs an href.
3. Expand collapsed content in the DOM. Accordions and tabs are fine for users, but the text must be in the HTML even when visually collapsed.
4. Make structured data come from the same source as the visible text. Generate JSON-LD on the server from the same fields as the page, so the two cannot disagree.
5. Return correct status codes. Unknown profile slugs should produce 404, not an empty 200 template.
6. Do not block the data. Remove robots.txt disallow rules on the script and API paths the page needs to render.
7. Keep live data client-side if you want. Slots, wait times and "available today" can load after render, since they change often. Put a static sentence about how to book beside them.

For the rest of the technical audit, including crawl and index checks, our technical SEO audit page lists what we review, and the schema markup service covers the structured data side of the same fields. If the profile pages feed a wider department structure, our post on building an SEO strategy for every hospital department sets out how profiles connect to service lines.

What to do after the test

• Record the date, the 20 URLs, the three views and the colour table in a shared document.
• Hand the red and amber rows to the development team as tickets with the URL, the field and the view in which it was missing.
• Retest the same 20 URLs after the release, and add five new ones.
• Add the comparison to your release checklist, so a new template is checked before launch rather than after traffic drops.
• Keep an eye on Search Console's page indexing report for "Crawled, currently not indexed" and soft 404 groups on profile URLs, which often follow a rendering regression.

The rendering test is cheap, and it removes an argument. Instead of debating whether Google "can handle JavaScript", you compare two files and see which fields are in them.