When a business asks me for a website, before any design there's a choice that will weigh on it for years: static site, server-side rendering (SSR) or CMS? Rather than explaining it in the abstract, I'll tell it through the project I know best: this site.
The three options in two lines
- Static site: pages are ready-made HTML files, generated once and uploaded to hosting. Very fast, cheap, very hard to attack. But every change requires a new release.
- SSR (server-side rendering): a server builds the page on every request, with always up-to-date data. Flexible and great for SEO, but you need a server that's always on and someone to maintain it.
- CMS (WordPress or a headless CMS): the owner edits copy and articles from a dashboard, without a developer. Convenient, but it brings updates, plugins and an attack surface to look after.
My case: an Angular site deployed as static files
This site is an Angular application with SSR configured, a separate NestJS backend with MongoDB and a blog in seven languages whose articles live in the database. On paper it's the perfect case for SSR. In practice, for cost and simplicity, the frontend is built and published as static files on Plesk hosting, while the backend runs on a separate service.
It works, but I learned the hard way what that choice implies.
1. Without a server, SSR doesn't exist
With a static deploy, server-side rendering never runs: if a page isn't generated during the build, Google only receives the application's empty "shell". When I noticed, Google had indexed 4 of the 32 URLs in my sitemap, and not a single article: I described the whole investigation in this article. The fix was prerendering: generating the HTML of every page at build time, article by article and language by language.
2. Hundreds of pages to generate on every build
Every article exists in seven languages, so there are hundreds of pages to prerender. The first builds called the production API for each one: the rate limit kicked in and some pages were generated with a "post not found" message. I fixed it by downloading every article once before the build into a cache file that the prerender reads from:
// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times3. Every new article needs a new release
This is the most obvious trade-off: when I publish an article from the dashboard, the content is immediately available through the API, but the HTML page Google reads only exists after the next build and file upload. For a blog updated now and then it's acceptable; for a news site it isn't.
4. Hosting details matter
Even with the pages generated, Apache answered every one of them with a 301 redirect: each prerendered page is a folder containing an index.html, and the server appended a trailing slash to the URL. The fix was a few lines in .htaccess, but without checking with curl -I I would never have noticed:
<IfModule mod_dir.c>
DirectorySlash Off
</IfModule>Because of these trade-offs I'm preparing a move to a Node container on Plesk with real SSR: the complexity was already in the project, so I might as well use it fully.
What I recommend to a small business
My site isn't a typical case: it's also a lab. For a real business, the choice almost always comes down to three questions: how often content changes, who updates it and how many pages are needed.
| Situation | Recommended choice | Why |
|---|---|---|
| Restaurant, craftsperson or practice with 5–10 pages that change a few times a year | Static site | Fast, cheap, no server to maintain |
| Professional who publishes articles or news on their own | CMS | Updates content without calling a developer |
| Catalogue with hundreds of products or content that changes daily | SSR or an e-commerce platform | Always up-to-date, indexable pages without rebuilding the site |
| Private area, bookings, per-user data | Web app plus static or SSR public pages | Public pages matter for SEO, the private area doesn't |
For many local businesses, opening hours, reviews and directions matter more than the website itself: a well-kept Google Business Profile is often worth more than an extra feature.
Questions to ask before choosing
- Who will update the content, and how often? If the answer is "the owner, every week", you need a dashboard.
- How much does Google matter? If the site lives on organic search, every page must reach the crawler as complete HTML: static or SSR, never a single-page app without prerendering.
- Who will maintain the server? An SSR app or a CMS without updates ages badly; a static site can sit untouched for years.
- How much might it grow? Starting static and moving to SSR is possible, as long as you pick an architecture that allows it, as happened to me with Angular.
The mistakes I see most often
- A heavy CMS for five pages that never change: plugins to update and security risks for no benefit.
- A single-page app without prerendering for a site that needs to be found: pleasant to use, invisible to search engines.
- Choosing SSR without a budget to maintain it: a server has to be monitored, updated and paid for every month.
In short
There's no universally best technology: there's the one that fits how content is updated and who manages it. For most small businesses a well-built static site is the most solid choice; a CMS makes sense when the owner wants autonomy; SSR is for lots of content that changes often. My site taught me that every choice has a hidden cost: what matters is knowing it in advance. If you're weighing up a project, get in touch and we'll start from these questions.