How to stop BOT searches

How to Stop Bot Searches in WordPress and Clean Search Analytics

by

A WordPress administrator recently noticed an unusual pattern in the website’s internal search analytics:

  • 24 searches for “captcha”
  • Two searches for “index/index”
  • None of the searches were performed by the administrator

At first glance, searches like these can look suspicious. They are often generated by automated bots probing WordPress websites for search forms, vulnerable URLs, indexed files, login pages, or CAPTCHA-related endpoints.

However, strange search terms do not automatically mean that the website has been hacked.

In most cases, bots are simply submitting values to the standard WordPress search parameter:

https://example.com/?s=captcha

This guide explains how to investigate the requests, exclude them from your search reports, block repeated abuse, and prevent bots from placing unnecessary load on your WordPress website.

Why Do Bots Search for “captcha” or “index/index”?

WordPress normally accepts a search term through the s query parameter. For example:

https://example.com/?s=index/index

When a bot visits this URL, WordPress processes it like a legitimate site search. A search analytics plugin may then record the request.

Bots may generate these searches for several reasons:

  • Looking for exposed files or directories
  • Testing how the website handles unusual URL values
  • Searching for login, CAPTCHA, or form-related pages
  • Attempting to identify plugins or website technologies
  • Crawling automatically generated URL combinations
  • Creating spam entries in analytics reports
  • Testing whether the search endpoint can be abused

A few isolated searches are usually not an emergency. The issue becomes more important when hundreds or thousands of requests are generated repeatedly, because they can pollute reports, increase database activity, and consume server resources.

Why Excluding the Administrator Does Not Exclude Bots

Many WordPress search analytics plugins include an option to exclude searches performed by administrators.

That setting only prevents searches from being recorded when the visitor is logged in with the Administrator role.

Most bots are anonymous visitors. They are not logged in, so the administrator exclusion rule does not apply to them.

You therefore need separate filtering or blocking rules for suspicious search terms, IP addresses, duplicate searches, or excessive request frequency.

Step 1: Confirm That the Searches Are Automated

Before blocking anything, inspect the requests and verify whether they are coming from bots.

Check the following information:

  • Search date and time
  • Visitor IP address
  • User agent
  • Number of repeated searches
  • Search URL
  • Country, when available
  • HTTP response status
  • Frequency of requests
  • Other URLs requested by the same IP address

You may find this information in:

  • Your search analytics plugin
  • Your hosting access logs
  • Cloudflare Security Events
  • A security plugin’s activity log
  • Your hosting control panel
  • Raw Apache or Nginx logs

Look for patterns such as:

/?s=captcha
/?s=index/index
/?s=wp-login
/?s=xmlrpc.php
/?s=https://spam-domain.example

A visitor performing the same unusual search many times within seconds or minutes is likely automated.

However, 24 searches by themselves are relatively small. It is still worth filtering them, but they do not necessarily indicate a serious attack.

Step 2: Configure Your Search Analytics Plugin

The report described above appears consistent with the type of data recorded by the Search Analytics for WP plugin.

Search Analytics for WP supports exclusions based on user roles and IP addresses, duplicate-search filtering, minimum search-term lengths, and additional filters for controlling which terms are recorded.

Open the plugin’s settings page and review the following options.

Exclude Administrator Searches

Keep the Administrator role excluded so that your own testing does not pollute the report.

Exclude Duplicate Searches

Enable duplicate-search filtering and choose a reasonable time window.

For example, you might prevent the same IP address and search term from being recorded repeatedly within 10 or 30 minutes.

This will not block the bot, but it can prevent one automated visitor from filling your report with hundreds of identical entries.

Exclude Known IP Addresses

You may exclude an IP address when:

  • The address repeatedly generates spam
  • It belongs to a monitoring service
  • It belongs to your office or development environment
  • It is a fixed address you recognize

IP exclusions are less effective against larger bot networks because bots frequently rotate IP addresses.

Exclude Suspicious Search Strings

Recent versions of the plugin include options for excluding searches that contain specified substrings. The plugin’s support guidance also recommends using term-exclusion filters when unwanted searches follow a recognizable pattern.

You could initially exclude:

captcha
index/index

Only exclude “captcha” when it is not a legitimate search term for your website. A cybersecurity, WordPress, or technical support website may have real visitors searching for CAPTCHA solutions.

Filtering a term removes it from analytics. It does not necessarily stop WordPress from processing the search request.

Step 3: Exclude Search Spam With a PHP Filter

Search Analytics for WP provides the following filter:

mwtsa_exclude_term

This filter lets you decide programmatically whether a search term should be recorded. The plugin author has specifically recommended this filter for spam-search exclusions.

Add the following code using a code snippets plugin or your child theme’s functions.php file:

/**
 * Exclude suspicious terms from Search Analytics for WP.
 *
 * This prevents matching searches from being recorded by the plugin.
 * It does not block the actual request.
 */
