Website Makeover: How We Moved a Website from Wix to WordPress & Obliterated its Bounce Rate

For this case study we moved a website from Wix to WordPress. Moving from a totally different platform to WordPress is quite challenging and as a result, there are many interesting lessons in this case study.

For example, you'll discover how we completed a whole website redesign and built out an entire mini-site using just Thrive Architect and the Symbols feature. I'll also explain exactly what we did to fix the one BIG problem the site had (as well as the many little ones).

The candidate for this case study is The Green Fairy. This is a small business from Switzerland run by just a handful of passionate people. They produce lactose free, organic, fully vegan ice cream that makes no compromises in deliciousness (or decadence, for that matter).

Before we got started, this is what the homepage of The Green Fairy's website looked like:

Let's take a look at the problems we found on this site, our redesign/rebuild and some special features and workarounds we made use of. Finally, I'll walk you through the process we followed to move the site from Wix to WordPress.

Part 1: The Problems

When we analyzed the site, there were several issues we found, all of which we aimed to address with our complete website redesign and rebuild. Here are the most important ones:

The Nr. 1 Problem: Speed

By far the highest priority problem this site had was loading speed. Even on a fast connection, it could easily take 10 seconds or longer before content on this site would appear.

What's worse, the website didn't just feel slow, it seemed broken. The little loading spinner in the browser tab would stop spinning after just a few seconds, indicating that the page had finished loading. But at that point, most of the content on the page wasn't visible yet. There was no indication that you'd have to wait several more seconds before the page really finished loading. I believe this was caused by some lazy loading feature on the site, but whatever the reason, it made for a very poor user experience.

Why is loading speed the highest priority problem to solve?

Because if your website is too slow, nothing else matters. You've got a fantastic product? Your site is chock-full of valuable content? You have an important message for the world? Too bad, because most of your visitors leave before your first page has even finished loading. And they won't come back, either.

This is why we mention site speed so often, when talking about improving a website's conversion rate. And it's why speed is always a consideration in the features we build for our products.

The Green Fairy website was a perfect example of this speed problem. As you'll see from the bounce rate results further below, most visitors simply did not stick around for this site to load.

Overdesigned & Outdated

From a design perspective, there are two main issues with the site:

1. It looks outdated. This is basically unavoidable. Web design changes all the time and any website will start looking outdated after a few years.
2. It is over-designed. This is a more subtle problem. It happens when a design tries too hard to convey a message. In this case, it's too playful, too colorful and too sweet. As a result, it looks a bit "heavy" and the design distracts from the content.

How can you know if your website has this same problem?

Ask yourself if your website's design looks overly "busy". Look at an important element on your homepage. Maybe a call to action button or an opt-in form. Does this element have some room to breathe? Does it stand out clearly from the surroundings, or are the surroundings so noisy that nothing really stands out?

Usability Issues

There were many small usability issues that we found and fixed in our do-over. To find such issues, it's really important to use a website for a while. To go through it "as a visitor", try the different links, try to find answers to specific questions and so on.

Some of the issues we encountered were:

• The site is available in 3 languages. In 2 of them, there were missing components and glitches on the homepage.
• There's a page listing the ingredients and nutrition facts for all the ice cream flavors. This page was linked to from the images of the ice creams on the homepage, not from a button or text link. It really wasn't obvious that you could find this page by clicking on an image. If visitors were looking for information about ingredients, they were unlikely to find it.
• On this same ingredients page, the tables listing the nutrition facts were added as image files. That means the table content wasn't searchable, indexable or selectable.
• Some of the maps showing shop locations where the ice creams are available were images instead of embedded maps.

The Mobile Responsiveness Issue

The mobile version of The Green Fairy's original website was not very good. This problem deserves special mention here because of the underlying system it was built with.

If you've ever used the Wix website builder, you know that with it, you can drag and drop elements anywhere on your page. Kind of like moving around layers in Photoshop or elements in Canva. This is called "absolute positioning".

Maybe you're thinking: "That's great! Why can't I do that in Thrive Architect?"

The reason is so that your content doesn't look horrible on medium and small screens. Thrive Architect is what you'd call a "block editor". With it, you create your content using fully responsive building blocks, to ensure that your content looks good on every screen size.

Note that even though there are only 3 preview screen sizes in Thrive Architect, all your content is actually optimized for every imaginable screen size.

With absolute positioning, you don't have this fluidity. Instead, you have a "big screen" version of your page and a "small screen" version of it and the system tries to awkwardly serve all the screen sizes in between with scaling.

The bottom line is: it usually doesn't look or work great.

The Green Fairy's mobile site was missing important parts of the content and was generally not nice to navigate. Fixing these issues with an absolute-positioning editor like Wix is not easy.

Part 2: The Website Makeover

By moving the site to WordPress and using Thrive Architect, most of the problems listed above were easy to solve.

Our new-and-improved version of The Green Fairy's homepage looks like this:

In our rebuild of this website, we made almost no changes to the content, but we changed the layout and design to make everything look more modern, cleaner and also to make everything load faster.

How we Solved to Loading Speed Problem

The loading speed of the website went from "glacial" to "very fast". And as a result, this is what happened to the bounce rate (the amount of visitors that abandon the website before viewing a second page):

The bounce rate dropped from close to 100% to less than 10%. This is almost entirely a result of the speed optimization we did.

