Control automated visitors without disrupting search engines, monitoring tools, or the connected services your WordPress website needs.
Bots are programs that visit websites automatically. Search engines and monitoring services can be helpful. Other bots scrape content, submit spam, guess passwords, or scan WordPress for vulnerable software.
Attackers can call themselves Googlebot, Bingbot, or anything else. BitFire checks network evidence whenever it is available.
A user-agent identifies the software making a request, but it does not prove who operates that software.
GooglebotEasy for anyone to copy
Cannot be impersonated
Use evidence before allowing
When reliable information is available, BitFire compares the bot's claim with network details that an attacker can not impersonate.
Checks whether an address belongs to the domain claimed by a known crawler.
Compares published IP ranges, network ownership, and routing information.
Uses known addresses and observed bot behavior to provide additional context.
Allowed bots are checked by BitFire's WAF and RASP protections. Allowing a bot bypasses bot restrictions; it does not turn off the rest of BitFire.
Most bots should remain Restricted. Use Allow only when a trusted service needs interactive access, and Block for clear abuse.
View-only access to ordinary public content.
Can usually:For services that must submit data or call a WordPress API.
Use only when:Prevents access to pages protected by BitFire.
Common reasons:BitFire learns approved query parameters, API requests, and AJAX actions normally used by your website visitors.
Visit public pages and use the website as a normal administrator or customer would.
Test forms, search, checkout, membership, login, and connected services.
Allow scheduled jobs and external integrations to complete their normal work.
Investigate a request before creating an exception. Learning does not make every request safe.
Open Bot Control from the BitFire dashboard, then use categories, search, filters, and sorting to narrow the list.
These bots attempted an API, AJAX action, or another interactive endpoint. Review this category if a connected service stops working.
These bots attempted logins, searched for sensitive files, accessed PHP directly, or enumerated WordPress information.
The bot resembles a normal service in BitFire and Slothstorm data. This provides context—not proof of identity.
Most bots appear here. If they cause no problem, leave them Restricted and take no further action.
Search is exact rather than approximate. Use google instead of a long description, or search the main product or company name.
BitFire searches the selected category first. If it finds nothing there, it expands the search to all categories. This is why results can differ depending on the category currently displayed.
Select a bot's row to review its recent activity, requests, network origin, and available reputation information.
The bot name alone is not enough to make a safe decision. Its request history and network details provide the most useful context.
Select an IP address to see available DNS names, related addresses, approximate network location, request categories, and access controls.
Limit a real bot to trusted IP addresses when other systems copy the same name.
Block an unrelated or malicious address without blocking the entire legitimate crawler.
Allow an address only after confirming its identity and expected purpose.
Open the requests associated with the user-agent and compare the requested page, method, and security result with the service's purpose. A monitor requesting the homepage may be normal. The same name requesting a password file is not.
A web search can provide background, but it cannot prove the request is genuine.
Deleting is not the same as blocking. If the bot returns, BitFire may list it again.
A bot-related block commonly uses a code beginning with 2400. Match the request to the affected service before changing access.
Note the WordPress feature or service, approximate time, request ID, and block code.
Open Needs review, sort by recent activity, and search the service or product name.
Check that the request time, URL, IP details, and action match the service's purpose.
Allow only the matching bot or trusted IP addresses, then test the service again.
Review its next requests to confirm the connection works and remains expected.
Select the checkbox beside each bot, review every selected name, then choose Allow, Restrict, or Block. Use bulk Allow cautiously. Approving one verified service at a time is safer than approving a whole category.
Attackers often borrow trusted names such as Google, Bing, or Facebook to make malicious traffic look harmless.
Review IP, DNS, location, and network ownership.
Does the request match what the claimed service normally does?
Block the spoofed address without blocking the genuine crawler.
Keep it Restricted or lock it to verified addresses.
Do not Allow a bot merely to stop repeated alerts. If the activity is unfamiliar and your website works normally, Restricted is the safer choice.
Several WordPress bot-blocking plugins can create conflicting rules, duplicate challenges, and confusing logs.
Keep bot access levels and WordPress-specific exceptions in one understandable place.
Your provider can still help with denial-of-service attacks and traffic before it reaches WordPress.
Start with the narrowest change and return a bot to Restricted whenever you are unsure.
2400.Use a shorter term, clear filter chips, try another category, and search for part of the company or product name.
Allow bypasses bot restrictions, not WAF or RASP. Open the blocked request to identify which protection stopped it. Review that specific request or contact support rather than disabling the firewall.
Do not Allow it based on the name. Review IP and DNS details; an unrelated system may be impersonating the real crawler.
Return it to Restricted and test the website. Restricted is the safest recovery setting when you are uncertain.
Bot Control does not require daily administration. Review it after important website changes and as part of routine periodic maintenance.
If no, leave it Restricted.
If no, keep it Restricted or Block it if abusive.
Review its requests before allowing.
Prefer trusted IP addresses when possible.
Leave it Restricted and contact support.
Send the request ID, block code, website address, and service name. Our team can help you decide whether the request should be allowed.