If you know that is happening with HTTP you can redirect those requests, based upon origin, to a honeypot of your choosing. It’s free traffic you didn’t have to work for to use as you wish without disruption to your business requirements. You can use that traffic to experiment with new features under experimental branding, AB testing, and more.
The malicious website can stop the Referer header from being sent by setting the Referrer-Policy header to "no-referrer". Also, redirects apparently wouldn't include a Referer header any way, according to kbolino's comment.
First of all you shouldn't rely on HTTP headers for traffic identification as that makes a bunch of assumptions. Secondly, look at the example 301 on MDN which contains no identifying information: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301
Redirected traffic is coming from one or more dedicated locations performing the redirection. The source of redirection is still identifiable by IP address. So, if you know the traffic is coming from the a given IP and is a 301 you have all you need. Even after that the identified traffic, if not bots, can then be further tracked via a variety of client-side things like cookies and localStorage.
I don't think that's correct. If server A redirects to server B, then server B does not obtain the IP address of server A, only the IP address of the client. Also, the client does not send a "301 request" to server B, it sends a normal GET request. The 301 code only applies to responses, not requests.
If you know that is happening with HTTP you can redirect those requests, based upon origin, to a honeypot of your choosing. It’s free traffic you didn’t have to work for to use as you wish without disruption to your business requirements. You can use that traffic to experiment with new features under experimental branding, AB testing, and more.