The State of WordPress 2026

WordPress lost share of the web this year for the first time in two decades. The decline is real, smaller than the headlines suggest, and coming from somewhere almost nobody is looking.

Synmek’s annual research report on the platform that runs a third of the internet. Published July 2026. Next edition July 2027.

Why this report exists

Every WordPress statistic you have read this year is probably true and probably misleading.

You will see that WordPress powers 43% of the web. You will also see 41.5%, and 33%. All three figures are correctly reported from real datasets. They disagree because they are measuring different things, and almost nobody explains which.

That matters more than it sounds. In 2026, for the first time in twenty years, the direction of travel changed. WordPress is no longer gaining share. Whether that is a rounding error or the beginning of something structural depends entirely on which dataset you read and how carefully you read it.

We build on WordPress every day, so we have a commercial interest in the answer. This report is our attempt to get at it honestly, with every figure sourced and dated, including the figures that do not flatter the platform.

Key findings

1. WordPress share is falling on every measure. W3Techs put it at 41.5% of all websites on 11 July 2026, down from 43.2% in December 2025. HTTP Archive put it at 33.21% of measurable origins in April 2026, down from a 35.76% peak in July 2022.
2. It is still not close. WordPress holds roughly 59% of the market among sites running a detectable CMS. The nearest competitor, Shopify, sits around 7.4% of that same market.
3. The share is not going to Wix or Squarespace. It is going to the “no detectable CMS” bucket, which now accounts for 48.3% of measurable origins.
4. Performance is WordPress’s most serious competitive liability. On the November 2025 Core Web Vitals Technology Report, 46.28% of WordPress origins passed all three metrics. Duda passed at 84.87%.
5. But WordPress is not slow to respond, it is slow to load. WordPress INP pass rates sit near 86%, comparable to Wix. The failure is concentrated almost entirely in LCP. That changes what the fix is.
6. Security has become an operations problem, not a coding problem. 11,334 new vulnerabilities were disclosed across the ecosystem in 2025, up 42% year on year. 91% were in plugins. A single-digit number were in core.
7. “Keep your plugins updated” now fails about half the time. 46% of vulnerabilities disclosed in 2025 had no patch available on the day the details went public.
8. The median gap between public disclosure and first exploitation attempt is five hours. Weekly patching is patching after the wave.
9. Elementor still leads the build layer but its growth has stalled. Detected on 32.67% of WordPress sites in April 2026, with year-on-year growth down from roughly 28% in early 2023 to 8.3%.
10. The governance dispute cost the project a release year. WordPress shipped no major version between 6.8 and 6.9, with project leadership citing the WP Engine litigation. WordPress 7.0 finally landed on 20 May 2026.

1. The decline is real. It is also three different numbers.

Start with the measurement problem, because everything else depends on it.

W3Techs surveys the top 10 million websites and counts subdomains of a site as a single entry. HTTP Archive crawls the origins in the Chrome UX Report and counts them separately, then reports against a denominator that includes every site with no detected CMS at all.

Neither is wrong. They answer different questions. W3Techs answers “of the sites people actually visit, how many run WordPress.” HTTP Archive answers “of every distinct origin Chrome can see, how many run WordPress.” If you quote one figure at a client without saying which, you are being imprecise in a way that will eventually cost you credibility.

What both agree on is the direction. W3Techs recorded a fall from 43.2% in December 2025 to 41.5% by 11 July 2026. HTTP Archive analysis published by GravityKit shows a decline of 2.55 percentage points from the July 2022 peak, roughly a 7% relative drop over four years.

The bear case deserves a fair hearing though, and it is this: 2026 is the first sustained contraction in twenty years, and contractions that begin at the bottom of a market do not always stay there.

2. The share is not going where you think

The intuitive story is that Wix and Squarespace are eating WordPress from below. The data does not support it.

On the April 2026 HTTP Archive crawl, Wix sat at 2.21% of measurable origins, Squarespace at 1.13%, Webflow at 0.73%. These are not the numbers of platforms absorbing a third of the web. Shopify, at 4.74%, was the only major platform meaningfully gaining share, up 12.4% year on year, and it is winning commerce, not general web presence.

The bucket that grew is the one with no name on it. 48.3% of measurable origins run no CMS that HTTP Archive can detect. That slice contains static sites, headless front-ends, hand-built pages, and anything without a recognisable fingerprint.

