How to Recover a Hacked Website: A Practical Step-by-Step Recovery Guide

If your website has been hacked, the priority is not simply to delete the suspicious page or change one password. You need to contain the compromise, preserve useful evidence, remove the attacker’s access, restore trustworthy files, and verify that the vulnerability that allowed the attack has been closed. For WordPress sites, the official WordPress guidance recommends documenting the symptoms, scanning both the website and the local computer, contacting the hosting provider, resetting access credentials, cleaning or restoring the installation, and investigating how the attacker gained entry.

The safest recovery path depends on what happened. A clean, recent backup can make restoration much faster, but restoring an old copy without fixing the vulnerability can simply put the same weakness back online. If you cannot establish when the compromise occurred, or the attacker appears to have retained administrative or server access, treat the incident as a deeper compromise rather than a cosmetic website problem.

First, determine whether the website is actually compromised

A website being unavailable does not necessarily mean it has been hacked. A server outage, expired domain, broken plugin, configuration error or hosting problem can produce similar symptoms.

Possible indicators of compromise include:

• Unexpected administrator accounts
• New or modified files you did not create
• Unknown pages appearing in search results
• Redirects to unrelated websites
• Spam, phishing or malware appearing on legitimate pages
• Unauthorized changes to website content
• Security warnings from browsers or search engines
• Your hosting provider disabling the account
• Unexpected changes to .htaccess or other server configuration
• Users reporting suspicious downloads or redirects

WordPress specifically identifies blacklisting, malware warnings, unauthorized users and visibly altered websites among common indicators of a compromise.

If you have Google Search Console configured, check its Security Issues report. Google uses the report to identify sites it believes may have been hacked or used in ways that could harm visitors.

Contain the website before trying to clean it

Once you have reasonable evidence of a compromise, reduce the attacker’s opportunity to make further changes.

If practical, temporarily take the affected website offline or restrict access while you investigate. SiteGround’s own hacked-site guidance recommends putting a compromised website into maintenance mode during recovery, while its technical guidance recommends quarantining an infected site during cleanup.

Do not immediately start deleting files at random.

Before making major changes, record:

• What the website looks like now
• When you first noticed the problem
• Which pages or functions are affected
• Recently installed plugins, themes or extensions
• Recently created users
• Suspicious filenames
• File modification dates
• Relevant hosting or server logs, if available
• Security warnings received from Google or your host

This information can help determine whether the infection was limited to one component or whether an attacker obtained broader access. WordPress recommends documenting symptoms and the approximate time they were observed as an early part of the recovery process.

Do not investigate from an infected computer

Your website may not be the only compromised component.

If credentials were stolen through malware on your computer, cleaning the website while continuing to use the same infected machine can lead to reinfection. WordPress recommends scanning the local environment as well as the website itself.

Use a trusted, updated computer for password changes and administrative work whenever possible.

Change the credentials that could have been exposed

A hacked website can expose more than the WordPress administrator password.

Review every account that could provide access to the website or its data, including:

• WordPress administrator accounts
• Hosting control-panel accounts
• SFTP or SSH accounts
• Database credentials
• Domain registrar accounts
• Email accounts used for password recovery
• API keys and application credentials
• Third-party services connected to the website

WordPress recommends resetting access across the relevant administrative systems rather than treating the WordPress password as the only credential that matters. It also recommends updating WordPress secret keys so existing authenticated sessions are invalidated.

Use unique passwords and enable multifactor authentication wherever the service supports it. Google likewise recommends strong passwords and keeping the computers used to administer websites secure.

If you suspect the attacker still has access, changing passwords should happen as part of a broader containment process—not as the entire recovery procedure.

Preserve a copy before deleting suspicious material

It can be tempting to delete every unfamiliar file immediately. That can destroy useful evidence and sometimes removes legitimate website components.

Before cleaning, make a backup or snapshot of the compromised environment if your hosting setup allows it. Keep it separate from the clean backup you intend to restore.

The infected copy may help a professional determine:

• Which files were modified
• When changes occurred
• Whether unauthorized accounts were created
• Whether malicious code remains elsewhere
• How the attacker may have entered
• Whether other sites or databases in the same hosting environment may be affected

This is particularly important for business websites, stores, membership platforms and sites handling sensitive information.

Scan the website for malware and unauthorized changes

A single malware scanner should not be treated as proof that a website is clean.

Different scanners inspect different layers, and sophisticated compromises can involve legitimate-looking files, database content, scheduled tasks, administrator accounts or backdoors that are not obvious from the homepage.

For WordPress, examine:

• Core WordPress files
• Plugins
• Themes
• Uploaded files
• Administrator accounts
• Database users and content
• .htaccess
• Configuration files
• Scheduled tasks
• Files outside the normal WordPress installation where your hosting environment permits them to exist

WordPress specifically highlights .htaccess, index.php, header.php, footer.php and functions.php as files worth examining when investigating a compromised installation.

Do not assume that deleting the visible malicious page removes the underlying backdoor.

Check for unauthorized WordPress users

Attackers sometimes create administrative accounts so they can return after the original vulnerability has been patched.

Review the complete list of WordPress users, particularly administrators. Look for:

• Accounts you did not create
• Unexpected administrator privileges
• Unfamiliar email addresses
• Strange usernames
• Accounts created around the time of the incident

If you cannot access WordPress administration, database-management tools provided by your host may allow a qualified administrator to investigate the user tables. If you are not comfortable working directly with the database, involve your hosting provider or a security professional rather than changing database records blindly.

Restore from a known-clean backup when appropriate

A clean backup can be one of the fastest ways to recover a compromised website.

The important word is clean.

If the attacker gained access two weeks ago and you restore a backup made yesterday, that backup may already contain the compromise. SiteGround recommends going back to the last known working, malware-free backup and notes that uncertainty about when the hack occurred may require considering older backups.

A restoration is therefore a recovery step, not necessarily the end of the incident.

Reinstall compromised software instead of trusting modified files

If a WordPress core file has been modified, replacing it with a clean copy is generally safer than trying to manually edit malicious code out of it.

The same principle applies to plugins and themes: where possible, obtain clean versions from their legitimate sources rather than assuming an existing installation can be made trustworthy by deleting one suspicious line.

WordPress recommends replacing core components from clean versions during recovery and paying particular attention to themes and plugins because those components can contain or retain malicious modifications.

Never download a supposedly “cleaned” plugin or theme from an unknown website simply because it is free.

Find the vulnerability that allowed the attack

Cleaning the malware without identifying the entry point leaves the door open.

Common possibilities include:

• An outdated plugin or theme
• Vulnerable WordPress core
• Stolen administrator credentials
• Reused passwords
• Compromised SFTP or SSH credentials
• A vulnerable third-party integration
• Unsafe file-upload functionality
• Poorly configured permissions
• An exposed server or hosting account
• Malware already present on an administrator’s computer

Google recommends keeping website software patched, reviewing server configuration, avoiding insecure permissions and using secure protocols such as SSH and SFTP instead of unencrypted FTP.

This is also why simply reinstalling an old backup can fail. If the vulnerable plugin or compromised credential remains, the restored website can be attacked again.

Update everything after recovery

Once you have a trustworthy installation, update the software that powers it.

For a WordPress site, that normally means reviewing:

• WordPress core
• Plugins
• Themes
• PHP
• Server software where applicable
• Security tools
• Third-party integrations

Remove software that is no longer needed rather than leaving unused components installed indefinitely.

SiteGround notes that website security depends partly on keeping applications updated and says that even server-level protections cannot replace ongoing attention to web applications.

Check Google Search Console after the cleanup

A hacked website can have consequences beyond the server itself.

Attackers may insert spam pages, phishing content or malicious scripts. Google may detect such content and warn users before they reach the website.

After cleaning the website:

