The new customer platform turned out fast and tidy. The team built it as a single Angular application: you log in, it loads once, and from then on everything moves without a page reload. Three months later, marketing asks why the product pages don't show up on Google. Open the source of any of them and all you find is an empty
<div>and a couple of scripts.
In web application development, the decision about where the HTML gets generated is made early and is expensive to undo. It can be built in the browser (SPA), on the server for every visit (SSR), or once at build time (static site). All three are valid, and none of them is "the modern one". Each changes your SEO, perceived speed, hosting bill and how much infrastructure your team has to look after. If you are still deciding whether your site needs custom development or a CMS will do, start with when a CMS is no longer enough. This article picks up from there: you know you're building, and now you have to choose the web application architecture.
What each option means
A SPA (single page application) sends the browser an almost empty page and a JavaScript bundle that draws everything else. The first load is heavier, but after that each screen appears without fetching a new page from the server.
With SSR (server-side rendering), a server builds the full HTML on every request and sends it ready to display. The browser shows content right away, and then JavaScript "wakes up" the page so it responds to clicks. That step is called hydration.
A static site generates every page at build time. What gets published is a set of HTML files that any CDN can serve, with no application server behind them.
Current frameworks no longer force you to pick just one. Angular's official documentation describes three modes: client-side rendering (the default), server rendering, and prerendering at build time. It also lets you mix them route by route, which it calls hybrid rendering. You add it to an existing project with ng add @angular/ssr.
Side-by-side comparison
| SPA | SSR | Static site | |
|---|---|---|---|
| Where the HTML is generated | In the browser | On the server, per visit | At build time, once |
| SEO for public pages | Depends on the search engine running JavaScript | Good: HTML arrives complete | Good: HTML arrives complete |
| First load | Slower | Fast, if the server responds quickly | Fastest |
| Later navigation | Very smooth | Smooth after hydration | Reloads between pages unless combined with JS |
| Per-user data | Natural fit | Natural fit | Needs API calls from the browser |
| Hosting | Static files + API | Always-on Node.js server | Static files (CDN) |
| Operational complexity | Medium | High | Low |
People rarely look hard at the hosting row when comparing quotes. A SPA or a static site ships as files. On Azure, for example, Static Web Apps has a free plan with no SLA and a Standard plan at US$9 per app per month, both with 100 GB of bandwidth included per subscription (list prices checked in November 2026). SSR also needs a Node.js process running, with its own monitoring, scaling and patching. It isn't expensive, but it's one more piece someone has to run.
What happens with Google and a SPA
Google does run JavaScript. Its JavaScript SEO basics guide describes three phases: crawling, rendering and indexing. Pages wait in a rendering queue that can last a few seconds "but it can take longer", until a headless Chromium executes the code. The same guide says server-side rendering or prerendering "is still a great idea" because the site loads faster for users and crawlers, and not all bots can run JavaScript.
That last point tends to get forgotten. Google isn't the only thing reading your site. Link previews in WhatsApp or LinkedIn also depend on the HTML carrying a title, description and image.
If you already have a SPA, Google's guidance leaves a few concrete fixes:
- Don't use fragments (
#/products) to load different content. Routes need to be real URLs. - Return meaningful HTTP status codes. A SPA that answers 200 for any route that doesn't exist creates "soft 404s"; Google suggests redirecting to a URL that returns 404, or adding
noindexto the error page with JavaScript. - Don't rely on dynamic rendering (serving a prerendered version only to bots). Google calls it a workaround and not a recommended solution because of the complexity and resources it adds.
How to choose based on what you're building
Ask who will see each page and whether anyone needs to find it through a search engine.
If the whole system lives behind a login (a customer portal, an intranet, a back office connected to the ERP), a SPA is usually the simplest option. No search engine will index those screens, and smooth navigation matters more than the first load. Angular with a Node.js API and static hosting is a solid pairing that's cheap to run.
If the public content changes rarely (a corporate site, documentation, landing pages, a blog updated a few times a week), static wins on almost everything: speed, cost and attack surface, since there's no server to break into. Generators like Astro, Hugo or Eleventy, or Angular's own prerendering, handle this well.
If public pages change often and also need to rank, like a catalog with stock and prices pulled from the ERP, that's where SSR earns its keep. Same when content depends on who's asking but still has to arrive fully built, such as regional pricing.
Most business projects end up with a mix: public pages prerendered or server-rendered, and the private area as a SPA. With Angular's hybrid rendering you configure this per route inside one project. Two separate applications also work, and sometimes they're easier to maintain.
One warning: SSR adds development work that people tend to underestimate. The code has to run correctly on both the server and the browser, and things that are trivial in a SPA (reading window, saving to localStorage) break there unless you guard them. Keep that in mind when you review a proposal. In what drives the cost of a custom application we go through how these decisions move the budget.
What to put in writing in the requirements
Before anyone picks a framework, settle these points:
- Which pages are public and need to rank, and which sit behind a login.
- How often public content changes and where the data comes from.
- Performance targets, measured with Core Web Vitals (thresholds and how to measure them are in our article on custom web development).
- Where it will be hosted and who will run it after handover.
- How old URLs and redirects are handled if you are replacing an existing site.
With those answers the architecture mostly picks itself, and any vendor proposing something different will have to explain why.
Frequently asked questions
Is a SPA bad for SEO?
Not necessarily. Google runs JavaScript and can index a well-built SPA with real URLs and correct status codes. But rendering goes through a queue, and other bots don't run JavaScript. For pages whose job is to rank, HTML generated on the server or at build time is the safer bet.
Can an Angular SPA move to SSR without a rewrite?
Often, yes. Angular adds SSR to an existing project with ng add @angular/ssr and lets you set, route by route, what renders on the server, what gets prerendered and what stays on the client. The real work is reviewing code that assumes it always runs in a browser.
Does a static site work if I have forms or dynamic data?
Yes. Pages are generated at build time, but they can call an API to submit forms or show specific data. What doesn't make sense is a static site where nearly all the content depends on the logged-in user.
Let's talk about your project
At Disrupsoft we build custom web applications with Angular, Node.js, Azure and Power Platform, and we start every project by understanding your requirements before choosing the technology. If you're defining the architecture for a new platform, or your current application isn't showing up where it should, let's talk about your custom development project.