It also contains the output of a new industry. Lovable passed roughly $500 million in annualised revenue by 2026 and was reported to be in talks at around a $12 billion valuation. Cursor crossed $2 billion annualised. Vercel’s v0 helped push its parent past $200 million ARR. Hostinger, itself a major WordPress host, reports more than a million sites built with its own AI builder since launch.

Read that carefully, because the threat is not the one people describe. Nobody is migrating a working WooCommerce store to Lovable. What is happening is that a cohort of buyers who would have commissioned a small WordPress site three years ago now never enters the WordPress funnel at all. They do not choose against WordPress. They never consider it.

3. Performance is the real competitive problem

If we had to pick one number that should worry the WordPress ecosystem more than market share, it is this one.

On the November 2025 Core Web Vitals Technology Report snapshot, the share of origins passing all three Core Web Vitals broke down like this:

A 38-point spread on a confirmed Google ranking signal is not a rounding error. And for context, the whole web has been improving: the May 2026 CrUX release, published 9 June 2026, recorded 55.9% of 18,445,974 tracked origins passing all three, with 68.6% good LCP, 81.3% good CLS and 86.6% good INP.

Now the part almost every article about this gets wrong.

WordPress’s INP pass rate is roughly 85.9%, effectively level with Wix and not far off Squarespace. WordPress sites are not unresponsive. The failure is concentrated in LCP: server response time, oversized hero images, render-blocking resources.

That distinction matters because it changes the entire remediation plan. If WordPress were failing INP, the answer would be JavaScript discipline, and you would need to go to war with your page builder to get it. Because it is failing LCP, the answer is hosting, image handling and critical-path work. That is comparatively cheap, well understood, and does not require rebuilding anything.

The hosting evidence supports this. Analysis by Colorlib puts WordPress on managed hosting at a 55 to 65% CWV pass rate against 33 to 40% for the self-hosted average. Same CMS. Same plugins, often. Twenty points of difference from a decision made before a line of code is written.

The three fixes that move LCP most

In our experience the majority of failing WordPress sites fail for the same three reasons, in this order.

1. The hero image is not prioritised. WordPress lazy-loads images by default, and on a hero image that is actively harmful: it delays the very element LCP measures.

<?php
/**
 * Stop WordPress lazy-loading the LCP element, and tell the
 * browser to fetch it first. Add to your theme's functions.php.
 */
add_filter( 'wp_get_attachment_image_attributes', function ( $attr, $attachment, $size ) {
    // Adjust the condition to match wherever your hero lives.
    if ( is_front_page() && ! did_action( 'synmek_hero_rendered' ) ) {
        $attr['loading']       = 'eager';
        $attr['fetchpriority'] = 'high';
        $attr['decoding']      = 'sync';
        do_action( 'synmek_hero_rendered' );
    }
    return $attr;
}, 10, 3 );

2. Fonts block the render. Self-host them, preload the one weight above the fold, and use font-display: swap. A single Google Fonts request on a cold connection routinely costs 300 to 600ms of LCP.

<link rel="preload" href="/fonts/inter-var-latin.woff2" as="font" type="font/woff2" crossorigin>

3. TTFB is slow before anything renders. No amount of front-end work fixes a 900ms server response. Measure it first:

# Real TTFB, five runs, no caching layer warm-up bias
for i in {1..5}; do
  curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s  Total: %{time_total}s\n" \
    -H 'Cache-Control: no-cache' https://example.com/
done

If TTFB is consistently above 800ms, the problem is hosting, database queries or an uncached plugin, and no image optimisation will rescue it. This is exactly the diagnostic layer we run before quoting on any WordPress development project, because a redesign that ignores it produces a prettier site with the same numbers.

4. Security is now an operations problem

Patchstack’s State of WordPress Security in 2026, published 25 February 2026 in partnership with malware intelligence firm Monarx, is the most important document in the ecosystem this year. The headline figures:

Where they came from:

Three findings deserve to change how agencies work.

Highly exploitable vulnerabilities rose 113% year on year. More high-severity issues were found in 2025 than in the previous two years combined. 1,966 (17%) of the total carried a high severity rating, meaning they are likely to be used in automated mass attacks.

46% of vulnerabilities had no patch available at disclosure. This is the finding that should end the phrase “just keep everything updated.” Nearly half the time there is nothing to update to on the day the exploit details become public.

The median time from disclosure to first exploitation attempt is five hours. Around 20% of heavily targeted flaws were attacked within six hours, roughly half within 24 hours, 70% within seven days.

Put those three together and the arithmetic is unforgiving. A site on a weekly maintenance schedule, with an attentive administrator who patches promptly every Monday, is on average patching several days after the attack wave has already passed through, and on 46% of occasions there was no patch to apply anyway.

