How Many Websites Use WordPress? Market Share, Security Risks and Practical Fixes

WordPress use in 2026: the accurate answer starts with the denominator

WordPress was detected on 40.2% of all websites in W3Techs’ relevant-web survey on 19 September 2026. In the same snapshot, it represented 58.8% of websites for which W3Techs knew the content management system. The first figure describes the whole relevant-web sample used by W3Techs; the second is a share within the smaller group where a CMS could be identified. Both figures are useful, but they answer different questions.

That distinction makes an unqualified statement that WordPress powers 80% of websites inaccurate. Neither the 40.2% all-websites figure nor the 58.8% CMS-known figure says that. A percentage from a niche, a hosting provider or a separately defined group might be valid for that particular group, but it cannot be presented as the share of the web without naming its method and population.

For readers asking how many websites use WordPress, the responsible shorthand is therefore date-specific: W3Techs placed WordPress at 40.2% of all websites in its relevant-web sample, and at 58.8% among websites whose CMS it knew, as at 19 September 2026. The figures are snapshots rather than a timeless total, so a later update should recheck both the values and the wording around them.

A useful way to report the result is to say both figures together rather than choosing the larger one. That keeps the comparison honest for readers deciding whether WordPress is widely used in a market, while avoiding a false impression that the CMS-known statistic covers every website. It also leaves room for the fact that the source’s relevant-web sample and detection rules define what the measurements mean.

What W3Techs measures, and why a snapshot needs context

W3Techs says its technology reports are based on a relevant-web sample of well over 20 million websites. Its methodology excludes sites without useful content and essential duplicates, and it treats a technology found on any page as used by that website. This is a defined measurement approach, not a census of every registered domain or every page on the internet.

Its reports are updated daily. That is why a careful market-share claim should carry four details: the named source, the check date, the denominator and a short description of the method. It is also why a percentage should not be converted into a total number of sites without a compatible estimate of the population being measured.

The CMS context matters as well. W3Techs separately reports that some sites use none of the CMSs it monitors. In practical terms, a CMS-known share tells readers how WordPress compares inside a classified CMS group, while the all-websites share includes the wider relevant-web sample. Treating the two as interchangeable overstates what either number proves.

W3Techs’ conventions also explain why these statistics should not be read as a quality ranking, a count of active businesses or a security measure. Detection of a technology on a page is not evidence about how carefully its owner maintains it. Adoption data can describe reach within a defined sample, but the security of an individual WordPress installation requires separate evidence from its software, configuration, accounts and operating practices.

Is WordPress secure? Separate the software from the installation

WordPress is not accurately described as inherently insecure. WordPress says its Security Team identifies and resolves core issues, coordinates fixes and releases with hosts and security providers, and can backport critical fixes to older versions as a courtesy. It also says only the latest release is officially supported. Those statements show an active maintenance and disclosure process; they do not make every installed site safe by default.

A WordPress site is an operating system of people, code and services around the core application. Its risk can be affected by third-party plugins, themes, child themes and custom integrations; by who can administer it; by the web server, PHP runtime and database; and by configuration choices such as access, HTTPS and file write permissions. A current core version is important, but it is not a complete security assessment.

WordPress’s own administration guidance frames security as continuing planning, maintenance, monitoring, risk reduction and recovery rather than a one-time installation task. That is a useful standard for a small business or publisher: assign owners, make changes deliberately, check evidence after changes and make sure recovery has been practised. Security controls reduce risk; they do not provide a promise that an incident cannot happen.

The distinction between core and a deployment helps avoid misplaced blame when a vulnerability is disclosed. A core release issue is addressed through WordPress’s core security and release process. An extension or custom-code issue may require a plugin or theme supplier, developer or site owner to act. Hosting and identity problems may require the provider and the organisation’s administrators to act. Naming the layer makes a remediation conversation more precise.

The main risk layers: core, extensions and custom work

Core software needs a clear update policy. WordPress documentation says older versions are not maintained with security updates and stresses keeping WordPress itself, plugins and themes up to date. Minor security updates can be delivered in the background on supported WordPress versions, but a business should still know who reviews update status, who approves significant changes and whether a staging check is sensible for its particular site.

