WordPress is a hassle to manage.
Too many plugins, too many themes, too many places where security is not the default.
In the beginning, the pages it generated followed a stricter pattern, which limited creativity. Over the years plugins and page builders appeared, such as Visual Composer, then Elementor, and a variety of themes, each with its own learning curve and all with more creative freedom.
The catch is that every new client and every new site entered at a different moment in that history, which left a legacy to support, or a pending migration to the new tool. On top of the complexity of integrations and incompatibilities, each one makes the site slower, and we have to train team members for each case.
Plugins and themes are a separate problem. The structure of WordPress is insecure by nature: any plugin can change the entire database and any WordPress file.
Wordfence, a security tool for WordPress, finds more than 200 security vulnerabilities per week (see the list of vulnerabilities), sometimes more than 500 in a single week.
In addition, some tasks required paid versions of themes and plugins: more subscriptions to manage and renew every year.
Then comes the dilemma: keeping plugins and themes up to date matters for security, but every upgrade risks breaking the layout and the plugin integrations. Not to mention supply chain attacks.
In short, maintaining WordPress is a burden for your IT, Security and Marketing teams.
Where WordPress was good
I recognize the importance the platform had in democratizing blogs, pages and ecommerce, but I think its time has passed.
It grew, the community grew along with it, it created a lot of jobs and powered many sites for many companies.
I can't imagine running a site that publishes content, with an editorial team and many people contributing, without a tool like WordPress, but there are other CMSs (Content Management Systems) on the market, often more specialized for that job.
As an example, EmDash CMS, launched by Cloudflare (emdashcms.com), has the same editorial approach as WordPress with multiple contributors, and even the interface is similar. It is still a new project, but its differentiator is that it is natively secure.
For individual writers, Blogger has been around since before WordPress, and Medium even solves the subscription question.
For e-commerce, there are more specialized platforms integrated with payment providers, carriers and marketplaces.
Where WordPress is not necessary
Most WordPress sites belong to small and medium companies, which chose the platform so their team could publish content easily. These use cases serve few of them.
Companies that generate very few news items, about events, trade shows and product launches, at a very low volume, of three posts per week at most, sometimes as few as one per month.
They usually have a lean marketing team, balancing events, advertising budget and internal marketing, and from time to time having to chase after the site because something broke.
These companies tend not to update WordPress, leaving security to luck, to avoid breaking the site because of plugin incompatibilities. With 200 vulnerabilities per week, it is only a matter of time until they are breached.
The aggravating factor
The creator of WordPress, Matt Mullenweg, founded a company called Automattic, which sells WordPress hosting services (the wordpress.com site) and licenses some plugins.
In 2024 he began publicly criticizing a company called WP Engine, which also offers WordPress hosting services, accusing WP Engine of benefiting from WordPress without contributing back.
If WordPress were not open source, WP Engine would not exist, but neither would WordPress be as well known, and Automattic knew that when it started.
Regardless, it is a lawful company, selling services, training people and promoting the product. Someone who got to know WordPress through WP Engine may end up using Automattic's services, or another vendor's, and that is fine.
If he had something to say, he should have done it privately, and would surely have found an ally in WP Engine. Instead, he created an enemy, and now they are fighting in US courts (Estadão).
In this fight, 8.4% of Automattic's employees resigned, volunteer translation contributors abandoned their work, and partners began looking for alternatives, afraid of being the next targets. We don't even know how essential those employees were, but the mere fact of driving partners away is worrying.
AI: the last straw
Claude Code and, more recently, OpenAI's Codex and even Google's Antigravity have become fantastic tools for building sites.
You can argue that AI-generated layouts look alike, but WordPress's default layouts look alike too.
In the hands of a creative person, these tools deliver exceptional results.
If the goal is only to remove WordPress, you can connect these tools to the WordPress database and ask them to generate an HTML copy. From there you can evolve the layout, or publish the site directly as AI-generated HTML.
That move alone makes the site faster, helps it rank better in search (SEO) and in AI answers (GEO), and avoids security problems.
Most sites have a contact form. You can ask the AI to build that small form in PHP (the same language as WordPress), using the same email-sending credentials that WordPress is configured with, so the internal team can respond.
Other integrations, such as article search, can also be implemented easily by AI, sometimes with better intelligence than the simple keyword search found in WordPress plugins.
Advanced interactions can be built with tools such as PowerBiz, which integrates with any website and has many features, including a Contact Form with integration to external tools.
You can create internal Skills to validate articles against company rules, such as fact checking, inclusion of links, checking the tone of the language (more formal or more relaxed), writing SEO summaries, suggesting title improvements and resizing images automatically.
My experience, in companies where I implemented this, was very positive. Before, publishing an article on WordPress took up to 4 hours to format, place images and adjust the mobile view. Now I drop in the raw text, sometimes dictating it, and the LLM prepares and publishes it in under 10 minutes.
It also became easier to have a place to test the site before changes go live (a staging environment, for developers), since most of the site is now plain HTML and CSS.
Some tools, such as GitHub, professionalize version control and publishing; once configured, they take all the technical difficulty out of the way.
In short, so far we only have advantages with this approach. I can say it took a weight off my back, one less worry from not having this insecurity vector in the company.
I recommend you do the same for your company.