Static vs dynamic websites: SSG, SSR and what to choose

A static website serves files generated in advance, without rebuilding them for each visitor. A dynamic website generates or adapts content from data at request time. That processing can happen server-side, while additional dynamic behavior can also happen in the browser.

The static vs dynamic website question is primarily about when and where content is produced. Who can edit and approve that content is a separate CMS and governance question. That difference drives hosting cost, the publishing chain, personalization and how much infrastructure there is to secure. This article compares the two against the canonical definitions from MDN and AWS, shows how to tell which one you are looking at, and explains where modern rendering modes fit.

Three things get mixed up in this debate, and separating them avoids most of the confusion. The rendering mode, static or dynamic, decides when the content is produced. The CMS provides editorial management, meaning the interface, the rights and the approval workflows. The DXP adds what more complex experiences need, customer data, personalization and integrations. A static site can perfectly well be driven by a CMS, and a dynamic site can have none at all.

The canonical definitions, and how they differ

MDN and AWS provide two useful definitions of the distinction, with slightly different emphasis. MDN defines a static site by what the server returns, AWS by whether server-side code runs.

Source	Static website	Dynamic website
MDN	"a static site is one that returns the same hard-coded content from the server whenever a particular resource is requested"	Part of the response is generated only when needed, by inserting data from a database into HTML templates
AWS	"A static website delivers content in the same format in which it is stored. No server-side code execution is required."	Displays dynamic or personalized content, interacts with data sources and web services, and needs development skills to build and maintain

They agree on the substance and diverge on what they emphasize next. MDN goes on to describe the architecture, while AWS goes on to the skills and the running cost, noting that dynamic sites require development expertise to build and maintain. One caveat worth knowing before quoting AWS. That whitepaper was published in May 2021, it carries a "historical reference only" banner, and AWS has not refreshed it since.

What is a Static Website?

A static website is made of HTML files prepared in advance, which the server hands over unchanged. No server-side code runs when the page is requested, and every visitor receives the same file.

Each page is written and saved in advance, and changing it means changing the source, or republishing from whatever produced it. To serve pages to visitors, a static site does not need to query a database or run an application server on every request, which generally allows a simpler delivery infrastructure. A database or a CMS can still be involved at build time.

What a static site is good for:

• Portfolios and presentation sites, where content changes a few times a year.
• Marketing sites and landing pages, published once and left alone.
• Event and campaign pages with a short life.
• Technical documentation generated from source files, where formatting is automated but the content is the same for everyone.

In all four, the content can be prepared in advance and served without application processing on every visit.

Its three real limits:

• No server-side personalization in a purely static setup, since the file served is the same for everyone. JavaScript can adapt the display in the browser, but the page received is identical.
• No editorial autonomy without tooling. Publishing means editing the source files, unless a static site generator is wired to a headless CMS, which hands editing back to a non-technical team at the cost of a publishing chain to build and run.
• A purely static site does not handle authentication, form persistence or user accounts on its own. Those need server-side services, APIs or serverless functions, which the organization can perfectly well run itself.

What is a Dynamic Website?

A dynamic website assembles or adapts all or part of its content from data held in a database, CMS, API or another business system. That processing can happen server-side, client-side, or through a combination of both. What the page shows can vary with stock, with a search, with the time of day, or with the profile and rights of the signed-in person.

In a dynamic architecture with server-side rendering, a request not served by the cache triggers processing. The server runs code, queries its content source, assembles the HTML and sends it. That is a common pattern for e-commerce platforms, authenticated portals and some enterprise web applications.

What dynamic rendering allows and a file served as-is does not:

• Making updated content available without necessarily regenerating every page of the site.
• Computing or fetching information at the moment of the visit: stock, a price, a due date, a search result.
• Deciding server-side what each visitor receives, by profile, rights or language, which is the basis of a personalized experience.
• Holding state server-side: sessions, accounts, rights, data submitted through a form.

All four rest on the same thing: being able to run application logic and query data at the moment it is needed.

What it costs:

• More application components or services to run, depending on the architecture you choose.
• Extra processing, which can lengthen the response time if caching and queries are not optimized.
• A wider surface to secure, since code and data are exposed and not only files.

Those components therefore add operational, performance and security requirements.

Static vs. Dynamic Website

Here is the static vs dynamic website comparison, criterion by criterion.

