The fix, in one snippet
curl -s https://example.com | grep -o 'wp-content\|wp-json'Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now fetches the homepage and looks for three markers in the HTML. The first is any asset URL under /wp-content/, the directory that holds themes, plugins and uploads. The second is a script or stylesheet under /wp-includes/, where core ships jQuery, the block library and the emoji loader. The third is a reference to the REST API: the <link rel="https://api.w.org/"> discovery element that WordPress prints in <head>, or an absolute /wp-json/ URL anywhere in the page. One marker is enough, and the report says which ones matched. Sites behind a CDN or a path-rewriting plugin sometimes hide the first two, so the wp-json reference is often what gives them away. No WordPress-specific request is sent to make this decision; it is read from the page you would receive in a browser. Rated informational. When it fires, the checks in this category run, along with the exposure probes for version disclosure, xmlrpc.php and user enumeration.
Why it matters
Running WordPress is a fact, not a finding. It matters for what follows. W3Techs' surveys consistently put WordPress far ahead of every other content management system, and attackers allocate effort accordingly: a newly disclosed plugin vulnerability is scanned for across the whole internet, and the scanners do not care whether a site is a personal blog or a bank's marketing page. Core itself is well maintained and updates automatically for minor releases; the risk lives in the tens of thousands of plugins and themes that run with the same privileges as core and are maintained by people with very different levels of care. Knowing you are WordPress sets the agenda: keep core, plugins and themes updated, remove what you do not use, and close the WordPress-specific exposures that make reconnaissance cheap. The WordPress scanning guide walks through what an external scan reveals and the order in which to fix it.
How to fix it
There is nothing to fix, and hiding the fact is not a strategy: renaming wp-content or stripping the generator tag does not survive the REST route fingerprinting described under wordpress-plugin-inventory. Spend the effort on the things that decide outcomes. Confirm that automatic updates are on for core and turn them on for plugins and themes you trust:
// wp-config.php
define('WP_AUTO_UPDATE_CORE', 'minor'); // or true for major releases as wellwp core check-update
wp plugin list --update=available
wp plugin auto-updates enable --all
wp theme auto-updates enable --allThen run the dedicated WordPress scanner, which adds a plugin brute-force pass to the passive fingerprinting, and work through its findings from critical downwards.
Where this fits
WordPress detected is check 10 of 10 that the website vulnerability scanner runs under wordpress plugins, themes and core, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits WordPress core version identified (info), where the exact WordPress core version could be read from the page or from readme.html. An attacker who has that does not need this, so it is the better use of the same hour.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: WordPress detected (info severity)
Scanner check id: wordpress-detectedThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