1. Open Google Search Console.
2. Review the Security Issues report.
3. Check for suspicious indexed pages.
4. Inspect important URLs.
5. Confirm that the malicious content has actually disappeared.
6. Request a security review when Google reports a security issue and the site has been cleaned.

Google says security reviews are appropriate after the underlying problem has been fixed; reviews can take several days.

Do not treat a temporary disappearance of the warning as proof that the underlying vulnerability has been fixed.

What if the website keeps getting hacked?

Repeated reinfection is an important clue.

If malicious files return after you have removed them, investigate the possibility that:

• A hidden backdoor remains
• An administrator account is still compromised
• Hosting credentials were not changed
• SFTP or SSH credentials remain exposed
• A vulnerable plugin or theme is still installed
• Another website in the same environment has been compromised
• A scheduled task is restoring the malware
• The backup itself contains the malicious code

At that point, repeatedly deleting individual files is usually less useful than determining how persistence is being maintained.

Your hosting provider can also investigate server-level information that may not be visible from WordPress. Google recommends contacting the hosting company when dealing with malware, while WordPress specifically advises checking with the host because a compromise can affect more than one website in a shared environment.

For sites where downtime, lost revenue or customer-data exposure is significant, professional incident-response assistance can be appropriate.

Hosting matters more than many site owners realize

Website security is shared between the website owner and the hosting environment. A host can provide useful protections such as infrastructure monitoring, isolation, backups, firewalls and malware detection, but it cannot compensate for every vulnerable plugin, stolen password or neglected administrator account.

For example, SiteGround currently describes distributed backups, server-level threat blocking, WordPress security controls and its Site Scanner malware-monitoring service as parts of its hosting security infrastructure. Its backup documentation also states that automatic backups are created for hosted sites, with restoration of entire sites or individual components available through its platform, although features vary by plan.

If you are rebuilding or moving a website after an incident, it is worth comparing what the hosting provider actually supplies rather than assuming every host offers the same recovery capabilities.

Secure the website after recovery

Recovery should end with a stronger configuration than the one that was compromised.

For a WordPress website, that generally means:

• Enable multifactor authentication for privileged accounts.
• Keep core software, plugins and themes updated.
• Remove abandoned or unnecessary components.
• Limit administrator accounts.
• Use strong, unique credentials.
• Prefer SFTP or SSH over insecure FTP.
• Maintain automated backups.
• Keep at least one backup independent of the live hosting environment.
• Monitor for unexpected changes.
• Use malware and security monitoring where appropriate.
• Review access permissions periodically.
• Keep the administrator’s computers protected and updated.

Google recommends secure protocols, current software, appropriate server configuration and regular monitoring, while WordPress emphasizes access control, backups, updates and post-incident hardening.

Backups deserve particular attention. A backup that exists but has never been tested is not the same as a demonstrated recovery capability. Periodically verify that you can actually restore the files and database you depend on.

When you should bring in a professional

You do not necessarily need a security specialist for every hacked personal website. But professional help becomes increasingly valuable when:

• Customer or payment information may have been exposed
• The attacker had server-level access
• The website repeatedly becomes infected
• You cannot determine how the attacker entered
• Important logs may need forensic analysis
• Multiple websites share the affected hosting environment
• The site is business-critical
• You suspect stolen credentials beyond the website itself
• Legal, regulatory or contractual reporting obligations may apply

In those circumstances, preserving evidence before performing extensive cleanup can matter as much as getting the website back online.

The recovery is not finished when the homepage looks normal

A website that displays normally can still be compromised. The meaningful recovery milestone is not simply that the homepage loads again; it is that the malicious access has been removed, the vulnerable component or credential has been addressed, the installation has been verified, and the surrounding accounts and hosting environment have been secured.

The most important question after a hack is therefore not “How do I remove the hacked page?” but “How did the attacker obtain and retain access?” If you can answer that question with reasonable confidence, restore from a trustworthy point, close the entry route, rotate exposed credentials, verify the site and monitor it afterward, you have moved from cosmetic repair to genuine recovery.