Confusion has propagated about the .well-known location. The historic RFCs used "host" and "site" which, when "site" is understood in the W3C sense, are contradictory. Current RFC is explicit that the origin [RFC6454] defines the scope of the .well-known file.
Background
Definition of .well-known
https://datatracker.ietf.org/doc/rfc8615/
Some applications on the Web require the discovery of information about an origin [RFC6454] (sometimes called "site-wide metadata") before making a request. ... While there are several ways to access per-resource metadata ..., the perceived overhead ... associated with them often precludes their use in these scenarios. At the same time, it has become more popular to use HTTP as a substrate for non-Web protocols. Sometimes, such protocols need a way to locate one or more resources on a given host. When this happens, one solution is to designate a "well-known location" for data or services related to the origin overall, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with resources that the origin has created (or wishes to create). Furthermore, defining well-known locations usurps the origin's control over its own URI space [RFC7320].
To address these uses, this memo reserves a path prefix in ... URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such metadata can register their use to avoid collisions and minimise impingement upon origins' URI space.
See the registry of /.well-known/ files.
The spec is explicit about the definition of origin by referencing RFC6454:
..., user agents group URIs together into protection domains called "origins". Roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.)