Your Website Was Hacked: What to Do in the First 24 Hours

When a website is hacked, the first instinct is usually “delete the bad file and get the site back online.” That can erase useful evidence, leave the entry point open, or restore the same compromise from an unsafe backup.

The first day should be controlled, not frantic.

NIST’s incident-response guidance organizes the work around detecting, responding to, and recovering from incidents. A small business does not need an enterprise security department to use that logic. It needs a clear owner, preserved evidence, a containment decision, and verified recovery.

Confirm what is actually happening

Do not assume every outage or strange page is a hack. Hosting failures, expired domains, broken deployments, plugin conflicts, and DNS mistakes can look similar.

Capture what you can see before changing anything:

• The affected URL and exact time.
• Screenshots of redirects, warnings, altered content, or browser messages.
• Hosting, security, and application alerts.
• Recent administrator, plugin, theme, deployment, and DNS changes.
• Whether forms, checkout, email, or account access are affected.

If the site is collecting payments or sensitive information, involve the appropriate security, payment, legal, or insurance contacts. A web team can investigate the site; it should not invent legal or notification obligations.

Contain the risk without destroying the scene

Containment depends on what is compromised. It may mean placing the site in maintenance mode, blocking a malicious route, disabling a vulnerable component, revoking a user, isolating the host, or temporarily stopping transactions.

Avoid blind mass deletion. Preserve current files, database state, logs, user lists, and configuration where possible. That snapshot can help identify what changed and whether the same weakness remains after cleanup.

Change credentials from a known-clean device. Prioritize hosting, the domain registrar, DNS, the CMS, deployment accounts, email used for recovery, and any payment or integration accounts connected to the site. Do not use a compromised browser session to rotate every password.

Find the entry point, not just the symptom

A malicious file is evidence, not necessarily the cause. The entry point could be a vulnerable plugin, stolen administrator password, exposed hosting account, old vendor access, compromised developer machine, unsafe API key, or another site on the same server.

Review recent users and logins, installed extensions, unexpected scheduled tasks, modified files, database administrators, DNS records, and deployment history. Our explanation of high-severity plugin disclosures shows why exposure and installed version matter more than a scary headline alone.

If the cause is uncertain, keep the site contained. A quick cleanup without a cause is an invitation to repeat the incident.

Recover from a known-good state

A backup is useful only when the team knows what it contains and when it was created. Restoring yesterday’s copy may also restore yesterday’s malware.

Choose a recovery point based on evidence. Patch or remove the entry point, rotate affected credentials, restore or clean the site, and compare the result with the expected application and content. The broader lesson in Backups Are Not a Security Plan applies here: recovery needs testing, ownership, and monitoring around the backup.

Verify the customer paths before reopening

Do not stop at “the homepage loads.” Check:

1. Public pages and mobile navigation.
2. Forms, inbox delivery, and stored entries.
3. Checkout, booking, account, or payment paths where applicable.
4. Administrator users and permissions.
5. DNS, SSL, redirects, analytics, and search visibility.
6. Security and server logs after the site returns.

Continue monitoring. Some compromises add persistence mechanisms designed to survive a superficial cleanup.

Document the decision and the next prevention step

Record what happened, what was changed, which credentials were rotated, what was restored, how the site was tested, and what remains uncertain. That record helps the next responder and turns an emergency into a better operating process.

Prevention work may include removing unused plugins, enforcing MFA, separating named accounts, tightening hosting access, adding file or uptime monitoring, testing restores, and clarifying who receives alerts.

If your website response plan is currently “call whoever built it,” make that relationship explicit before an incident. Robben Media’s website security and support work focuses on the unglamorous controls that make recovery clearer when something does go wrong.