- What does your project look like with WordPress from Day 1 to Launch?
- What does this project look like with ButterCMS from Day 1 to Launch?
- Marketing considerations
- Post-setup considerations
- Things to keep in mind
- Why do some make the mistake of choosing WordPress?
- The problems with WordPress
- An even Butter solution
- How to switch to ButterCMS
- A smooth transition
new to butter
ButterCMS vs. WordPress: A Typical Project Journey
Posted by Jake Lumetta on October 19, 2023
Table of contents
In our first article in this series, we explained the high-level differences between a headless CMS like Butter and a traditional CMS like WordPress. Now we can take a look at a more concrete example of a typical project journey.
Let’s say you’ve got an existing website built using a modern tech stack like React, Node.js, Ruby on Rails, etc and you want to add a blog to it. You’ll have very different experiences doing this with a traditional CMS than you will with a headless CMS. Below, we’ll see how.
What does your project look like with WordPress from Day 1 to Launch?
Let’s go through what this project will look like if you use WordPress and your site is built on Rails.
First, you’ll need to decide whether you want to self-host or not. Since this example scenario involves you already having a website and you want to add a blog to it, then you’re likely going to have to self-host WordPress. Initially your costs for hosting may be low, but as your site gains more traffic, the costs will increase. Additionally, self-hosting means you are responsible for keeping current with WordPress updates and also for backing up your data.
Once you’ve gotten basic WordPress installed, it comes with a default theme that you’re going to want to change so that your blog matches the look and feel of your existing website. This means either buying a theme that is close to what you want and hacking it apart or starting from scratch and building it from the ground up. Both paths involve your developers cracking open the WordPress source code and navigating the WordPress template + theme systems.
A simplified process of building a theme to match your existing brand will likely involve the following:
- Customizing a header and footer to match your site
- Customizing the blog home page design
- Customizing the blog post page design
- Customizing the category, tag, and author page designs
- Customizing the side rail
- This can include things like email capture and a search function within your website
- Finding, installing, and configuring plugins
Plugins are an integral part of WordPress. There are a lot of them. For example, here’s a WordPress link to its most popular plugins. As you can see, for everything that you want to add to your blog, you’ll need to find the right plugin.
Let’s just take a simple example and say you wanted to be able to have a contact form, a way to screen for spam in your comments, add Google analytics (we’ll talk more about analytics later), and have eCommerce capability on your blog to sell your product.
You’ll need to find, install, customize, and configure any plugins you want to add.
For these capabilities you’ll be adding four plugins:
- Contact Form 7 - this is one option for adding a contact form. There are, of course, many others. You can read through the descriptions, documentation, and requirements of each one to decide which is best for you.
- Akismet Anti-Spam - if you want to add commenting capabilities to your WordPress blog, but are worried about spam comments, you can install this plugin.
- Google Analytics for WordPress by MonsterInsights - since WordPress is separate from your existing website, any analytics you have set up for the existing site won’t necessarily translate to your new blog. This type of plugin can add analytics to your blog that are separate from the analytics of your home page
- WooCommerce - if you want to add eCommerce capabilities to your blog, you can use something like WooCommerce. Again, you’ll need to customize and configure it.
Out of the box, these plugins may not quite fit with your existing site design. If that’s the case, you’ll need to go into the config / source code to make changes so that everything blends seamlessly.
You may also want additional plugins for social sharing (Twitter, Facebook, Instagram, etc.) and SEO (Yoast), which will also require some configuration.
With the level of customization you’ll likely need with a WordPress-powered blog, it’s important to keep in mind that customization isn’t the only change developers will be considering. Remember, there’s already an existing website built in modern technology. The engineering team has a set of tools and processes to develop and deploy this primary site. By adding a traditional CMS like WordPress to the fold, engineers now also have to think about:
- How to deploy the blog
- How will it impact your current deployment process?
- Do you set up continuous integration for the blog?
- What testing suite will you use? Any?
- How will you handle backups for the blog?
- Do you put it under source control? What about the plugins?
- Who’s going to make future changes and do code reviews for PHP WordPress code?
- How will you handle URL setup?
- For SEO purposes, you’ll see differences with blog.yoursite.com (the WordPress default) and yoursite.com/blog. You’ll need to figure out how to get your existing site and routing to play nicely with WordPress. The technical side of this can get a little hairy.
Your engineers aren’t the only ones who will be affected by a WordPress integration. From a marketing standpoint, here are a few key things your team will need to consider:
- How to ensure you get optimal SEO
- WordPress and SEO have a somewhat complicated relationship. There are ways to maximize SEO using WordPress, but your team will need to look into the best plugin options to ensure your blog is getting optimal SEO
- Ensuring consistent branding across your site and blog
- This ties back into customization, but if you want a seamless experience between your site and blog in terms of branding, you’ll need to do a fair amount of customization
- How to reconfigure your analytics on the blog
- If your main app or website has a login and user accounts, you’ll need to determine how to configure analytics across everything because WordPress has its own authentication and user system
- How to achieve end-to-end insight given WordPress has a different authentication system?
- If your main website allows users to log in to an account, then it has its own authentication system then WordPress. So while someone is on the main website and logged in, you can easily gather analytics on them. However, once they go over to Wordpress, that’s no longer the case
Post Setup Considerations
Once your engineers and marketing team are on board and have done all the legwork to add a WordPress-powered blog to your site, there are a few considerations that remain on the horizon:
- WordPress stack ownership
- WordPress is built on PHP. Who on your engineering team knows PHP? If none, who wants to learn it? If no one, then who’s the poor soul getting this responsibility thrust upon them?
- Let’s say a year down the road, you decide to rebrand your main site. You’ll need to work with developers and the marketing team to ensure that your WordPress-powered blog customization is also updated to this new branding to maintain consistency across your site and blog
- Maintaining consistency overall
- Any tiny changes you make to your main site (design, header, footer) will need to be changed separately in WordPress
- Determining who owns maintenance
- WordPress does require maintenance, including updates and backups. You’ll need to ensure those tasks are clearly assigned to someone in your organization (or pay a third party to do it)
- Considering how you’ll scale as traffic increases
- Since you aren’t working solely within the container of your site alone, any scaling considerations for your DevOps team will need to take into account your new WordPress server stack as well
What does this project look like with ButterCMS from Day 1 to Launch?
Now that we’ve peered under the hood of a WordPress-powered blog, let’s take a look at what your project would look like using ButterCMS assuming we have an existing Ruby on Rails website.
First, you’ll need to set up a ButterCMS account. You can do this for free.
Then run the Rails Generator to create URLs, application code, and Rails templates. Note that these templates live in your existing website’s codebase. Butter is a headless CMS, it doesn’t control the look and feel of your blog, your website controls that. Butter simply provides the raw content via a Content API.
Here’s a 60 second video showing the entire process:
Butter provides your content editors the same easy-to-use experience as WordPress.
Butter also provides built-in SEO, scheduling capability, and more. No plugins to install and hassle with.
Now let’s look at the same engineering considerations we did with WordPress and see how they look when using Butter.
How do you deploy this site?
You deploy it the same way you deploy in your current process. ButterCMS melts into your existing tech stack. Your deploy process stays exactly the same.
How does using ButterCMS impact your current deployment process?
Do we need to put this under source control?
Assuming your existing app uses source control (and you are, right? ;) ), source control automatically happens since the code to integrate with Butter’s API lives in your existing application.
How do we ensure the URL setup makes sense?
Same as the rest, this part is easy, as it’s part of your app so your app controls the URL’s. Butter was designed to make achieving your blog at www.yoursite.com/blog dead simple.
Your marketing team will also have questions, but Butter makes the transition to its CMS smooth.
How do we optimize SEO?
Butter allows you to directly manage metadata and SEO in the pre-existing templates so you can add tags, descriptions, metadata, and other information with ease. Butter’s transparency makes it easy to see exactly what you’re doing.
Do we need to reconfigure our analytics on the blog?
No. Existing tags in your main website layout carry over to your blog automatically. Also, if your main website or app has login capabilities and user accounts, you don’t need to worry about integrating analytics across everything. People viewing your blog will be authenticated with your existing user accounts database since the blog and site are all part of the same app.
- Not a concern. Changes made to your main website layout / branding automatically apply to your blog because the blog templates live within the same code base.
- Maintaining consistency
- Not a concern. Remember, it’s one app, so you don’t need to worry about consistency between two separate things.
- Determining who owns maintenance requirements
- ButterCMS is SaaS meaning we handle the maintenance of the CMS platform for you.
- Considering how you’ll scale as traffic increases
- Same as the previous question, ButterCMS handles this for you and we make doing it at scale a top priority. Our platform has served over a billion requests.
Things to keep in mind
So far, we’ve walked you through the typical product journey when using two solutions: a traditional CMS like WordPress and a headless CMS like Butter. There are three key areas where you can see significant differences between these two solutions:
A traditional CMS is a massive piece of software. WordPress has over 1.5 million lines of code. WordPress comes predefined, with tightly coupled templates, logic, and database. You start with everything -- often more than you need -- and then you customize and hack it to mold it to your needs.
ButterCMS is the opposite. You start with a clean slate and build up. Instead of hacking the guts and actual source code of the CMS, you use Butter’s content modeling to create exactly what you need. It was built for that purpose, with no assumptions or limitations for the kinds of content you want to manage.
A traditional CMS requires you to download and host and maintain yourself. As an alternative, you can pay a professional WordPress service to do this for you.
ButterCMS is delivered as an API-driven service, and has nothing for you to host or maintain. Butter hosts the data, the CMS dashboard, and API platform. You simply query our API to pull your content into your application.
A traditional CMS is separate from your existing site or app. Any changes you make (branding, etc.) will need to be made twice: on your existing site and within WordPress. Additionally, any login/user info you have on your main site will differ from that of WordPress, which has its own user and authentication system.
ButterCMS slides into your existing site or app. Changes to your main site will be reflected in your CMS. And you don’t need to worry about login for your blog: people viewing your blog will be authenticated with your existing user accounts database.
Unless you have developers who have the time and know-how to work fluidly with a traditional CMS like WordPress, there is an unavoidable time-sink involved with using a traditional CMS that requires you to get under the hood to really customize your blog. A headless CMS like Butter means a shorter project timeline and a lighter burden on your developers and marketing team.
Why do some people make the mistake of choosing WordPress?
As we discussed earlier, getting WordPress to look and behave the way you want it to look and behave will involve a great deal of customization (i.e. developer) work. This time spent customizing WordPress is time your developers could be working on more important core problems that will drive revenue. Looked at this way, WordPress is a cost-sink. But this isn’t the way most people think of WordPress. Why? Well, there are several WordPress fallacies that obscure the true costs of using WordPress as your CMS. In this section, we’ll explore the WordPress fallacies and learn how ButterCMS is a better solution for your CMS needs.
WordPress Fallacy #1: We don’t need a developer
The first WordPress fallacy goes something like this: “Themes and plugins allow me, the marketer, to do everything I need to do to set up CMS. I don’t need a developer at all.”
This fallacy is based on a mistaken premise: that a marketer can, with a few simple clicks, choose a theme, add some plugins, and voila - a functional blog that fits into the existing website and behaves precisely how you want it to behave. In practice, this simply isn’t true.
You’ll always need a developer to customize WordPress, fix plugins, and do other work to ensure that your WordPress site behaves exactly as you want it to behave.
Since you’ll need a developer no matter what, this leads to a number of other questions:
- What is a better process or system for them? Is it to work in a system they may not be comfortable with (like WordPress’s underlying millions of lines of code), or is it to work in a language they already love working with?
- Which tech stack (WordPress or their own) will they be more proficient (read: cost savings) with? Which will they enjoy more?
- Which CMS - WordPress or headless - will do more for them (maintenance, scaling, hosting) and free up their time for more important and more interesting work?
The answer to all of these questions is that a headless CMS is likely your optimal solution. It means your developers can work with a tech stack they already love, meaning they’ll be more satisfied and efficient. Developers are less likely to push back when they are working with something they already love, and the marketing team will have an easier time working with happy developers. And developer time saved is a huge benefit from a cost perspective.
The reason ButterCMS exists is because the WordPress architecture isn’t optimal for every scenario. In fact, it’s suboptimal for scenarios where you want full control over the presentation layer (i.e. design of your website) and deep integration with your existing tech stack. In other words, once you have a need beyond hosting a simple WordPress install and purchasing an off-the-shelf WordPress theme, you enter into a scenario where diving into the guts of WordPress becomes required.
WordPress Fallacy #2: WordPress is “free”
WordPress has a lack of transparency about total cost of ownership
One of the biggest draws of WordPress is that it’s free. But is it really?
The short, WordPress sales pitch answer is, “yes.” It’s not a lie: you can get the files you need to set up WordPress and run it -- on a basic level -- for free. However, when you are using WordPress in any way other than a very simple blogging tool with minimal to no customization, the total cost of ownership is significantly more than $0.00.
As we’ve already discussed, developer time is a significant cost if you want to customize WordPress to match your existing site. Some simple math will tell you the approximate cost of having a developer (even a freelance developer) dive into WordPress to customize it for you by ripping out the parts you don’t need, fixing buggy plugins, etc. If it takes three full weeks (a conservative estimate) to customize your WordPress blog, take those 120 hours and multiply it by the developer’s rate. Suddenly you’re looking at thousands of dollars just to get your WordPress site to play nice with your existing site.
On top of that, there are other “hidden costs” associated with WordPress once you step outside the off-the-shelf templates and basic hosting. This article does a great job of shining a light on some of those hidden costs which include, but are not limited to:
- Domain registration
- Premium theme
- Premium plugins
- Developer fees
- Security services
- Storage and backups
Most critically, WordPress’s “free” model doesn’t take into account the most invaluable resource you have: time. Software is only really free if you don’t value your time.
Below we’ll be reviewing in-depth some of the problems with WordPress and how a headless CMS solves these problems.
The problems with WordPress
When an off-the-shelf template and basic plugins aren’t going to make your blog look and behave the way you need it to look and behave, some of the problems of WordPress become more obvious.
WordPress is bloated
A complaint that developers often raise about WordPress is that it’s bloated. They aren’t wrong. WordPress has been around for 15 years and has amassed over 1.5 million lines of code. Its themes have additional thousands of lines of code. And it isn’t just the sheer amount of code your developers have to work through if you stick with WordPress. The bloated nature of WordPress means that it can be slow.
When discussing WordPress with ButterCMS, many customers have concerns about WordPress’s speed: “We've historically used WordPress REST/JSON APIs (with the front-end disabled) for the comfort of our writers but are finding it is having significant impact on page load times because the API is slow, isn't really customizable and we are limited in the ways we can query it.”
WordPress requires a lot of security upkeep
WordPress is open source software, which means it is especially vulnerable to hostile attacks. It’s certainly possible to do everything you can to protect your WordPress site from malware or hacking, but it requires a significant investment of time and resources to do so. As an example, here’s a 2018 guide to keeping WordPress secure (warning: it’s long). Failure to keep WordPress updated can open up your site to significant security vulnerabilities that can create real costs (developer time spent dealing with the security breach, paying ransomware, losing business while the site is down).
An even Butter solution
Puns aside, ButterCMS was created to be a better solution for your CMS needs. Butter is a professional, scalable platform that allows you to smoothly integrate CMS into your existing tech stack in a matter of minutes. Butter handles the infrastructure side of things so you aren’t wading through a DevOps nightmare when your site starts to grow. Butter also offers professional support, including 24/7 chat support, integration help, and more.
Additionally, you don’t have to worry about the hidden costs of WordPress with Butter. Here’s how Butter compares on the hidden costs of WordPress:
WordPress Hidden Cost
No cost - use your existing domain
No cost - nothing to host
No cost - Butter doesn’t require them
No cost - Butter doesn’t require them
Butter secures the CMS platform, saving you time and headaches
Storage and Backups
Butter handles all of it for you, freeing up developer time
And by saving you time and the opportunity costs that come with time spent customizing and worrying about WordPress, Butter offers you peace of mind and the opportunity to do more interesting and profitable things.
How to switch to ButterCMS
At this point, Butter might seem like the right ingredient for your website. But how do you get started with Butter? We’ve laid out a few scenarios depending on where you are.
No existing WordPress site
If you don’t have an existing WordPress site, you can give Butter a try for free here. You can get setup in minutes and start publishing content.
You already have a WordPress site
Butter can help you transition from WordPress to ButterCMS with no switching costs. You’ll just need to follow a few simple steps:
- Send us your export. You can access this here: https://en.support.wordpress.com/export/. We handle importing everything (text, seo meta, categories, images, etc.)
- You implement Butter into your site
- Implement URL redirects (optional)
- If your blog is on a subdomain (blog.yoursite.com) you will want to implement 301 redirects to your new improves URLs
- Butter lets you keep your same blog URL slugs (i.e. blog-post-slug). The difference (and one that will improve your SEO a great deal) is that you will switch from blog.example.com/blog-post-slug to example.com/blog/blog-post-slug
- If you’re currently on a blog subdomain (like on WordPress), you can find a WordPress plugin that helps with 301 redirects
You are using a non-WordPress CMS
You can also make the switch to Butter from other CMS systems out there. If you’re using something like HubSpot or Medium, the switch to Butter is just as easy. Send us your export file and we’ll handle the rest.
A smooth transition
Butter was built to make developers lives easier. By extension, using Butter instead of a traditional CMS like WordPress will save your team time, headaches, and money. WordPress has been around for 15 years at this point, and while it is often the default CMS for businesses and individuals, it may not be the right fit for you. Butter is a modern approach to CMS and will save you from having to churn through customization and security headaches.
Don’t miss a single post
Get our latest articles, stay updated!