• Resolved ms100

    (@ms100)


    Good afternoon,

    If possible I would like to ask some help blocking Headless visits by bots.

    Does anybody have any idea why Headless Chrome visits, sometimes still show up in my analytics tool, after adding to .htaccess:

    RewriteCond %{HTTP_USER_AGENT} Headless [NC]
    RewriteRule .* - [F]

    Or for example:

    RewriteCond %{HTTP_USER_AGENT} (HeadlessChrome) [NC]
    RewriteRule .* - [F]

    I thought maybe it had something to do with the agent name being:

    Headless Browser 114.0 (or other versions)

    I would like to block all versions of the Headless browsers visits.

    Thanks in advance.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Well, ideally you should really let CloudFlare manage this for you.

    But, you could try adding the wildcard to your expression:

    RewriteCond %{HTTP_USER_AGENT} ^.*Headless.*$ [NC]

    If you add the or, it may ignore the end? [OR]

    Thread Starter ms100

    (@ms100)

    Thanks for your reply @corrinarusso

    It motivated me to spend another day searching for an explanation.

    I think maybe the lines with and without the wildcard expression do work both. But the visitors are spoofing their user agent, so they are able to do whatever they like anyway. And then, when the analytics JavaScript is loaded, it sends the real user agent (Headless Chrome) to my analytics software. But they are not blocked. I think that is what is happening.

    Also, I had the impression, some visitors (accidentally) reveal their true user agent, when trying to GET (Download) an image from the /wp-content/uploads/ folder. It seems like the true user agent shows up in the raw access log, and then the visit does get blocked by the .htaccess rule, serving a 403 code.

    Maybe in the future I will try CloudFlare. For now I am happy to understand better what probably is going on. Thanks again 🙂

Viewing 2 replies - 1 through 2 (of 2 total)

The topic ‘Bock HeadlessChrome’ is closed to new replies.