Skip to main content
HashnodeVeloCMSVeloCMS

Command Palette

Search for a command to run...

Is anyone still using WordPress?

Yes: about 40% of all websites, per W3Techs on 2026-10-14. How that is measured, who runs it, and seven realistic options for developers.

Updated
•18 min read•View as Markdown
V
VeloCMS

Yes, a lot of people. On the W3Techs page I read on 2026-10-14, WordPress runs 40.0% of all websites it surveys, which is 58.5% of the sites where a CMS could be identified at all. That share has slipped from 43.0% on 1 January 2026, so "dominant but shrinking" is the accurate summary, and the rest of this piece is about what's behind those two numbers.

Disclosure: I work on VeloCMS, a small hosted publishing platform. It appears once in the comparison near the end, last, as one option among seven.

Last verified: 2026-10-14.

Every figure below came off a page or public endpoint I opened that day, and the links are at the bottom. Where I couldn't read a source (BuiltWith sat behind a verification screen), I say so instead of quoting it second-hand. Survey numbers move daily, so open the linked page before you repeat me.

How do we actually know how many sites run WordPress?

Nobody counts. Three different things get called "WordPress usage," and they measure different objects.

The first is W3Techs, the number everyone quotes. It crawls sites and looks for patterns that identify a technology: the generator meta tag, JavaScript and CSS, URL structure, HTTP headers, DNS and WHOIS data (W3Techs FAQ). It says it counts "the relevant web," meaning it drops throw-away sites, parked domains and spam, and it states plainly that no survey can be fully accurate because sites can hide what they run. The FAQ doesn't publish a sample size (it says only that it visits each site roughly monthly and usually crawls a few sample pages, and it lists Tranco among its public sources), which is worth knowing before you treat 40.0% as a census.

The second is HTTP Archive's Web Almanac, which uses its own crawl and its own classification. Its 2025 CMS chapter says CMS-driven sites are over 54% of observed websites and that WordPress accounts for 64.3% of all mobile CMS usage (Web Almanac 2025). That's higher than W3Techs' 60.2% to 62.0% of CMS sites around the same time, and the gap is the point: different samples, different detectors, different answers. The chapter also notes that Shopify became a separate entry this year after previously being filed under ecommerce, so year-on-year comparisons aren't always like for like.

The third is WordPress.org's own statistics page, and it isn't a market-share number at all. It charts which WordPress, PHP and database versions are in use, not how many sites exist. The page doesn't say how it collects data. What I can verify is that WordPress core's update check sends the WordPress version, PHP version, locale, database version and more to api.wordpress.org (wp_version_check reference), and that a filter can alter that payload. My inference, not something the page states, is that this ping is the likely feed. If so, a site that blocks outbound update checks doesn't show up.

BuiltWith is the fourth name people reach for. I tried to open its WordPress trends page and got a verification screen instead of data, so I'm not quoting it.

One more trap: "40.0%" and "58.5%" aren't contradictory. W3Techs also reports 31.6% of sites using no CMS it monitors. WordPress is 40.0% of everything and 58.5% of the sites with a recognizable CMS. Always check which denominator a headline is using.

Is WordPress's share growing or shrinking?

Shrinking, slowly and then a little faster. W3Techs' history page gives the share of all websites on 1 January of each year: 23.3% in 2015, 39.5% in 2021, 43.2% in 2022, then 43.1%, 43.1%, 43.6% and 43.0% through 2026, and 40.0% on 14 October 2026 (usage history). Five January readings within 0.6 points of each other, then a three-point drop in under ten months.

The interesting part is what that drop is made of. Over the same stretch the "no monitored CMS" bucket rose from 28.6% to 31.6%, and WordPress's share among CMS-identified sites fell from 60.2% to 58.5% (market share history). Share of all sites is just those two numbers multiplied, so I split the drop with arithmetic: roughly 1.8 points came from the identified-CMS pool shrinking and roughly 1.2 points from WordPress losing ground inside it. About three-fifths of the headline decline is the denominator moving.

What does a shrinking pool mean? I can't tell from W3Techs' pages. It could be sites moving to custom or headless stacks that don't announce a CMS, a change in what the crawler counts, or both. W3Techs hasn't published a reason on the pages I read, and I didn't find a primary source that explains it, so any confident causal story you see (the WP Engine dispute, plugin fatigue, AI search) is a hypothesis. The within-CMS slide is steadier: 65.2% in January 2022, 62.0% in January 2025, 58.5% now.

Who still runs WordPress in production?

