With search engines increasingly prioritizing sites that perform well in rankings, the rendering approach you select could mean the difference between appearing on the first page of results or being buried deep where customers won't bother looking for you.

For eCommerce sites, choosing the right strategy is critical as it directly impacts SEO (search engine optimization) ranking, customer experience, and ultimately, the sale.

And for B2B eCommerce the stakes are even higher.

B2B eCommerce is significantly more complex than its B2C counterpart: A typical product sold by one of Villvay’s B2B enterprise clients could have multiple specifications and variations depending on adherence to local regulations, compatibility information, availability based on location, shipping specifications, etc. Even something usually considered standard, like product pricing also depends on the order quantity, customer relationships, location, etc.

You’re dealing with entire businesses and industries—a buggy, unintuitive experience on a B2B eCommerce site could mean potential millions lost every year in sales.

As the title of this article suggests, we’re looking at a fundamental element that influences SEO rankings: website rendering strategies.

When building a web application, there are multiple rendering strategies that can be used, each with their own advantages and drawbacks. And to understand each strategy and figure out which one is best for your site, it makes sense to go through them in chronological order to understand what each was trying to solve, starting with the first: Multi-Page Applications.

Multi Page Applications (MPA)

During the early days of the internet, web pages were just static HTML files being served off a server. So the home page (”/”) would be the “index.html” file, the about page (”/about”) would be the “about.html” file, and so on. When you’d click on an anchor tag (<a>) to navigate to another page, the browser would request the server for that file. While waiting for the file to be sent, you would see a loading indicator next to the page title in the tab 🔄

A visual representation of information flow for early web pages

As the development of web pages progressed and sites became more interactive, the need for dynamic pages with changing content became prominent. Languages like PHP were used to generate the page on the server for each request. With this approach however, the page would take longer to load because it has to be generated for every request.

A visual representation of information flow in a Multi Page Application

Exacerbating these loading times, even if only a part of the site changes between pages, the entire page has to be re-rendered, resulting in losing state. For example, when navigating through a typical site, the header and footer tend to stay the same. The header might have some dynamic data, like the current logged-in user, which is not expected to change during a user’s session. But with MPAs the state of the header and footer is repeatedly discarded and re-rendered with every click, meaning data like the logged-in user must be fetched again between page navigations even though nothing changed in this regard. This results in wasted resources. And the more complex your website is, the more significant the resource waste becomes when using an MPA.

However, from an SEO perspective, MPAs have one significant advantage: search engines can easily crawl and index their content since each page has its own unique URL and is fully rendered HTML. This made traditional MPAs excellent for discoverability, even with their performance limitations.

Single Page Applications (SPA)

Single Page Applications were popularized with libraries and frameworks like Angular, React, and Vue. They help sites feel more like applications—instantly navigating between pages and animations.

A visual representation of information flow in a Single Page Application

When the browser first requests the site, the CDN (Content Delivery Network) returns a blank HTML file with a link to the application bundle. This bundle is then fetched and parsed. Only once the bundle is parsed will anything show up on the screen. Until then, the user will see a blank white screen.

In practice, you’ll still need to fetch more data for the site, so once the bundle is parsed, a loading state will be shown while the browser requests more data (e.g., product information) from the server. Only once that data has been returned will the user see any useful information.

While making the user wait a considerable time for any useful information sounds like a disadvantage if there ever was one,any subsequent navigation between pages will be instant because the browser no longer has to request anything from the server to get the pages as the application bundle contains the code for the entire site.

Another potential advantage of SPAs is that when navigating between pages, only sections of the page that need to change are re-rendered. Going back to our previous example with MPAs, the header and footer can remain the same in an SPA, meaning session-persistent data, like the logged-in user’s data, doesn’t need to be refetched for the header.

But there are some major drawbacks with SPAs, especially when it comes to SEO:

The first issue affecting both user experience and SEO is that SPAs have a large FCP and LCP because the browser cannot display any content until it has downloaded and parsed the application bundle and fetched the data for the page from the server.
Another reason SPAs have poor SEO is because (in stark contrast to an MPA) the initial HTML from the CDN doesn’t contain any useful information. As the diagram above shows, the connection to fetch the page closes after the HTML file is sent, and unfortunately, this is the content that crawlers are guaranteed to index, which is essentially nothing from an SEO perspective. There are anecdotal reports that modern crawlers are able to wait and index the proper data in SPAs, but this isn’t foolproof and depends on many variables, like how quickly you can load the data onto the page.
And finally, since the entire site is included in the initial application bundle, as the site grows and more features are added, this bundle will grow in size. This will ultimately result in longer delays in terms of FCP and LCP, as it will take longer to download and parse the bundle. And eventually, customers may decide that the load time is not worth the payoff.

Universal Web Application

So you have MPAs, where you get useful information displayed in the browser as soon as possible on the first navigation, but each subsequent click results in significant wait times as the page reloads from scratch again and again.

And SPAs, where you face a long initial load time and poor SEO, but on the other hand, you get a much better overall user experience thanks to seemingly instant onscreen changes.

Which one would you choose for your site?

Why not use something that has the best of both worlds? One that has the quick initial load of MPAs and the better user experience and instant navigations of SPAs. This middle ground exists, and they’re called Universal Web Applications. They are a mix of MPAs and SPAs and can be implemented with frameworks like .