Plugins are separate code supplied by third parties, so each one adds a maintenance and trust decision. Themes, child themes, code snippets and custom integrations deserve the same attention. WordPress’s developer guidance identifies plugins and themes as possible weak points and advises developers to validate untrusted input, sanitise it where needed, escape output late and use WordPress APIs. For a site owner, the practical equivalent is to keep an extension inventory, keep only what is necessary and ensure custom changes have a responsible maintainer.

The most useful verification is simple and repeatable. In the WordPress administration area, record the installed core version and the version, supplier, purpose, owner and update status of every plugin and theme. Compare installed versions with the supplier’s current fixed or supported release. Remove unused extensions rather than leaving them installed without an owner, and retain a suitable fallback theme where the site’s operating needs call for one.

Before a major change, take a backup and decide how the organisation will verify normal functions afterwards, such as contact forms, user sign-in, checkout or an internal publishing workflow. WordPress recommends backups before upgrades, while the appropriate test scope depends on the site. Keeping a short change record also helps a future maintainer identify when a problem appeared, without assuming that every update should be delayed indefinitely.

A bounded September 2026 plugin example

A disclosure on 1 September 2026 illustrates why extension inventories and prompt patching matter. Wordfence reported an unauthenticated second-order SQL injection vulnerability, identified as CVE-2026-19949, in the All-in-One WP Migration and Backup plugin. Its report said versions through 7.109 were affected and named version 7.110 as the patched release.

Wordfence described the reported impact as potentially leading to remote code execution after a particular restore workflow. That condition is important. The disclosure is evidence about a named third-party plugin and specified versions, not about WordPress core, every WordPress backup product or every WordPress site. It also does not establish that a site has been targeted merely because the plugin was once installed.

The safe response is verification rather than alarm. A site manager can establish whether the named plugin is present, check the installed version against the vendor’s fixed version, review whether the relevant restore process is in use and apply the vendor’s update guidance after appropriate backup and compatibility checks. If the plugin is not needed, removal may be preferable to carrying an unused dependency. Changes should be tested and recorded according to the organisation’s normal change process.

The disclosure should not be turned into a prevalence claim. Its headline referenced five million sites, but a published installation count is not a verified count of vulnerable, reachable or compromised sites. Exposure depends on the named version and the conditions described by the researcher, among other site-specific facts. The responsible conclusion is limited: a relevant installed version required timely review and, where applicable, the supplier’s patch.

Accounts and roles are part of WordPress security

An administrator account can change code, users and settings, so account compromise can outweigh an otherwise tidy update record. WordPress recommends strong passwords and two-step authentication, while OWASP recommends multi-factor authentication where possible and explains risks including brute-force attempts, credential stuffing and password spraying. The response is not to share one administrator login among a team; each person should have a named account and only the privileges needed for their job.

Least privilege is a practical review exercise. List all administrator-level users, confirm why each still needs that role and remove or reduce access when a staff member, agency relationship or task ends. Use unique, long passphrases held in a password manager, make MFA a requirement for administrators and keep an offboarding process for access removal. Suspected credential exposure should trigger a response process; routine forced password changes on a calendar are not a substitute for stronger authentication and detection.

Login protection should be checked, not assumed. Confirm that administrator sign-in uses HTTPS, that MFA enrolment is complete for required users, and that the site or its hosting layer has an appropriate rate-limit or login-throttling and alerting arrangement. WordPress warns that HTTP logins can expose credentials in transit, while OWASP calls for defences against automated login attacks. The right setting varies by hosting architecture, so the verification should include a recorded owner and a test of the intended login path.

MFA and least privilege also need an operational fallback plan. Keep recovery methods under controlled access, review them when staff change and make sure emergency access does not become an unmonitored permanent administrator account. A password manager and named roles make this easier to administer. These measures are intended to lower the likelihood and impact of account misuse; they do not remove the need to investigate unusual access alerts.

Hosting, HTTPS and permissions need clear ownership

A WordPress installation runs inside a wider server environment. An unsupported PHP version, an unpatched web server, a database problem, a compromised administrator computer or weaknesses on a shared environment can affect the site even if its WordPress dashboard shows no pending update. WordPress advises using secure, stable server software or a trusted host, and notes that a compromise on a shared server can affect another site.

