There do not appear to be any Purpose: request headers set for no-state prefetch.

If a page is fetched via <link rel=prefetch>, a Purpose: prefetch header is added to the request. If prerender is enabled, and a page is fetched by <link rel=prerender>, there is no Purpose: header, but any javascript in the page has the page visibility API to determine where the page came from.

As far as I can tell, if no-state prefetch is enabled, and a page is fetched by <link rel=prerender>, there is no Purpose: header and neither is there any positive JS signal (since there is no JS at all).

Thus there is ambiguity from the perspective of this site about where the resource is coming from.

The context is from a client, where (according to a customer service rep):

> "search this site" on the results page is resulting a large spike 
> of traffic that their attribution model cannot distinguish from 
> regular SEM traffic which is causing them to drop their SEM bids.

Distinguishing no-state from prerender is possible although inconvenient, by looking for lack of JS execution. Presumably the same thing could be done in the future when there is no prerender at all, to distinguish no-state fetches from regular fetches. 

Although there might be a problem about distinguishing no-state fetches discovered during the preload scanning from regular page load preload scanning?

At any rate, I couldn't find anything in the spec about what headers are necessary to add for link rel:

https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element

But there seems to be some consensus that a header should be added, eg scroll to "As a server admin, can I distinguish prefetch requests from normal requests?" in the following:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ

or this ancient webkit bug which describes chrome's old X-Purpose header:

https://bugs.webkit.org/show_bug.cgi?id=46529

Note that chrome appears to now have just a Purpose header, I wasn't able to find the history of that change (there's no bug matching "x-purpose").