Why Change the WordPress Login URL? Setting Up WPS Hide Login

2026-02-15

A WordPress site can slow down even when few people are reading it. Before blaming a theme or a plugin, look at the access logs. Automated requests often cluster around /wp-login.php because scanners know where to find the default WordPress login.

Much of this traffic comes from broad scans. A bot may test many sites for WordPress and then submit credentials repeatedly wherever it finds a login form. A failed login can still cost the server work.

Why the login endpoint takes server resources

Public posts are often served from a page cache. A login submission needs to be handled by the application. Depending on the request and the site’s configuration, that can involve the following steps.

  • Running PHP
  • Loading WordPress core
  • Looking up the account
  • Querying the database
  • Checking a password
  • Setting authentication cookies after a successful sign-in

If bots submit many login attempts in a short period, PHP and database work can add up. On a small instance, CPU usage can rise and responses can slow. A gateway timeout is one possible symptom, although the logs are needed to establish its cause.

Traffic to the login endpoint can rise while the number of people reading the site stays flat.

How a new login address works

Changing the login URL moves the form away from the location that broad scans commonly probe. The new URL still needs the same authentication protections as before.

For example, WordPress uses this path by default.

/wp-login.php


A custom login path could look like this.

/my-login

A bot that keeps submitting credentials to /wp-login.php will then get the response configured for the old URL, commonly a 404. With WPS Hide Login, WordPress still starts up to handle the request, but the old path no longer invokes the usual login flow.

The practical aim is to keep routine scans away from the authentication form while leaving the form available to people who use it.

Where Cloudflare fits

At the edge, Cloudflare can challenge or block requests that match your firewall or rate-limiting rules before they reach the WordPress server. Other requests will still reach the origin.

If the old path is still the login endpoint, any submissions that get through can reach that endpoint. After the move, the same requests can still reach WordPress but will no longer submit credentials through the old form.

Each setting works at a different point.

  • Cloudflare can filter matching requests before they reach the origin.
  • The plugin changes where WordPress accepts requests for the login form.

You can use both. Check edge events and origin logs to see where the traffic is going and which requests are still reaching the server.

Set up WPS Hide Login

Editing WordPress core files makes the change hard to maintain across updates. WPS Hide Login gives you a way to change the URL from the dashboard.

The plugin intercepts requests and changes the address of the login form without editing WordPress core. Set a new path and test it before you close your existing administrator session.

In the WordPress dashboard, follow these steps.

  1. Sign in to the WordPress dashboard.
  2. Open Plugins → Add New Plugin.
  3. Search for WPS Hide Login, then install and activate it.
  4. Open Settings → General.
  5. Find Login URL near the bottom of the page. Enter a new path and save.

For illustration, the following is a placeholder path. Choose a less predictable one for your site.

login


With that placeholder, the full URL would look like this.

https://example.com/login

In a separate private browser window, confirm that the new URL opens the form and that the old /wp-login.php and logged-out /wp-admin paths behave as expected.

Keep a way back in

Save the new address somewhere you can retrieve it before signing out. If you lose access, the plugin’s documentation explains how to recover the path or disable the plugin using server access.

Common words such as admin, login or wordpress are easy to guess. A less predictable path avoids some routine scans, while your password and other authentication controls still protect the account.

What to look for in the logs

Requests to /wp-login.php can still appear in Cloudflare events and server logs. The change you are looking for is fewer submissions reaching the actual login form.

Watch the logs and performance metrics over comparable periods to see whether you get any of these results.

  • Fewer requests reaching the actual login form
  • Fewer database queries tied to authentication
  • Less variation in CPU usage
  • Fewer intermittent slowdowns

A small Lightsail instance may show the difference more clearly if repeated login attempts were using a meaningful share of its resources.

What the change buys you

Moving the login form can reduce unnecessary authentication work from bots that probe the default path. The old address may still receive requests, and other WordPress endpoints still need their usual safeguards.

Cloudflare can filter requests at the edge, while the plugin changes which path brings a request to the form. The access log will tell you whether the combination helped on your site.

Search stories