What Your Site Tells Strangers Before You Say a Word

Before a visitor reads a single word on your site, the site has already answered a dozen questions about itself. That is not a flaw unique to your host or your CMS. It is how the web works: everything you publish is also, unavoidably, a description of the thing that published it.

None of it is hidden from you. You have just never read your own site the way someone who has never met you reads it — as an inventory rather than a homepage.

What is public by default

Start with what answers without being asked. On a stock WordPress install, all of the following will talk to a stranger with no account and no invitation:

• robots.txt is a public list of the paths you consider sensitive. Read it as a stranger and you will find the admin panel, the upload directories and the log folders you hoped nobody would look at. It is also advisory: it asks crawlers to stay out, and the ones that ignore it are the ones you were worried about.
• Sitemaps enumerate every published page, including the drafts you forgot you made public and the landing pages you built for one client and never deleted. Yours is at /wp-sitemap.xml, or whatever an SEO plugin renamed it to.
• Generator tags announce the platform, often with a version number — <meta name="generator" content="WordPress 6.7.1">. A version number is a shopping list of known issues, and it is the first thing a scanner reads.
• Asset paths name the plugins and theme you are running — a second copy of the same inventory. Every /wp-content/plugins/whatever/ in your source is a line item, and the ?ver= stuck on the end of a stylesheet is frequently the version.
• The REST API and xmlrpc.php answer questions by default on a stock install: what content exists, and depending on configuration, which accounts exist. /wp-json/wp/v2/users will happily list your author names to anyone who asks.

You can inventory most of it in three commands:

curl -s https://example.com/robots.txt

curl -s https://example.com/wp-json/wp/v2/users

curl -s https://example.com/ | grep -Eo 'wp-content/(plugins|themes)/[^/?"]+' | sort -u

The first returns your do-not-enter list. The second returns your usernames, which is the half of a login most people assume is private. The third returns the plugin and theme slugs you are actually running.

None of that is a vulnerability. All of it is intelligence.

Fingerprinting does not break anything. It removes the guessing. It tells someone which of a hundred approaches is likely to work before they spend an hour on it — and it does the same thing for you: it shows you what your front door looks like from the street.

The asymmetry is worth stating plainly. A scanner runs the same list against millions of hosts; it is not looking for you, it is looking for the version number that matches a tool it already has. You have to be right about your exposure everywhere, once. It only has to find the one endpoint you forgot about.

Which is also why the honest answer to “what do I fix first” is usually dull. Not the exotic path you read about in a headline. The plugin nobody has touched since 2023, the .php file someone dropped into uploads/, the backup archive sitting at /backup.zip, the staging copy that still resolves and still points at the old database.

What I actually do about it

• Strip version strings where they are cosmetic. They exist for convenience, not for visitors — nothing needs them but a cache and a scanner. In WordPress that is two filters and a generator tag: the same strip_ver callback on style_loader_src and script_loader_src at priority 9999, plus remove_action('wp_head', 'wp_generator').
• Treat robots.txt as public documentation, not as a security control. Anything secret does not belong there. Naming /private-notes/ in a public file is an announcement, not a lock.
• Ask what every public endpoint reveals, then decide whether answering is worth it. If nothing on the site uses XML-RPC, turn it off rather than filtering it. If your author list does not need to be public, stop publishing it. If uploads/ does not need a directory index, deny it at the server with Options -Indexes instead of hoping nobody types the path.
• Keep an inventory of what is installed. The biggest surprise is always the plugin you installed for one afternoon in 2023 — wp plugin list if you have WP-CLI, the Plugins screen if you do not, and either way a real date attached to how long each one has gone untouched.
• Update what you keep, and delete what you do not use. The exposure that matters is not the one you know about. Anything you stop maintaining becomes a permanent fixture on somebody else’s list, and deactivated is not the same as gone.

Security is not a moat. It is knowing what your own site looks like to someone who has never visited it.