A small website may be compromised: contain access before restoring files
Preserve evidence, protect the hosting and domain accounts and recover from a verified clean version without overwriting the investigation.
In brief
An unexpected redirect, changed page or unknown deployment is a reason to investigate, not proof of a particular attacker. Record the symptom and secure the accounts able to change the site.
For a small website, host, registrar, deployment and recovery-email access often matter as much as the page files.
Determine what changed
Compare the intended release with the served page and inspect recent deployments and DNS changes. Check whether the symptom occurs across networks rather than relying on one browser extension’s view. Preserve provider event records, not just a screenshot of the wrong page.
Contain the relevant route
Protect the recovery email and hosting or domain account from a trusted device. Revoke exposed deployment credentials and review collaborators, API tokens and recovery methods. If users are being sent to a harmful destination, coordinate a safe temporary containment with the host while retaining evidence.
Recover and verify
Use a known clean release and validate the build inputs, routing and external scripts. Review whether user data or credentials could have been affected, seeking appropriate incident expertise when needed. Check that the unwanted access is gone before treating a clean-looking homepage as resolution.
Before you act
A redeploy can remove visible changes while leaving stolen credentials active. It can also overwrite evidence, so preserve relevant logs and versions before cleanup.
What to do next
- Record affected URLs, times and unexpected changes, keeping sensitive evidence private.
- Contact the responsible host/support and revoke suspicious access through trusted account sessions.
- Recover from a verified clean version after containing the cause, then check accounts, routes and monitoring.
