Rendering SEO

If you asked me today which rendering strategy to pick, I'd say static site generation (SSG) for any page where content is mostly stable, and server-side rendering (SSR) for pages that need real-time personalisation or user-specific data. Client-side rendering (CSR) still works, but it adds risk that you don't need to carry. Here is a concrete example. I recently audited a travel review site built with React (CSR). The homepage loaded fine in a browser, but the rendered HTML in Search Console contained no <h1>, no meta description, and only one internal link. The page depended on an API call that sometimes timed out. Of the 50,000 pages in the sitemap, only 18% were showing as indexed with a meaningful title. The rest were either not indexed or showing a generic error message. I recommended moving to SSG with a static site generator, and within two months indexation climbed to 76%. The reduction in crawl waste alone saved about 300,000 Googlebot requests per month.

When you audit your own site, start by comparing the source HTML (view page source) with the rendered DOM (inspect in Chrome DevTools or use Search Console's URL inspection). If critical text, links, or schema markup appear only in the rendered DOM, you have a problem. Your next move is to pull those elements into the initial server response. For [Technical SEO](/technical-seo/) teams, this often means working with developers to implement a pre-render step or adopting a framework like Next.js that gives you SSR and SSG options out of the box. Prioritise the content that matters most to search: product titles, prices, breadcrumbs, canonical references, and structured data. Analytics scripts and chat widgets can wait.

One decision rule I use: if the page is primarily informational (a blog post, a category page, a product description), go SSG. If the page shows different content based on the user's location or login status, go SSR. If you must use CSR, then invest in a pre-rendering service that serves a static HTML snapshot to crawlers while your JavaScript loads for users. I have used this approach for a large marketplace where client-side interactivity was non-negotiable, and it kept indexation rates above 90%.

The biggest trap is assuming that because a page looks correct in your browser, Google sees the same thing. Always check the rendered HTML in Search Console or a tool like Sitebulb. I once saw a site where every product page had a robots meta tag injected by JavaScript that set "noindex" on Mondays because of a cron-related bug. Google had been de-indexing those pages every week for six months.

Never inject canonical tags, meta descriptions, or <title> elements via JavaScript. These signals must be present in the initial HTML to be reliable. If Googlebot encounters a <link rel="canonical" /> that was added after the JavaScript runs, it may ignore it or apply it inconsistently. I have seen this cause [duplicate content](/duplicate-content/) problems that took weeks to unwind.

Dynamic rendering is another watch-out. It serves a different HTML version to crawlers than to users. Google's official guidance treats dynamic rendering as a workaround, not a best practice. It can introduce consistency errors—a bot might see a fully loaded page while a user gets a broken interactive app—and it raises the risk of being perceived as cloaking. If you use it, keep the bot-version as close to the user-version as possible and test regularly with the "Fetch as Google" tool.

Finally, soft 404s are common with JavaScript-heavy pages. A single-page app that catches a broken route and shows an empty state instead of a true 404 status code can trick crawlers into seeing thousands of soft 404s. Use proper HTTP status codes on error states. For [Pagination](/pagination/) or infinite scroll, ensure your rendered output includes <link rel="next"> or <link rel="prev"> in the initial HTML, not after a JS interaction. If your page depends on [Core Web Vitals](/core-web-vitals/) scores, remember that rendering delays increase Largest Contentful Paint (LCP) and can hurt your ranking eligibility.

When I started out, I believed the line that Google could handle JavaScript just fine. I built a client's entire site with React, no SSR, no pre-rendering. I tested in a browser, it looked perfect, and I shipped it. Two months later, Search Console showed that only 30% of their pages were indexed. The others were blank. The problem? A third-party analytics script was failing silently in Googlebot's headless browser, and the entire page render depended on that script's callback. I had never tested with JavaScript off. Now I do it as a standard step: open the page with JavaScript disabled in Chrome DevTools and see what's left. If there's no text, no links, no heading, the page is invisible to a crawler.

Another mistake: I used dynamic rendering as a permanent solution because it was easy to configure on a CDN. Google sent a manual action warning about inconsistent content. The bot-version was a clean static page, but the user-version loaded a heavy interactive dashboard with different text. We had to rebuild the entire front end in a year to switch to SSR. If you are using dynamic rendering today, start planning your migration to SSG or SSR now.

I also overlooked the importance of checking structured data in the rendered output. I added [Schema Markup](/schema-markup/) to the source code, but a JavaScript function was stripping it out before rendering. Search Console showed "missing field" errors for six weeks before I caught it. Now I always validate schema against the rendered HTML, not the source. That single check probably saved me from another manual action.