add_filter(
    'mwtsa_exclude_term',
    function ( $excluded, $search_term ) {
        if ( $excluded ) {
            return true;
        }

        $term = strtolower(
            trim(
                sanitize_text_field( (string) $search_term )
            )
        );

        /*
         * Add only terms that should never be legitimate searches
         * on your website.
         */
        $blocked_exact_terms = array(
            'captcha',
            'index/index',
        );

        if ( in_array( $term, $blocked_exact_terms, true ) ) {
            return true;
        }

        /*
         * Exclude extremely long searches commonly generated
         * by automated scanners or malformed requests.
         */
        $term_length = function_exists( 'mb_strlen' )
            ? mb_strlen( $term )
            : strlen( $term );

        if ( $term_length > 80 ) {
            return true;
        }

        /*
         * Exclude a limited set of suspicious patterns.
         * Keep this list conservative to avoid blocking real searches.
         */
        $suspicious_patterns = array(
            '#https?://#i',
            '#(?:wp-admin|wp-login|xmlrpc\.php)#i',
            '#(?:<|>|%3c|%3e)#i',
            '#(?:/index/){2,}#i',
        );

        foreach ( $suspicious_patterns as $pattern ) {
            if ( preg_match( $pattern, $term ) ) {
                return true;
            }
        }

        return false;
    },
    10,
    2
);

What This Code Does

The snippet prevents the analytics plugin from recording:

  • Exact searches for “captcha”
  • Exact searches for “index/index”
  • Search terms longer than 80 characters
  • Searches containing external URLs
  • Searches containing common WordPress attack targets
  • Searches containing encoded HTML characters
  • Repeated /index/ patterns

Modify the list based on what is normal for your website.

Do not add broad terms such as “login,” “admin,” “payment,” or “error” unless you are certain that legitimate visitors will never search for them.

Step 4: Block Specific Searches at the WordPress Level

The previous solution cleans your analytics, but WordPress may still process the search request.

To return a 403 Forbidden response for specific search terms, add this separate snippet:

/**
 * Block exact abusive WordPress search terms.
 */
add_action(
    'template_redirect',
    function () {
        if ( is_admin() || ! is_search() ) {
            return;
        }

        $search_term = strtolower(
            trim(
                get_search_query( false )
            )
        );

        $blocked_terms = array(
            'captcha',
            'index/index',
        );

        if ( ! in_array( $search_term, $blocked_terms, true ) ) {
            return;
        }

        nocache_headers();

        wp_die(
            esc_html__( 'This search request was blocked.', 'debugnexus' ),
            esc_html__( 'Forbidden', 'debugnexus' ),
            array(
                'response' => 403,
            )
        );
    },
    1
);

WordPress provides is_search() for identifying search requests, get_search_query() for retrieving the submitted search term, template_redirect for acting after WordPress recognizes the requested page, and wp_die() for stopping the response with a selected HTTP status.

Important Limitation

This snippet executes inside WordPress. The request has already reached your hosting server.

It is suitable for stopping specific unwanted searches, but Cloudflare or another web application firewall is more effective during a large bot attack because it can challenge or block requests before they reach WordPress.

Step 5: Rate-Limit WordPress Search Requests With Cloudflare

Blocking individual terms works only when the bots keep using the same terms.

A better long-term strategy is to rate-limit the search endpoint.

Cloudflare rate-limiting rules can match requests based on the URL path, query string, IP address, and other request properties. You can then apply a Managed Challenge or blocking action when an IP exceeds your selected threshold.

For the standard WordPress search URL, a starting expression could be:

http.request.uri.query contains "s="

For websites using pretty search URLs, you may also need:

http.request.uri.path contains "/search/"

A combined expression could be:

(http.request.uri.query contains "s=")
or
(http.request.uri.path contains "/search/")

Configure a conservative starting threshold such as:

20 search requests per minute from one IP address

Use Managed Challenge as the first action rather than permanently blocking every matching visitor.

The exact threshold should depend on your website. A documentation website, product catalog, or large directory may receive more legitimate searches than a small business website.

Test Before Blocking

When possible:

  1. Start with a logging or challenge action.
  2. Perform several legitimate searches yourself.
  3. Confirm that normal searches still work.
  4. Review Cloudflare Security Events.
  5. Lower or increase the threshold based on real traffic.
  6. Switch to blocking only when clearly abusive behavior is confirmed.

Make sure the rule matches the actual search endpoint. Some themes and plugins use AJAX requests instead of the standard ?s= WordPress parameter.

Step 6: Block Known Terms With a Cloudflare Custom Rule

You can also create a custom firewall rule for exact unwanted query strings.

For example:

(http.request.uri.query contains "s=captcha")
or
(http.request.uri.query contains "s=index%2Findex")
or
(http.request.uri.query contains "s=index/index")

