WordPress Security

Type example.com/?author=1 into your address bar. If WordPress redirects you to a page with a username in the URL, you just enumerated your own admin.

That’s user enumeration. It hands attackers half of every login, so they only have to guess the password.

Where usernames leak

There are three common routes. The ?author=1 redirect works by counting through user IDs. The REST API lists authors at /wp-json/wp/v2/users. And the author archive pages, like /author/yourname/, print the login name right in the address.

Login error messages leak too. “The password you entered for the username admin is incorrect” confirms that “admin” exists.

Block the ?author= scan

Add this rule to .htaccess above the WordPress block. It sends the scan to the home page.

RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* /? [L,R=301]

Test it afterwards by loading /?author=1 again. You should land on your home page, not an author URL.

Close the REST API route

Anonymous visitors shouldn’t be able to list users. The steps are in the guide to restricting the WordPress REST API, which covers both a code snippet and a path change.

Change the author path

Public author archives put the login name in the URL. WP Ghost can change that path and swap the ID, and the author path guide has the steps.

The sitemap author listing leaks names too.

Make the display name different from the login

Go to Users, edit your profile and pick a display name that isn’t your login. Then change any admin account still named “admin” to something else. Create a new administrator, move the content over and delete the old one.

Stop the login form giving hints

Return one generic message for every failed login. A filter on login_errors that returns “Login failed.” does it.

Then turn on two-factor authentication.

Check your work

Run the three tests again. /?author=1, /wp-json/wp/v2/users and /author/yourname/ should all fail to show a login name. Do it in a private window so you see what a stranger sees.

FAQ

Is user enumeration dangerous?

On its own it breaks nothing. It makes password attacks cheaper, because the attacker already has the username.

Can I protect a multi-author blog?

Yes. Show author display names, and keep the login name out of URLs and the API.

How can I see enumeration attempts?

Look for requests to /?author= with rising numbers in your access logs.

Visit example.com/wp-json/wp/v2/users in a private browser window. On many sites you get a list of usernames, no login needed.

The WordPress REST API is on by default, and it answers anyone who asks. Parts of it are needed. Parts of it just give strangers a free look at how your site is built.

What the REST API shows a stranger

Two endpoints do most of the damage. /wp-json/wp/v2/users can list your authors and their usernames. /wp-json/ itself lists the plugins that register routes, which tells a scanner what you run.

That’s a head start for anyone planning a password attack or picking an exploit.

Don’t switch it off completely

The block editor uses the REST API. So do many plugins, contact forms and page builders. Turn it off for everyone and your editor stops saving.

The safer move is to restrict it for people who aren’t logged in.

Restrict it for logged-out visitors

Add this to your theme’s functions.php or a small custom plugin. It returns an error for anyone who isn’t signed in.

add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    if (!is_user_logged_in()) {
        return new WP_Error('rest_forbidden', 'Not allowed.', array('status' => 401));
    }
    return $result;
});

Some public features break with this. A headless front end, a contact form that posts to the API, or an app reading your posts will all need a login or an exception. Test your forms right after you add it.

Change the API path instead

Another option is to move /wp-json/ to a path of your own, so scanners that look for the default find a 404. WP Ghost does this, and the steps are in the guide to changing the REST API path.

I’d ship the path change first on a public site, because it breaks fewer features than blocking logged-out access. The login restriction is stricter and fits sites with no public API use.

Check the result

Open /wp-json/wp/v2/users again in a private window. You want a 401, a 403 or a 404, not a list of names. Then open the editor and save a draft to confirm it still works.

Also look at the author path and ID settings, since author archives leak the same usernames by another route.

FAQ

Is the REST API a security risk?

It lists usernames and routes to anyone by default. Restricting it for logged-out visitors closes most of that.

Can I disable it without breaking Gutenberg?

Not fully, since the editor needs it. Restrict logged-out access or change the path instead.

Will changing the path break plugins?

Plugins that use WordPress functions follow the new path. Test forms and integrations that have the old one typed in.

How do I see if my users are exposed?

Visit /wp-json/wp/v2/users while logged out. Usernames in the response mean they’re exposed.

Open example.com/xmlrpc.php in a browser. If you see the text “XML-RPC server accepts POST requests only”, the file is live and answering strangers.

That file is a leftover from the days before the REST API. Mobile apps and remote publishing tools used it to talk to WordPress. Most sites today use none of that, and the file still sits there with its doors open.

Why attackers like xmlrpc.php

The file accepts login attempts. One request can carry many username and password guesses through a method called system.multicall, so a bot tries hundreds of passwords in a single hit. Your login page never sees most of it.

