WordPress is an open-source content management system that stores content in a MySQL database and renders it with PHP themes - and its dominance comes less from the software than from the fact that millions of people already know how to use it.
Technical discussions of it tend to be either dismissive or defensive, and neither is useful. It is a mature piece of software with clear strengths, clear weaknesses, and one genuinely underrated advantage that has nothing to do with code.
Table of contents
- What it actually is
- Where it is genuinely the right choice
- Where it struggles, honestly
- Running it without the usual pain
- The headless option, and when it makes sense
- How this fits the rest of the stack
- FAQ
What it actually is
Content and configuration live in a MySQL database. PHP renders it, using a theme for presentation and plugins for functionality. An admin interface lets non-technical people create pages and posts, upload media, and manage users without touching any of that.
The architecture is unremarkable and it is very well understood, which is most of the point. Three things follow from its ubiquity and they are the actual reasons to choose it.
- Editors already know it. This is the underrated one. Training a content team on a new interface costs real money and real goodwill, and that cost is invisible in technical comparisons.
- Someone has already built what you need. Whatever the requirement - forms, e-commerce, memberships, multilingual content, events - a plugin exists. Quality varies enormously and the coverage is genuine.
- You can hire for it. The pool of people who can maintain a WordPress site is larger than for any other CMS by a wide margin, which matters when the person who built it leaves.
Where it is genuinely the right choice
Content-driven sites where non-technical people publish regularly. Marketing sites that need to change without a developer in the loop. Blogs and publications, which is what it was built for and still does best. Sites where the editorial team already knows the interface. And projects where a plugin genuinely solves the requirement and building it would take weeks.
It is also, quietly, a reasonable answer for a small business site that needs to exist, be editable, and not be a project. Not every website is an engineering opportunity.
Where it struggles, honestly
Plugin sprawl. The strength is the weakness. Thirty plugins, each from a different author with a different update schedule and quality bar, is a fragile system where a routine update can take the site down. Every plugin is code you did not write running with full access to your database.
Security surface. It is the most-targeted platform on the web, and the vast majority of incidents come from outdated plugins and weak credentials rather than from core. Keeping it patched is a real, ongoing obligation and it is the obligation people most often abandon.
Performance by default. An unoptimised install with a heavy theme and many plugins is slow, because every page view runs PHP and queries the database. Caching fixes most of it and someone has to set caching up.
Structured content. Custom fields and custom post types make it possible; the data model still fundamentally wants to be pages with content in them. If your content is genuinely structured and reused across channels, a purpose-built headless CMS models it better.
Version control. Content is in a database and configuration is spread between the database and files, which makes staging-to-production workflows awkward in a way that Git-based systems simply are not.
Running it without the usual pain
- Ruthlessly limit plugins. Every one is a dependency, a security surface, and an update that can break things. If a plugin does one small thing, consider whether a few lines in the theme would do instead.
- Update on a schedule, with a staging copy. Not automatically into production, and not never. A monthly window with a restore point is the practical middle.
- Cache properly. Page caching in front of PHP and object caching behind it. This is the difference between a site that feels slow and one that does not.
- Back up the database and the uploads folder. Both, because the theme is in your repository but the content and the media are not. Test a restore.
- Keep credentials strong and admin accounts few. Most compromises are credential problems, not code problems.
The headless option, and when it makes sense
WordPress can serve content through its REST or GraphQL API while a separate frontend handles rendering. This keeps the editing interface everyone knows and replaces the presentation layer with something modern.
It is a genuinely good arrangement in one specific case: the editorial team is happy and productive, and the frontend needs to be a JavaScript application or a statically generated site. You keep the thing that works and replace the thing that does not.
It is a poor arrangement when adopted for fashion, because you now operate two systems, lose the live preview that editors rely on, and give up the plugin ecosystem for anything touching presentation. The question to ask is whether the editing experience is the problem. If it is not, do not replace it.
The part worth improving regardless of architecture is the operational layer. Most of the daily friction with WordPress is not the software - it is the SFTP client, the phpMyAdmin login, and the separate database credentials needed to do routine things. A dashboard with file management and a database browser built in removes most of that without changing anything about how the site works.
How this fits the rest of the stack
The recurring cost of a WordPress site is the hosting plus the attention, and reducing the second is usually worth more than shaving the first. The RunxBuild hosting calculator prices the WordPress plan and the bandwidth alongside anything else the project needs. RunxBuild runs managed WordPress from $3/month on its own plan ladder, with a file manager in the dashboard for browsing, editing, uploading, unzipping and downloading files, and a database browser for tables, rows, SQL, export and import - so no SFTP client or phpMyAdmin login is needed.
Useful related references:
- git push origin main: What Each Word Does and Why It Fails
- Git Workspace: Working Tree, Worktrees, and the Word That Means Three Things
- Static Site CMS: The Git-Based, the API-Based, and the One That Beats Both for Most Teams
- Services on RunxBuild
FAQ
What is WordPress used for?
Content-driven websites where non-technical people publish regularly: blogs, publications, marketing sites, and small business sites. It stores content in a MySQL database and renders it with PHP themes, with an admin interface that requires no technical knowledge to use.
Is WordPress still a good choice?
For content sites with non-technical editors, yes, and the strongest reasons are not technical: editors already know the interface, a plugin probably exists for your requirement, and you can hire people who can maintain it. For structured content reused across channels, a headless CMS models it better.
Why do WordPress sites get hacked?
Almost always outdated plugins and weak credentials rather than flaws in core. Every plugin is third-party code running with full database access, on the most-targeted platform on the web. Limiting plugin count, updating on a schedule, and using strong admin credentials prevents most incidents.
Should I use WordPress headless?
Only when the editorial experience is working well and the frontend specifically needs to be a JavaScript application or a static site. It keeps the interface editors know and replaces rendering. Adopted without that reason, you operate two systems and lose live preview.
How do I make a WordPress site faster?
Page caching in front of PHP so most requests never execute code, object caching behind it to reduce database queries, an optimised theme, and fewer plugins. An unoptimised install runs PHP and queries the database on every single page view.