I can think of three causes, only one of which actually point to a real error as such:
Somebody is trying to exploit a security hole in asp.net (a patch here) where you can get one of the axd handlers to serve up any content on the web server if you can figure out the encryption key. It is unlikely, but its possible. In this case, you don't have to do anything, except make sure that you have that fix applied.
(This is something I have observed on a site that I just finished) The scenario is where an existing site has been replaced or where the web server has been changed from what it was previously. If you have a site that is public and on Google, say, people might often view 'cached' page if they're trying to get to old content or indeed if the current page is not what they expect (perhaps an error or indeed just different). The problem being that if the site uses webresource.axd, that page will have a reference to it. The browser opens the cached html and then makes the request. If the site has been changed or is a replacement then the old axd links might not be valid any more and will cause an error.
If this is an mvc site you might no longer be using resources rendered by the axds, in which case you could consider removing them from the site by editing the web config and adding 'remove' entries for them in the handlers section of system.webserver. Then the requests will yield a 404 and no longer will you get errors. Equally if the site does use axds legitimately, but you can't repro the errors yourself by browsing it, then you probably don't have anything to worry about.
the site runs in a web farm and each machine therefore needs to have the same machine key, this is the one actually needs attention if it is the case. I left it till last, tho, because looking at your other questions I'm assuming a web farm is not involved :)
I would have liked to format this answer better but I am on my phone, apologies!