Updated January 12, 2023
Reading Time: 5 minutes
Wrapped in Short Code
WordPress developers are divided in their opinions about using a visual composer theme. It looks like we struck a nerve with our Divi post. Therefore, it warrants a follow-up, examining some clarifications about nomenclature, a client’s ability to maintain their content, portability across themes, using theme frameworks, and its impact on SEO.
Known By Other Names
In our previous post, we used the term “Divi” referring to a popular visual composer theme created by Elegant Themes. It has name recognition in WordPress circles, kind of like “Kleenex.” When we referenced “Divi,” we used the term to be synonymous with visual composers, page builders and drag/drop design systems in general. Our analysis was not specific to the Divi theme; rather it was directed to the drag/drop or visual approach of building a WordPress page or post. In essence, page builders or visual composers create islands of content surrounded by shortcode. More on that a little later.
Is It Really Easy for Clients to Manage Content Without Understanding Code?
One of the major arguments in favor of visual composers is the ability for clients to “build everything visually on a page” without the need to understand CSS or other code. We work with clients that have visual composer websites (not created by us); all too often they find it difficult to navigate the system and make their content behave like the vision in their heads. Even with detailed how-to guides, video tutorials, and built-in controls, time and again they ask us to add and optimize content for them.
Just like any kind of software, it takes practice. MS Word’s menus and text formatting, for example, can be confusing at first to the novice. So, can clients figure out the visual interface and maintain their own content? Yes, they can. They can also easily add content using a non-page builder theme. They both take a bit of effort. That’s just the nature of website management regardless if it is in WordPress, Joomla or any other Content Management System (CMS).
WordPress Updates, Theme Frameworks & Longevity
Now a word about website maintenance. WordPress’ software automatically updates its core code when it involves security. This is built in; clients don’t have to worry about it. What’s not part of those automatic software updates are upgrades or changes to plugins and themes. That’s a manual process; you need to log into the backend and upgrade specific plugins. 95% of the time there aren’t issues especially if you choose plugins from reputable developers. However, some plugins don’t keep up-to-date with WordPress versions and can break. Then more intervention is needed. This is the case regardless of what WordPress theme you choose.
Another important element when building a WordPress site is not to touch the core code. Nor should you modify the core code of a theme. When you do, it causes all types of problems that makes ongoing maintenance and security a nightmare.
Most developers have a favorite theme framework. Ours happens to be StudioPress’ Genesis framework (note: we’re an affiliate). It has clean code and a good reputation. When we create WordPress sites, we work with a client to choose a theme that has the features and functions they desire. Then we create a child theme — a copy of the original theme — that we modify. We don’t “hard code” changes within the Genesis theme as doing so will create havoc when updates are rolled out by theme developers. By using this child theme base, we eliminate hours of custom coding and can focus on tailoring the look and feel based on a client’s needs.
The Web is changing at break-neck speed. It’s unlikely that a website designed for a business four years ago still fulfills their needs. It’s common that a business’ website needs change over time. Technology evolves. Trends change. A good rule of thumb is to re-invest in your website every two years or so.
The beauty of WordPress is the ability to redress the look without having to migrate content. The analogy we use is this: WordPress is a mannequin; themes are the clothes you put on the mannequin. You can change the look and feel of a website (the theme) without having to migrate databases and code (the WordPress platform). Building on a child theme, you can customize or tailor the site so it’s unique. To further our mannequin analogy, we can alter a garment to the point where it looks like haute couture.
If a business is focused on visibility in organic search (building SEO), they are most likely creating new content (and a lot of it). At the end of 2-3 years, they should have a healthy and large library of content. Which leads us to the next sticking point… the ability export off a visual composer-based theme.
Visual Composer Portability: Exporting Content
One major concern with page builder themes is the ability to pull out content and port it into a different non-visual composer theme. Remember those islands of text surrounded by shortcode we mentioned? Extracting a page’s content without the shortcode can be problematic.
After peeking at the Export/Import Feature on the Divi Builder Layouts, it looks like this function allows you to port content (via .json files) to another Divi site… not to a non-visual composer theme. So that makes a client trapped into the theme. Migrating to a new (non-visual composer) WordPress theme and importing existing content isn’t easy. We agree with Chris Lema’s analysis; we suggest you read his “If you use the Divi theme with WordPress, it better be forever” post.
Visual Composers Slows Down Page Speed, Thus SEO
Page speed is one element of SEO, a very important one. Because of all the shortcode loaded onto each page with page builders, it slows down the page load speed. A lot. We’ve done multiple speed tests comparing non-Divi like WordPress sites against visual composer sites. Note: we are partial to StudioPress’s Genesis theme framework as the code is clean and fast.
With that said, if you add enough plugins and other add-ons to any WordPress site, it can negatively affect page speed. One pro-visual composer developer commented that Yoast (one of our favorite SEO plugins) can be a speed hog. As with anything, you have to weigh the benefits against the cost to site speed.
Yoast is one of those plugins that provides significant value over any other SEO plugin we’ve tested. It’s a conscious choice on our part as a WordPress developer to use this plugin. Without it, you run the risk of using default metadata (depending upon theme settings)… something we never recommend based on our 10+ years of hands-on SEO experience. Yoast allows our clients to craft their title tags and meta descriptions, elements that are integral to their SEO. We also mitigate the speed problem with caching, photo smushing, and other techniques to optimize load times.
What’s Right For You
If getting visibility with search engines (Google, Bing, etc) is important to your business or personal website, then consider alternatives to a visual composer framework. You’ll want to pay particular attention to speed and foundational SEO elements like metadata. Google is specifically rewarding websites that provide a great user experience — which includes quick load times, no errors, and content that’s new and contains quality (helping searchers find the answers they want and need).
Photo credit – Kerstin; Kiran Foster, Torbakhopper, Christopher Ross
Mobile Device Habits Examined
I read the original Divi post and this one. I wholeheartedly agree with these articles 100%, and my personal experiences in client work are exactly like how these articles described.
I contend that there is no way around learning at least the basics of HTML and CSS if you want to be serious about SEO. It’s relatively easy to hit the limitation with those visual builders. Once you hit the limit, you will have to deal with custom codes, and there is absolutely no way around learning HTML/CSS at that point, which, by the way, is NOT that hard to learn. I have to say that HTML and CSS have become somewhat of a rubber dragon at this point. Learning all the quirks of visual builders such as Divi is, in fact, more complicated than the HTML and CSS languages themselves those visual builders are ostensibly designed to simplify.
I think that the biggest irony of “no code necessary” tools such as Divi is that those who could code HTML/CSS responsive layouts by hand are the one who could get the most out of visual builders (IF they chose to use it). They could see how a visual builder abstracts HTML/CSS coding in its GUI because they know the code. But then what happens is that you will hit the limit sooner than later because GUI could cover only so many variables. That’s why most of them have an admin panel where you inject handwritten codes. At that point, users of those tools painfully realize that knowing how to code *is* necessary after all.
Furthermore, there’s the question of whether clients are even well-suited to make a variety of changes in the first place. They’re probably not professional copy editors, and they are probably not knowledgeable in SEO and how it works. So, you might be giving them the rope to hang themselves by giving them an environment such as Divi. They should either learn enough to do things the proper way or hire someone who can. They most often have no problem doing that for their house (hiring a plumber to fix their kitchen sink) or their car (have an auto mechanic change the filter of their vehicle). Their difficulty with doing that for their website puzzles me to no end.
And that leads to yet another problem with visual builder tools; they give users a false presupposition that good web marketing is about look and feel. It encourages clients to buy into the idea of building the frame first and then drop the content in later. It’s completely backward. Building a website is ultimately about contents, and semantic code is a part of essential product quality. They are important for effective SEO. Visual builders such as Divi encourages a backward process that takes what should be the top priority (contents, code, etc.) and saves it for the end, in the name of “ease of use.”
I hope more clients will come to understand the points of your articles.
Sam, you make several good points, especially about understanding how to create clean code. I hope that the Divi and Visual Composer fad comes to an end… but not before they develop an easy way to extract content from the shortcode. Otherwise, clients will be held hostage.
EXACTLY. Chris Lema has written about the Divi shortcake problem.
It bothers me to no end that so many people, even so-called professional WordPress developers, seem to think visual builders are a good idea. It goes against every principle that the industry fought for; separation between contents and presentation for a maintainable website, semantic HTML for better accessibility, cleaner and lighter code for mobile UX, and so on. So much focus on “around” stuff (= appearance), not enough focus on “it” stuff (= contents). More additional layers of unnecessary abstractions for the sake of “ease of use” while, ironically, making things more complicated for end users. It’s a mess.
Yes! While I agree that a website needs to be attractive and easy to navigate, it’s the content that drives a business. Focus on providing value — by writing content that informs, helps and challenges your readers. Then, you’ll succeed on the web.
Thank you for both these posts. For our previous website, we could not get the side to be faster to rank highly for Google SEO tests (even with tons of compression and SEO consulting help). And now I realize the issue must have been with Divi.
I use Divi on multiple sites, including my own. With several other plugins we often get page load times < 3 seconds and PageSpeed scores of 85+ for both mobile and desktop. I often use some code in functions.php to improve performance (to do minor things like remove query strings and defer js) but the biggest improvement I saw was when we moved from GoDaddy to a better host. There are a number of factors that can influence PageSpeed, and a number of ways to mitigate them, but IME with Divi it doesn't necessarily have to mean poor page load times. The most common major issues I see on sites performing poorly on PageSpeed have to do with caching and not serving properly scaled and optimized images.