A Drupal site gets requests for WordPress login pages because automated scanners probe websites without knowing which content management system they use. The bots try common WordPress paths, such as `/wp-login.php` and `/wp-admin/`, hoping to find an exposed or poorly secured installation. These requests usually do not mean Drupal is misconfigured or that WordPress secretly runs on the server. They show that the site is reachable and included in broad, automated scanning.
Table of Contents
- What the requests actually mean
- Is this evidence of a compromise?
- What should the site owner check?
- Should the requests be blocked?
- When does scanning become an operational problem?
What the requests actually mean
Many bots work from lists of domain names or IP addresses. They send the same set of requests to every server, checking for popular software, known files, backup archives, configuration mistakes, and login screens. A typical scanner might request `/wp-login.php`, `/xmlrpc.php`, `/administrator/`, and other product-specific paths within seconds.
Most targets will not use those products. The scanner accepts those failures because checking another address costs very little. On a drupal-only site, the expected response is usually `404 Not Found`. A `403 Forbidden` response may also be appropriate if the web server or security layer blocks the request before Drupal handles it.
Is this evidence of a compromise?
A request alone is not evidence that an attacker entered the site. It records an attempt to locate something, much like someone testing whether a locked building has a particular door. The response and surrounding activity matter more.
Investigate further if logs show any of these warning signs: A `200` response does not always prove that the file exists. Custom error pages, redirects, and single-page application routing can return `200` for missing URLs. Request the path yourself and inspect its actual content before drawing a conclusion.
- A `200 OK` response for a WordPress path that should not exist
- Successful POST requests to unfamiliar PHP files
- New files or directories beginning with `wp-`
- Unexpected administrator accounts or configuration changes
- Outbound traffic, scheduled tasks, or processes with no known purpose
What should the site owner check?
First, confirm that the server behaves as expected. Review access logs for the requested path, HTTP method, response status, source address, user agent, and nearby requests from the same source.
Then check the application and hosting environment: Do not delete a file merely because its name resembles a WordPress file. Establish whether it belongs to a legitimate application, deployment artifact, or security tool before changing the server.
- Verify that WordPress is not installed in a subdirectory, abandoned staging site, or old virtual host
- Search the document root for unexpected `wp-login.php`, `wp-admin`, and `xmlrpc.php` files
- Confirm that missing PHP paths return `404` or `403`, not executable content
- Review recent file changes, deployment records, administrator accounts, and scheduled jobs
- Update supported Drupal core, modules, themes, PHP, the web server, and other exposed components
Should the requests be blocked?
Blocking can reduce log noise and server work, but it does not eliminate scanning. Bots change addresses frequently, and blocking each source IP can create a large, fragile rule set. A web application firewall, reverse proxy, or web-server rule can reject known irrelevant paths early. Rate limits may also help when one source sends many requests quickly.
Test every rule against legitimate routes, integrations, and administrative tools before deploying it. Avoid redirecting nonexistent WordPress paths to the homepage. That can conceal useful `404` signals, complicate monitoring, and make scanners believe the path returned real content. A clear `404` or deliberate `403` is easier to interpret.
When does scanning become an operational problem?
Occasional probes are normal background traffic. They become an operational concern when request volume consumes meaningful CPU, memory, bandwidth, logging capacity, or security-team time. Group alerts by behavior instead of generating an incident for every missing login page.
A stronger alert might combine high request volume, many probed paths, POST attempts, suspicious response codes, or follow-on requests to valid Drupal administration routes. Preserve enough logs to reconstruct an incident, but avoid collecting sensitive request data without a purpose. If a scan causes resource pressure, block it at the earliest practical layer—such as the content delivery network, firewall, or reverse proxy—before it reaches Drupal.
You Might Also Like
- What Is New With CMS Migration and Web Development in August 2026? Latest release notes and search documentation and Key Takeaways
- How to Verify CMS Migration and Web Development Claims in 2026: release notes and search documentation, Evidence, and Red Flags
- CMS Migration and Web Development FAQ for September 2026: Source-Checked Answers to Common Questions
