Website change or legal content drift? Telling two look-alike cases apart
In both cases the website and the legal text no longer line up — but the cause is the opposite: either reality moved, or simply the wrong version is live. A decision tree and what each case calls for.
In short
Both cases present the same way: the website and the legal text do not line up. The cause is the opposite though — and so is the ownership.
- Website change: reality moved. The legal text is live in its approved version but may no longer describe the current state. → a content assessment is needed.
- Legal content drift: reality is unchanged. It is simply not the approved version that is live. → delivery needs correcting.
So the decisive question is not “is the text right?” but: is the version visible in production the approved one? That question can be answered objectively, and it separates the two cases cleanly.
Why the two get confused
The trigger is usually the same: someone looks at the website and notices that the legal text does not match the rest of the site. A service is embedded that the text never mentions. The ordering flow works differently than described. A detail in the legal notice is out of date.
At that point the reflex is to switch straight to the content track: the text gets reworked, someone drafts an addition, the item travels to legal or to outside counsel. Sometimes that is right. Sometimes the text had long been correct internally — it was just never delivered. Then a decision that was already made gets made a second time, and the actual cause in the deployment stays where it is.
The reverse happens too: a genuine change in reality gets filed as “a deployment thing, we'll catch up later”. That is the same misassignment in the other direction.
The decision tree
Four questions, in this order:
- Which version is approved internally? Without that answer none of the following questions can be answered. If there is no unambiguously approved version, that is the actual problem — and it sits upstream of both cases.
- Is exactly that version live? Publicly visible page, right language, right brand, right market — including in emails and PDFs.
No → legal content drift. The case is closed for now: deliver first, then assess again.
Yes → continue with question 3. - Did something change that the text describes? New service, new vendor, new interaction point, new ordering flow, changed provider details, new market.
Yes → website change with a possible need to review. Capture the evidence, have it assessed professionally.
No → continue with question 4. - Did the requirements applied to the unchanged text move? Then it is neither of the two cases but a legal change — see a law changed — which of your legal documents actually need reviewing?
The value of the ordering lies in question 2: it is cheap to answer, objective, and it stops professional capacity being spent on a delivery problem.
What actually differs between the two cases
The two differ not only in cause but in almost everything that happens afterwards:
- Determinability: drift can be established technically — a comparison of two versions. A need to review arising from a website change is a judgement.
- Ownership: drift is typically a case for web operations, deployment or editorial. A website change needs a content and possibly a legal assessment.
- Fix: drift is resolved by delivering the approved version. A website change may lead to a new version — or to the recorded finding that none is needed.
- Recurrence: drift comes back as long as the cause persists (copied full texts, caching, hand-maintained templates). A website change is a single event.
- Urgency: drift means a decision that was already taken is not in effect. That is unsatisfying regardless of the content question, and usually quick to fix.
The mixed case — and why the ordering matters most there
In practice the two like to appear together, because they share a root cause: a relaunch. The website changes (new structure, new services, new domains) and at the same time the legal texts get tangled (old pages stay reachable, new paths link wrongly, language versions lag behind).
Whoever starts with the content work in that situation may be assessing a text that is not the current one. So the ordering is not cosmetic: straighten out the delivery state first, then assess what the changed reality means for the text that is now genuinely live.
How to prevent drift instead of hunting for it afterwards is covered in preventing legal content drift.
Why TermShelf keeps the two separate
Document Intelligence deliberately keeps the two cases as distinct signals instead of merging them into one “website check”:
- Legal Content Drift compares the publicly delivered version against the one approved in TermShelf — per website, language and market. The result is a drift finding that names a concrete, technically fixable divergence.
- Website Change Monitoring (beta) observes changes on a monitored website and relates them to a possible need to review. The result is a review finding that starts an assessment.
The separation is not a UI nicety: it keeps a delivery problem from landing in a content review and a content question from disappearing into a deployment backlog. Details on the feature pages Legal Content Drift Scanner and Website Change Monitoring.
Limits
TermShelf does not produce legally binding content and is not a substitute for legal advice. The decision tree classifies an item, it does not assess it. Even a case cleanly classified as drift can raise content questions once the approved version is live again — that is where the second branch begins.
The basics of the term are in what is legal content drift?, the wider picture in the hub keeping legal content current.
Frequently asked questions
- How do you tell legal content drift and a website change apart?
- By one question: is the version visible in production exactly the one approved internally? If not, it is drift — a delivery problem that gets fixed technically. If it is, but the website describes a different state than the text does, it is a website change with a possible content review needed.
- Which one should be handled first when both apply?
- Delivery first. As long as the approved version is not live, you may be assessing an outdated text. Only once the current version is actually being served is it worth assessing what the changed reality means for it.
- Is a drift finding a legal determination?
- No. A drift finding establishes technically that the delivered version diverges from the approved one. Whether that divergence matters legally in a specific case is a separate assessment by qualified counsel.
Check whether what is live really is the approved version
The live check compares publicly visible legal texts against the approved version and records divergence as findings — per website, language and market. That answers question 2 of the decision tree before anyone starts on content.
Related guides
Keeping legal content current: why change starts outside the document
A privacy policy or terms page can become review-worthy without anyone touching it: because the legal framework moved, because the website and the offering moved, or because the version live is not the version approved. An overview of the three triggers and the review process behind them.
A law changed — which of your legal documents actually need reviewing?
Not every legal change touches every document. How to narrow a change down to the brands, markets and document types genuinely affected — instead of turning every regulatory newsletter into a full re-read of everything you publish.
Your website changed — should your legal content be reviewed too?
New tool, new feature, new vendor: the website keeps moving, the published legal text does not move with it. Which website changes typically create a reason to review, how to evidence one — and why there is no blanket yes-or-no answer.