Criterion	Static website	Dynamic website
When the content is produced	Before the visit, at build time	At request time on the server, or subsequently in the browser depending on the architecture
Content source queried on request	None server-side, possible from the browser in JavaScript	Database, CMS, API or business system
Content updates	Editing the sources, or publishing from a CMS with a generation step	Depends on the architecture. With a CMS, publishing from an editorial interface
Personalization	Possible through JavaScript or complementary services	Can be handled server-side from context, profile or rights
Authenticated area	Possible through complementary services or APIs	Can be handled by the application server-side
Hosting cost	Generally very low, plain files to serve	Varies with the processing, the data and the infrastructure
Serving the pages	Generally simple to serve, and easy to distribute through a CDN	Depends on caching and queries
Surface to secure	Narrow server-side, but any API the browser calls still needs securing	Wider, code and data included
Best for	Brochure sites, portfolios, documentation	Portals, authenticated areas, e-commerce, business applications

Neither column is better than the other. The way to read this static vs dynamic website table is to identify which functions need processing on demand, and which can be prepared in advance.

How to tell whether a site is static or dynamic

Load the same page signed out, then signed in. If the content changes, something beyond a pre-built file is at work, either the server or the browser. If it does not, the test is inconclusive, because a dynamic CMS serves most of its pages identically to everyone. Three further checks narrow it down.

• View the raw source, not the rendered page. Fetch the URL without running JavaScript. If the content you see in the browser is missing from that response, the browser is assembling it, whatever the server does.
• Read the response headers. Response headers such as session cookies or Cache-Control: private can provide clues that personalized or stateful processing is involved, but they do not prove how the page itself was rendered.
• Look for a signed-in area, a cart or a persistent form. All three mean a server is involved somewhere. They do not prove the page itself is built on request, since a statically generated site can call a third-party service from the browser for all of them.

No single check settles it, and that is the point: the static vs dynamic website binary describes how a page is built, not how it behaves.

Beyond the binary: SSG, SSR, ISR, edge and client-side rendering

Many sites in production are neither purely static nor purely dynamic. What decides their behavior is the rendering mode, and five common rendering approaches cover many modern web use cases.

Rendering mode	When the page is built	Good for	What it costs
SSG, static generation	At build time	Documentation, marketing pages and content that can be generated in advance	Content changes require regeneration or redeployment, depending on the build system
SSR, server-side rendering	On request, on the server, subject to caching	Signed-in areas, prices, anything that depends on the visitor	Server-side compute and infrastructure to operate
ISR, incremental regeneration (Next.js)	At build time, then refreshed page by page	Large catalogs that change often but not per visitor	Cache invalidation and revalidation logic to manage
Edge rendering	On request, close to the visitor	Geographic or lightweight personalization at scale	A constrained runtime and harder debugging
CSR, client-side rendering	In the browser, after the page loads	Applications behind a login, dashboards	More work in the browser, with potential performance and crawlability considerations

A single page often combines two of them, with a mostly pre-rendered shell and a few zones built on request. This hybrid approach buys flexibility, but it asks you to master several rendering, caching and deployment strategies.

Dynamic Website examples

A banking or insurance customer area, a supplier extranet, a government services portal and an e-commerce catalog are the classic examples of dynamic websites. What they share is that all or part of the content is produced from data that changes, or from the context of the request. It can therefore vary with the signed-in person, their rights, a search, stock or other business data, without being personalized at all.

Netflix and Spotify illustrate personalization well, one tailoring recommendations to viewing habits, the other playlists to each listener. Their real architecture is far more complex than a page assembled on every request, and it proves nothing about the rendering mode. In the enterprise, the cases are less visible.

• An insurance or banking customer area, where contracts, due dates and documents differ for every signed-in person.
• A government or local authority portal, where the services offered depend on the user's profile and location.
• A partner or supplier extranet, where prices, orders and contractual documents vary by account, with distinct rights per user.
• An internal search engine or a comparison tool, where the page depends on the query typed, not on who typed it.
• An e-commerce catalog, where stock, prices and recommendations change constantly.

Static rendering suits cases where the main content can be generated in advance and does not need recomputing on every visit.

What are the benefits of dynamic websites over static?

In the static vs dynamic website trade-off, one of the main draws of a dynamic architecture paired with a CMS is being able to manage and publish large volumes of content from an editorial interface. That autonomy comes from the CMS, not from dynamic rendering on its own.

