Why Server Side Testing is Better than Client Side Testing

The majority of traditional A/B testing platforms are deployed client-side via JavaScript libraries that are loaded in the browser, and modify the page after the initial load. Server-side solutions, such as SearchPilot, instead make modifications to the HTML source before it reaches the user (see more about how SearchPilot works here). We believe that this is the best way to implement SEO and CRO split testing for an array of reasons, which we’ve outlined below:

It gives users a better experience

Client-side testing tools often take time after the page loads to make their changes to the page. This means users will often see one version of the page when it initially loads, before it switches.
This effect can also cause elements to shift around on the page, which can be a bad user experience, especially if a user tries to click on one element and ends up clicking on something else.
If the changes are made server-side, and the site is deployed behind a CDN, the changes to the page can be cached, which means a user will only see the changed version of the page, without slow page load times or elements moving around the page.

It’s better for SEO testing

While Google has improved a great deal at parsing and interpreting JavaScript-heavy pages, it is still not perfect. This is particularly true if the JavaScript takes a long time to execute - there’s evidence to suggest that Google only waits five seconds for content to render, so anything that changes after this point will not be taken into consideration for ranking.
This can also lead to mixed signals, especially around crawling and indexation directives such as canonical tags, noindex and nofollow. If one version is set when the page initially loads, and it is updated client-side, Google will receive a mixed signal and will err on the side of the more restrictive setting (noindex or nofollow over index or follow).
Even changes to title tags, meta descriptions and structured data can be unreliable if implemented through JavaScript. If Google sees two versions of the title, what will it choose to use? What if your new title takes more than five seconds to render when Googlebot happens to visit?
With server-side testing, you can test removing elements. If JavaScript is removing content from the page after the initial load, how do you know whether Google is taking that content into consideration when deciding where you rank?
Internal linking tests are only possible if implemented server-side. This is because, again, Google can be unreliable in rendering elements added or removed via JS, and we cannot reliably know which version of the page (before or after client-side changes) Google is taking into account for linking purposes.
As well as issues with specific tests, there is evidence that reducing the amount of JavaScript rendering that Google needs to spend its resources on can be beneficial for a website’s overall performance.
Client-side testing tools do not enable you to change status codes, or implement redirects. If you want to test a change involving redirects, that’s only possible with server-side testing.

And there’s more

If your split tests are being implemented client-side, it is very easy for your competitors to see what you’re testing. All they need to do is disable JavaScript when they visit your page, and they will see what’s being added in or changed by your client-side testing tool. When changes are made server-side, there is only one version of each page, so it is much more difficult for competitors to work out what’s being tested.
Because SearchPilot is server-side, it can be used as a meta-CMS, enabling you to add new content, make design changes, or even create brand new pages.
With server-side testing, we’re able to serve entire new templates directly from the origin server, rather than modifying the page. We can add headers to requests, which can be used by the origin server to return a completely different version of the page. This can even include whole new pieces of website functionality that wouldn’t be possible to deliver through a client-side testing tool.