It also supports pingbacks. Those can be abused to make your site send traffic to a target, which is how a small blog ends up helping in someone else’s attack.

Check whether you need it

Plugins that connect your site to WordPress.com can still use xmlrpc.php for that link.

Test on a staging copy if a plugin connects your site to WordPress.com or you post from a remote publishing tool.

If you use none of those, turn it off. If you aren’t sure, turn it off on a staging copy first and see what breaks.

Disable it on Apache

Add this to the .htaccess file in your site root.

<Files xmlrpc.php>
  Require all denied
</Files>

On older Apache 2.2 servers the line is Order deny,allow followed by Deny from all. Requests now get a 403 before WordPress loads at all, which also saves server work.

Disable it on Nginx

Add this inside your server block, then reload Nginx.

location = /xmlrpc.php {
  deny all;
}

Disable it with WP Ghost

If you would rather not touch server files, WP Ghost has a setting for it. The steps are in the guide to disabling XML-RPC with WP Ghost. It’s one toggle, and it keeps working after a host migration, which a hand-edited .htaccess often doesn’t.

Check that it’s closed

Reload example.com/xmlrpc.php. You want a 403 or a 404. Then run the Website Security Check, and test again after your next host move.

Bots can still guess passwords at your login page. Add brute force protection, and see the complete hack prevention guide for the next steps.

FAQ

Will disabling XML-RPC break my site?

Only if a plugin or app still uses it. Test on a staging copy if a plugin connects your site to WordPress.com or you post from a remote publishing tool.

Does the REST API replace XML-RPC?

For almost everything, yes. XML-RPC stays for backward compatibility.

Can I just rename xmlrpc.php?

Updates can put the file back. A server rule that denies the request holds up better.

How do I spot an attack on xmlrpc.php?

Look in your access logs for repeated POST requests to /xmlrpc.php from a few addresses.

Type /wp-content/uploads/ into a browser. If you see a file list, anyone can read your uploads. Here’s how to disable directory browsing and confirm it’s closed.

Every bot on the internet tries /wp-login.php first. Change your login slug to a custom URL, safely, without breaking WooCommerce emails or membership plugins.

Stripping the generator tag from your header isn’t enough. Remove your WordPress version from the meta tag, RSS feed, ?ver= strings, and readme too.

Change your wp-content, plugins, and uploads paths so attackers can’t map your site. A safe, conflict-free way to secure WordPress paths.

Detectors expose your WordPress version, theme, and plugins in seconds. See how to hide WordPress from detectors and erase the fingerprints.

Open a random site in your browser, click a detector extension, and it names the CMS, the theme, and half the plugin stack before the page finishes loading. Any visitor, or any attacker, can do the same to your site right now. Removing your footprint tag by tag helps, but detectors are built to beat exactly that. They read dozens of signals at once and need only one to confirm you.

This guide is about defeating the detectors specifically: the browser extensions, the online CMS scanners, and the technology-profiling databases that fingerprint WordPress. If you have already worked through general WordPress footprint removal, this is the next layer, which is making the tools that look for WordPress come back empty.

How WordPress detectors actually fingerprint you

Detectors do not see WordPress. They match patterns. Knowing which patterns they check is most of the work, because you cannot hide from a signal you do not know you are sending. Technology profilers like Wappalyzer and BuiltWith, plus CMS scanners like WhatCMS and the security-focused WPScan, look at:

1. HTML fingerprints. The generator meta tag, //s.w.org and //api.w.org references, emoji and oEmbed scripts, and body classes such as page-id-*.
2. Asset paths. Any /wp-content/, /wp-includes/, or theme and plugin directory in your source is a near-certain WordPress tell.
3. HTTP headers. The Link header advertising the REST API (rel="https://api.w.org/"), the X-Pingback header, and default cache headers.
4. Predictable URLs. /wp-json/, /wp-login.php, /readme.html, /xmlrpc.php, and /wp-admin/. A single 200 response confirms the platform.
5. Cached and historical records. This is the one people miss. Profiling databases store what your site looked like the last time they crawled it, so they keep reporting WordPress long after you clean the live page.

You remove signals 1 to 4. Signal 5 you have to flush actively, which the last step covers. For a fuller catalogue of which tools check what, see the most popular WordPress theme detectors and how to hide from WordPress theme detectors.

Make detectors come back empty: The anti-fingerprinting steps

Work through these in order and re-test with a detector after each one. The goal is not fewer signals. It is zero confirming signals, because one is enough.

