This new unboxing video from Google shows off the Pixel 10a’s sleek, durable design and brand new Berry color.

Called Automations, the new system gives users a way to automatically launch agents within their coding environment, triggered by a new addition to the codebase, a Slack message, or a simple timer.

At its core, WordPress software is highly secure. The platform itself follows strong security practices and is regularly updated.

Most WordPress security issues don’t come from WordPress itself — but from how a site is set up and maintained.

In this guide, we’ll explain how secure WordPress is, where real risks come from, and what steps you can take to reduce your chances of being hacked.

Is WordPress a safe option for websites? 

Yes — WordPress is secure by design. Vulnerabilities in WordPress core are relatively rare and are usually patched quickly when discovered. Security issues occur within the WordPress ecosystem, not the core platform itself. 

Most successful attacks exploit:

• Outdated or abandoned plugins and themes.
• Weak or reused passwords.
• Missing software updates.
• Poorly configured or low-quality hosting environments.

Why do people think WordPress isn’t secure?

People think WordPress isn’t secure because it’s widely used, frequently targeted, and transparent about vulnerabilities — not because the core software is weak.

Here’s what contributes to this WordPress myth: 

• WordPress powers over 43% of all websites, so it simply shows up more often in security reports and browser warnings than other platforms.

• Issues caused by plugins, themes, or hosting are usually treated as WordPress problems, even though they’re not part of WordPress core. For example, Patchstack, WordPress’s vulnerability database, reported that of 5,948 vulnerabilities, almost 97% were found in WordPress plugins, while the core WordPress software had just 13 vulnerabilities in 2024.
• Security companies like Wordfence run bug bounty programs and publish vulnerabilities publicly. That improves WordPress security, but it also makes those issues easier to notice.

How secure and reliable is WordPress core?

WordPress core software is secure and actively maintained. Security issues in the core platform are relatively rare and typically patched quickly.

WordPress core security is supported by:

• A dedicated security team that reviews vulnerability reports and coordinates responsible disclosures.
• Open-source code transparency that allows thousands of contributors to identify and fix issues.
• Regular security updates, including automatic minor security releases.
• Built-in password strength tools that encourage strong credentials.

Most large-scale WordPress security issues do not originate in core software, but in plugins, themes, or poor site management.

How does WordPress.com further strengthen security?

WordPress core provides a secure foundation. But in practice, many security risks come from how a site is hosted and managed.

WordPress.com reduces those risks by handling key security layers for you.

It includes:

• Built-in two-factor authentication to protect accounts from unauthorized logins.
• Automatic WordPress core updates.
• Free SSL encryption on all sites.
• Daily security scans for plugins, themes, and malware.
• Web Application Firewall (WAF), DDoS mitigation, and brute-force protection.
• Regular platform backups, with real-time backups on Business and higher.
• Activity logging to monitor site changes.
• A dedicated security team supported by a public bug bounty program.

How to keep your WordPress website secure

To keep your WordPress site secure, you need to reduce avoidable risk — the kind that comes from outdated software, weak access controls, and hosting environments without built-in security protections.

Let’s explore the key steps you can follow.

1. Use strong, unique passwords for each account

Create a unique, complex password for each user account. Avoid easily-guessed formats like “password123” which are susceptible to brute force hacking attacks.

Use WordPress.com’s built-in password generator to create strong credentials, and change your password immediately if you receive a suspicious activity alert.

2. Enable two-factor authentication (2FA)

Turn on two-factor authentication to add a second verification step to your login.

With 2FA enabled, logging in requires your password plus a one-time code from an authenticator app or SMS. 

Even if someone obtains your password, they won’t be able to access your account without that code.

WordPress.com includes built-in two-step authentication. On self-hosted WordPress sites, you can enable 2FA through a security plugin.

3. Review and limit user access

Control who has access to your site and review user roles regularly.

Give each user their own account with the appropriate role. Avoid shared logins, and limit Administrator access to trusted users only.

At least once a month, go to Users → All Users and check:

• Are there accounts you don’t recognize?
• Does anyone have Administrator access who doesn’t need it?
• Are there old contributors or contractors who should be removed?
• Are external collaborators marked correctly?

Remove unused accounts or downgrade permissions if full access isn’t required.

4. Monitor your site’s activity log

Then, check your site’s activity logs regularly to see who logged in, what changed, and when. 

If you notice unfamiliar logins, new admin users, or unexpected plugin or settings changes, reset passwords immediately and investigate.

• WordPress.com’s Free, Personal, and Premium plans include 20-event logs, while the Business plan and above feature full logging with Jetpack’s Activity Log. 
• Self-hosted sites can install an activity log plugin for WordPress. 

5. Keep WordPress, themes, and plugins updated

Update your WordPress core, themes, and plugins as soon as new versions are released.

It’s essential since outdated software is one of the most common causes of WordPress security issues. 

Only install plugins and themes from reputable sources like the WordPress.com plugin directory, prioritize those that are actively maintained, and delete anything you’re not using — inactive plugins and themes can still create risk.

If you’re using WordPress.com, core updates are handled automatically, and the Business plan and higher include managed plugin updates. 

Many core features also come built into WordPress.com, so you don’t need to install as many plugins, which lowers your overall security risk.

On self-hosted WordPress sites, you’re responsible for monitoring and applying updates yourself.

6. Enable SSL certificates

Make sure your site uses HTTPS to encrypt data between your website and your visitors.

An SSL certificate protects sensitive information like login credentials and form submissions. Without it, browsers may label your site as “Not secure,” which can damage trust and expose user data.

