JavaScript SEO: Server Rendering and Indexing Explained

The process has roughly three steps. The search engine crawls the address and receives the raw HTML, the page joins a rendering queue, and when its turn comes the JavaScript is run to produce the final page, which is then indexed. Google does this rendering with a current browser engine, but the step is separate and a wait can sit in between.

A page with nothing in its raw HTML therefore looks empty at first glance. The content arrives later, but queue time varies from page to page. For a news or stock page that changes often, that wait means the content shows up late.

Not every search engine or AI crawler renders equally well. Some run no JavaScript at all, or only part of it. Content that appears only after rendering puts at risk not one search engine but every tool that reads your site.

With client rendering the server sends an empty page shell and the browser builds the content with JavaScript. With server rendering the page is prepared on the server at request time and arrives full; JavaScript then takes over interaction in the browser. With pre-building, the page is generated once at publishing time and served as a ready file.

For pages that rarely change, pre-building is the fastest and sturdiest option: company pages, service pages, articles. Pages carrying price, stock or personalised data suit server rendering better. Areas search engines should not see anyway, such as a logged-in dashboard, can happily use client rendering.

Most modern frameworks let you mix all three on one site. The decision is made per page type; you do not have to pick a single method for everything.

The simplest test is to view the page source. If you can see the title, the main text and the links, there is no basic problem. If you see only an empty root element and script tags, the content is being built in the browser.

The second test is the URL inspection tool in Google Search Console, which shows the HTML received and the page as the search engine sees it after rendering. Any gap between the real page and the rendered one appears there. You can also check your titles, descriptions and content structure quickly with our free on-page SEO audit.

The third sign is in the index reports: many pages marked as crawled but currently not indexed, or results whose title and description do not match the real content, can point to a rendering problem.

• Are the main text and links visible in the page source
• Does the rendered HTML in URL inspection match the real page
• Are the title and meta description in the first HTML, or added later
• Are menus and in-page links built with real link tags
• Are script and style files blocked by robots.txt

The most common mistake is building links from elements that work on a click event rather than real link tags. Search engines follow only links that carry an address; a structure where a button changes the page stops those pages from being discovered. A related fault is putting pages behind a hash fragment in the address, which squeezes separate pages into one URL.

The second is tying content to user interaction. Content that loads when someone clicks a tab, scrolls down or presses a show more button is content the search engine does not see. The core text of a page should never sit behind such interactions.

The third is blocking script and style files in robots.txt, which stops the search engine rendering the page and leads it to misread layout or content. The fourth is failing to return a proper error status for pages that do not exist: single page apps can answer an invalid address with a success code and a page not found message, and the search engine takes it for a real page and tries to index it.

They can, with the risk understood. Google can read titles and meta tags after rendering, but if they are missing from the first HTML, not every crawler or social preview tool will see them. An empty preview card when a link is shared is often caused by exactly this.

The same logic applies to structured data. You can add it with JavaScript, but having it in the first HTML is safer and carries fewer dependencies. Critical tags such as the canonical address and robots directive belong in the first HTML; a directive changed after rendering can contradict the value the search engine read first.

This area changes fast and there is no single answer. The crawlers used by AI assistants and search summaries generally do not render as capably as a classic search engine, and some settle for raw HTML. Keeping important content in the first HTML is therefore the safest route for every likely reader.

If you are aiming for AI visibility, put the page's main answer and core facts in server-rendered HTML. You can test how your site appears to these tools with our free AI visibility check.

Not every JavaScript site needs rewriting. A customer portal, a booking tool or an application behind a login does not need search traffic, so client rendering is enough. You would want to keep those areas out of search anyway.

If your current site shows content in the page source, uses real link tags and URL inspection raises no concerns, there is no reason to change the rendering method. Rebuilding a working setup out of search worries creates new faults. Measure first, then decide.