Common WordPress Security Advices That Are Actually Useless

The internet is full of WordPress security advice. Unfortunately, much of it is outdated, misunderstood, or simply ineffective.
Many popular “security tips” create a false sense of security while doing very little to protect your website.

In this article we will break down some of the most common WordPress security myths and explain why they don’t actually improve your site’s security — along with what you should do instead.

Myth #1: “Changing the WordPress Login URL Makes Your Site Secure”

Security plugins are helpful, but they operate after WordPress loads.
By that time, malicious requests have already reached your application.

Why It’s Useless

• Doesn’t stop server-level attacks
• Consumes resources (runs on every request)
• Too late in the execution lifecycle

Many plugins claim that changing /wp-login.php to something like /secret-login-123 dramatically improves security.
This is essentially security through obscurity.

Attackers do not rely on the default login URL. They typically scan your site and detect the login endpoint automatically.

Example Attack Pattern

GET /wp-login.php
GET /?author=1
POST /xmlrpc.php
POST /wp-json/jwt-auth/v1/token

Bots test multiple endpoints and do not rely on a fixed login URL.

What Actually Works

• Rate limiting login attempts
• Server-level blocking
• Fail2ban protection

Example NGINX Rate Limiting

limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
}

Myth #2: “Hide the WordPress Version and You Are Safe”

Another common recommendation is removing the WordPress version from HTML.

Typical Code

<?php
\remove_action( 'wp_head', 'wp_generator' );

This only removes the version number from the page source. Attackers can still determine your version through:

• JavaScript and CSS file versions
• REST API responses
• Plugin compatibility detection

Example Detection

/wp-includes/js/jquery/jquery.js?ver=6.4.3

This exposes the version anyway.

What Actually Works

Keep WordPress updated.

wp core update

Or keep WordPress updated automatically:

define('WP_AUTO_UPDATE_CORE', true);

Myth #3: “Security Plugins Alone Can Protect Your Site”

Security plugins help but they cannot protect your server from attacks that occur before WordPress even loads.

Most attacks target:

• HTTP requests
• Login endpoints
• Server vulnerabilities

Plugins operate inside PHP — meaning the request has already reached WordPress.

Better Approach

Use server-level protections.

Example: Blocking XML-RPC in NGINX

location = /xmlrpc.php {
    deny all;
}

Myth #4: “777 File Permissions Fix Problems Safely”

Some guides recommend setting permissions to 777 when plugins or uploads fail.
This is extremely dangerous.

Example of Dangerous Command

chmod -R 777 /var/www/html

This gives every user on the system full control over your files.

Correct Permissions

• Directories → 755
• Files → 644
• wp-config.php → 600

Proper Fix

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php

Myth #5: “Disabling the Admin Username Is Enough”

Removing the admin username helps slightly but does not stop attackers.
Bots usually enumerate users automatically.

Example User Enumeration

GET /?author=1

This request often redirects to the author’s username.

Better Solution

Disable user enumeration at the server level.

if ($request_uri ~* "author=\d") {
    return 403;
}

Myth #6: “Disabling XML-RPC with a Plugin Is Enough”

Many plugins claim to disable XML-RPC, but the request still reaches WordPress before being blocked.

Plugin Approach

<?php
\add_filter('xmlrpc_enabled', '__return_false');

Better approach: block it before PHP executes.

Server-Level Blocking

location = /xmlrpc.php {
    deny all;
}

What Actually Improves WordPress Security

• Server-level firewall rules
• Fail2ban brute-force protection
• Correct file permissions
• Regular updates
• Monitoring server logs

Example Fail2ban WordPress Filter

[Definition]
failregex = ^<HOST>.*"(POST /wp-login.php|POST /xmlrpc.php)

Myth #7: “Security Through Obscurity Works”

Changing paths, hiding files, or renaming directories doesn’t stop real attackers.

Why It’s Useless

• Automated scanners detect everything
• Doesn’t fix root vulnerabilities

What Works Instead

• Principle of least privilege
• Server-level filtering
• Proper authentication and rate limiting

Frequently Asked Questions

Final Thoughts

WordPress security is often misunderstood. Many popular tips provide little real protection.

True security comes from understanding how attacks work and protecting your server at the lowest level possible.

Focus on server hardening, log monitoring, and proper configuration instead of relying solely on plugins.