1. Kill the version and generator tags. Remove the generator meta tag and strip ?ver= strings from CSS and JS so scanners cannot read your version. Details in how to hide the WordPress version and remove the generator meta tag.
2. Rewrite /wp-content/ and /wp-includes/. These paths are the loudest structural fingerprint a profiler reads. Map them to neutral paths carefully, so references do not break, using custom WordPress paths.
3. Remove the REST API discovery signal. Drop the Link header advertising api.w.org and restrict unauthenticated /wp-json/ responses that leak users and active plugins.
4. Block the giveaway files and endpoints. Return 404s on readme.html, license.txt, wlwmanifest.xml, and the RSD endpoint, and remove the X-Pingback header.
5. Change the login and admin paths. A custom login slug plus redirects on /wp-login.php and /wp-admin/ removes both a confirmation signal and the target of automated login attacks.
6. Strip the small tells. Remove theme and plugin HTML comments, the emoji script, and s.w.org DNS-prefetch tags. These are the leftovers most people forget after doing the big items.
7. Flush cached detection results. After the live page is clean, re-scan and, where the profiler allows, request a re-crawl so its stored record updates. This is the step that makes the database-backed detectors finally agree you are hidden.

“I hid everything, but BuiltWith still says WordPress”

This is the most common complaint, and it is almost always signal 5, the cached history. BuiltWith and similar profilers are databases, not live scanners. They report the last snapshot they took, so a site you cleaned yesterday can show WordPress for weeks until the record refreshes. The fix is not more hardening. It is forcing or waiting out the re-crawl. The detector-specific playbooks cover the exact process. Hide WordPress from BuiltWith walks through the cache-removal steps, and hide WordPress from Wappalyzer covers the extension that reads your live page in real time.

The detectors you won’t fully beat

Know the ceiling here. Some detection is behavioural rather than signature-based: response timing, the shape of a 404 page, how the site handles a malformed request, or JavaScript globals a script reads after the DOM loads. A determined analyst running a custom check can often still infer WordPress even when every standard signal is gone. Anti-fingerprinting defeats the automated, at-scale detection that feeds opportunistic attacks. It does not guarantee invisibility to a human who is specifically investigating you. Aim for scanners that give up, and accept that a focused person may still work it out.

Manual hardening vs. a managed approach

You can do every step above by hand. The problem is durability. A core update restores readme.html, a new plugin enqueues fresh versioned assets, and your cleaned headers reset. Miss one signal after any update and the detectors light up again. Anti-fingerprinting is only as good as its weakest un-refreshed moment.

A dedicated solution keeps the whole signal set suppressed and re-applies it after updates. Hide My WP Ghost bundles the anti-fingerprinting work. It hides the generator and DNS-prefetch tags, strips versions from image, CSS, and JS files, removes detector-readable HTML comments, rewrites wp-content and wp-includes, redirects the default login and admin paths, and handles the cached-detection cleanup for the profiling databases. Review the full list of security features to see each toggle, and confirm your result with how to know if your site is hidden from detectors.

The payoff: An empty scan

A clean detector result changes the economics of attacking you. Opportunistic bots pick targets by scanning for a known CMS and version, then firing the matching exploit. When Wappalyzer, BuiltWith, and the CMS scanners return nothing, or return a false or blank result, your site drops off those automated target lists. You are not invisible to a skilled human, but you have removed yourself from the volume game where most attacks actually happen. Start with the version and generator tags today, work down the seven steps, and then flush the caches so the databases agree.

Frequently asked questions

If I already removed my footprint, why do I still need detector evasion?

Footprint removal and detector evasion overlap, but they are not identical. Footprint removal cleans your live source. Detector evasion also handles the cached databases and the real-time extensions that re-check you. A site can have a clean footprint and still show WordPress in a profiler that has not re-crawled.

Will hiding from detectors break my site or hurt SEO?

No, when done correctly. Search engines index your content, not your CMS signature, so a blank detector result has no effect on rankings. The only real risk is careless path rewriting, so check that old URLs redirect and that you don’t create 404s.

Can Wappalyzer or BuiltWith still detect me after all this?

The live-page extension (Wappalyzer) should come back empty once every signal is gone. The database-backed profiler (BuiltWith) may lag until its cached record refreshes, which is expected and clears with a re-crawl rather than more hardening.

Is detector evasion the same as being secure?

No. It reduces your automated attack surface, which is real and valuable, but it never replaces updating plugins, running a firewall, and enforcing strong logins. Treat it as one layer, not the whole defense.

How do I verify I’m actually hidden?

Run the site through several detectors, a live extension, an online CMS scanner, and a profiling database, and confirm each returns no WordPress signature. Re-check after every major update, since a WordPress, theme or plugin update can bring the signals back.

Bots fingerprint WordPress before they attack. Remove the meta tag, exposed paths, and files that reveal your site — without breaking anything.