WordPress.com and WordPress.org Are Not Two Versions of the Same Thing

An agency quoted two days to add a membership tier to a small charity's site. For a WordPress site the quote was fair: log in, install a membership plugin, adjust the templates, hand over the keys. The site was on WordPress.com on a plan that did not include plugin installation, so the quote was not wrong by a small margin. It was wrong by an architecture.

What made it awkward was the client's objection, which was reasonable. They had been paying for WordPress for years and had read the tutorials. The tutorials named the plugin they wanted, with screenshots, and nothing in the language they had been sold distinguished that software from the service they paid for every month.

The confusion survives because the two things share a name. The most-searched WordPress question there is, the .com or .org one, gets answered as a hosting comparison with a price column and a winner. It is not one. It is a governance comparison: who holds write access to the code, who decides what runs, and who is answerable when it breaks. Hosting is downstream of those three answers.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the situations where the hosted product is the wrong answer are named below, in as much detail as the ones where it is right.

One name, two different things

WordPress.org is a software project. The code is free, licensed so that it stays free, and downloadable by anyone with a server to put it on. The project publishes the documentation, runs the plugin and theme directories, and ships the release cycle. It does not host sites or sell plans, and has no opinion about who should take your money for the machine.

WordPress.com is a hosting company. Automattic runs that software on its own infrastructure and sells access in tiers, bundling the CDN, the backups, the security patching, the spam filtering and a support address into one bill. It also controls what customers can run, and that control is the product rather than an oversight. A platform that lets every customer install arbitrary code into a shared environment cannot promise the environment stays up.

Self-hosted is a misleading phrase in its own right. Almost nobody self-hosts literally: people rent a server or a slice of one, and the host keeps the machine alive. What the operator owns is the filesystem and the database, plus the obligations attached to them. That is the whole difference, and everything else here follows from it. Choosing WordPress.org is also not choosing a host; it is choosing to choose one.

Who holds the code

On the hosted side, the platform team deploys core. Updates arrive on somebody else's schedule, security releases land on the platform's timetable rather than whenever an owner notices, and a botched release is somebody else's shift. Most sites are better off for that.

The trade is that the door does not open the other way. If a site needs one changed line in a template, or a filter added in a small plugin, there is no changed line available, and below the top tier there is not even a file to look at. The platform's answer to most code-level requests is a feature request, and feature requests are not a schedule.

On the self-hosted side the operator holds the files and, with them, every decision the platform team used to make. Core updates can be automatic and mostly should be. Plugin and theme updates are the interesting category, because a minor release that renames a hook can take a checkout page offline at an hour nobody chose. The person applying them also decides when to wait a week, and that judgement is what a managed host sells.

Two consequences follow, pointing opposite ways. Hosted is safer for a site whose owner will never apply a patch, and no amount of advice changes that. Self-hosted is more fixable, because a developer can read the code that broke. Neither is an advantage in general; each suits a particular owner.

On the hosted side, plugin installation begins at a particular tier and not before. Below it the site runs what the platform provides: a fixed set of features, some good, none swappable. Above it, installation from the public directory opens up, bounded by what the platform can support. Anything expecting to rewrite server configuration or manage its own object cache will be a fight or simply absent.

On the self-hosted side there is no list. Any plugin in the directory installs in seconds, including the ones that will break the site, and a plugin written for one client installs too. That freedom is the reason most of this archive exists, and the reason a site ends up with forty plugins, two of which filter the same hook and cancel each other out.

The plugins themselves are free either way. The WordPress plugin directory does not charge for downloads, and a premium licence buys support and automatic updates rather than the code. A premium licence costs the same on a self-hosted site and on the hosted tiers where plugins exist at all, so it belongs in both columns.

Four limits surprise people.

• Plugins on the lower plans. The tutorials assume the plugin can be installed. On the lower tiers it cannot, and no workaround avoids changing plans. This ends most hosted projects, late, after the content is in.
• Theme editing. The appearance tools are not the theme editor. They expose colours, fonts, a header image and a stylesheet box, never the template producing the wrong markup. Above the entry point the files exist; below it, a ten-minute design change becomes a support thread.
• The database. No direct access below the top tier means no SQL, no repair on a corrupted table, no export of a custom table, and no reading a row to find out why a form is not saving. Debugging stops at the edge of the dashboard.
• Arbitrary PHP. No mu-plugins directory, no functions file, no cron event added by hand, no server rule for a redirect. Anything expressible only as code is expressible only as a feature request.

