CASE STUDY: Converting a Volcanic Site to WordPress + Integrating with Broadbean

The Challenge

Recently a client came to me in the recruitment industry who wanted to switch providers from Volcanic to WordPress. If you are in teh recruitment industry and were considering a website you would have most likely heard of Volcanic (in fact you probably clicked from an AdWords ad).

In this case study I wanted to give an overview of the challenges and pain points of the client on the Volcanic system – and the specific way I addressed these by recreating the site in WordPress.

It may be of interest to you if you currently use Volcanic and are considering other options – and how such a project was done.

[su_box title=”Note” style=”default” box_color=”#ffd400″ title_color=”#FFFFFF” radius=”0″]This case study is not 100% complete and I am only trialing this as an ad on AdWords – so fair warning it’s a little rough around the edges.[/su_box]

Monthly SaaS Fee vs. Development

When my client started with Volcanic they were paying a certain monthly fee. However this monthly fee – a lot of it anyway – was eaten up by the platform fee. In other words the client wasn’t really paying every month for development services – they were just paying to have access to the platform.

Now when I say platform – Volcanic is a CMS platform just like WordPress – however it was custom built from the ground up to work as a recruitment type CMS website. Which is like a WordPress CMS with some job recruitment plugins.

Tied to One Provider

When you use a CMS platform developed by a single web development company – you are tied to that one provider – whether it be an agency or a specialist recruitment company like Volcanic.

This might not seem like a bad deal when you are first presented with the features the CMS could do – in fact you could be shown a graph that says “Hey, this is everything our CMS can do that WordPress can’t”.

However being tied to one provider also has a whole host of negatives – and these include:

• The provider is less likely to take care of you since you are stuck within their ecosystem
• The switching cost is high – since no one else knows how to use this CMS besides the developer
• If you do switch – even if you keep the CMS platform the developer has built – you can pretty much count out doing any kind of custom development work

In my client’s case they were paying $x per month for Volcanic – however I suspect that amount included minimum custom development – the fee in essence was to have access to the Volcanic CMS Platform.

The Solution

After speaking with the client and going over some pain points – I proposed a solution where I would convert the site to WordPress and the client would continue paying a monthly fee to myself.

The great thing about this for the client was that not only were they paying less per month then they would be were they to stay with Volcanic – but that monthly fee could then be used towards my services including:

• Custom development and adding new features
• SEO and building organic traffic

This was great value for the client – since the client was going on a monthly plan with me rather than a one-off payment there would be minimal additional expense (other than the first 3 months of that plan being used to convert the current site and take it live).

Basically this was a web dev and SEO solution. But this case study deals with just the aspects of converting the site to WordPress.

The Project

Maintaining Permalink Structure

One of the most common and egregious mistakes WordPress developers make when converting a site to WordPress is not maintaining the permalink structure and losing Google rankings and organic traffic.

Let me give you an example.

Let’s say you have a URL for your services page like so:

https://www.yoursite.com.au/recruitment-services

You convert your site to WordPress and put it live but the new URL for the page is:

https://www.yoursite.com.au/services

Now – any links pointing to that page from other sites will not be counted by Google – not only that but if Google has that page in its index – and it’s now being returned as 404 Not Found – this will lead to a higher bounce rate and – well let’s just say if someone doesn’t know how to convert your site to maintain (and maybe even increase) your Google rankings/traffic then that is a big problem – and it defeats the whole proccess.

After all what’s the point of saving money in IT costs by switching to WordPress only to lose your Google rankings right?

As part of my development I replicated every permalink and meta description on the site to match their current page structure – also I optimised/tweaked their WordPress page speed so it was as fast – if not faster than what it was on Volcanic.

Speed Increase

While the Volcanic site was loading quite quickly on browsers – it had a terrible PageSpeed score from GTMetrix (F). No one really knows how Google ranks sites – but we know that page speed is a ranking factor. It’s also a fair assumption that if your PageSpeed score is F that this would mean the Google crawlers are not going to be too happy with you – and you would give ground to your competitors whose sites are optimised.

As part of the SEO part of the project I tinkered and improved the page speed significantly

[su_box title=”Note” style=”default” box_color=”#ffd400″ title_color=”#FFFFFF” radius=”0″]Page speed optimisation is an on-going proccess – and there are still issues I am looking in to get the PageSpeed higher. But also keep in mind that GTMetrix scores are a guide – and you don’t need 100% PageSpeed score to rank high in Google – but you definately don’t want an F score either. [/su_box]

Broadbean Integration with WP Job Manager

More information coming soon – if you would like the full case study sent to you please fill out the form below: