Europe wants tech sovereignty. Most companies don't even know what their websites load.

A website can look simple. A homepage. A cookie banner. Some analytics. Maybe an embedded video. But a single page visit can create connections to services involved in analytics, tag management, fonts, video, advertising, consent management, content delivery, customer support, embedded content, authentication and marketing automation.

The important distinction is this:

Your website stack is not just the list of tools your team remembers installing. It is the wider chain of services the browser actually contacts.

Those two lists are often not the same. A marketing team may remember adding Google Analytics. A developer may remember configuring a consent platform. Someone else may have embedded a Vimeo video two years ago. A tag manager may contain scripts nobody currently owns. A third-party tool may itself communicate with additional domains.

Over time, the real stack becomes less like a deliberate architecture diagram and more like a record of accumulated decisions.

Dependencies compound. A common sequence looks something like this:

You install one tag manager. The tag manager loads an analytics tool. The analytics tool communicates with additional domains. A marketing script adds another integration. An embedded video introduces its own delivery infrastructure.

Nobody sat in a meeting and approved:

“Let's connect our visitors to a dozen different companies.”

It happened one reasonable decision at a time. That is why the question “Which vendors are on our website?” is harder than it sounds. The honest answer is often not in a spreadsheet. It is in the network traffic.

Not every dependency is the same. It helps to distinguish between four layers.

1. Direct dependency

This is a service your organisation deliberately chose and installed — for example, “we added Plausible.” The relationship is visible and intentional. Someone evaluated the product, approved it and connected it to the website.

2. Indirect dependency

This appears when a tool you chose brings other services into the chain. An embedded video may rely on additional delivery domains or supporting infrastructure that your team never selected directly. You chose the integration. You may not have consciously chosen every company that became part of the resulting chain.

3. Infrastructure dependency

Some dependencies sit outside the visible page itself: hosting, DNS, CDN, email. A company may run a website with a strongly European application stack while its email, edge infrastructure or other supporting services are operated by providers headquartered elsewhere. These dependencies are not always visible in ordinary browser traffic, but they are still part of the wider technical picture.

4. Organisational dependency

This is the strategic layer: who ultimately owns and controls the company your website relies on? A product may have European servers but non-European ownership. A European company may itself depend heavily on infrastructure providers elsewhere. A service may have a local subsidiary but a parent company in another jurisdiction.

The first three layers tell you how the dependency works. The fourth adds ownership and control to the picture. Together, they provide a much more useful map than simply asking where a server is located.

There is a bad version of the European sovereignty debate. It sounds like this:

American technology is bad. Replace everything with European alternatives.

That framing is too simplistic. Many non-European services are excellent products. Some are difficult to replace. Some may be exactly the right choice for a particular organisation. Digital sovereignty should not mean replacing every non-European service by default. It should mean understanding where important dependencies exist and deciding which ones matter.

The principle is simpler:

Digital sovereignty does not mean replacing every non-European service. It starts with knowing what you depend on.

Or, put another way:

Unknown dependency is bad decision-making.

You cannot meaningfully evaluate a dependency you cannot see. You cannot assess alternatives if you do not know what needs replacing. You cannot decide that a dependency is acceptable until you know it exists. And you cannot reduce concentration risk if nobody has mapped where that concentration actually sits. Sovereignty starts with visibility, not with a boycott.

I wanted to see what this looked like in practice, so I scanned the website of a large European software company. From the outside, the website looked like any modern B2B site: a marketing page, a consent banner, analytics, embedded media. The browser traffic and surrounding infrastructure revealed a much broader dependency chain.

What the browser contacted

Before any interaction with the consent banner, StackPatrol observed connections associated with nine US-owned services and one European-owned service. Four of the services were classified as analytics or tracking-related. After consent was accepted, the picture expanded to more than thirty identifiable vendors and more than sixty third-party domains. The observed stack included analytics, marketing automation, error monitoring, video hosting and advertising services.

What the wider infrastructure check showed

The surrounding infrastructure added more dependencies to the picture. The website was delivered through a US-owned content delivery provider. The consent platform was US-owned. The company's email infrastructure used Google Workspace. Two major infrastructure layers — website delivery and company email — therefore also relied on US-owned providers.

The result was a strongly non-European dependency profile across the layers StackPatrol measured. That does not mean the company made reckless decisions. Most modern technology stacks are built one reasonable choice at a time. One team chooses analytics. Another adds a video platform. Marketing introduces automation. Infrastructure decisions happen somewhere else. The dependencies accumulate.

Eventually, the full picture becomes much broader than the short list of tools anyone inside the organisation remembers choosing. That is the interesting part.

See the chain first. Then decide what, if anything, should change.

This distinction matters. A company can be:

• based in Europe
• hosted in Europe
• serving European customers
• compliant with European law

and still depend on a wide network of companies headquartered elsewhere. That is not automatically a problem. But it is something an organisation should be able to see. The same applies in reverse: a website may use several non-European products while still having a relatively resilient and well-understood architecture.

The goal is not to maximise the number of European flags in a dashboard. The goal is to know:

• which services are present
• how they entered the stack
• where they sit in the dependency chain
• who ultimately controls them
• whether the organisation could replace them if necessary

That is a much more useful definition of technological awareness.

There is another consequence of not knowing what a website actually loads: documentation can drift away from reality. A privacy policy may have been written when a site used one analytics service. Six months later, someone adds a marketing platform. Then a video tool. Then a customer-support widget. The website changes faster than the documentation around it.

Before an organisation can ask whether its privacy or cookie documentation accurately reflects reality, it needs a reliable inventory of what the website actually does. That does not mean a browser scan can determine legal compliance. It cannot. But it can reveal a much more practical question:

Does what we observe on the website appear to match what the organisation believes it is running?

That is a useful place to start.

If technological sovereignty is on your organisation's agenda, the cheapest first step is probably not a migration project. It is a map. Start with your own website. Look at what the browser contacts during a normal visit. Separate direct dependencies from indirect ones. Look at the infrastructure around the site. Then ask who owns and controls the companies involved.

You may find that the real stack is broader than anyone consciously designed. That does not mean you need to replace everything. It means you can finally make the decision deliberately.

You cannot manage a dependency you cannot see.