What self-hosting asks in return

The freedom is paid for in maintenance, and the maintenance is not optional. Core, plugin and theme updates. The quarterly question of whether the PHP version is still supported. Backups on a schedule somebody has tested by restoring one. A staging copy, or at least the discipline to use it. A plan for the hour the site is down, usually the hour the owner is asleep.

None of it is hard once. All of it is a standing commitment belonging to a named person. When the answer to "who does this" is "nobody", the site is not self-hosted. It is hosted by luck, with a database that has never been restored.

The bill, with the line items people leave out

The hosted side looks more expensive per month, and on the invoice it is: one predictable figure covering the machine, the CDN, the backups and the patching. Set that against a cheap shared plan and it loses by a multiple that is easy to resent.. WordPress.com's plans price the machine, the CDN, the backups and the patching as one figure; a VPS is the rent for the machine alone

The comparison only becomes honest when the other column is finished. Self-hosted hosting is a floor, not a total. On top sit the annual plugin licences a business site accumulates without deciding to: forms, SEO, backup, caching, a page builder, whatever the shop needs. Each renews per year and per site, each is easy to forget until a card is declined, and together they commonly exceed the hosting bill. Then the hours: the update rounds, the conflict that eats a morning, the PHP upgrade needing a staging pass, the certificate that lapsed because nobody owned it.

Those hours are only free if they belong to somebody whose time is worth nothing, which is rarely the person paying. Where a retainer does the work, use their rate and the arithmetic often reverses: the hosted plan, at the order of magnitude it actually costs, is cheaper for a small site. Where the owner does it on Sunday nights, count the Sunday nights. Prices move, so check current figures rather than trusting a number from an article, including this one.

Where the hosted figure and a small server actually cross is worked through in the companion piece on choosing a WordPress.com plan. The point to carry over here is narrower: the crossover is not the whole comparison, because the hours never appear on a receipt, and the tier that permits plugins still will not permit all of them.

Where the hosted product is the wrong purchase

If the site depends on a plugin the platform will not run, no plan fixes it. The test is cheap and belongs before the migration: write down the five plugins the site cannot live without, then check each against the plan's allowed set and its support documentation. A site that fails that test at setup fails it harder in year two, when the plugin is load-bearing.

If the site is a product rather than a publication, with custom post types, a warehouse integration or a pricing calculator in PHP, the hosted tiers are a series of walls met in sequence. Paying more to reach a higher wall is not progress.

If the only reason for the upgrade is stylesheet editing or one redirect rule, that is a bad reason to buy a tier. The free option is usually enough: the WordPress.com free tier genuinely suits a personal blog that will never need a plugin, and the free plugin directory covers most of what a small site pays a licence for. A form plugin with a million installs is free. Paid versions earn their money when support and automatic updates matter more than the fee, which is a decision about risk rather than features.

The decision rule

Choose the hosted side when all four hold: nobody on the team will ever open a filesystem; the site publishes content rather than running a workflow; no plugin outside the platform's set is load-bearing; and one invoice with a support address is worth a premium. That last point is the product, and it is worth real money to an organisation with no technical employee.

Choose self-hosted when any one of these holds: the site needs a plugin the platform will not run; someone already owns updates as part of their job; filesystem or database access is needed to debug or integrate; or the site is the business, not the brochure for it.

The one migration that hurts

The mechanics of leaving are worked through in the companion piece on moving a WordPress.com site without losing the permalinks. Posts, pages and comments travel through the export, images follow by reference while the old site stays public, and an evening covers the rest. What is genuinely hard there is DNS, email and addresses, which are hard for every host alike.

The exception is the site that has been collecting things: form entries, orders, member records, subscriber rows, whatever the platform's features store in tables of their own. Those rows are not in the content export. On a self-hosted site the operator queries them out. On the hosted lower tiers there is no database to query, so they stay behind, and the polite name for that is a re-platforming project.

That is the one situation where migrating later is genuinely painful, and the pain compounds, since the longer the site runs the more of those rows exist. It also arrives at the worst moment: people migrate when a capability has become urgent, on a deadline, with the site busy. The decision is cheap now and expensive in year three.

So the rule that survives all of it is to choose for the site that will exist in two years rather than the one that exists this month. A blog that will stay a blog will be happy on the hosted side and should not feel bad about it. A site about to grow a membership or a checkout is choosing its future constraints along with its hosting.