You may have heard the term content management systems (or CMS for short), though maybe you're not quite familiar with what it really is and does.
They're one of those things that's both a crucial component to having an easy-to-update website but also obscurely flies under the radar with most non-developers.
If your brand has a website, and that website requires any sort of updating, you're in the right place to learn about your options.
This article will cover:
So, what is a CMS, anyway?
The short definition
A CMS is a platform that helps developers create a good tool for editors to edit content. It makes a website easily updatable as it’s a way to edit your content without having any coding knowledge.
The long definition
Essentially, a CMS is just a way to manage content—whether it’s text or images or other types. Typically, it has the ability to have multiple users contributing and editing content with different levels of permissions—that’s its main job.
The most common use, though, is to have both the editing and the website be a part of the same platform. Really, a CMS’s purpose is to manage content such as text, images, rich media, videos, and anything else that falls under the category.
The real benefit of a content management system (CMS) is to make it easy for non-technical people to manage content that will be delivered in some sort of way—the most common of which is through a website.
You don’t necessarily need to use a CMS as a front end to your website; it could also deliver the content through something like an API which is then parsed by different applications (website, mobile app, etc.).
Technically, you can separate the front end part of the website from the CMS. For example, you can create a blog article and then use some other static website to push content to it—or rather, the website reads content from Drupal. The CMS doesn’t have to be built into your website; you could easily separate content and delivery if need be.
What are the components of a CMS?
Basically, a CMS handles things like:
- Creating and managing content
- Being able to have multiple users
- Assigning different levels of permissions to each user (i.e. some users can only edit blog articles, some can edit everything, etc.)
- Managing some sort of media library (just images, images and videos, etc.)
- Being able to edit and create content through some sort of easy way like a WYSIWYG (“what you see is what you get”) or a quick edit tool
- Being able to automatically form clean URLs based on what Google would want
- Automatically generating a sitemap for you when adding content so that Google can just read that and you don’t have to manually create it
Overall SEO friendliness for your site is a big component of a CMS, with the sitemap generation being a key benefit. Without a CMS, you either have to write your own sitemap manually—which most people wouldn’t even know how to do—or you just wait for Google to (eventually) figure out that that page exists, which can hurt your ranking opportunity on search engines.
Therefore, it’s much more efficient to just have your CMS create a sitemap for you because Google will read the sitemap every time it crawls, and if it sees a new page, it’ll know it needs to crawl that page and figure out what it contains.
However, if the sitemap is not there to guide the crawlers, it may or may not find the page eventually. While there are ways around it (like having a link to that page from another article, allowing Google to follow through and find a new page), it’s a lot faster to have the CMS generate a sitemap.
Usually, the CMS will take care of things like menu systems, too: if you have a primary menu at the top of your page, when you create a new page, you can create a menu item for it and it will automatically highlight it when you’re on that page.
Without a CMS, there’s a bunch of coding you’d have to do to figure out which URL is tied to which page, identify the associated top menu item, then manually link the two to display correctly together. Back in the day, we developers would have to manually do that, and it was a pain in the ass.
A CMS also helps build some of the UI because you’re not starting from scratch anymore—you don’t have to write anything with a database; instead, it creates tables for you when you create a new type of content.
For instance, if you create a blog article and you say, “ok, a blog article always has a title, body, etc.” and you create those fields, the CMS goes in the database and creates a table, columns, and stuff like that so you don’t have to write any of that code yourself.
As for whether you need to have any coding knowledge to use a CMS, it really depends on what you want to do, how the website was coded, and how the CMS was enhanced. Typically, you shouldn’t have to have any coding knowledge, especially for updating content through the CMS as a user.
Benefits of using a CMS in your website
For developers...
It’s nice to not have to rewrite a bunch of code every time. I love that you can create content types, match fields within those content types, and then those forms are automatically built for you in the backend, and sometimes you don’t have to write any code for functionality, which is nice.
For non-developers...
It’s nice that you can just fill out a form and it builds pages for you.
If you didn’t have a CMS, you’d have to call your developer every time you wanted to make a change, no matter how small—even updating a tagline or changing an article title count.
There may be other ways to set it up, like creating an article on Medium that automatically pulls in to your website, but overall, if you didn’t have a CMS, you wouldn’t be able to edit your website; you’d have to call a developer.
It’s important to note that there are types of websites that don’t necessarily need a CMS, and the most common of these is web applications—Gmail, Groupon, Pinterest, and so on.
In cases like those, the actual webpage where you’re browsing has no need for a CMS because there’s no content to edit.
When you’re creating or editing an app, it’s not the same process as when you’re creating a website for marketing your brand—you usually go through a big workflow. For instance, if you want to change a button title or name in the app, it goes through this whole process: the product manager decides if they want to change the button name, then it goes to the design phase, development phase, testing phase, approval phase, and then it finally goes into production—with apps, you can’t just go in and change a button.
That’s because, usually, everything is version-controlled, meaning it lives in the code, so it can be rolled back and it’s a lot more enterprise-focused as opposed to someone quick-editing content.
Simply put, if you’re updating any type of marketing material, then you need a CMS.
If it’s a web application, then you don’t have to start with a CMS—you could, but it might be too much overhead and probably not the smartest idea.
Basically, any marketing site should have a CMS. Sometimes it’s good to decouple the CMS and the webpage: for example, Pinterest might be running on Rails or something, but then they might have WordPress or Drupal to manage some of their frontend marketing content, which then pushes to the Rails app. It depends on how quickly the brand wants to make changes or if the marketer wants to make changes without involving the development team.
Sometimes the business doesn’t want that—maybe they don’t want the marketer to be able to change the tagline because that has to go through an approval process. Other times, they may have a system for updating the site, or they don’t update their site regularly enough to need a CMS.
Pros and cons of a CMS
Pros
It’s going to cost you less because you’re not starting from scratch—if you want something you can regularly update, it’s going to cost you less to go with a CMS.
Drupal has been out on the market for 17 years and has accumulated a lot over the years. Imagine developing all of that—it’s crazy; it would take me years to write the code that makes Drupal or WordPress what it is.
If a small business hired a developer to build all of that, they’d have to build a user management system, logins, password resets, permissioning, backend pages, WYSIWYGs, the ability to upload files and images, the ability to crop...everything. It’s all built in to the CMS so that you don’t have to build it.
In short, the big pro is that you’re not starting from scratch.
Another pro is that you can edit content easily with a CMS as we’ve touched on before.
Cons
Typically, CMSes are not the fastest thing to render; there’s a lot of overhead because there’s all of this code that’s written to manage stuff, so sometimes it could be slower than just having a static website in terms of loading times.
You have to work with which modules are available from the community (or your CMS), otherwise you’d have to write it yourself and build that module.
Most of these CMSes are open-source so it’s a pro and a con: the pro is that the community works together to make the CMS better; the con is that you have to wait for other people to write a module or fix a bug. You can go in and fix it yourself, but it’s probably not worth it.
The amount of control you have over editing your website is all dependent on how the developer sets it up: if you have administer control and you can see everything, then you should be able to edit most of it, but the CMS doesn’t restrict developers from just hard-coding content on the website, too.
For some brands, it’s really important to be able to edit every single piece of text on the website because of legal purposes or otherwise, so there’s nothing on the site that can’t be changed by them as a result.
Meanwhile, other websites using a CMS are much more restricted. On one of our client’s website, there’s a place where it displays a case study. The marketer can go in and select which case study to showcase, but there’s a small title on top of it that says “Case Study” that I hard-coded in because I didn’t want the marketer to change that; I wanted it to be static so that that always shows.
As a developer using a CMS, I restrict the user control because I don’t want them to go in and change stuff, delete stuff, rearrange how things are shown—I want them to be able to edit content without breaking any of the design, so I don’t give them any control in terms of how the page is laid out; I only give them control on what’s displayed. They can’t move the banner above the menu, for example; there’s not that level of control. It’s definitely a fine balance between flexibility and ease of use.
At the same time, there’s no restriction for me, as a developer—I set up the level of content that can be edited and how much can be edited. So, if you’re frustrated with how restricted your CMS is currently, talk to your developer to find out why that’s the case or to gain more access.
Typically, I don’t even give clients the option to use colors outside of their palette because it goes against the site’s design. It’s harder to edit when you have too much control anyway: sometimes, they want to create a new page outside of existing ones and they don’t really know how to do it—it’s too plain, there’s no banner; it just doesn’t look good.
For best results, you should know all the types of content that live in the website prior to getting the CMS all set up—blog articles, testimonials, team bios, and so on. We could always go in and add it later, but it’s easier to do from the start.
Drupal vs. WordPress vs. Other CMS Solutions
In the past, I’ve written a whole blog article about why Drupal is my favorite CMS.
To quickly summarize, here’s why it’s our preferred CMS:
- It’s secure
- It’s built by developers, for developers
- It’s flexible and maintainable
- It’s open-source and robust
- It has contributors around the globe
Even though we (clearly) think Drupal is awesome, it’s important to point out that there are plenty of CMSes to choose from.
No CMS is definitively the best because they all kind of steal from each other. Most CMSes have their own community and people don’t really jump between those; they pretty much pick a side and stick with it. The two top CMSes are Drupal and WordPress, but there are others, including older ones like Joomla.
Other CMSes are more specific, too—there’s one called Magento that’s very ecommerce-driven. Though you could do ecommerce in WordPress or Drupal, in Magento, you’re choosing it because it already has ecommerce built in and you don’t have to add modules to create an ecommerce site.
The reason for the variety is that the purpose behind the CMS will differ: Drupal and WordPress are more bare-boned; they give you the essentials and then you build on top of them. Others give you the essentials but also give you something like ecommerce, where you wouldn’t use that kind of CMS for a marketing site because everything is built for shopping—there are shopping pages, products, checkout, all that.
However, you don’t necessarily have to use an ecommerce-specific CMS for an ecommerce site: we used Drupal for Oyster Kits because we’re familiar with it, but it is more work. Ultimately, which CMS you use becomes the developer’s preference—sometimes agencies will pick a CMS depending on what needs the client has; other times, the selection is based off of what CMS the agency is most skilled in using.
There are also online CMSes (such as Woocommerce, Wix, or SquareSpace) where you don’t download anything and they’re not open-source. Some of those, though, you can’t add functionality. You may be able to edit the theme, but usually you can’t add more features because the company owns the code, so that’s a big limitation there.
So the main difference between CMSes is: their community, brand, purpose or function, and available modules.
Most of the CMSes come with modules that offer the same functionality as other CMSes. It’s hard to see someone pick WordPress because it comes with a specific module they want to use as usually, it’s more about functionality. Think of it as the difference between going to Target or Walmart—they both have food, clothes, and overall similar products; it’s just that you like one more than the other. It’s where your loyalty lies, what you prefer at the end of the day.
WordPress has a bigger community; it’s more hip, but it’s also the biggest brand. That means they run updates a little more frequently, they have a better design team than Drupal does, and they’re just the biggest website builder so they’re a little more organized with funding than Drupal is.
Drupal and WordPress are both written in PHP, but they’re completely different code. They run on similar backend stuff—PHP, the same database structure—but they’re two different code faces and two different communities.
In terms of setup, you could almost set up WordPress yourself without having any coding knowledge; you can kind of play around with it and figure it out. And while you’re going to start with a template and just go from there, it’s a pretty decent one at that.
It’s perhaps a little less complex there, but it also has its drawbacks: it’s not as flexible because it’s not as complex. Customization kind of correlates with the technical complexity, so the easier it is to set up, you’re more limited overall.
WordPress is more aimed toward freelancers—people who may not know how to do backend coding but can do some frontend coding and then create their own template, play around with it, download a bunch of modules or plugins, and so on. It’s more aimed toward that level and scale of use, though there are big sites running on WordPress, too.
When setting up a CMS, it really comes in two forms: setting up all the content types and then using those content types to create a theme that then you can plop content into.
To get started, you grab your developer, tell them which CMS you want, and they’ll download the CMS and install it. It’s important to note that you can’t just add a CMS to your website; it becomes your website. So if you have a website already, you can’t simply add Drupal to it—the CMS is what controls the content and how it displays too, so it’s impossible to plop Drupal on top of some other website.
When you’re choosing your CMS, first you pick the CMS, and then you build the website on top of it. When you download the CMS, it’s just a bunch of code. Once your developer installs it, it creates some database stuff and comes with one basic content type called a “page,” but it still comes with all of the backend stuff, too.
At Herosmyth, we don’t start from scratch in Drupal; we have our own version of it because I’ve already downloaded all of the modules that I need, I’ve written modules, obtained the 3rd party modules and custom backend theme, and so on. There are modules that you know you’ll always need, so you build on it based on prior knowledge as things come up. Instead of cloning the Drupal CMS from their website each time we start a new project, we take the basic Drupal CMS, make it better, and offer that customized one as our starting point.
Cost of a CMS
The two big CMSes, Drupal and WordPress, are free to download because they’re open source, but they do charge for hosting. Other CMS-like platforms, such as SquareSpace or Wix, typically charge users for hosting, too, and don’t require downloading anything since the CRM functionality is built-in.
For Drupal, all of the modules are free. Not all modules for WordPress are free, which means they’re not open source, so they could be riskier in terms of security vulnerabilities—a module could be made by some random person who may or may not know what they’re doing, so you never know what you’re actually going to get. In that case, WordPress modules are sold without being verified by a larger community, which adds a level of risk.
Only the WordPress CMS is backed by a guarantee from WordPress itself—they actually hired a big team of security experts about 5 years ago because they were doing so bad with getting hacked often.
That’s good, but Drupal has a community where the modules made by people are also backed by Drupal—essentially, if you’re getting any module, you’re usually more safe with Drupal than WordPress.
If you don’t have a CMS, though, you end up paying per every update to your site; you could hire a kid who will do your website for $500, but there’s no guarantee of quality there. Then, that developer may charge you $50 per update after that, so you can save money by not building your site on a CMS but the quality will definitely suffer—and then you can’t instantly update the site, too, plus you risk spending more money if you have to make changes to the site regularly.
In short, having a CMS is the faster, cheaper, and easier solution for brands’ websites.