A visual representation of information flow in a Universal Web Application

The initial request/page, like with an MPA, is rendered on the server so the user/crawler can get the relevant information to view/index it—great for user experience and SEO. And on subsequent navigation, client-side navigation takes over in the form of the application bundle, resulting in instant page changes.

From an SEO perspective, this was a game-changer. Search engine crawlers receive fully rendered HTML with all critical content and metadata, allowing them to properly index products, categories, and other important pages.

This directly addressed the biggest SEO pitfall of traditional SPAs while maintaining the excellent user experience it offers.

Static Site Generation (SSG)

So far, when navigating to a page, the relevant data has had to be fetched from the server or database for every request. This is fine if the page’s data is expected to change a lot or if it is specific to the user. But it would be wasteful for data like product details that are not expected to change much over time.

For this kind of data, the best thing to do would be to cache it so that it does not have to be fetched for every request, thereby saving time and serving the page back to the browser faster. This is where SSG (Static Site Generation) comes in.

A visual representation of information flow with Static Site Generation

With SSG, instead of fetching and generating the page for every request. All pages are built and saved beforehand so that when a page is requested, it can be returned immediately, resulting in a massive speed boost to the site, drastically improving SEO and user experience.

However, because the entire site is built in one go, the build could take a very long time, potentially even several hours. And if you needed to make a small change on a single page, the entire site would need to be rebuilt. Because of this, even though the speed of SSG would greatly benefit an eCommerce site, it is not feasible for a site that could potentially have around 50,000 pages.

Incremental Static Regeneration

Incremental Static Regeneration is an evolution of SSG where not all the pages are built at build time. Instead, the remaining pages are built and saved on request.

A visual representation of information flow with Incremental Static Regeneration

In the diagram above, only the 1st product page is built at build time. So when a user goes to that page, they can get a response immediately. But when they visit the 2nd product page, since it hasn’t been built yet, the frontend server needs to generate it at that time. However, once it has been generated, the saved page can be returned immediately for subsequent requests by other users within the revalidation time.

Once a page is generated, it can be set to update itself after a certain period of time, which is known as there validation time. For example, if a page has a revalidation time of 60 seconds, once version 1 of the page is built, all requests during the next 60 seconds will continue to get version 1 of the page. The first request to the page after the 60 seconds will trigger a rebuild of the page in the background and get version 1 of the page, which is considered stale at this point. Any requests made while the page is rebuilding will continue to get version 1, and once the page has finished rebuilding, the new version (version 2) will replace the old one, and any requests that come next will get the updated version of the page. This is illustrated below:

A representation of how pages are generated via ISR with a sample revalidation period of 60 seconds

For eCommerce sites with large product catalogs, ISR offers the perfect balance of SEO-friendly architecture and performance optimization. High-traffic or priority pages can be pre-built at deploy time, while long-tail product pages are generated on demand and then cached. This approach means search engines can properly index your entire catalog while maintaining excellent performance metrics that boost your search rankings.

Static vs Dynamic rendering

If a page is to be indexed by crawlers, the page must be generated on the server (Server Side Rendering). With this, the question then arises: Should be the page be rendered dynamically or statically?

Dynamic - The data will always be fresh but it will slower since the page must be generated fresh for each request.
Static - The page will be returned a lot faster but there is a chance the data could be stale.

Having to choose between dynamic and static for the entire page is not ideal because not all sections of the page require the same type of rendering. For example, in a typical product page on an eCommerce site, the product information can be static while the pricing and availability should be dynamic.

This point becomes especially important in B2B eCommerce sites where data might be at different locations, such as a CRM, and it would take longer to wait for all the data before displaying the page. Since Core Web Vitals are a vital part of SEO, it is important to send data as soon as it is ready. The best way to do this would be to generate the static elements of a page ahead of time so that they don’t have to wait for the dynamic elements of the page that might take more time to be received, such as product availability and pricing.

A simplified illustration of dynamic and static page elements on a typical product page

This hybrid approach means search engines see complete, content-rich pages with all the vital product information they need to properly index and rank your products, while dynamic elements like real-time pricing don't delay indexing or hurt performance metrics.

Conclusion

In today's competitive eCommerce landscape, a good SEO ranking isn't optional—it's essential for business survival. Previously, sites would go with dynamic rendering for the whole page as good SEO was priority, even if it meant a worse user experience. But since Google started incorporating Core Web Vitals into Google Search results, we can no longer afford to treat user experience and site performance as an afterthought.

As evidenced throughout this post, there’s no easy way to achieve both great SEO and user experience, especially with smaller development teams. But some libraries have introduced features that allow us to do just that. At Villvay, we've embraced hybrid rendering approaches using React through the Next.js framework to deliver sites that perform exceptionally well in search results while providing outstanding user experiences. By considering the strategies outlined in this article, we've been able to achieve immense success in both search rankings and conversion rates for our eCommerce clients.

And in our next blog post, we'll explore Villvay’s approach and how it resulted in client feedback like:

“[…] we've transformed from an unindexable site we had to take down because it wouldn’t run, to a high-performing site that's soaring in search engines and achieving top sales. This is an incredible achievement […]”

See you there!

Rendering SEO Success (Part 1)