To block a bot by user agent, add a RewriteCond rule to your site's .htaccess file that matches the User-Agent header and returns a 403. Open File Manager in cPanel, navigate to your site's root, edit .htaccess, and add the rule near the top of the file, before any existing rewrite rules for WordPress or your app.
The rule
This blocks a single bot by exact name:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "SemrushBot" [NC]
RewriteRule .* - [F,L]
The [NC] flag makes the match case-insensitive. [F,L] returns a 403 Forbidden and stops processing further rules for that request. If your file already has a RewriteEngine On line, don't repeat it, add the RewriteCond/RewriteRule pair.
Blocking several bots at once
Chain conditions with [OR] so any match triggers the block. The last condition in the group has no [OR]:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "SemrushBot" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "AhrefsBot" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "MJ12bot" [NC]
RewriteRule .* - [F,L]
This is the right approach for known, named crawlers: SEO tools, aggressive scrapers, and outdated bots that ignore robots.txt. It's a blunt instrument though: user agent strings are just text the client sends, and nothing stops a bot from lying about who it is. Anything genuinely malicious (credential stuffing, content scraping at scale, layer 7 floods) will usually rotate or spoof its user agent to get around exactly this kind of rule.
Blocking empty or generic user agents
A lot of low-effort bots send no user agent at all, or a generic one like python-requests or curl. You can catch these the same way:
RewriteCond %{HTTP_USER_AGENT} "^$" [OR]
RewriteCond %{HTTP_USER_AGENT} "^python-requests" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "^curl" [NC]
RewriteRule .* - [F,L]
Be careful here if you run any of your own cron jobs, uptime monitors, or webhooks that hit your own domain using curl or a script, since this will block those too. Test the change against your own tooling before leaving it in place.
Verifying the block works
From a terminal, send a request with the blocked user agent and confirm you get a 403:
curl -A "SemrushBot" -I https://yourdomain.com/
If you get a 200 instead of a 403, check that the rule sits above any WordPress rewrite block in .htaccess (WordPress's own rules can sometimes intercept the request first if your rule is placed after the # BEGIN WordPress marker) and that RewriteEngine On only appears once in the file.
When user agent blocking isn't enough
If you're dealing with a high volume of requests from a bot that ignores or spoofs its user agent, blocking by string match won't hold up. At that point you're better off blocking by IP or IP range, which you can do from Security → IP Blocker in cPanel, or opening a ticket to discuss further options on your account. Persistent, high-volume scraping or anything that looks like a denial-of-service pattern is worth a support ticket via the portal rather than relying on .htaccess rules alone.
When to contact support
If you've added a rule and traffic isn't dropping, if you're not sure whether a rewrite rule is conflicting with an app's existing .htaccess block, or if you suspect the traffic is actually malicious rather than just an aggressive SEO crawler, open a ticket from Support in the portal and a support agent can help investigate.