I’ve separated this article into a short version and a long version. This one is the long version. If you aren’t into the gory details, then check out the short version before continuing.

WordPress is a wonderful tool for a lot of different use cases, but let me help you understand why I don’t use WordPress. Yes, it is free to use, open-source, extremely popular, and modular. It’s popularity is what makes it easy to use and it makes a quick Google search the go-to solution to many problems. Wait… what was that last word?


No Testing Environments

If you want to make changes to a WordPress site, you will be making them on a live website that could have active users on it. There are exceptions to this of course, but in 2 years of running a web design business I have never met an owner of a WordPress site that maintains more than one version of their site for testing and development purposes.

When developing software of any kind there is a standard process to follow that involves making changes or adding features to the code-base in a development environment. The development environment is basically a sandbox where the coder can try things without fear of breaking anything for current users of the software. After all changes in the development environment have been tested, code is then pushed to the production environment where it becomes live for all users. Sometimes there are also intermediate testing environments between the development and production environments for integration and end-to-end testing. The development and production environments are totally separate from one another to ensure production environments are running code that is completely tested before being put in front of users.

When working with a WordPress site it is nearly impossible to maintain a separate environment for development and testing. This is because WordPress relies on a complex architecture to deliver even the most simple web pages. This complexity is why traditional software tools that are used to maintain software versions (like Git) can’t work. Software versioning is file based.

In version 1.0 you have files X, Y, and Z each with some content. In version 1.1 only line 2 has changed in file Z.

Since WordPress sites depend on files AND a database to render even the most simple web content, traditional versioning tools just won’t work. Ambitious people have tried. See versionpress.net for an example. However, continue on and you will find at versionpress.net/#get there is a very bold note that says:

We’re still developing it and there are known limitations.

Here are some of the benefits of versioning that WordPress is missing out on:

  • Version repositories serve as a backup by default. No extra steps are necessary. If you’re using WordPress however, you’ll need to dig through an article like 7 best backup plugins instead.
  • Versioning tools allow multiple developers to work on a project at the same time without stepping on each others toes.
  • Testing environments are easily created and duplicated.

Hire a new developer? Simply run one command to get your own fully functional development version of my website:

git clone https://WebsByTodd@bitbucket.org/WebsByTodd/websbytodd.git
  • Versions can be Tagged to easily find later. There’s a complete standard for Semantic Versioning out there! I’m sure you’ve seen something like this before right? Windows 10.1 ring any bells? 10.1 is a semantic version number.
  • If an issue is introduced into a production environment because, let’s face it, mistakes do happen. With versioning tools the environment can easily revert back to an earlier stable state. Misspell something in a PHP file of your WordPress site and good luck finding a way to fix it!

My Time

I have all of the necessary skills to edit HTML, CSS, and JavaScript, which are the three types of files that make up any web page. I don’t need a visual web-based editor to help me do this. Actually, the visual editor makes this process slower, because I have to figure out how to tell the visual editor to edit the file that I’d like to edit myself. Once I figure it out, I then have to navigate through the WordPress dashboard by clicking links. Each link click then makes me wait for the page to reload. If you are paying me an hourly rate, you will get more for your money if you don’t make me use WordPress.

The WordPress Database

Entire web pages are stored in a database. Each time a visitor to a WordPress site requests a page, the server needs to retrieve information from the database, organize it into web files, and then send it to a user.

This is incredibly slow!

No web server should make the user wait before it can show the user a web page. WordPress sites do exactly that, which is why they are often penalized for slow load speeds by Google.

See the difference for yourself by comparing PageSpeed Insights of WordPress.com to JekyllRb.com (a free and open-source static site generator).

PageSpeed Insights for jekyllrb.com PageSpeed Insights for wordpress.com

See how your site fares by entering your URL into Google’s PageSpeed Insights.

Databases should be for data that needs security (like passwords), long lists of data with the same structure (like contact information), or application data that changes over time (like prices on Amazon.com. If any of this data needs to be displayed on the webpage it can be displayed after the other static content is loaded without impacting the site’s page load speed and a user’s experience.

40% of mobile users click away from a site after just 3 seconds if it hasn’t loaded yet, according to the AMP Project.

The reason it’s so hard to create testing/development environments for WordPress sites is because the WordPress database stores rendering information in addition to security, lists, or application data. We can’t keep version history of page content and page design when it’s all in the database.

WordPress Is Too Modular

There’s probably a plugin for anything you desire in WordPress. In fact, there are probably 100 plugins that all claim to be the best. So how do you choose the right one for the job? I’m a big fan of modularity to prevent reinventing the wheel and to allow for exponential growth and creativity, however, WordPress plugins can come with all sorts of nasty side effects.

  • Security flaws
  • Incompatibility with different WordPress versions
  • New menu items on your Admin dashboard
  • Loading duplicate data other plugins have loaded
  • Conflicting styles with other plugins/themes

Unless you dig through the code, you don’t know what secure information in your database the plugin will try to read. All it takes is one mistake, whether it’s your mistake or a mistake by a plugin developer, to leak all of your user’s passwords to the whole world.

Plugins compete with one another load JavaScript and to style certain objects. This sometimes leads thousands of lines of duplicate JavaScript code (PageSpeed Insights again?). There is no hierarchy in place so often one plugin will get blamed for causing a problem when the flaw is in the model, not the plugin.

Often plugins try to ensure precedence by using the !important CSS flag. Unfortunately, this prevents future precedence. For example, a paid theme uses !important to define the maximum page width. If I want the header width to be a different width (Like 100% instead of 800 pixels) I have to compete with an !important flag in my custom stylesheet.

Ugly Stuff

Ever see “&nbsp” in your code? Probably not, but if you’re using the WordPress editor to write your content this is being added frequently. Often it shows up in places like the meta tag where your page description goes. “&nbsp” is a character that tells the web browser how to render words on the page. This is totally unnecessary in header information that is not being rendered.

Also, WordPress is PHP based. When PHP get’s complicated, it get’s ugly. PHP and HTML mix and PHP makes it super easy to output HTML while the server is processing a request. This allows WordPress to render data as it becomes available, however I don’t think the inventors of PHP anticipated the rats nest of tangled PHP and HTML in a lot of WordPress PHP files. It gets especially confusing when rendering quotation marks, which are also necessary when defining an HTML attribute.

if ( ! empty( $previd ) ) {
  ?><a rel="prev" href="<?php echo get_permalink($previd) ?>"><i class="fa fa-angle-<?php echo esc_attr( $left_class ) ?>"></i> <?php echo get_the_title($previd)?></a><?php


A lot of these reasons are very technical in nature, so if I lost you as some point don’t feel bad. I’ve spent a lot of time engineering software, and a website is essentially a piece of a software. Other web designers who use WordPress have probably spent a lot less time engineering software and a lot more time in sales and marketing. For these people WordPress is a fantastic money saving tool because they can use it to have a website that is good enough for their needs. With my in depth knowledge of HTML, CSS, JavaScript, and web server languages like PHP and NodeJS, WordPress just gets in the way. It’s like having training wheels on a bicycle. You just can’t take the turns as quickly with the training wheels on.