Use a Managed Challenge first.

URL values may be encoded differently, which is why the example checks both:

index/index

and:

index%2Findex

Be careful when using contains. The rule can match a longer query string that includes the same text.

Review Cloudflare events after activating the rule to ensure legitimate visitors are not being challenged.

Step 7: Remove Existing Spam Entries

Filtering prevents new records, but it does not automatically remove existing search entries.

Use the search analytics plugin’s reporting or history interface to delete unwanted records when that option is available.

Remove entries such as:

captcha
index/index

Avoid manually deleting database rows unless:

  • You have created a database backup
  • You know the plugin’s database table structure
  • The plugin cannot remove the records through its interface

Deleting the wrong database records can damage reports or plugin settings.

Step 8: Check for Additional Security Problems

Strange searches alone are not evidence of a compromised website.

However, investigate further when you also notice:

  • Unknown administrator accounts
  • Modified WordPress core files
  • Unexpected PHP files
  • Spam redirects
  • New scheduled tasks
  • Unknown plugins
  • Changes to .htaccess
  • High CPU usage
  • Thousands of search requests
  • Repeated attempts to access wp-login.php or xmlrpc.php
  • Outgoing spam email
  • Search results containing injected pharmaceutical or casino content

In that situation:

  1. Back up the website.
  2. Scan WordPress files for malware.
  3. Compare WordPress core files against clean copies.
  4. Review administrator accounts.
  5. Change WordPress, hosting, database, and SFTP passwords.
  6. Update WordPress core, plugins, and themes.
  7. Review server access logs.
  8. Enable a web application firewall.
  9. Remove abandoned plugins and themes.

Should You Add CAPTCHA to the Search Form?

Adding CAPTCHA to every search form can stop some automation, but it can also create a poor experience for real visitors.

For most websites, use this order:

  1. Exclude duplicates from analytics.
  2. Exclude clearly invalid search terms.
  3. Rate-limit excessive searches.
  4. Apply a firewall challenge to suspicious traffic.
  5. Add CAPTCHA only when the abuse continues.

A CAPTCHA is more appropriate when the search endpoint is under sustained attack and other controls are not enough.

Can You Exclude Bots by User Agent?

You can exclude user agents containing values such as:

bot
crawler
spider
scanner

However, user-agent filtering should not be your only protection. Request headers can be changed, and malicious bots may identify themselves as ordinary browsers.

Behavior-based controls are more dependable:

  • Too many searches in a short period
  • Repeated identical terms
  • Extremely long search strings
  • URLs submitted as search terms
  • Attempts to search for WordPress system files
  • Requests from IP addresses already generating other malicious traffic

Recommended Final Configuration

For most WordPress websites, use the following combination:

Inside the Analytics Plugin

  • Exclude Administrator searches
  • Enable duplicate-search filtering
  • Set a sensible minimum search length
  • Exclude specific spam substrings
  • Exclude known internal IP addresses
  • Delete existing spam entries

Inside WordPress

  • Add the mwtsa_exclude_term filter
  • Block only exact terms that cannot be legitimate
  • Avoid broad keyword blocking
  • Keep the code in a child theme or snippets plugin

At the Firewall Level

  • Rate-limit the WordPress search endpoint
  • Use Managed Challenge before Block
  • Review security events
  • Block repeat offenders
  • Adjust the limit based on normal website traffic

Frequently Asked Questions

Are strange WordPress searches proof that my website was hacked?

No. Automated bots routinely submit random values to public search forms. Investigate server logs and other security indicators before concluding that the website has been compromised.

Why does excluding administrators not remove bot searches?

The setting only excludes searches performed by logged-in administrators. Most bots visit the website anonymously.

Does filtering a search term block the bot?

Not necessarily. Analytics filtering only prevents the search from appearing in reports. Use WordPress-level blocking or a firewall rule to stop the request.

Should I block the word “captcha”?

Only when it is not a legitimate search term for your website. Technical support and security websites may have real visitors searching for CAPTCHA-related content.

Should I block every bot?

No. Search engines, monitoring services, accessibility tools, and other legitimate services may also use automated requests. Block abusive behavior rather than all automation.

Will robots.txt stop search spam?

Do not depend on robots.txt as a security measure. Firewall rules, rate limits, and application-level validation are more appropriate for controlling abusive requests.

Final Thoughts

A small number of unusual searches such as “captcha” or “index/index” is usually caused by automated scanning rather than a successful website compromise.

The most effective solution is layered:

  1. Confirm the requests through access logs.
  2. Filter invalid terms from analytics.
  3. Remove existing spam records.
  4. Block clearly abusive terms.
  5. Rate-limit repeated search requests.
  6. Monitor for additional security symptoms.

This keeps your analytics clean while avoiding overly aggressive rules that could block real visitors.

Leave a Comment