To speed up the website, here are the most important steps we took:

• We reduced the amount of images used in the design. For example, we used colors and gradients instead of background images everywhere except in the title section.
• The images we kept were all resized and compressed, to keep the file sizes as small as possible.
• We built the entire website using Thrive Architect landing pages, which are speed optimized by default (no loading of heavy theme files).
• We hosted the new site on WPX Hosting which is, simply put, bloody fast!

Design Trick for the Title Section

There's a design trick we used, which is also related to speed and which we used specifically for this title section:

In this section, there's a large background image. Even compressed, it can still take a moment to load. We added a solid color layer behind the background image of this title section. The color loads immediately and that means that the text on top of this section is immediately readable, even in the moments before the background image loads.

In the video, you can catch a glimpse of this at 06:41.

In Thrive Architect, the layering of the background looks like this:

We recommend this as a best practice: whenever you have a large background image and text (or other content) on top of it, add a solid background color behind the image.

Check out this post to learn more about how to create the perfect background image for your website.

Part 3: Moving from Wix to WordPress

Now, let's get into the nitty-gritty of how we moved a site from a platform that is very much not WordPress to a WordPress site.

First, let me state clearly that there's no instant, one-click way of doing this. I'm going to go into some of the technical details of what was involved in the move. I will also try to keep the description concise, as a fully detailed, step-by-step guide is outside the scope of this blog post.

If you aren't highly tech savvy, you can treat the guide below as a jumping-off point in case you want to do a similar transition yourself.

Here are the steps we took:

Step 1: Preparation

First, we made a list of all the pages on The Green Fairy's website and developed the new design concept with the help of the Thrive Themes design team.

This gave us a solid foundation: we knew which pages we had to build and what they'd look like.

Step 2: Templates & Symbols

This step is super important, because it makes the difference between an efficient build or having to do the same work over and over again.

Before we launched into building any of the pages, we looked at what we needed templates or Symbols for.

We created the following, to lay the groundwork:

• A header layout, saved as a Symbol.
• A footer layout, saved as a Symbol.
• A custom landing page template which included the header and footer Symbols as well as a title section and content area.

Step 2B: Multilingual?

An extra challenge on this site was the fact that it's available in 3 languages. Unfortunately, our tools don't integrate with WPML, the standard multi-language solution for WordPress. We had to find a different solution.

This solution was:

• Create 3 versions of each page (one in each language).
• Add 3 buttons to the header, each one linking to the homepage of its respective language. This was our makeshift language switch.

Step 3: Build the Site

We built the site on WordPress, on a staging site (a test site that isn't live on the Internet). This gave us time to do all the work that was needed without having to worry about downtime or transitions yet.

Many hosting providers offer a staging feature you can use. You can also create a test site for yourself, if your hosting provider has no such feature. To do so, set up a sub-domain in your hosting account, install WordPress on it and set it to not show up in search results in your WordPress dashboard under "Settings" and "Reading": 

On our staging site, we built each page by first loading the template we'd created and then copy-pasting the text from the original website.

Once a page was built, we cloned it and replaced the text to create the alternative language versions.

Step 4: Optimization Stuff

Apart from the image/speed optimization I've already mentioned, we also did some usability optimization.

Two parts of this that warrant special mention are:

1. We used a tool called Mapkit to create and embed interactive store location maps.
2. We used the Thrive Architect HTML table element to make the nutrition facts tables fully editable.

Step 5: The Move

Once the site was ready to go on staging, it was time for the actual transition. This is a matter of changing the website your domain points to. When setting up hosting or setting up a website on a service like Wix, one of the steps always involves domain names and nameservers.

You can think of your domain name as a "human friendly" address that points the server and content of your website. We can update this, so that the same domain points to a new location and new content.

Doing this involved mainly 2 steps:

1. Updating the nameservers of the domain to point to the WPX Hosting account instead of Wix.
2. Getting amazing help and support from the WPX team in moving all our content from our staging site to the new hosting location.

Once the nameservers are updated, it's just a matter of waiting (for up to 2 days) for the DNS propagation. Once that's done, visitors seamlessly see the new site instead of the old Wix site. Downtime = 0.

Step 6: SEO Stuff & Testing

Some SEO stuff can be done before the move, but everything needs to be checked after the move. I won't go into great detail here. In summary, here's what was done:

• We installed the Yoast SEO plugin to take care of all the basics.
• Using the Yoast SEO plugin, we create custom meta titles and descriptions for each page.
• We update the site's validation for Google's Search Console.
• We use the Script Manager feature to add Facebook pixels and tracking scripts that are needed.
• We double check to make sure all links and signup forms work.

Conclusion: Mini Site Building Works!

Thrive Architect is not purpose-built to create a mini site with several, interconnected pages. And it's definitely not built to create a multilingual website. Of course, we are always striving to improve the plugin and make it more suitable to a wider range of use cases like this. But it was good to see that it's already up to the task.

The greatest challenge for this case study was the multilingual aspect of the site. Remove that and you could very efficiently build a mini-site using Thrive Architect, the Symbols feature and nothing else.

If you are interested in similar design makeovers, check out our article about a landing page redesign.

Let me know what you think of this website makeover. What lessons can you learn from this to improve your own website? Leave a comment below!