Generating page HTML on the server for a request before sending it to the browser.
Server-side rendering generates page HTML on the server in response to a request before sending it to the browser. This allows the response to contain meaningful page content rather than relying entirely on browser-side code to assemble it.
SSR is a rendering strategy, not a claim that a page has no JavaScript. A site can deliver initial HTML from the server and still use scripts for interactive behavior afterward. Caching may also affect how responses are served, so the architecture needs to be understood rather than inferred from a marketing label.
Request-time work can be appropriate when the response depends on frequently changing information. It also creates operational considerations: the server and data sources need to return the correct content reliably. A server-rendered error, empty page or wrong canonical remains a problem even though HTML was generated on the server.
Takeaway: Discuss SSR in terms of the page’s content and update requirements. Ask what is delivered in the initial response, how it stays accurate and how failures are handled rather than expecting an automatic ranking gain.
Example
A course directory needs current availability from a backend system. A request-time implementation could include that information in its HTML response. If the backend fails, the team needs a deliberate response strategy; a blank availability section is not solved simply by saying the page uses SSR.
What to check
Inspect the returned HTML and rendered page, including status codes and metadata. Consider server load, data dependencies and caching with the developer. Choose the strategy that supports the application’s requirements, and evaluate search accessibility separately from a guarantee of indexation or rankings.
For more detail, see Next.js server-side rendering.