Skip to main content

Switch to the new publishing platform (Beta)

This article explains how to switch Studio.Design’s publishing platform from the current SPA (CSR)–based approach to an MPA (SSR)–based one, how this improves load speed and SEO/AEO, and the steps and key points for making the switch.

Updated today

In January 2026, we released the “Publishing Platform Switch (Beta)” feature, which lets you apply a new rendering method designed to improve the performance of your public site.

Until now, live sites were published as SPA (Single Page Application) + CSR (Client Side Rendering), but with the new publishing platform, pages are delivered as MPA (Multi Page Application) + SSR (Server Side Rendering).

This can improve page‑load performance and also make it easier for search engines and AI systems to understand your content, which is beneficial for SEO and AEO.

In this article, we explain what terms like SPA/MPA and CSR/SSR mean, then introduce the characteristics of Studio.Design’s new publishing platform, how to switch it in the UI, and what to keep in mind when you use it.


How the old and new publishing platforms differ

First, here is how the previous publishing platform (SPA + CSR) differs from the new publishing platform (MPA + SSR).

Previous platform (SPA + CSR): how it works and what it offers

  • SPA (Single Page Application):

    A single HTML file is used as the base, and JavaScript dynamically replaces content in the page to make page transitions feel seamless.

  • CSR (Client Side Rendering):

    JavaScript in the browser builds the HTML and renders it on screen.

    Studio.Design’s previous publishing platform combines SPA and CSR, which makes post‑load page transitions feel light and helps deliver an interactive experience when users move through multi‑page sites.

New platform (MPA + SSR + cache): how it works and what it offers

  • MPA (Multi Page Application):

    The site consists of multiple HTML pages, and each page transition fetches a new HTML document from the server.

  • SSR (Server Side Rendering):

    The server renders the HTML and sends the finished HTML to the browser.

  • Cache (CDN cache):

    With the new publishing platform, HTML generated by SSR is cached on a CDN. Once a page is accessed, later visits to the same page are served from this generated HTML, so repeat visits to the same page load faster.

Because Studio.Design’s new publishing platform uses MPA + SSR + cache, the HTML sent to the browser already includes text and meta information, which can improve load speed, visual stability, and results for SEO and AEO.

Serving previously generated HTML from the CDN cache also makes responses faster on repeat visits and can help keep the site stable even when many users access it at once.

Point: When cache is generated

The cache is rebuilt mainly at the following times:

  • When you republish the site

  • When CMS content is published, updated, or deleted

  • When Studio.Design’s publishing engine is updated

When any of these happen, the HTML for the entire site is generated again, and the next visit builds a fresh CDN cache.


Benefits of the new publishing platform

Here are the main benefits of using the new publishing platform (MPA + SSR).

Improved load speed and stability

  • On the initial view, the browser receives HTML that already includes text and images, so the first view is more stable.

  • Even on slower connections or lower‑spec devices, the page is less likely to break layout or stay blank for a long time.

SEO and AEO benefits

  • Because the page body, headings, and meta information are output directly in the HTML, search engines can more easily understand the structure of the page.

  • AI‑based search summaries and answers can also reference the SSR‑generated text more reliably, which is helpful from an AEO perspective.


What’s included in the beta release

The new publishing platform is being rolled out in stages as a beta, with the goal of making it the default publishing method in the future.

At this stage, there are still cases where compatibility with some features is not complete, and we are actively testing and improving support across different types of sites.

For sites where compatibility has been confirmed, you can switch on the new publishing platform yourself so you can take advantage of faster page loads and better SEO/AEO.

We maintain a dedicated issues page summarizing known compatibility problems and bugs for the new platform, and we update it as needed.

If you want to try the new publishing platform, follow the switching steps in this article to change your publishing platform.

Important notes when using the beta

  • During the beta period, our top priorities are testing and improving the feature. For that reason, our staffed chat support does not formally cover the new publishing platform, and we ask that you report compatibility issues and bugs through a dedicated one‑way contact form. We use the reports you send us to improve the platform so that more types of sites can use it comfortably by the time of the official release.

  • When you switch publishing platforms during the beta, we recommend doing so only when you are able to thoroughly test display, metrics, and forms before and after the switch.

  • For important conversion pages or sites with large traffic, we also recommend reaching agreement with all stakeholders before switching.


How to switch the publishing platform

This section explains how to switch the publishing platform in the Studio.Design UI.

Before you start

  1. Log in to Studio.Design.

  2. Open the project for the site you want to change and check how the current live site looks.

  3. If needed, record the current site in another environment or with screenshots.

Switch the publishing platform

  1. In the target project, open Dashboard > Project settings.

  2. Open Publishing platform switch > Settings.

  3. Select the publishing platform you want to use.

  4. Read the description and notes, and if everything looks fine, click Save.

Point: It can take around 5 minutes from clicking Save until the switch is complete.

Confirm the switch and generate the cache (first time only)

  1. Open the public site and launch your browser’s developer tools.

    💡 In Chrome, you can open Developer Tools by right‑clicking on the page and selecting Inspect.

  2. Open the Elements tab and search for the keyword “Studio.Design.HRC”.

    💡 Use ctrl/cmd + F to open the search bar.

  3. If you see <meta name="generator" content="Studio.Design.HRC">, the switch is complete.

  4. Finally, perform a site update operation to generate the initial cache.

Tip: By generating the initial cache, you can deliver site content quickly even to users visiting your site for the first time after it goes live.

After this first cache generation, you only need to perform regular update/publish operations; cache will be generated automatically each time.


Notes and recommended workflow for switching

Beta‑specific limitations and cautions

  • Some features currently have known compatibility issues or bugs on the new publishing platform. See 🔗 Public Site New Platform (beta) Issues for details.

  • During the beta period, as we fix issues and address compatibility, behavior may change for sites that depend on specific existing features or custom code.

  • If your site loads dynamic scripts such as external services or JavaScript, confirm that those parts behave as expected in the MPA + SSR environment before running them in production.

  • If your custom domain’s A record still points to the old IP address 35.194.122.208, you cannot switch that site to the new platform. Change the A record to 34.111.141.225 before using the new platform.

  • Once major issues are resolved and compatibility is fully confirmed, the plan is for the new publishing platform to become the default in the future.

Recommended gradual rollout

  • If you are considering switching an important, already‑live site, we recommend first testing behavior on the new publishing platform in a separate test project.

  • For pages where you track conversions using external services, test those flows before starting production use.

  • For high‑traffic sites, test load and behavior in a staging or test environment before switching in production.


Reference:

Did this answer your question?