• Publishing without depending on engineering. A price correction or a news item goes live in minutes from an editing interface, once a CMS is in place.
• Personalizing what is displayed. Content adapts to profile, rights, language or behavior, which an identical file cannot do server-side.
• Opening authenticated areas. Accounts, persistent forms and case tracking need server-side processing and persistence. The page that displays them can itself be static, dynamic or hybrid.
• Publishing at scale. With a CMS, adding or updating hundreds of pages without touching code becomes possible, which matters when content is what brings the audience. That is a production advantage rather than a ranking one.

Depending on the architecture, these capabilities add application components, data and services to run and to secure. They only materialize if someone actually runs the platform day to day.

Which one should you choose?

The choice depends less on how often you publish than on what the pages have to do. Static rendering works well when pages can be generated in advance. A dynamic architecture earns its keep when some information has to be computed or fetched at the moment of the visit, by signed-in user, rights, a search, stock or business data.

Three questions settle the static vs dynamic website decision.

• How often does the content change, and who changes it? If a non-technical team has to publish often, you need an editorial interface, whether it drives a dynamic site or a static site generator wired to a headless CMS.
• Does any information have to be computed or fetched at the moment of the visit? A signed-in state, a price, stock, a search result. If so, dynamic, at least for that part.
• Neither? Static rendering is enough for the published content, even if other technical constraints may justify an application platform anyway.

The rendering mode is an architecture decision. Editorial governance, multisite and multilingual estates, rights, integrations and customer data are a different decision, the one about the content platform. Our Jahia Digital Experience Platform (DXP) is built for that second one. Jahia DXP builds on our CMS foundation with customer data activation, personalization, integrations and experience optimization. Together they give businesses an advanced content management system that goes beyond just creating web pages.

Why choose our DXP?

The platform brings content management, customer data and multi-channel delivery into one environment.

• Personalized customer journeys: deliver content tailored to user behavior, preferences and location.
• Omnichannel Experience: manage and distribute content across websites, mobile apps, and other digital channels.
• Analytics and automation: draw on performance analytics and automation to steer your content.
• Scalable & Secure: designed for growth, with built-in security features and rights management that help govern access to user data.
• Integrations: connect Jahia to your CRMs, analytics tools and marketing automation platforms through its connectors.

Jahia lets teams manage their content, their sites and their digital experiences while connecting the data and tools that personalization needs. It is a fit for businesses that prioritize engagement, personalization, and long-term scalability.

If that sounds like your situation, book a demo and we will look at your setup together.

FAQs

1. What is the difference between static and dynamic websites?

The difference is when the content is produced. A static site serves files generated in advance, so every visitor gets the same page. A dynamic site generates or adapts all or part of its content at the moment of the visit, from data and from the context of the request. That difference shapes the infrastructure, the performance, what can be processed on demand, and the technical surface to secure.

2. How does MDN define a static website?

MDN defines it by what the server does, in one sentence: a static site returns the same hard-coded content from the server whenever a particular resource is requested. AWS defines the same object by delivery format instead, saying a static website delivers content in the same format in which it is stored, with no server-side code execution required. Both agree on the substance.

3. Why choose a dynamic website over a static one?

Dynamic rendering lets you compute or fetch information at the moment of the visit, hold sessions and rights server-side, and adapt the response to the context. Paired with a CMS, it sits inside a platform that also gives strong editorial autonomy. You pay for it with application components and data to run and secure. If none of that applies, static rendering may provide a simpler architecture.

4. Are dynamic websites secure?

They can be, but they have more to protect. A static site generally narrows the server-side attack surface when it carries no application logic, though the APIs it calls and its JavaScript dependencies still need securing. A dynamic site exposes an application server, a content source and the code between them, so it needs patching, access control and input validation on top of HTTPS. Security depends on how the stack is run.

5. Can a static website be converted into a dynamic one?

Yes, and gradually rather than all at once. You add APIs, server-side functions, authentication or dynamic rendering only to the parts that need it, and you leave the rest as they are. Many sites today combine pre-generated pages with dynamic features, which gives a deliberate hybrid rather than a full migration.

6. Which is better for SEO: static or dynamic websites?

Neither is better in itself. The static vs dynamic website choice does not decide ranking, and both can be crawled, rendered and indexed correctly. What matters is accessible, stable URLs, indexable content, decent performance, links crawlers can follow, and an architecture that blocks neither crawling nor rendering. Server-side rendering and pre-rendering make that easier when the content depends on JavaScript.

7. How to know if a website is static or dynamic?

Load the same page signed out, then signed in. If the content changes, something beyond a pre-built file is at work, either the server or the browser. A session cookie set on a first anonymous visit can suggest that stateful processing is involved, and content missing from the raw HTML means the browser is assembling it.