The plain-English version
Every web page has to be assembled from content and templates at some point. The only real question is *when*. Static site generation (SSG) assembles every page ahead of time, when the site is built, and serves ready-made files. Server-side rendering (SSR) assembles the page fresh on a server each time someone asks for it.
Think of it as a bakery versus a made-to-order kitchen. The bakery (static) has everything ready the moment you walk in (instant, cheap to serve, but the menu only changes when they bake again. The kitchen (SSR) can make anything for anyone) including a dish personalized to you, but you wait while it cooks, and the kitchen needs staff around the clock.
There is a third pattern, client-side rendering, where the visitor’s browser does the assembling, useful inside apps, and generally the weakest choice for pages that need to rank. Google’s own overview of rendering strategies covers the full menu if you enjoy diagrams.
Speed: static wins on physics
A static page already exists before anyone asks for it, so it can sit on a CDN, servers physically near your visitors, and arrive with essentially no compute time. An SSR page pays a small assembly cost on every request: run code, maybe query a database, then send.
Good SSR with caching can be very fast. Static is simply fast without anyone trying, which matters because Core Web Vitals feed rankings and, more importantly, because slow pages lose buyers before the offer loads. Fewer moving parts also means fewer 2am incidents, there is no server to fall over when a campaign spikes traffic.
SEO: both work, one just has fewer ways to fail
Search engines happily index both static and server-rendered pages, because both deliver complete HTML. There is no ranking bonus for the rendering strategy itself. The SEO difference is indirect and practical:
- Speed is a ranking input, and static sites pass speed thresholds with less engineering effort.
- Reliability is an indexing input. A crawler that hits slow responses or server errors crawls less. Static files do not have bad days.
- Simplicity reduces mistakes. Most technical SEO disasters we audit are misconfigured dynamic behavior, not problems a folder of finished HTML files can even have.
Crawlers do not reward rendering strategies. They reward fast, consistent, complete pages, static just makes those properties hard to lose.
When each approach wins
Static wins when the same page can be shown to everyone and content changes on human timescales, marketing sites, service pages, blogs, portfolios, documentation. That is most business websites, including this one: it is a static build, rebuilt in minutes whenever content changes.
SSR wins when pages genuinely differ per visitor or per minute, logged-in dashboards and account areas, search results over live inventory, pricing that changes constantly, or catalogs so large that pre-building every page is impractical.
Modern frameworks blur the line nicely: a mostly-static site can fetch live pieces (a booking widget, a stock counter) from the visitor’s browser, keeping the fast static shell while the dynamic bits stay dynamic. You rarely need to pick one religion for the whole site.
How to decide for your website
- Ask what actually varies. List the pages that would differ per visitor. If the answer is “none” or “one widget”, static is your default.
- Ask what it costs to run. Static hosting is nearly free and unattended; SSR means servers, scaling and someone responsible for them.
- Ask who maintains it. The less infrastructure a site has, the less there is to break, patch and monitor over the years you own it.
- Do not let the stack pick you. This choice sits inside a bigger one, see Next.js vs WordPress, and both should follow from the site’s job, not from what the vendor prefers building.
If the job is a marketing site that loads instantly, ranks well and turns visitors into enquiries, static is usually the answer, and building exactly that is what our web design service does, with the SEO foundations baked in rather than bolted on.
Frequently asked questions
What is the difference between static and server-side rendering?
Timing. Static site generation builds every page once, ahead of time, and serves finished files; server-side rendering builds the page fresh on a server for each request. Static is faster and cheaper to serve, SSR can personalize and reflect live data instantly.
Is static or server-side rendering better for SEO?
Both index fine, search engines receive complete HTML either way, and there is no ranking bonus for the strategy itself. Static sites have an indirect edge: they pass speed metrics with less effort and have fewer moving parts to misconfigure, which is where most technical SEO problems actually come from.
Which is faster, SSG or SSR?
Static generation, all else being equal. Pre-built files served from a CDN skip the per-request assembly work SSR does, so time-to-first-byte is consistently lower. Well-cached SSR narrows the gap, but static achieves the result without the caching layer that needs tuning and can fail.
When do I actually need server-side rendering?
When pages genuinely differ per visitor or change faster than you can rebuild: logged-in areas, live search and inventory, constantly-shifting pricing, or catalogs too large to pre-build. If your pages are the same for everyone and change weekly, you are paying SSR costs for nothing.
Can a static site still have dynamic features?
Yes. The common modern pattern is a static shell with dynamic islands (forms, booking widgets, live counters) fetched from the browser after the fast static page loads. You keep static speed and reliability for the 95 percent of the page that never changes per visitor.