Skip to content
  • Quick Ref
  • Contact
  • About
wpcanyon.com

wpcanyon.com

Tag: Bots

Serve static 410 for bots hitting wp‑login & xmlrpc

Posted on August 19, 2025 By Admin No Comments on Serve static 410 for bots hitting wp‑login & xmlrpc

Serve static 410 for bots hitting wp-login & xmlrpc

If your WordPress site is frequently targeted by bots attempting to access wp-login.php and xmlrpc.php, it can lead to increased server load and security risks. A quick and effective way to mitigate this is by serving a static HTTP 410 Gone response to these requests. This tells bots that these endpoints are permanently gone, discouraging repeated access attempts.

Quick Fix

  1. Identify your web server type (Apache, Nginx, LiteSpeed, etc.).
  2. Add the appropriate configuration snippet to serve a 410 response for wp-login.php and xmlrpc.php.
  3. Reload or restart your web server to apply changes.
  4. Test by accessing these URLs and confirm you receive a 410 Gone status.

Why this happens

WordPress sites commonly expose wp-login.php and xmlrpc.php files, which are often targeted by bots for brute-force attacks or exploiting XML-RPC vulnerabilities. While legitimate users need wp-login.php to log in, many sites use alternative login methods or restrict access via plugins or IP whitelisting. Similarly, xmlrpc.php is rarely needed and often disabled to prevent abuse.

Serving a 410 Gone status explicitly informs bots that these endpoints are no longer available, reducing unnecessary server load and improving security posture.

Requirements

  • Access to your web server configuration files or control panel (e.g., Apache .htaccess, Nginx config, LiteSpeed config).
  • Basic knowledge of editing server config files or ability to upload files via FTP/SFTP.
  • Ability to reload or restart your web server after changes.
  • Optional: Backup your configuration files before editing.

Step-by-step

1. Determine your web server

Check your hosting environment or server info to confirm if you use Apache, Nginx, LiteSpeed, or another server.

2. Add configuration to serve 410 for wp-login.php and xmlrpc.php

Apache (.htaccess)

# Serve 410 Gone for wp-login.php and xmlrpc.php
<FilesMatch "^(wp-login.php|xmlrpc.php)$">
  Require all denied
  Redirect gone /
</FilesMatch>

Alternative Apache method:

# Return 410 Gone for wp-login.php and xmlrpc.php
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/(wp-login.php|xmlrpc.php)$ [NC]
RewriteRule ^ - [G,L]

Nginx

# Return 410 Gone for wp-login.php and xmlrpc.php
location ~* ^/(wp-login.php|xmlrpc.php)$ {
    return 410;
}

LiteSpeed

LiteSpeed supports Apache-style .htaccess rules, so use the Apache snippets above.

3. Save and apply changes

After adding the code:

  • For Apache or LiteSpeed, save the .htaccess file in your WordPress root directory.
  • For Nginx, add the snippet to your server block configuration file (e.g., /etc/nginx/sites-available/your-site.conf).
  • Reload or restart your web server:
# Apache
sudo systemctl reload apache2

# Nginx
sudo systemctl reload nginx

# LiteSpeed (depends on setup, often via control panel)

4. Test the response

Use curl or a browser to verify the 410 response:

curl -I https://yourdomain.com/wp-login.php
HTTP/1.1 410 Gone

curl -I https://yourdomain.com/xmlrpc.php
HTTP/1.1 410 Gone

If you see 410 Gone, the configuration works correctly.

Common pitfalls

  • Incorrect file placement: Apache .htaccess must be in the WordPress root directory.
  • Conflicting rules: Other rewrite rules or security plugins may override or conflict with these directives.
  • Server caching: Some hosts use aggressive caching; clear caches after changes.
  • Access needed: If you still need legitimate access to wp-login.php (e.g., for admins), consider restricting by IP instead of serving 410.
  • Control panel overrides: Some managed hosts restrict direct config edits; check with your provider.

Works on

Web Server Supported Notes
Apache Yes Use .htaccess or main config files
Nginx Yes Requires editing server block config
LiteSpeed Yes Supports Apache-style .htaccess rules
cPanel Yes Access .htaccess via File Manager or FTP
Plesk Yes Supports Apache and Nginx config editing

FAQ

1. Will serving 410 break my login or XML-RPC functionality?

Yes, if you or your users rely on wp-login.php or xmlrpc.php, serving 410 will block access. Use this only if you have alternative login methods or have disabled XML-RPC.