Ask the host or internal platform team a direct question: who patches WordPress core, plugins, PHP, the web server, database, operating system, backups and the underlying infrastructure? The answer should be documented rather than inferred from a marketing page. Also confirm the supported runtime versions, the incident contact route, the backup boundaries and whether secure administrative access such as SFTP is available instead of plaintext FTP.

File write access should follow least privilege. WordPress warns that write access can be dangerous and provides restrictive ownership and permission guidance, but a universal command is not safe because hosting layouts differ. A practical check is to have the responsible host or technical team review ownership and permissions, verify that only the appropriate service account can write where necessary, and confirm that diagnostic errors are logged rather than displayed publicly in production. Test that visitors and administrators are consistently redirected to HTTPS where intended.

HTTPS and secure transfer methods protect credentials and data while they travel, but they do not replace patching or access control. Likewise, restrictive file permissions reduce unnecessary write access but do not fix a vulnerable plugin or a compromised administrator account. The value of assigning infrastructure responsibilities is that each layer is checked by the person or provider able to maintain it, rather than being assumed to be covered by another layer.

A prioritised hardening checklist with evidence to keep

First, create a current inventory and patch plan. Record WordPress core, plugins, themes, custom code locations, hosting components and their owners. Apply available updates after taking a backup and considering compatibility, especially for significant changes. Check the WordPress updates screen, supplier advisories and hosting notices, then keep a short record of what changed, who approved it and any justified exception. An inventory turns a vague security task into a list that can be reviewed.

Second, reduce what must be defended. Uninstall plugins and themes that are no longer needed, retire abandoned custom features where possible and review administrator accounts and roles. For every remaining extension, retain the purpose, supplier, current version and owner. This is not a claim that every third-party extension is unsafe; it is a way to prevent an unknown or unowned component from becoming a patching blind spot.

Third, protect the people and entry points. Require unique named accounts, long unique passphrases, MFA for administrators and HTTPS logins. Confirm the user-role list after staffing or supplier changes, and use appropriate rate limiting, login throttling and alerts to make automated password attacks harder to sustain. Review the host’s secure administration methods and the administrative devices used to manage the site.

Fourth, check the recovery and detection evidence. Confirm that backups include the database and site files, that copies are retained separately from the live site, that update and security alerts reach a named person, and that a restoration was actually completed in a controlled test. A checklist is complete only when each item has an owner, a date and a result. It should be adapted to the site’s size, traffic, regulatory duties and technical design rather than treated as a promise of universal protection.

Backups, monitoring and restoration turn maintenance into resilience

WordPress documentation says a full restore normally requires both the database and the files. It recommends regular backups, backups before upgrades and keeping several recent copies in different locations. A backup that omits uploads, themes, configuration or the database may be of limited use when it is needed most, so a backup plan should state exactly what is covered and who can access it during an incident.

The key test is restoration, not the presence of a green backup indicator. Schedule a controlled restoration exercise suitable for the organisation’s environment, document the date, what was restored, any missing data or permissions problems and the time required. Test after significant hosting, plugin, theme or architecture changes as well as on a regular cadence. This provides evidence that the recovery path is understood before a disruption.

Monitoring completes the loop. A named person should receive and review update notices, account alerts, backup failures and relevant hosting notifications. Keep contact details for the host, site maintainer and decision-maker available, and write a concise incident and recovery procedure. Monitoring and backups reduce the impact of problems; they cannot establish in advance that every compromise will be detected or every restoration will be effortless.

Make WordPress security an operating routine, not a one-off project

After the initial clean-up, set a documented cadence. Review updates and urgent supplier notices promptly, revisit extensions and privileged accounts at planned intervals, test the backup path, and record exceptions with an owner and expiry date. Major updates may warrant a staging test where the site has complex functions or integrations. The aim is proportionate maintenance with clear accountability, not constant disruptive change.

The balanced conclusion is straightforward. WordPress’s W3Techs share is large but should be stated precisely: 40.2% of all websites in W3Techs’ relevant-web snapshot and 58.8% among the sites whose CMS it knew on 19 September 2026. Its security question is equally practical: keep core and extensions maintained, control privileged access, use a securely managed hosting environment, protect logins and prove that recovery works. That approach is more useful than either an inflated market-share claim or a blanket judgement about the platform.