Website hacked? What to do first and mistakes to avoid
- Web developing
- September 7, 2026
Table of contents
Your website redirects visitors to unfamiliar pages, displays content you never published or has been suspended by your hosting provider. If you suspect your website has been hacked, start by limiting the damage: contact your host, have the affected site isolated when visitors are at risk and preserve information for the investigation before deleting or restoring anything.
Changing a password or removing the visible message may be necessary, but neither proves the incident is resolved. Recovery requires identifying the affected accounts and components, removing unauthorized changes and closing the entry point.
This guide helps you organize the initial response for a business website, WordPress installation, Joomla site or online store, even if someone else manages the server.
What to do first when your website has been hacked
Use this sequence as a working plan with whoever manages your infrastructure:
- Notify your hosting provider and website developer, explaining what you observed and when.
- Contain the incident: have access restricted if the affected service distributes malware, captures information without authorization or sends visitors to harmful pages.
- Preserve evidence and copies of the current environment before cleanup, keeping earlier backups intact.
- Secure access from a trusted device, including revoking compromised credentials and active sessions.
- Assess whether personal data is affected while the technical investigation continues.
- Restore and reopen after verification, then address any search engine security warnings.
If damage is ongoing, do not delay containment until you have collected every possible piece of evidence. Ask your provider to coordinate both tasks and avoid unnecessary information loss. The separation between containment, eradication and recovery follows the incident handling approach described in CISA’s incident response playbooks.
How to distinguish a hack from a website fault
A server error, blank page or slow response does not establish that an attack took place. Updates, configuration problems and insufficient resources can produce those symptoms. Unauthorized administrator accounts, altered pages and warnings about harmful content warrant investigation.
Record the affected URL, the time and time zone, and what happened. Keep alerts you received, verifying them through the service’s official dashboard instead of following login links in suspicious emails. Do not ask customers to bypass browser security warnings to demonstrate the problem.
The WordPress guide for hacked websites recommends documenting symptoms. A normal-looking homepage does not rule out a compromise elsewhere on the site or behavior that appears only under certain conditions.
When to take the website offline and what to ask your host
If visitors are exposed to harmful content, request containment at the hosting or infrastructure level. A maintenance page controlled by the CMS may hide the homepage while other compromised files remain executable.
Include specific questions in your support request:
- Which files, requests or activities triggered the alert?
- Are other websites or services in the same account affected?
- Which logs and backups are available, and when will they expire?
- Which containment and cleanup tasks does the support agreement cover?
Cloudflare’s hacked website recovery guidance identifies the hosting provider as a contact for investigating the attack and removing malicious content. Check your own agreement: hosting support does not necessarily include full CMS cleanup.
For an online store, coordinate the suspension of affected processes and provide a reliable contact channel for customers. Avoid improvised DNS changes, which could interrupt email and other services without removing the compromise.
Preserve evidence before choosing a backup to restore
Ask for copies of the available files, database, configuration and logs. Maintain a record of each intervention, including who changed what, when and the result. Technical evidence collection belongs with someone who can handle the environment without accidentally executing suspicious material.
A copy of an infected site is evidence, not a clean recovery backup. Label it clearly, protect it and keep it separate from earlier copies. Archives must not be downloadable from a public website directory.
Before selecting a restore point, establish when the first signs appeared, how far back the backups extend and what data would change if you rolled back. The intrusion may have happened before anyone noticed its effects.
Consider an online store: restoring last week’s database could remove legitimate orders placed since then. Recovery needs a plan for preserving and checking those orders without importing everything from the compromised environment indiscriminately.
Which credentials to change and why sessions matter
Use a trusted device to secure accounts. Review the recovery email account, hosting dashboard, CMS administrators and any technical access that exists. Include domain registration, DNS and connected services when there are signs of unauthorized access.
The person handling recovery should check users, privileges, active sessions, SSH keys and API tokens. A password change does not guarantee that every session or token is invalidated. Exposed credentials need to be revoked or replaced using the relevant service’s procedure.
Enable multifactor authentication where supported and remove unnecessary access. For WordPress, the official security handbook covers credentials, permissions and authentication keys.
Application credentials require coordination: changing a database password without updating the site’s configuration breaks its connection. After cleanup, rotate secrets again if they could have been read while the environment was compromised.
Should you restore a backup or rebuild the affected site?
A backup is an option, not a guarantee. Verify it in an isolated environment and address the vulnerable component or compromised access before reopening. Without a trustworthy backup, recovery may require rebuilding with original software packages and selectively recovering content and data.
The decision depends on the extent of the compromise, custom code and whether files can be compared against trusted versions. Overwriting some files may leave attacker-added files behind. The database, scheduled tasks and configuration may also need inspection.
For Joomla, the official hacked site recovery checklist addresses hidden access that can allow reinfection and the need for compatible software versions. A major version migration requires planning; it should not be treated as a blind file replacement during an emergency.
With WordPress, distinguish distributed software files from customizations and uploaded content. An unfamiliar directory name is not enough reason to delete it. When an installation needs technical assessment, agree on the scope of the investigation before changes begin.
Mistakes that can make website recovery harder
Before approving an operation, ask what problem it addresses and how the result will be checked. Avoid:
- deleting files or emptying database tables based on a generic search;
- treating a single clean scan as definitive proof of recovery;
- restoring a backup without checking its date, integrity and the cause of the incident;
- changing hosting, CMS and DNS simultaneously without a plan;
- sending passwords, database copies or customer data in the initial support enquiry.
A scanner can help identify anomalies. The investigation still needs to connect the findings: what changed, which access was available and what evidence supports reopening the service.
Assess personal data exposure alongside technical recovery
A hacked website does not automatically mean all its data was stolen. Assess unauthorized access, disclosure, alteration and loss of availability of personal data, involving the person responsible for privacy or the data protection officer, where appointed.
For processing subject to the GDPR, the Italian data protection authority explains the breach notification requirements: notify the competent authority without undue delay and, where feasible, within 72 hours of awareness, unless a risk to people’s rights and freedoms is unlikely. High-risk breaches may also require communication to affected individuals. Document the assessment rather than waiting for the website to reopen.
When to reopen and how to handle Google security warnings
Agree on acceptance criteria: the cause has been addressed or containment measures justified, components checked and access reviewed. Test forms, email delivery, login and, for an online store, the purchase journey in test mode. Check public pages while logged out as well.
If Google reports a compromise, inspect the Security issues report in Search Console. Once the whole issue has been resolved, request a review explaining the work completed. Google’s documentation describes the process. Requesting indexing alone does not replace a security review.
There is no guaranteed timeline for warning removal or search visibility recovery. Plan log monitoring, backup checks and component maintenance after reopening. A functioning homepage alone does not close the incident.
How to request help with a hacked website
Start with the domain, CMS if known, symptoms, when you first noticed them and any message from your hosting provider. Explain whether you have backups and whether the website collects orders or other user data. Technical access can be arranged separately through an appropriate channel.
For international businesses managing a website in Italy, my website support services also cover technical coordination with the people responsible for the site.
If your website has been hacked, I can assess the situation and the work needed for cleanup and recovery, coordinating with the hosting provider where necessary.
Request help with your hacked website
