They can't be doing this. What if just opening the link does a destructive action, like unsubscribing or posting a comment on your website?
If what you said makes sense to you, ask yourself how google can crawl any URL at all, considering communicating anything to any server could trigger a destructive action.
The google-bots wouldn't affect it since they don't run javascript
I.e.: http://searchengineland.com/tested-googlebot-crawls-javascri...
Then whoever created the link that does that is doing web wrong and needs to stop.
GET is, by definition, a safe method. (See RFC 7231, Sec. 4.2.1; RFC 2616, Sec. 9.1.1.) Doing destructive actions via a safe method is plain wrong.
There are links that do that and if google were to follow every linkt people would notice very fast.
(Or they get fed up and patch the problem without understanding it, by using robots.txt to block all crawlers from their site.)
That's true, but the relevant feature here is safety, not idempotence. (Though a safe method is also idempotent, not all idempotent methods are safe.)
No, of the "base" HTTP/1.1 methods, all safe methods (GET, HEAD, OPTIONS, TRACE) and some unsafe methods (PUT and DELETE) are idempotent.
POST is neither safe nor idempotent (and safety is the key feature here, rather than idempotence.)
GET, HEAD, and POST are cacheable methods, which you may be confusing with idempotent methods. These are very different categories, however.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.