You can verify SSL is active by checking for https:// and a padlock icon in your browser’s address bar:

All sites hosted on WordPress.com include a free SSL certificate enabled by default. On self-hosted WordPress sites, SSL must be configured through your hosting provider. 

7. Set up reliable backups 

Make sure your site is backed up regularly so you can restore it if something breaks or your site is compromised.

Backups allow you to roll back to a clean version after a failed update, malware infection, or accidental change. 

Look for solutions that offer automated backups and simple restore options — e.g., the JetPack plugin.

On WordPress.com, sites are backed up at the platform level, and Business and Commerce plans include real-time backups with one-click restores via Jetpack VaultPress Backup. 

For self-hosted WordPress sites, you’ll need to install a backup plugin to achieve the same level of protection.

8. Choose secure web hosting

Opt for a trusted WordPress hosting provider with robust security features to ensure a safe environment for your website. 

When choosing a web hosting provider, look for:

• Firewalls to block suspicious traffic.
• Suspicious activity monitoring to protect against unwanted login attempts, brute force attacks, and distributed denial of service (DDoS) attacks.
• Daily scans of sites for dangerous plugins, themes, malware, and other vulnerabilities.
• Managed updates that automatically apply the latest patches for WordPress core, plugins, and themes. 
• An expert security team that monitors threats and resolves issues as soon as they arise. 

On WordPress.com, these layers are built into the platform, with additional security features powered by Jetpack — including activity logging, malware scanning, and real-time backups on eligible plans.

7. Stay informed 

New threats emerge all the time, so we recommend keeping up to date on WordPress and website security issues.

You don’t need to become a web security expert. But you can follow the latest WordPress security news and check for issues that may concern your site’s security. 

We recommend these sources for reliable WordPress security news:

• Patchstack Security News
• Sucuri Monthly Vulnerability & Patch Roundup
• Wordfence Blog

Ensure your website security with WordPress.com

Out of the box, and at its core, WordPress is highly secure. Vulnerabilities typically come from outdated plugins and themes, insecure hosting, or poor security practices.

According to Patchstack, “vulnerability management and mitigation (coupled with 2FA & session management) remain the most important proactive security measures.”

The simplest way to stay on top of these security habits is to use a hosting provider that handles them for you.

WordPress.com includes built-in protections like automatic core updates, free SSL, firewalls, malware scanning, activity monitoring, and backups — reducing the number of security tools you need to manage yourself.

Temani Afif recently did this exercise and I thought I’d build off of it. Some of these are useful. Many of them are not. There’s a bird at the end!

html

html {
  /* I mean, duh */
}

:root

:root {
  /* Sarsaparilla, anyone? */
}

:root is a CSS pseudo-class that matches the root element of the current (XML) document. If the current document is a HTML document, then it matches <html>. The XML documents that you’ll most likely encounter as a web developer (besides HTML) are:

• SVG documents: :root matches <svg>
• RSS documents: :root matches <rss>
• Atom documents: :root matches <feed>
• MathML documents: :root matches <math>
• Other XML documents: :root matches the outermost element (e.g., <note>)

But what’s the practicality of :root? Well, the specificity of pseudo-classes (0-1-0) is higher than that of elements (0-0-1), so you’re less likely to run into conflicts with :root.

It’s conventional to declare global custom properties on :root, but I actually prefer :scope because it semantically matches the global scope. In practice though, it makes no difference.

/* Global variables */
:root { --color: black; }
:scope { --color: black; }

Let’s talk about :scope some more…

:scope or &

:scope {
  /* Insert scope creep here */
}

Okay, that’s not really what :scope is for.

As I mentioned, :scope matches the global scope root (<html>). However, this is only true when not used within the newly baseline @scope at-rule, which is used to define a custom scope root.

We can also do this:

& {
  /* And...? */
}

Normally, the & selector is used with CSS nesting to concatenate the current selector to the containing selector, enabling us to nest selectors even when we aren’t technically dealing with nested selectors. For example:

element:hover {
  /* This */
}

element {
  &:hover {
    /* Becomes this (notice the &) */
  }
}

element {
  :hover {
    /* Because this (with no &) */
  }
}

element :hover {
  /* Means this (notice the space before :hover) */
}

element {
  :hover & {
    /* Means :hover element, but I digress */
  }
}

When & isn’t nested, it simply selects the scope root, which outside of an @scope block is <html>. Who knew?

‌:has(head) or :has(body)

:has(head) {
  /* Nice! */
}

:has(body) {
  /* Even better! */
}

<html> elements should only contain a <head> and <body> (à la Anakin Skywalker) as direct children. Any other markup inserted here is invalid, although parsers will typically move it into the <head> or <body> anyway. More importantly, no other element is allowed to contain <head> or <body>, so when we say :has(head) or :has(body), this can only refer to the <html> element, unless you mistakenly insert <head> or <body> inside of <head> or <body>. But why would you? That’s just nasty.

Is :has(head) or :has(body) practical? No. But I am going to plug :has(), and you also learned about the illegal things that you shouldn’t do to HTML bodies.

:not(* *)

:not(* *) {
  /* (* *) are my starry eyes looking at CSS <3 */
}

Any element that’s contained by another element (* *)? Yeah, :not() that. The only element that’s not contained by another element is the <html> element. *, by the way, is called the universal selector.

And if you throw a child combinator right in the middle of them, you get a cute bird:

:not(* > *) {
  /* Chirp, chirp */
}

“Siri, file this under Completely Useless.” (Ironically, Siri did no such thing).

---

The Different Ways to Select <html> in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.