# How to Detect Unauthorised Website Changes

> A client’s homepage can be altered in minutes. A promotion disappears, a payment link is replaced, tracking code is injected, or a well-meaning editor changes…

A client’s homepage can be altered in minutes. A promotion disappears, a payment link is replaced, tracking code is injected, or a well-meaning editor changes regulated copy without approval. The difficult part is rarely fixing the page. It is knowing that it changed, identifying exactly what changed, and responding before a client, customer or search engine finds it first.

Knowing **how to detect unauthorised website changes** is therefore not just a security task. For [agencies and web teams](https://www.tldtrack.com/agencies), it is an operational control that protects revenue, brand standards, search visibility and client trust across an entire portfolio.

## Start by defining what “unauthorised” means

Not every unexpected change is malicious. A developer may deploy an approved release outside the usual window. A client-side marketing team may update campaign copy without telling the agency. A consent-management tool may alter a script or banner automatically.

Treating every difference as an incident creates alert fatigue. Treating every difference as harmless creates blind spots. The practical approach is to establish approved sources, approved people and approved time windows for each important site.

For example, a retail client may permit price and stock changes from its e-commerce platform all day, while its legal, returns and checkout pages require formal approval. A financial services site may need every visible content adjustment recorded. A brochure site may only need alerts for changes to key conversion pages, forms, navigation, scripts and outbound links.

This classification turns a vague instruction to “watch the website” into a monitoring policy your team can operate.

## Build a trusted baseline before you monitor

A change can only be meaningful when you know what the approved version looked like. Capture a baseline for each monitored page after a verified release, rather than accepting the first version a tool happens to see as trustworthy.

That baseline should cover more than visible page text. Compare the rendered page, its HTML and selected critical elements. The rendered view catches layout damage, unexpected overlays and off-brand imagery. HTML comparison can reveal injected scripts, changed canonical tags, removed headings and altered links that may not be obvious on a screenshot. Element-level monitoring is useful when only one item matters, such as the price, a regulatory notice, a booking button or a phone number.

Record who approved the baseline and which release it represents. Without that small discipline, teams can spend time investigating a difference that was actually part of last week’s deployment.

### Prioritise pages with real business consequences

Monitoring every URL with the same sensitivity is expensive in attention, even when the technical check is inexpensive. Start with the pages where a change can cost money, create compliance exposure or harm a client relationship.

These usually include the homepage, high-traffic landing pages, checkout and payment steps, enquiry forms, account and login pages, pricing pages, legal pages, key service pages and pages targeted by paid campaigns. For [e-commerce sites](https://www.tldtrack.com/blog/content-monitoring-for-ecommerce), product availability, prices, shipping messages and promotional banners deserve their own checks. For organisations with strict brand governance, monitor headers, logos, approved terminology and prominent calls to action.

Lower-priority blog archives and tag pages can still be watched, but they do not need the same alert urgency. The aim is not maximum notification volume. It is fast notice of material changes.

## Use more than one type of website change detection

A single page-diff check is useful, but it will not answer every question. The most reliable programmes combine several views of the site because unauthorised changes can happen at different layers.

**Content monitoring** detects additions, deletions and alterations in page copy, links, metadata and code. It is the right control for altered claims, broken calls to action, changed titles, suspicious outbound links and unexpected script tags.

**Visual monitoring** compares rendered screenshots. It catches issues that source-code checks can miss: a hidden button, a cookie banner covering the checkout, a missing hero image, distorted styling or an unapproved logo.

**Infrastructure monitoring** watches [DNS records](https://www.tldtrack.com/blog/dns-records-explained), SSL certificates, hosting availability and redirects. A nameserver or redirect change may point visitors somewhere else while the original site files remain untouched.

**Security monitoring** looks for vulnerable software, exposed services, malware indicators and configuration errors. A content diff tells you that a script appeared. Security checks help establish whether it may be part of a compromise.

The exact mix depends on the site. A static campaign landing page may need frequent visual and content checks. A WordPress estate also needs plugin, core and user-account oversight. A large e-commerce operation needs close monitoring of transactional pages and third-party scripts.

## Set sensible intervals and alert thresholds

Five-minute checks are appropriate for a revenue-critical homepage, payment flow or high-spend advertising destination. They may be excessive for a small charity’s history page. Monitoring frequency should reflect the consequence of a missed change and the rate of legitimate publishing.

Thresholds matter just as much. Ignore predictable dynamic areas such as rotating testimonials, timestamps, personalisation blocks and stock counters where appropriate. Otherwise, your team will learn to ignore the very alerts meant to protect them.

At the same time, avoid excluding a whole page simply because one section changes often. Configure the monitor around stable elements: watch the purchase button, price block or legal copy rather than the live social feed beside it. Good monitoring is specific enough to be trusted.

## Make every alert actionable

An alert that says “page changed” is a starting point, not an operational outcome. The recipient should be able to see the before-and-after view, the affected URL, the time of detection and whether the change is content, visual, code or infrastructure related.

Route alerts based on severity. A missing logo may go to the account manager during business hours. A checkout redirect, changed bank details or unexpected JavaScript should reach the technical on-call contact immediately. For managed clients, agree this escalation path before an incident occurs, including who can authorise a rollback and who communicates with the client.

Keep a simple change log alongside the alerts. Capture the detected difference, the suspected cause, the owner, the decision and the resolution time. Over time, this reveals recurring failures: unannounced releases, a plugin that edits pages, an external tag manager with weak access control, or a client team publishing directly to production.

## Investigate the source, not just the symptom

When an unauthorised change appears, first confirm it from a clean browser session or second monitoring location. Cached content, A/B tests and personalisation can produce misleading differences.

Then compare the timing against deployment records, CMS audit logs, tag-manager versions, hosting activity and DNS history. If the change is in the page source, inspect recently added scripts, iframes, forms and external domains. If it is visual only, check the stylesheet, image assets, consent tooling and third-party widgets. A redirect or DNS difference needs faster containment because it can affect every visitor.

If you suspect compromise, preserve evidence before making broad changes. Take screenshots, save affected source, note timestamps and document the accounts involved. Then remove unauthorised access, rotate relevant credentials, patch the underlying weakness and restore a known-good version. Restoring the page without closing the entry point simply invites a repeat incident.

## Reduce the chances of unauthorised changes

Detection is essential, but prevention reduces the number of alarms your team has to manage. Give each person the minimum access needed, require multi-factor authentication for CMS, hosting, DNS and tag-management accounts, and remove access promptly when staff or suppliers leave.

Use separate accounts rather than shared logins, protect production deployments with review steps, and maintain a clear approval route for urgent edits. Agencies should also agree boundaries with clients: which teams may publish directly, which pages require approval, and where change requests are recorded.

A platform such as TLDTrack can bring content, visual, DNS, SSL and security monitoring into one portfolio view, which makes it easier to spot a single issue affecting several sites or prove that a change was isolated. The value is not another dashboard for its own sake. It is less time switching tools and a clearer route from alert to owner.

## Turn detection into proactive client service

The strongest agencies do not merely report that a site was altered. They show what changed, when it was detected, whether visitors were affected and what was done next. That changes the conversation from reactive support to visible operational care.

Review alerts regularly with account and technical teams. If a certain class of alert is always legitimate, refine the rule. If the same unauthorised edit keeps returning, fix the process or access control behind it. Monitoring should become quieter and more valuable over time.

A website can change without warning. Your clients should not have to be the people who notice first.

---

Published: 2026-10-29  
Web version: https://www.tldtrack.com/blog/how-to-detect-unauthorised-website-changes