Date:September 24, 2026
One of the worst, but also funniest, website mistakes I have seen over the years came from a website owner who had changed almost the entire site to H1 tags because he wanted the text to be bigger.
It is a little like producing a newspaper where the largest front-page headline is used on every single page. The result was a website with very little structure, and it was not exactly a great setup for SEO either.
How did it happen? He was using a page builder.
WordPress page builders are a subject I could talk about for a long time, and I do not think the answer is as simple as saying that builders are either good or bad.
They can be very useful in the right situation. I have used them myself on charity projects where the goal was to get something online quickly and allow people without technical experience to build and edit pages themselves afterwards.
The problems usually start when the requirements grow.
If a website needs strong performance, custom functionality or a structure that can be developed further for years, the flexibility that made the builder attractive in the first place can eventually become a limitation. That is why we generally build our WordPress solutions with a more controlled structure and custom components instead of relying on heavy page builders.
This becomes even more important for online stores. A WooCommerce solution can involve product data, checkout, integrations, tracking, plugins and many other technical layers that all need to work together. Adding a heavy builder on top can make both performance and future development harder to manage.
We regularly hear from companies that need help taking over, maintaining or further developing an existing WordPress site. Many of those sites were built with page builders, and we have even seen setups where several different builders were active at the same time.
That is where WebFrankenstein starts taking shape.
It rarely happens in a single day. First comes one small adjustment. Then another plugin. Later, another builder is introduced because it can do something the first one cannot. A few years down the line, the site suddenly consists of multiple layers and dependencies that nobody fully understands anymore.
That technical debt often becomes visible when the company wants to make a change. Something that should be simple suddenly takes much longer. Updates become riskier, performance suffers, and it becomes harder to understand which part of the setup is affecting another. These are also some of the issues we deal with when taking over the maintenance and optimization of existing WordPress solutions.
That does not mean every company should remove its page builder tomorrow. If the setup is simple, works well and still matches the business needs, there may be perfectly good reasons to keep it.
But as a company and its digital requirements become more mature, it is worth asking whether the technical solution has matured with them.
And the story about the website held together by more than 50 active plugins that all depended on each other?
That will probably be the next chapter of WebFrankenstein.