# Website change monitoring: how to make sense of a changed page By Track.Name Canonical URL: https://staging.track.name/blog/website-change-monitoring Website change monitoring compares observations of a page over time. Text, page structure, screenshots, redirects and HTTP responses can reveal different changes. A useful review preserves the before and after, separates expected variation from meaningful differences, and checks related domain signals before drawing conclusions about a site's status or ownership. ## Choose the kind of website change you need to see Start by writing the question you want a check to answer. Has the homepage been replaced? Does the domain redirect somewhere new? Has a page stopped returning the expected response? Text comparison helps you review wording. An HTML comparison can expose changes in the document, including changes that are not visible. A screenshot comparison is useful when layout and presentation matter. An HTTP observation records the response to a request rather than judging the page's meaning. A visual difference may be a moved button; a status change may occur without a new design. Before selecting monitoring, ask what it compares, whether it runs JavaScript, and which parts of the result are retained for review. ## Read content, status codes and redirects together An HTTP status describes the result of a particular request. Successful responses, redirects, client errors and server errors form distinct groups. A `200` response does not describe the business meaning of the returned page; a `301` or `302` directs the client to another location. [MDN documents the HTTP status groups](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status). For domain monitoring, save the requested address and the final destination. If a familiar homepage now redirects to an unrelated host, investigate the destination and the change record. If the site returns an error, preserve that response separately from the last usable content comparison. Caching also affects what a client sees. A cache can reuse a stored response, so an observation need not involve a fresh response from the origin server. [MDN explains HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching). When results disagree, record the time and request conditions instead of choosing whichever screenshot supports your first assumption. ## Reduce noise without hiding important changes List elements expected to vary: rotating promotions, time stamps, consent notices, language choices and signed-in content. Choose the part carrying the information you need. For your own site, compare a stable public view and document the language, viewport and authentication state used. If a tool supports excluding page regions, test the exclusions against a known meaningful change before relying on them. An exclusion that removes a banner may also hide an important announcement. HTTP validators offer another kind of comparison. An `ETag` or `Last-Modified` value supports conditional requests; a `304` response tells the client to reuse its stored representation. These mechanisms are designed for resource validation and caching, not to decide whether a change matters to your business. [Read MDN's guide to conditional requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Conditional_requests). Ask for an explanation of skipped or unavailable comparisons. A missing screenshot or failed fetch should remain visible as missing evidence, rather than being treated as proof that the page stayed the same. ## Example: a taken domain starts showing a different website Imagine a founder following `example.com` for a future project. In this hypothetical example, the domain previously showed a holding page. A later observation shows a product homepage and redirects visitors from the bare domain to `www.example.com`. The useful finding is specific: the observed content and destination changed between two checks. It does not establish that the registration changed hands, that the domain is for sale or that the founder has an opportunity to register it. The next review should compare the registration record, nameservers, relevant DNS answers and certificate observations. Record which signals changed and which stayed the same. If the public registration data is limited, leave that uncertainty visible. A timeline lets the founder decide whether to keep following the name without inventing a story about its owner. The same approach helps a company investigate an unexpected change on a domain it already uses. ## A practical checklist for reviewing a page change Use a consistent review sequence: 1. **Confirm the scope.** Check the exact hostname, requested page, observation time and method. Keep times in one stated timezone. 2. **Read the difference.** Look at the before and after, not just a change score or headline. Identify the specific content, status or destination that changed. 3. **Check expected work.** For a domain you operate, compare the event with releases, campaigns, redirects and provider changes. 4. **Repeat the observation when appropriate.** Note whether the result persists and whether request conditions have changed. A repeat helps establish the current result; it does not reconstruct everything between checks. 5. **Connect related evidence.** Review DNS, certificates and registration information around the same period. 6. **Record a decision.** Mark the change as expected, unresolved or requiring action, and give unresolved work an owner. Keep sensitive material out of shared notes. A public page observation may still contain contact details or information that does not belong in a broadly distributed incident message. ## Use page changes as evidence, not a prediction Website monitoring observes what a check can reach under its configured conditions. It cannot infer a domain owner's intention from a blank page, a new design or a broken link. Nor does a working homepage prove that every customer journey works. Use [website uptime monitoring](/blog/website-uptime-monitoring) to understand response failures and timing separately. Use [taken-domain monitoring](/blog/taken-domain-monitoring) when the question is how to follow a name that is already registered. [DNS record monitoring](/blog/dns-record-monitoring) helps connect visible website changes to changes in routing or services. Track.Name groups these observations around the domain. For any monitoring setup, insist on clear timestamps and visible limits. The goal is a finding you can investigate, with enough context to decide your next action. ## Frequently asked questions ### Can website change monitoring tell me when a domain is available? A page change alone cannot establish domain availability. A parked page, an error or an empty response still belongs to a domain with its own registration status. Check registration and availability data separately, and confirm current availability with a registrar before acting. ### Why might a page change alert show no obvious visual difference? Check the comparison method. A document comparison may capture a change that is not visible, while a text or screenshot comparison measures something else. Review the actual before and after and any filtering rules before deciding the alert is unhelpful. ### Does a website returning HTTP 200 mean it is working correctly? It means that particular HTTP request succeeded. Review the returned content and, for a site you operate, test the customer action that matters. A successful homepage response is not a test of sign-in, search, checkout or every other page. ## Sources - [MDN: HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) - [MDN: HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching) - [MDN: HTTP conditional requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Conditional_requests)