Big names, and they're not hard to find. WordPress VIP, the enterprise hosting arm, lists customers on its own page, including Ubisoft, Pew Research Center, CNN Brasil, ADWEEK, Slate, USA TODAY Co., TIME and an Al Jazeera case study. WordPress.org's showcase features NASA, Rolling Stone, The White House, Disney Connect, Daily Kos and Taylor Swift's site among its 157 entries.

Treat both lists as vendor-curated. A company on a VIP page may run WordPress for one property and something else for the rest, and a showcase entry tells you the site is on WordPress today, not that it will be next year. They answer "does serious production traffic run on this?" (yes) rather than "how much?".

The long tail matters more for the arithmetic. The overwhelming majority of the 40.0% is small sites on shared hosting that nobody writes case studies about. That's also where the maintenance burden lands, which brings us to versions.

What versions and PHP are WordPress sites actually running?

I pulled the public JSON behind WordPress.org's stats charts (WordPress versions, PHP versions) on 2026-10-14. The current release was 7.1.3, per the WordPress news feed.

By WordPress version: 7.x accounts for 70.1% of reporting sites, with 7.1 alone at 61.7%. The 6.x line is 22.3%, and 5.x and older add up to 7.6%. W3Techs reads the same population differently (Version 7 at 65.7%, Version 6 at 27.4%, Version 5 at 4.8%), which is what you'd expect from two instruments with different samples.

PHP is the more uncomfortable chart. The 8.x branches hold 78.0% of reporting sites, 7.x holds 20.0% and 5.x holds 2.0%. WordPress recommends PHP 8.3 or newer and MariaDB 10.11 or MySQL 8.0 or newer (requirements), and by my addition only about 39% of sites sit on 8.3 or later. Checking against php.net's supported versions and its end-of-life list: PHP 7.4 ended in November 2022, 8.0 in November 2023 and 8.1 on 31 December 2025, and 8.2 drops to unsupported on 31 December 2026. Add up 5.x, 7.x, 8.0 and 8.1 and about 36.8% of reporting sites run a PHP branch with no security support.

That isn't WordPress core's fault, and it isn't a reason to avoid it. It's the cost of a platform whose users range from agency teams with CI pipelines to people who installed it in 2014 and never logged in again.

Why do developers still choose it in 2026?

The honest answer is a stack of boring, compounding reasons, not one killer feature.

It's free software under GPLv2 or later (license), so no vendor can reprice you, and the update stream is live (7.1.3 is labelled a maintenance and security release). The editor and theming model has moved on from the PHP templates people remember: the handbook calls block themes "the modern method of building WordPress themes," with theme.json defining global settings and styles, and HTML templates editable in the Site Editor (block themes handbook). Classic themes still work, but that's where the project says it is heading.

Then there's the API. The REST API handbook describes it as "the foundation of the WordPress Block Editor," exchanging JSON, and says private and password-protected content is only exposed with authentication (REST API handbook). That's what lets you treat WordPress as a content store and put anything you like in front of it, which I get to below.

The ecosystem is the other half. WordPress.org maintains a list of recommended hosts (Pressable, Bluehost and Hostinger when I looked), and says plainly that "listing is completely arbitrary" (it also notes some hosts donate a portion of your fee back to WordPress.org) (hosting page), so don't read it as a ranking. As for hiring, the pool of people who know WordPress should be large simply because the installed base is, but I couldn't find a sourced figure for developers or freelancers, so I'm not putting a number on it.

Who is moving off WordPress, and to what?

Nobody publishes migration flows, so the only public evidence is share shifts in W3Techs' CMS market-share series. Since January 2022, WordPress went from 65.2% to 58.5% of CMS-identified sites. Over that period Wix rose from 2.9% to 6.2%, Shopify from 6.6% to 7.8% and Squarespace from 2.7% to 3.6%, while Joomla fell from 2.6% to 1.6% and Drupal from 2.0% to 0.9%.

So hosted builders are taking measurable ground at the small-site end, and the older open-source CMSs are losing it faster than WordPress in relative terms (Joomla and Drupal each lost roughly 40 to 55% of their share since 2022, against about 10% for WordPress). What the data can't show is the developer-led exit: teams rebuilding on a Next.js or Astro frontend with a headless backend largely vanish into the "no CMS" bucket because nothing on the page says WordPress, Payload or Strapi. That would be consistent with the rising "none" figure above, but it's a hypothesis, not a measurement.

What are the realistic options for a developer deciding today?

Seven, compared on the same terms. They're ordered by how much of the stack you own, not by merit. Prices are what each vendor's own page showed on 2026-10-14.

WordPress, self-hosted

You get the whole thing: admin UI, themes, a huge plugin ecosystem, a mature REST API, and a license (GPLv2 or later) that makes it yours to run anywhere. WordPress.org distributes it free, so cost is hosting, which varies by provider and isn't a number I can give you.

The trade-off is that you own operations. Updates, backups, PHP version, and the security posture of every plugin you install are your job, and the version charts above show how that plays out across the installed base. It's the right default when you need a specific plugin, or when a client's editors already know it.

  • Price: free software, hosting varies
  • License: GPLv2 or later
  • Hosting: yours, or any WordPress host
  • Content model: posts, pages, custom post types, plugin-defined fields
  • Main trade-off: you carry maintenance and plugin risk

Headless WordPress with WPGraphQL and Next.js or Astro

Keep the WordPress editor, replace the front end. WPGraphQL is a free, open-source plugin (GPL-3.0) that adds a GraphQL schema to a WordPress site, and its site lists Next.js among compatible frameworks. Faust.js, whose repository sits under WP Engine's GitHub organization, is a Next.js toolkit whose feature list includes authentication, post previews, template hierarchy and block editor support. You still need the FaustWP plugin on the WordPress side as well as the npm packages (repository).

The weakness is that you now run two systems: PHP and a database for editors, plus a Node front end for visitors. My read, and it is an inference, is that Faust exists because previews, routing and block rendering don't come free once the front end is decoupled. Plugins that output shortcodes or front-end markup may also not carry across. Pick this when your team already ships React and editors insist on WordPress.

  • Price: WPGraphQL free; hosting for both halves is yours
  • License: GPL-3.0 (WPGraphQL)
  • Hosting: WordPress host plus a Node or edge host
  • Content model: whatever WordPress defines, exposed over GraphQL or REST
  • Main trade-off: two systems, and previews and plugin output need work

Ghost

Ghost is built for publishing as a business: it describes native signup forms, paid subscriptions with monthly and yearly tiers, and email newsletters. The code is MIT-licensed, so you can self-host it with its CLI, and it's run by a non-profit foundation.

On Ghost(Pro) the pricing page showed Starter at \(18/month billed yearly (1 staff user, 1,000 members), Publisher at \)29/month (3 staff users) and Business at $199/month (15 staff users), all billed yearly. Starter has no marketplace or custom themes and no custom integrations; those arrive at Publisher. The Business card says 1,000 members while the comparison table says 10,000, so confirm before you budget. The weakness is scope: Ghost is a publication engine, not a general site builder, and it isn't trying to be a store.

  • Price: from $18/month billed yearly (Ghost(Pro)); self-hosting is free
  • License: MIT
  • Hosting: Ghost(Pro) or your own server
  • Content model: posts, pages, tags, members and tiers
  • Main trade-off: narrow by design, with tiers capped by members and staff

Payload CMS

Payload titles itself "The Next.js Headless CMS and App Framework" and says you get "a full backend seamlessly built into your Next.js app." The repository is MIT-licensed, and its docs list MongoDB, Postgres and SQLite as supported databases (database docs). For a TypeScript team that wants the CMS inside the same codebase as the site, that integration is the draw.

The catch is exactly the same thing. It's a framework, so the editorial product, whether that means newsletter, membership, SEO tooling or a page builder, is something you assemble or build. Figma announced in June 2025 that it was acquiring Payload (CMSWire coverage); CMSWire reported that Figma intends to keep Payload open and independently usable, while noting that the future depends on how governance, pricing and feature access evolve. That's an intention, not a commitment. I couldn't load Payload's pricing page (it returned a 404), so I'm not quoting hosted prices.

  • Price: free to self-host; hosted pricing not verified
  • License: MIT
  • Hosting: your Next.js host and database
  • Content model: code-defined collections and fields
  • Main trade-off: you build the publishing features yourself

Strapi

Strapi is the long-running open-source headless CMS: its repository describes a JavaScript and TypeScript CMS that is self-hosted or cloud-hosted and generates REST and GraphQL APIs from content types. The license file says the Community Edition is MIT, while anything under an ee/ directory is Enterprise, and that the MIT terms apply only if you aren't using ee/ components and have no registered Strapi Cloud account.

Strapi Cloud's pricing page listed Starter at \(35/month (100,000 API requests, 50 GB storage), Pro at \)90 and Business at $450, plus overage charges. The page notes that Starter sleeps when idle. The weakness is the content-modeling-first mindset: it's a data layer, and like Payload you build the presentation and the product features yourself. Pick it when several front ends consume one structured content API.

  • Price: self-host free; Cloud from $35/month (monthly billing shown)
  • License: MIT (Community), separate license for ee/
  • Hosting: your own Node host or Strapi Cloud
  • Content model: content types exposed as REST and GraphQL
  • Main trade-off: front end and product features are yours to build

Astro or Hugo with Git-based content

Skip the CMS and keep content in the repository. Astro is MIT-licensed, and its content collections load Markdown, MDX, Markdoc, JSON, YAML and TOML from files, validating each entry against a Zod schema so malformed front matter fails loudly. Hugo, written in Go and released under Apache 2.0, describes itself as "the world's fastest framework for building websites." That's a vendor claim, so I haven't repeated a benchmark for it.

This is the cheapest and most reviewable setup, with pull-request review for content and almost no moving parts in production. The weakness is that your editors need Git or a separate editing layer, and anything dynamic (forms, comments, memberships, search) comes from services you wire in. For a developer's own blog or documentation it's hard to beat; for a non-technical team it usually isn't.

  • Price: both tools are free; hosting for static output varies
  • License: MIT (Astro), Apache 2.0 (Hugo)
  • Hosting: any static host
  • Content model: files in Git, schema-checked in Astro
  • Main trade-off: no editor UI and no built-in dynamic features

VeloCMS

VeloCMS is a hosted publishing platform. Pro is \(9/month (\)86.40 a year on annual billing), Business is $29 and Agency is $69, each with a 14-day trial; there is no free plan, and the FAQ says a card is added when the trial starts. Pro includes unlimited posts, a custom domain, a visual page builder (70+ blocks), membership and paywall with no platform fee (Stripe's processing fees still apply), newsletters, e-commerce and a WordPress migration wizard. Pro caps storage at 5 GB and subscribers at 5,000.

The weaknesses are real. It isn't open source and can't be self-hosted, per its own comparison page, and plugins are first-party only, so WordPress plugins don't run. The developer page says the platform for outside developers isn't live yet, so it's the opposite of a headless-first tool. Its ecosystem and track record are a fraction of WordPress's. It suits a writer or small team who wants posts, newsletter, memberships and a store behind one login.

  • Price: \(9/month Pro, \)29 Business, $69 Agency; 14-day trial, no free plan
  • License: proprietary, hosted only
  • Hosting: included
  • Content model: posts, pages, products, members, built-in blocks
  • Main trade-off: small ecosystem, no self-hosting, no third-party plugins

Who is each option best for?

  • WordPress, self-hosted: teams that need a specific plugin or have editors who already know it, and will own maintenance.
  • Headless WordPress: React teams that must keep the WordPress editor.
  • Ghost: publishers whose business is a newsletter and paid membership.
  • Payload: TypeScript teams that want the CMS inside their Next.js app.
  • Strapi: projects feeding one content API to several front ends.
  • Astro or Hugo with Git: developers publishing their own blog or docs.
  • VeloCMS: solo writers and small teams who want blog, newsletter, memberships and a store without managing infrastructure.

When is VeloCMS not the right pick?

Quite often, for the readers of this article. If you need a plugin from WordPress's catalog, need to self-host, need a headless API for an existing React front end, or want to run it on your own infrastructure for compliance, pick something else above. Its developer story is the thinnest of the seven, and a hosted product with a short track record is a different bet from the platform running 40% of the surveyed web.

FAQ

Is WordPress dying?

Not on the evidence I could read. It's on 40.0% of websites and 58.5% of CMS-identified sites per W3Techs, but both numbers have fallen this year, and I couldn't establish why.

How many websites use WordPress?

W3Techs gives a percentage, not a count, and the pages I read don't state the sample size. The 40.0% figure refers to the websites in W3Techs' survey, not every site on the internet.

Is it safe to run WordPress in 2026?

Core ships regular maintenance and security releases (7.1.3 at time of writing). The bigger risk is the environment: about 36.8% of reporting sites run a PHP branch with no security support, per the stats endpoint and php.net.

Is WordPress worth learning for a new developer?

If you want client work, the installed base alone says yes. If you want a modern TypeScript stack, learn it as a content backend (REST or WPGraphQL) rather than as a PHP theme platform.

Can I leave WordPress without losing my content?

Content moves, but behavior doesn't. Posts, tags and images import into most platforms (VeloCMS's wizard reads WXR export files, for example), but plugin-driven features need rebuilding wherever you land.

Sources (all accessed 2026-10-14)

#wordpress#cms#webdev#headless-cms#php

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog

V

VeloCMS

26 posts