Some website compromises announce themselves with a warning page. Others stay quiet while adding spam, creating hidden accounts or redirecting only certain visitors. A single symptom does not prove the cause, but it should trigger a deliberate check.
Visible warning signs
- Visitors are redirected to unrelated or suspicious websites.
- Pages display text, links, pop-ups or advertisements your team did not publish.
- Search results show pharmaceutical, gambling or other spam under your domain.
- Browsers, search engines or the hosting provider warn that the site may be unsafe.
- The homepage or important pages have been defaced.
- Downloads appear that the organisation did not provide.
Administrative warning signs
- Unknown administrator accounts appear.
- Legitimate users cannot log in or passwords change unexpectedly.
- Plugins, modules, themes or extensions appear without explanation.
- Files change outside an approved release.
- Security, audit or server logs show unusual access.
- Forms stop delivering, or they begin sending unexpected mail.
- The host reports high resource use, spam or malicious processes.
Quiet operational signs
A hacked website can also present as a performance or reliability problem: unusual traffic, sudden server load, unexplained scheduled tasks, new API calls or intermittent redirects. These signs have innocent causes too, so treat them as evidence to investigate rather than a final diagnosis.
What to do first
Record the symptoms
Take screenshots, note the exact URL, time, device and network, and save provider alerts. If the behaviour is intermittent, record how it was triggered. This helps distinguish the incident from a cache, browser extension or local-device issue.
Contact the host when containment is urgent
If customers are at risk, the host may be able to isolate or suspend the site while evidence is preserved. Understand the business impact before taking the site offline, but do not prioritise appearance over active harm.
Preserve a snapshot
Before deleting files or restoring a backup, preserve the current state when it is safe and authorised to do so. A rushed restore may remove evidence, and a recent backup may already contain the compromise.
Secure the access route
Review administrator, hosting, database, file-transfer and repository access. Password changes may be necessary, but if the device or account used to change them is compromised, the attacker may obtain the new credentials. Use a known-clean device and coordinate the sequence.
Investigate, recover and update
The recovery route may be a known-clean backup, targeted cleanup or a controlled rebuild. Update the CMS, plugins, themes and dependencies after accounting for compatibility and custom code. Then change relevant credentials again and review the cause as far as the evidence allows.
WordPress’s official hacked-site guidance follows a similar progression: document the incident, scan the website and local environment, check with the host, reset access, create a backup or snapshot, remove the hack, update and harden.
What not to do
- Do not install multiple random cleanup plugins and hope one fixes everything.
- Do not delete evidence before understanding the recovery options.
- Do not assume the newest backup is clean.
- Do not send passwords through an ordinary contact form.
- Do not declare the site clean because the visible symptom disappeared.
- Do not promise customers that no data was affected without evidence and appropriate advice.
After the site is back
Recovery is not complete when the homepage loads. Check critical journeys, review access, rotate credentials, confirm software support, monitor for recurrence and establish ongoing maintenance. If personal or regulated data may be involved, the organisation should obtain appropriate legal, regulatory and incident-response advice.