A page builder makes it easier for non-developers to build a custom WordPress website. But WordPress developers (i.e., those who code) argue that page builders make a big mess of your content. And they’re right! Here’s why we should use them anyway.
Disclosure: I am both— a WordPress designer and developer. Until recently, I insisted on coding all new WordPress themes/websites “manually”— in a code editor, starting with my custom, developer-friendly framework to streamline the design and development process. There are still situations when this approach is the best way to go for a new website.
But writing and rewriting good code, especially when you design in the web browser like I often do, takes a lot of time. Although I love to code, it does not lend itself to quickly building functional wireframes; rapid-prototyping; design improvisation; or client revisions.
Secondly, it’s difficult to compete (price-wise) against designers and developers who rely exclusively on predesigned themes, page builders, and/or sloppy coding practices. That’s because many small businesses, eager to save money, are quick to hire inexperienced web designers/developers— until they eventually realize what it will cost to fix or extend their poorly-coded website.
So a few years ago, I bit the bullet and began using a page builder called Divi to build new websites.
WordPress Page Builders Defined
Page builders are especially attractive to designers and novices who can’t code. Want a full-width slider here? Click. Want a 2-column row there? Click. Want a 3-column row of images here? Click. Changed your mind? Click.
Admittedly, that scenario is a dangerous oversimplification— it takes far more than a few clicks to create a good website. The point is, there was no coding required to build that simple layout— at least initially.
Developers Argue that Page Builders Stuff Your Pages with Shortcodes
Yes, page builders like Divi rely heavily on WordPress’ shortcode API (application program interface) to insert complex features like multi-column layouts; slideshows; image galleries; “contact us” forms; buttons; and more. What would otherwise be many lines of code in the WordPress editor is transformed into one very short phrase surrounded by brackets.
The problem is, page builders use shortcodes excessively. That’s one reason why you must use their interface, rather than the WordPress editor, to build your pages.
Developers rightly argue that if/when you eventually switch to a WordPress theme that doesn’t recognize the old page builder’s shortcodes, they will appear scattered throughout the text of your next website!
This is commonly referred to as “theme lock-in”. And opponents often use words like “nightmare” to describe it.
Why Page Builders (and Shortcodes) Aren’t a “Nightmare”
During the 20+ years I’ve worked as a freelance web designer/developer, I cannot recall a single client who frequently redesigned their website. In fact, I’d say the average lifespan of a new website is about 3 to 5 years— depending on the industry the business is in; the pace of technological advances; and how well the website was maintained.
Years later, the text usually needs to be edited or completely rewritten anyway— typically within the writer’s word processor of choice— without any trace of shortcodes!
But what about a blog with hundreds of blog posts that won’t be edited or completely rewritten? Just use the same page builder for your next redesign, and those unexecutable shortcodes will not be an issue.
How to Remove Shortcodes
Even if you can’t, or refuse to use the same page builder for your next redesign 3 to 5 years later— it is highly unlikely you will have a “nightmare” on your hands.
A developer can use a “search pattern” to isolate and delete these no-longer-used shortcodes from your original text.
For example, export the original WordPress database file before the redesign process begins; open it in BBEdit (or your tool of choice); do a “grep” search and replace for “[(.?)]” (without quotes); re-import the cleaned-up database; install your new theme; and begin the redesign process without any trace of shortcodes.
Removing Page Builder Shortcodes is Less Expensive Than Manually Coding an Entire Website
Even if the entire cleanup process outlined above takes a day or two to remove the unused shortcodes from the text of a large blog, you’ll have to pay a web developer for 8 to 16 hours worth of work. And yes, if you’re the client, that would suck.
But manually coding the same high-quality, custom website (yes, without a page builder) will require more development time (and money) to build in the first place— no matter how streamlined the developer’s process.
The time/money saved using a page builder, will more than offset the time required to remove the shortcodes.
Some Developers Argue that Page Builders are Bad for SEO
I searched for recent scientific evidence that current versions of page builders, particularly the one I use (Divi), are bad for search engine optimization, and could not find anything.
Yes, there is some discussion about “code bloat” and page loading times— this is also an argument I’ve used against the use of older page builders and predesigned themes, in the past, as well.
However, if you load any web page built without a page builder with oversized, non-optimized images; lots of crazy parallax effects and animation; pull data from multiple external servers (e.g. social media feeds, ads, images, etc.); install a ton of unnecessary plugins; ignore basic SEO principles; and buy a cheap hosting plan; you will get exactly what you’re looking for— a slow loading website that performs poorly in the search results.
The real problem with page builders is that they empower novices to make bad decisions.
Conclusion
Despite the marketing hype generated by companies that create and market page builders, there is no such thing as a “no coding required” website— certainly not the kind my clients hire me to design and develop. Invariably, there are customizations that extend well beyond the capabilities of a page builder.
The bottom line is that a page builder allows a designer/developer like myself, to spend more time crafting the user experience, and less time coding.