2. Can I serve 403 Forbidden instead of 410 Gone?

Yes, 403 is common for blocking access, but 410 explicitly signals the resource is permanently gone, which…

Speed & Security

Block bad bots with .htaccess (copy/paste rules)

Posted on August 19, 2025 By Admin No Comments on Block bad bots with .htaccess (copy/paste rules)

Block Bad Bots with .htaccess (Copy/Paste Rules)

If your WordPress site is suffering from unwanted traffic caused by bad bots—scraping content, spamming forms, or consuming server resources—you can block them efficiently using .htaccess rules. This tutorial provides quick, copy-paste-ready .htaccess snippets to block common bad bots and protect your site.

Quick Fix: Block Bad Bots in .htaccess

  1. Access your WordPress site’s root directory via FTP or hosting file manager.
  2. Open or create the .htaccess file in the root folder.
  3. Copy and paste the provided bad bot blocking rules into the .htaccess file.
  4. Save the file and test your site to ensure it works correctly.

Why This Happens

Bad bots are automated scripts that crawl websites for malicious purposes such as scraping content, spamming, brute forcing login pages, or overloading servers. Unlike good bots (like Googlebot), bad bots ignore robots.txt rules and can cause:

  • High server load and slow site performance
  • Security vulnerabilities through brute force or injection attacks
  • Content theft and SEO penalties

Blocking these bots at the server level using .htaccess is an effective way to reduce unwanted traffic before it reaches WordPress.

Requirements

  • Apache web server with mod_rewrite enabled
  • Access to your site’s root .htaccess file
  • Basic knowledge of FTP or hosting file manager
  • Backup of your current .htaccess file before editing

Step-by-step: Block Bad Bots with .htaccess

  1. Backup your current .htaccess file. Always keep a copy before making changes.
  2. Access your site’s root directory. Use FTP or your hosting control panel’s file manager.
  3. Open the .htaccess file. If it doesn’t exist, create a new plain text file named .htaccess.
  4. Paste the following code at the top of the file, before WordPress rules:
# BEGIN Block Bad Bots
<IfModule mod_rewrite.c>
RewriteEngine On

# Block bad bots by User-Agent
RewriteCond %{HTTP_USER_AGENT} ^.*(AhrefsBot|SemrushBot|MJ12bot|BLEXBot|DotBot|Screaming Frog|YandexBot|Exabot|Ezooms|Sogou).* [NC]
RewriteRule .* - [F,L]

# Block bad bots by Referer (optional)
# RewriteCond %{HTTP_REFERER} ^.*(spamdomain1.com|spamdomain2.net).* [NC]
# RewriteRule .* - [F,L]

</IfModule>
# END Block Bad Bots
  1. Save the file. Upload it back if using FTP.
  2. Test your site. Visit your site to ensure it loads correctly.
  3. Verify blocking. Use online tools or curl commands to simulate bad bot User-Agents and confirm they receive a 403 Forbidden response.

Common Pitfalls

  • Placing rules after WordPress block: Always add bad bot rules before the WordPress section in .htaccess to ensure they take effect.
  • Typos in User-Agent names: User-Agent strings are case-insensitive but must be spelled correctly to match.
  • Blocking legitimate bots: Avoid blocking well-known good bots like Googlebot or Bingbot to prevent SEO issues.
  • Server without mod_rewrite: These rules require Apache’s mod_rewrite module; they won’t work on Nginx or if mod_rewrite is disabled.
  • Overblocking: Be cautious with broad patterns to avoid blocking real users or services.

Works on

Server Compatibility
Apache Fully compatible with mod_rewrite enabled
Nginx Not compatible (requires different config)
LiteSpeed Compatible (supports Apache .htaccess rules)
cPanel / Plesk Compatible (access .htaccess via file manager or FTP)

FAQ

Q1: How do I find out which bots are bad?
A: You can check your server logs or use analytics tools to identify suspicious User-Agent strings. Common bad bots include AhrefsBot, SemrushBot, MJ12bot, and others known for scraping or spamming.
Q2: Can I block bad bots using plugins instead of .htaccess?
A: Yes, there are WordPress plugins that block bad bots, but .htaccess blocking is faster and reduces server load by stopping requests early.
Q3: What if I accidentally block a good bot?
A: Remove or adjust the User-Agent pattern from the .htaccess file and test again. Always verify User-Agent strings before blocking.
Q4: Will blocking bad bots improve my SEO?
A: Indirectly yes. Blocking bad bots reduces server load and prevents content scraping, which can protect your SEO rankings.
Q5: Can I block bots by IP instead of User-Agent?
A: Yes, but IP addresses can change frequently. Blocking by User-Agent is more flexible for bad bots that identify themselves.
…
Speed & Security

