Understanding server-side rendering.
Open the homepage of your Wix site. Click onto the first post you see, view the source code of this post, and try to locate your title tag and content.
You might notice that the default post template title tag is present and none of the page’s content is visible in the HTML.
It might startle you at first, but don’t panic -- this is due to the nature of client vs. server side rendering (SSR). In 2016, Wix began their move from client-side rendering to server side, with the goal of improving overall site speed and SEO performance.
For an explainer on client vs. server-side rendering, here are the two approaches and the differences between them broken down succinctly by Guillaume Breux:
Client-side rendering allows developers to make their websites entirely rendered in the browser with JavaScript. Instead of having a different HTML page per route, a client-side rendered website creates each route dynamically directly in the browser. This approach spread once JS frameworks made it easy to take.
Server-side rendering allows developers to pre-populate a web page with custom user data directly on the server. It is generally faster to make all the requests within a server than making extra browser-to-server round-trips for them. This is what developers used to do before client-side rendering.
Client-side rendering manages the routing dynamically without refreshing the page every time a user requests a different route. But server-side rendering is able to display a fully populated page on the first load for any route of the website, whereas client-side rendering displays a blank page first.
For the human user navigating a Wix site within their browser of choice, page titles and content are loaded dynamically using JavaScript just as a Single Page Application would work -- thus why the source code reflects the post template code, but the actual browser tab will show the right title.
Source Code
Browser Tab
As you navigate your Wix site, watch the browser tab as a new post loads and you’ll see this unfold in real time. Think of it as JavaScript working to add your own code and content within the existing Wix template.
Within the source code, you’ll see the first <div> on the page is marked with an id of site_container. Wix sites are built with the ReactJS framework; this is where React will load your site into the div. After this is complete, you now have fully interactive page with all of your content visible.
With server-side rendering, bots are directed to Wix’s node server, where a full HTML version is returned. The bot no longer has to run the scripts in full to successfully find your content -- it is all there upon the initial server response.
While Wix still has a long way to go in improving speed performance, since implementing SSR, they have released data indicating up to 60-70% improvements in the time-to-visible speed metric upon the initial load of a site.
A quick way to verify your page is working properly and the server is serving up your content in full to search-engine bots is to view the site as the Googlebot user-agent would. The Test Live URL tool within URL Inspection in Google Search Console (formerly Fetch & Render) is one great way to test this properly, but it can take a little while to load a rendered version of a live page, let alone check multiple URLs quickly as you navigate your site.
If you’re using Chrome to browse, you can also add the Chrome UA Spoofer extension. This tool allows you to toggle user agents within a drop-down menu and view the site as Googlebot.
With the extension active, you can now see the content and page title just as Googlebot would via the view-source within your browser:
Page viewed with chrome user agent
& no page content visible
Page viewed with Googlebot user agent
You can see the differences more clearly demonstrated with the diffchecker tool here.
Now that you know the basics of SSR, you may have more questions about how Wix’s rendering works and how it impacts SEO. You can contact us with all of your Wix SEO questions here.