Two further findings worth internalising. Premium is not safer: Patchstack received 1,983 valid vulnerability reports for paid or freemium components, 29% of its total, and 59% of those were high-priority. And hosting-level defences are weaker than most people assume: Patchstack’s own case study found host protections failed against 87.8% of tested exploits.

The only defence that scales is a smaller attack surface

Every plugin is third-party code running with deep access. The most reliable security intervention available to an agency is not a firewall, it is a shorter list.

# Inventory: what is actually installed, and what is dormant
wp plugin list --fields=name,status,version,update --format=table

# Anything inactive is attack surface with no upside. Remove, don't deactivate.
wp plugin list --status=inactive --field=name | xargs -r -n1 wp plugin delete

# Flag plugins with no update in over a year: abandonment is the real risk signal
wp plugin list --field=name | while read -r p; do
  printf '%s\t' "$p"
  curl -s "https://api.wordpress.org/plugins/info/1.0/${p}.json" \
    | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('last_updated','unknown'))" 2>/dev/null \
    || echo "not in .org directory"
done

That last check matters more than the version numbers. A plugin last updated in 2023 is not stable, it is unmaintained, and it will not be patched when its turn comes.

One regulatory note for anyone selling plugins into Europe: under the EU Cyber Resilience Act, commercial plugin and theme developers distributing to EU users are required to operate a vulnerability disclosure programme during 2026. Whether the long tail of commercial plugin authors has the resources to run one is, politely, an open question.

5. The build layer is consolidating, and Elementor’s growth has stalled

Page builder data from the April 2026 HTTP Archive crawl, measured as share of WordPress sites:

Two caveats before drawing conclusions. Builders overlap: a single site can register Elementor and the block editor on the same page. And core-shipped block editor detection understates real usage, so treat 20.62% as a floor rather than a measurement.

The interesting number is Elementor’s deceleration. Annual share gains have compressed from roughly 5 to 6 percentage points a year in 2020 to 2022 to 2.51 points in the year to April 2026; the year-on-year growth rate has fallen from around 28% in early 2023 to 8.3%. That is the signature of a product that has finished capturing its market rather than one losing it.

wpBakery is the cautionary tale. Its install base was built on bundled ThemeForest themes, and it is now in sustained decline. Every one of those sites represents content locked into shortcodes that do not survive a builder migration cleanly. If you inherit one, the honest answer to “can we just switch builders” is usually no: you are rebuilding the content, not moving it.

6. Commerce: WooCommerce leads the web, Shopify leads the money

The WooCommerce-versus-Shopify numbers in circulation are the worst-behaved statistics in this entire report. We found published figures putting WooCommerce anywhere between 18% and 39% “market share” in the same six-month window.

They are not contradictory so much as incomparable. Here are three defensible measurements with their denominators attached:

WooCommerce leads the whole web by a factor of about 1.4x. Among the most-visited sites, the order flips and Shopify leads. Shopify also processes substantially more gross merchandise volume from fewer installations.

Both facts are real and they describe different businesses. WooCommerce’s count includes a very large number of WordPress sites that activated a free plugin and sell three things occasionally. Shopify’s skews toward merchants for whom commerce is the entire company.

7. Governance: the year the litigation cost a release

You cannot write an honest report on WordPress in 2026 without addressing the dispute between Automattic and WP Engine, because it stopped being gossip and started showing up in the release calendar.

The sequence, briefly. WP Engine filed suit in October 2024. In December 2025 a California federal judge ordered Automattic and Matt Mullenweg to restore WP Engine’s access to WordPress.org resources. Automattic, the WordPress Foundation and WooCommerce filed counterclaims alleging trademark misuse and deceptive branding. WP Engine’s third amended complaint, filed in early 2026, alleged that Automattic had planned to pursue royalty fees from ten different hosting companies and that Mullenweg attempted to have Stripe cancel WP Engine’s payment processing.

Where it stands as of late July 2026: discovery closed on 14 May 2026, with discovery hearings held on 27 and 29 May and arguments on both parties’ motions to dismiss heard on 25 June. No trial date has been set and no settlement has been reached. A separate customer class action, initially dismissed, was permitted to proceed after the court found the amended allegations supported an inference that Automattic knew the plaintiffs were WP Engine customers. WP Engine has produced over 630,000 pages in discovery. Trial is widely expected in late 2026 or 2027. You can follow the docket at wpvswpe.report.

