wpscanteam/wpscan · error · WPScan::Error::NotWordPress

The remote website is up, but does not seem to be running Wo

Error message

The remote website is up, but does not seem to be running WordPress.

What it means

Raised by Core#check_wordpress_state (app/controllers/core.rb:233) when the target responds normally but shows no WordPress fingerprints under the configured detection mode (passive = homepage markers; aggressive = additional requests). Core#before_scan rescues it once, injects anti-bot cookies via target.maybe_add_cookies and re-checks; it still re-raises if the site does not look like WordPress. --force bypasses the check entirely.

Source

Thrown at app/controllers/core.rb:233

      # @return [ Boolean ] Whether the DB update is currently in progress
      def updating_db?
        @updating_db
      end

      # Raises errors if the target is hosted on wordpress.com or is not running WordPress.
      # Also checks if the homepage_url is still the install URL.
      def check_wordpress_state
        raise Error::WordPressHosted if target.wordpress_hosted?

        if %r{/wp-admin/install.php$}i.match?(Addressable::URI.parse(target.homepage_url).path)

          output('not_fully_configured', url: target.homepage_url)

          exit(WPScan::ExitCode::VULNERABLE)
        end

        raise Error::NotWordPress unless target.wordpress?(ParsedCli.detection_mode) || ParsedCli.force
      end

      # Loads the related server module into the target and includes it on WpItem
      # (needed to check if directory listing is enabled etc.).
      #
      # @return [ Symbol ] The server module loaded
      def load_server_module
        server = target.server || :Apache # auto-detect

        case ParsedCli.server
        when :apache
          server = :Apache
        when :iis
          server = :IIS
        when :nginx
          server = :Nginx
        end

View on GitHub (pinned to 62c9cef471)

Solutions

1. Open the site in a browser and confirm it is WordPress; if the blog lives under a path such as /blog, point --url at that path
2. Re-run with --detection-mode aggressive so more fingerprints are checked
3. If you are certain it is WordPress and accept the risk, add --force
4. If wp-content was renamed, supply --wp-content-dir to help detection

Example fix

# before
wpscan --url http://example.com
# => The remote website is up, but does not seem to be running WordPress.

# after
wpscan --url http://example.com/blog --detection-mode aggressive
# or, when certain it is WP: wpscan --url http://example.com --force

# Quick WordPress fingerprint before committing to a scan
body = Typhoeus.get(url, followlocation: true).body
wp = body.match?(/wp-content|wp-includes|name="generator" content="WordPress/i)
puts 'not obviously WordPress — consider aggressive mode or --force' unless wp

begin
  scan.run
rescue WPScan::Error::NotWordPress
  retry with '--detection-mode aggressive' # decide on --force only after manual confirmation
end

When it happens

Trigger: `wpscan --url http://target` against a non-WordPress site (static site, other CMS), or a WordPress site whose markers are hidden — renamed wp-content, no generator meta, no wp-login references, WAF stripping fingerprints — with passive detection mode and no --force, so target.wordpress?(ParsedCli.detection_mode) is false both before and after the cookie retry.

Common situations: Wrong --url (marketing site in front of the WP install at /blog); obfuscation plugins (Hide My WP) removing markers; heavily customized themes with no default WP asset paths; targets genuinely not running WordPress.

AI-assisted analysis of wpscanteam/wpscan@62c9cef471 (2026-08-21). Data as JSON: /api/errors/448a7cba4a78d98c. Report an issue: GitHub.