Block bad bots in .htaccess (copy/paste)

Posted on August 19, 2025 By Admin No Comments on Block bad bots in .htaccess (copy/paste)

Block Bad Bots in .htaccess (Copy/Paste)

If your WordPress site is suffering from unwanted traffic caused by bad bots—such as scrapers, spammers, or malicious crawlers—you can block them efficiently using your .htaccess file. This quick fix not only denies access to known bad bots but also rate limits requests to reduce server load and improve site security.

Quick Fix: Deny Bad Bots & Rate Limit in .htaccess

  1. Open your WordPress root directory and locate the .htaccess file.
  2. Backup the .htaccess file before making changes.
  3. Copy and paste the following code at the top of your .htaccess file:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500

  1. Save the file and upload it back to your server if editing locally.
  2. Test your site to ensure it loads correctly and bad bots are blocked.

Why This Happens

Bad bots can cause multiple issues for WordPress sites:

  • Server overload: Excessive requests from bots can consume bandwidth and CPU, slowing down your site.
  • Security risks: Some bots scan for vulnerabilities or attempt brute force attacks.
  • SEO damage: Scrapers can steal your content, harming your search engine rankings.

Blocking bad bots at the .htaccess level prevents them from reaching your WordPress application, reducing resource usage and improving overall site performance and security.

Step-by-Step: How to Block Bad Bots in .htaccess

  1. Access your WordPress root directory: Use FTP, SFTP, or your hosting control panel’s file manager to navigate to the folder where WordPress is installed. This folder contains the wp-config.php and .htaccess files.
  2. Backup your current .htaccess file: Before making any changes, download a copy of your existing .htaccess file to your local machine. This ensures you can restore it if something goes wrong.
  3. Edit the .htaccess file: Open the .htaccess file in a plain text editor.
  4. Add bad bot blocking rules: Insert the following code at the very top of the file, before any WordPress rules:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

This code uses SetEnvIfNoCase to detect bad bots by their user-agent strings and denies them access.

  1. Add rate limiting rules: To prevent excessive requests from any IP address, add the following code below the bot blocking rules:
# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500

This limits the bandwidth and request rate to protect your server from overload.

  1. Save and upload the file: If editing locally, upload the modified .htaccess file back to your server, overwriting the existing one.
  2. Test your website: Visit your site in a browser to ensure it loads normally. Use online tools or command line to simulate bad bot user-agents and confirm they are blocked.

Testing Your Bad Bot Blocking

  • Browser test: Your site should load normally for regular browsers.
  • Command line test: Use curl to simulate a bad bot user-agent:
curl -A "AhrefsBot" -I https://yourdomain.com/

The response should be 403 Forbidden or similar, indicating the bot is blocked.

  • Check server logs: Review your Apache error or access logs to verify that requests from bad bots are denied.

Works On

Server Software Notes
Apache Fully supported; requires mod_setenvif, mod_authz_host, and optionally mod_ratelimit or mod_reqtimeout
Nginx Does not use .htaccess; configure in server block instead
LiteSpeed Supports .htaccess rules similar to Apache
cPanel / Ples
…
Speed & Security

Recent Posts

  • Top WordPress Themes for Blogs in 2025
  • WordPress Admin Panel Trick: Adding ID Field to the Posts Listing
  • Solution previous_posts_link and next_posts_link Not Working
  • Show Top Commentators in WordPress Without a Plugin
  • How to Style Admin Comments in WordPress

Recent Comments

    Archives

    • August 2025

    Categories

    • Admin & Blocks
    • Admin & UI
    • Automation
    • Automation & Plugins
    • Comments
    • Comparisons
    • Database & Revisions
    • Developer Snippets
    • Fixes & Errors
    • Media & Thumbnails
    • Queries & Pagination
    • Security
    • Speed & Security
    • Tips & Tricks
    • WooCommerce How‑tos
    • WordPress Snippets
    • WordPress Themes
    • Terms & Conditions
    • Affiliate Disclosure

    Copyright © 2025 wpcanyon.com.

    Powered by PressBook WordPress theme

    Also by the maker of MySurveyReviews.com