The ecosystem cost is measurable. WordPress shipped no major release between 6.8 and 6.9. Executive Director Mary Hubbard cited ongoing legal matters as a factor in the decision to defer, and Automattic paused its core contributions during the period. A project that had been shipping three major releases a year shipped one.

8. What WordPress 7.0 actually changed

WordPress 6.9 “Gene” shipped in December 2025. WordPress 7.0 shipped on 20 May 2026, having been pulled from its original 9 April slot at WordCamp Asia in Mumbai. The real-time collaboration feature was storing sync data in post meta, which inadvertently disabled query caches sitewide whenever the block editor was opened. The fix required a new database table, which is not a change you rush.

That delay is worth knowing about, because it is evidence of a release process that stopped rather than shipped. Interpret that as you prefer.

7.0 formally opens Gutenberg Phase 3, collaboration and workflows, with block-level commenting, review workflows, and the Abilities and Connectors APIs that let plugins expose data sources and capabilities to the editor in a standardised way. Three releases are planned for 2026, with 7.1 targeted for August and 7.2 for December, the latter beginning work toward native multilingual support. The official roadmap is the only source worth trusting on timing.

The practical warning for agencies: the risk in 7.0 is not the update, it is plugin compatibility. Anything that heavily customises the editor (page builders, SEO plugins, multilingual tools, WooCommerce extensions) needs testing on staging first. Features that overlap with native Phase 3 collaboration are the ones most likely to conflict.

On the runtime side, WordPress.org’s own statistics API reports PHP 8.2 as the most common version at 25.8%, and PHP 7.4 still running 19.3% of installations. PHP 7.4 reached end of life in November 2022. Roughly one in five WordPress sites is running a PHP version that has been unsupported for over three years. That is the single largest source of latent risk in the ecosystem and it does not appear in any vulnerability count, because unsupported runtimes do not get CVEs, they just quietly stop being patched.

Our verdict: five positions we will defend

Original data is scarce in this ecosystem. Original opinion should not be. Here is where we actually stand.

1. Choose WordPress for the ownership, not the market share. The 41.5% figure is a reason to trust the talent pool and the plugin economy. It is not an argument about fit. The real argument is that you own the code and the content, and can leave. Every AI builder currently winning the bottom of the market has worse lock-in than Wix ever did.
2. Hosting is a performance decision, and it is made before design starts. Twenty points of Core Web Vitals separate managed from average self-hosted WordPress. That gap is larger than anything a developer will claw back later. Deciding hosting after the build is deciding it too late.
3. Plugin count is your security posture. Not your firewall. With 91% of vulnerabilities in plugins, a median five hours to exploitation and 46% of disclosures unpatched, the only defence that compounds is having less installed. We hold new builds to a hard ceiling and justify every exception.
4. Do not migrate a working site to escape a headline. The litigation does not break your site. Elementor’s decelerating growth does not break your site. A 1.7-point share decline does not break your site. Migrate when the platform genuinely stops fitting the business, and not because of a chart.
5. The performance gap is an opportunity, not an indictment. If 46% of WordPress origins pass Core Web Vitals and 86% pass INP, then the failure is concentrated, well understood and fixable. Most of your competitors on the same platform have not fixed it. That is a ranking advantage available for the cost of a diagnosis, and our free performance audit is exactly that diagnosis.

Methodology and sources

What we used. W3Techs for CMS market share across the top 10 million sites, quoted with its date because it updates daily. HTTP Archive’s Tech Report, via published analysis, for share of measurable origins and page builder detection. Google’s Chrome UX Report and the Core Web Vitals Technology Report for field performance. Patchstack’s State of WordPress Security in 2026 for vulnerability data. Store Leads for live store counts. WordPress.org’s statistics API for PHP and version distribution. Court filings and reporting for the litigation timeline.

What we did not do. We have not estimated, extrapolated or rounded any figure into a nicer-sounding number. Where sources disagree, and on ecommerce share they disagree wildly, we have published the range and named the denominators rather than picking the most convenient one. Where a figure comes from a single source we have said so.

Known limitations. Technology detection under-reports custom, obfuscated and headless stacks, which inflates the “no CMS” bucket. Block editor detection is unreliable because it ships in core. CrUX only covers origins with sufficient Chrome traffic, so quiet sites are invisible to it. Market share percentages are sensitive to crawl size changes; HTTP Archive’s mid-2022 expansion is a known discontinuity, which is why share-based rather than absolute comparisons are used throughout.

Corrections. If you can show a figure here is wrong, tell us and we will amend it with a visible note. A report that cannot be corrected is marketing.