Your website changed — should your legal content be reviewed too?

In short

A website change does not automatically mean the legal content has to be edited. The useful question is not “did the website change?” but: did something change that the legal text describes?

A new frontend design typically changes nothing about data processing. A newly embedded third-party service, an additional payment route or a new contractual subject matter, on the other hand, can create a reason to review — whether they do is a professional assessment of the specific case.

Operationally, three things matter: noticing the change at all, evidencing it well enough for someone to judge it, and recording that judgement. That is what this guide covers — not a legal answer.

A legal text is a statement about reality

Legal pages are often treated as a formality: written once, then filed. Functionally they are something else — a description of an actual state of affairs. They say who the provider is, which services are embedded, how a contract is concluded, which data is processed for what purpose and who receives it.

That couples them to reality — and reality does not change through a legislative procedure. It changes in day-to-day operations: in a sprint, in a marketing experiment, when a vendor is swapped, when a new language version is rolled out.

The gap appears because the two sides run on different clocks. The website ships weekly, the legal text is reviewed annually. Between those two clocks sits the range in which the published text describes a state that no longer exists in that form.

Which website changes typically create a reason to review

The following list is an operational heuristic, not legal advice and not exhaustive. It describes types of change where experience says a look is worthwhile:

• New third-party services. Analytics, chat, maps, video, fonts, A/B testing, support widgets, embedded booking or scheduling flows.
• Swapped or added vendors. A different host, a different newsletter sender, a different payment provider, a different shipping provider.
• New interaction points. A form where there was none: contact, newsletter, sign-up, gated download, job application.
• Changes to the ordering or contract flow. A new product type, a new subscription model, new delivery conditions, digital instead of physical goods.
• New reach. An additional language version, an additional target market, a new domain or microsite.
• Changes to the provider itself. Company name, legal form, address, authorised representatives, registry details — the things a legal notice carries.
• A new audience. A B2B-only offering opens up to consumers — or the reverse.

Conversely, there are changes that are far more visible and still rarely trigger anything: a redesign, new navigation, new imagery, a frontend technology swap that introduces no new services. Visibility is simply a poor indicator of relevance to legal content.

Why there is no blanket yes-or-no answer here

To the question “we embedded a tool — does the privacy policy have to change?” there are products that answer with a firm yes and supply the edit immediately. That is convenient, but it short-circuits an assessment that depends on the specific case: on what the tool actually does, how it is embedded, which data arises, where it flows and what the existing text already covers.

An already broadly worded section may cover a new embedding. Another case calls for a specific addition. A third does not touch the text at all but entirely different duties. Making that distinction is a legal assessment.

What an operational process can and should do instead: make sure the change is noticed at all, that it is evidenced, and that the decision — either way — is recorded traceably.

What usable evidence contains

“Something changed on the website” is worthless for an assessment. Whoever has to judge it needs specifics:

• Where: website, domain, the concrete page or area — with several brands and domains that is not trivial.
• What: the observed change, ideally as before/after rather than as an interpretation.
• When: the time of observation, so the change can be tied to a release or a campaign.
• Relation: which legal text, which language version, which market is potentially affected.
• Status: open, under assessment, assessed with no action needed, in progress.

With those five pieces an observation becomes an item you can put in front of a qualified person — and one that still makes sense three months later.

A website change is not the same as drift

Two cases look alike from the outside and are opposites:

• Website change: reality moved. The legal text is live in exactly the version that was approved — it may simply no longer describe the current state.
• Legal content drift: reality is unchanged. It is just not the approved version that is live, but an older or copied one.

The first case needs a content assessment, the second a technical correction. Mixing them up means looking in the wrong place. The distinction, with a decision tree, is in website change or legal content drift?

Coupling the review trigger to the change process

The most effective organisational measure has little to do with legal texts at first: it is connecting the moment of the website change to a review question, rather than relying on a later read-through.

In practice:

• Whoever embeds a new service answers, in the same work item, whether third-party data is involved — and if so, who assesses it.
• Release checklists for the website carry a legal-content item; “not affected” is an acceptable answer, blank is not.
• When a vendor is swapped, the legal text is part of the migration list — not just the contract and the credentials.

Monitoring does not replace this process; it is the net for the cases where the process did not catch — a campaign page built around the release checklist, say, or a service added through a tag manager.

What TermShelf does here — Website Change Monitoring (Beta)

Website Change Monitoring is one of the three Document Intelligence signals. On a monitored website, changes are detected, evidenced and related to whether they might create a need to review the published legal texts. The result is a review finding, not a text edit.

This signal is marked beta: it is available and under active development — detection, assessment and the degree of automation can still change. The automatic assessment is opt-in and is being rolled out gradually; the check cadence and the number of monitored websites depend on the plan. The other two signals — Legal Change Monitoring and Legal Content Drift — do not carry this status.

Worth setting expectations on: the signal is not a complete website diff and not a legal review of a website. It does not promise to catch every change, and it does not answer whether an edit is required. It makes sure a detected change reaches the people who decide that, as an evidenced item. Details on the feature page Website Change Monitoring.

Limits

TermShelf does not produce legally binding content and is not a substitute for legal advice. Neither a checklist nor monitoring can answer whether a specific website change requires a specific edit. That assessment belongs to qualified counsel, and the types of change listed here are operational pointers, not a list of obligations.

The wider picture — legal change, website change, diverging delivery — is in the hub keeping legal content current. How a finding becomes a recorded decision is covered in from change signal to review finding.