In SharePoint, Globally Unique Identifiers (GUID) are anchored everywhere. Whether it's a site collection, a website, or a list item. The GUID is used everywhere.

Normally you can assume that this ID is unique. I like to use the localStorage or sessionStorage in my solutions with my npm package. To make sure that the cached data is only valid in one context, I use the web ID as the prefix for the cache key. This has always worked very well so far. And then one day I had the case with a customer that two modules, which should display different data, have displayed the same data. Always the data from the website that was visited first.

The first thing I thought was that something was wrong with my code. Then I investigated further and saw that the site ID of the two site collections was different (as expected) but the web ID was amazingly identical.

My research has shown that it probably has to do with the "Fast Site Creation" feature (known from MySites with SharePoint 2016 OnPremises and newer). So such situations will happen more often. So Web IDs are no longer GUIDs but GIDs.

What are the effects?

For all queries where you want to get a unique site based on the ID, you have to be more restrictive (e.g. Site ID AND Web ID). Probably the most common case is the search query. For example, the query

WebId:87be4443-6671-446c-967d-c7f0cf146af7

must be extended with the site ID

WebId:87be4443-6671-446c-967d-c7f0cf146af7 AND SiteId:666ffe48-6145-43b6-a350-a459087b46e9

By the way: The webpart instance ID does not always change either. For example, when translating a page (standard multilingual feature), a "copy" of the page is created and all webparts are copied there. The instance ID remains unchanged.