WPlus archive maintenance hub

Monitoring uptime and integrity

Purpose: A compact monitoring playbook for older sites: catch downtime, unexpected redirects, and content changes that can put users at risk.

What to monitor on older sites

Monitoring for legacy properties is not just “is it up.” The risks are often subtle: a host that starts redirecting unexpectedly, a page that changes without review, or a content type that flips and becomes unsafe. The goal is predictable behavior and user trust.

Start with availability, then add drift detection

Basic uptime checks (HTTP checks from multiple regions) are a baseline, but legacy sites need drift detection. A host can be “up” while still becoming unsafe if important URLs start redirecting, returning unexpected status codes, or serving surprising content types.

For the URLs you care about most, alert on new 3xx responses and on unexpected body changes. Redirect changes are often the first sign of misconfiguration or compromise.

Monitor status codes and “final destination”

For each monitored URL, record: status code, final URL (after redirects), and a small fingerprint of the body. This catches the common failure modes: unexpected redirects, parked pages, and template injection.

Integrity monitoring for static content

Static sites are still vulnerable to file modifications if the deployment path is writable by the wrong user or if a vulnerable control panel is in place. Maintain a checksum list (for example SHA-256) of the deployed HTML and CSS files and compare it periodically. If any page changes outside an authorized deployment, treat it as an incident: capture the modified artifact, rotate credentials, and redeploy from a known-good build.

Because the content is small, integrity checks can be lightweight and frequent without undue cost. The operational payoff is large: you can prove the state of the archive over time.

Content-type checks for “extension but HTML” stubs

Legacy URLs sometimes end with extensions that browsers associate with media playlists or video files. WPlus serves some of these as HTML stubs to preserve the path while avoiding unsafe downloads. Monitoring should explicitly verify that these URLs render as HTML (via response headers and a small body match), not as binary content.

Minimum viable monitoring checklist

A small number of targeted checks beats a large number of generic checks.

Status code: verify 200 for expected pages; alert on any new 3xx and unexpected 4xx/5xx.
Final URL: record where the request ends up; a new redirect is often the first sign of misconfiguration or compromise.
Body fingerprint: hash a small, stable portion of the HTML (or full body for small pages) to catch template injection.
Content type: for special legacy paths (for example “media extension but HTML”), verify the response is served as text/html.
Robots/sitemaps availability: verify each host’s /robots.txt and /sitemap.xml remain reachable and unchanged.

Example check (PowerShell)

This quick check records status and whether a page body changed unexpectedly.

$url = 'https://www.wplus.net/pp/citwatch/'
$resp = Invoke-WebRequest -Uri $url -MaximumRedirection 0 -ErrorAction SilentlyContinue
$status = $resp.StatusCode
$bodyHash = (Get-FileHash -InputStream ([IO.MemoryStream]::new([Text.Encoding]::UTF8.GetBytes($resp.Content))) -Algorithm SHA256).Hash
"$url`t$status`t$bodyHash"

Common mistakes

Monitoring only 5xx: redirects and content drift are often the real problem on older sites.
Not alerting on new 3xx: redirects can appear due to config drift or compromise.
No integrity baseline: without a known-good fingerprint, you cannot detect silent changes.
Assuming content types are stable: legacy file extensions can produce unexpected handling.

Response playbook for “redirect drift”

When a monitored URL unexpectedly becomes a 301/302, treat it as a high-signal event. The fix is often simple, but the impact can compound if it persists.

For archives, the “business impact” of redirect drift is rarely obvious in dashboards. What actually breaks is trust and consolidation: search engines learn that your historical URLs no longer exist as distinct resources, and users bounce because they land on unrelated destinations. That’s why it is worth treating this class of change like an incident even when uptime is green.

Confirm scope: check whether drift affects only one path or an entire host (common with host-level rewrites).
Identify the layer: determine whether the change is at DNS/CDN, Nginx config, or upstream storage.
Restore known-good: redeploy the static tree and revert any recent config changes.
Lock down: ensure deployment paths are not writable by runtime users; rotate credentials if needed.
Re-verify canonicals: confirm canonicals still point to the stable form you expect.