If you are wondering what to do before bringing a hacked website back online, treat the return to public access as a decision to verify, not a switch to flip as soon as the homepage looks normal. Suspicious redirects, injected pages, or unfamiliar changes can point to unauthorized access that is still active or hidden elsewhere.
Work through the incident in a deliberate order: contain the problem, preserve useful evidence, determine what may be affected, remove the cause, review access, and test the result. If your team does not have the technical experience to investigate safely, coordinate with your web host and a qualified security professional.
Contain the issue and preserve what you can
If visitors are being sent to harmful or misleading pages, or the site is actively changing, limit public access while you investigate. Depending on the site and its setup, that may mean using a maintenance page, restricting access, or asking your host to isolate the affected environment. The goal is to reduce risk to visitors without destroying information that could help identify what happened.
Before deleting files or restoring a backup, preserve a copy of the current site and relevant logs if you can do so safely. Record what you observed, when you noticed it, which pages or visitors appear affected, and any changes already made. Avoid repeatedly editing the site during the investigation. Uncoordinated changes can make it harder to understand the issue or tell whether the cleanup worked.
Use a trusted device and communication channel for incident work. If a work computer or email account may also be compromised, do not rely on it to reset sensitive credentials or coordinate recovery.
Find the scope and the likely entry point
A redirect on the homepage may be only the visible symptom. Review important pages and site functions, including forms, account areas, checkout or booking pages, and content that visitors reach from search results. Check the site’s files and database for unfamiliar changes, and ask the host to review relevant activity and access logs.
Consider what changed before the issue appeared. Review recent updates, new users, installed extensions or plugins, themes, deployment changes, and third-party integrations. If the site uses a content management system such as WordPress, check the platform, extensions, and themes as part of the investigation. The purpose is not just to remove suspicious code, but to understand how it may have arrived and whether the weakness remains.
NIST’s incident response recommendations provide a framework for treating response as an organized process rather than an isolated cleanup task.
Remove malicious changes and close the foothold
Once you have preserved what is needed for investigation, have a qualified person remove malicious code and unauthorized changes from the site files and database. Review unfamiliar administrator accounts, altered settings, unexpected scheduled tasks, and other changes that could allow the attacker to return. Update or remove vulnerable and unused components, and confirm that the original entry point has been addressed.
Do not assume that replacing the homepage, deleting a suspicious file, or running a single malware scan is enough. Harmful content may be placed on less-visited pages or appear only under certain conditions. If you cannot tell what is legitimate or what has changed, ask the host or a security professional to help before making broad deletions or restoring the site.
Review every route into the website
A website’s access points extend beyond its administrator login. Make a deliberate inventory of accounts and credentials that could affect the site, including:
- Website administrator and other user accounts, including unfamiliar users and permissions.
- Hosting, control panel, file transfer, server login, and database accounts.
- Domain registrar, DNS, content delivery network, and deployment accounts.
- API keys, application secrets, active sessions, and integrations connected to the site.
- Email accounts used for password resets, alerts, or administration.
From a trusted device, change affected passwords and rotate exposed keys or secrets. Remove accounts that should not have access, review permissions, and end active sessions where the platform allows it. Enable multifactor authentication where available, especially for administrative and hosting accounts. For more on assessing access paths, see this secure remote access checklist.
Be cautious about restoring a backup
A backup is useful only if it does not put the same problem back on the site. Do not choose a copy just because it predates the day you noticed the redirect. The attacker may have gained access earlier, or the backup may contain the same vulnerable component or unauthorized change.
Work with your host or technical team to assess the backup, compare it with a known-good version where available, and check the restored files and database before opening the site to visitors. Confirm that the underlying weakness has been fixed and that account credentials and secrets have been reviewed. If you cannot establish that a backup is clean, do not treat it as proof of a safe recovery.
Recovery planning can also help a business prepare for a wider technology disruption. Zevonix has experience developing, documenting, and testing business continuity plans covering people, processes, communications, and technology resilience. You can also review these disaster recovery planning considerations.
Test before restoring public access
When the cleanup and access review are complete, validate the site in a controlled way before making it broadly available. Check more than the homepage. Visit important pages and test the functions customers and employees rely on. Use different devices and browsers, and check how pages behave when reached through different routes, such as a direct visit and a search result.
Look for redirects, unexpected content, unfamiliar links, and changes to forms or other interactions. Ask your technical team or host to review the site files, database, users, logs, and relevant scheduled tasks again. If a content delivery network or caching service is involved, confirm that old or altered content is not still being served from a cache.
After cleaning a site, review its Security issues report in Google Search Console and follow the available guidance for any issues shown. Google explains how to use the Security issues report. A clear report is helpful, but it does not replace technical checks of the site and its access points.
Restore public access in a controlled way and continue monitoring for the symptoms that led you to take the site offline. If suspicious behavior returns, contain the site again and revisit the investigation rather than assuming the earlier cleanup was conclusive.
Consider whether information may have been exposed
If the site stores or processes customer, employee, or other personal information, assess whether the incident may have exposed it. That is a separate question from whether the website now appears clean. Preserve relevant records, involve the appropriate internal decision-makers, and consult qualified security and legal professionals about next steps. The FTC’s data breach response guide for businesses offers general response considerations.
Businesses with specific compliance responsibilities should also consider their existing procedures and get qualified guidance on what applies to their situation. Zevonix provides compliance support for requirements including HIPAA and GDPR. For general planning, see this guide to small business IT compliance.
Frequently asked questions
Should I take my website offline if I think it has been hacked?
If visitors may be exposed to harmful redirects or content, limit public access while you investigate. Coordinate with your host or technical team to choose a containment approach that fits the site and preserves information needed for recovery.
How can I tell whether a website backup is clean enough to restore?
Have the backup assessed for unauthorized changes and compare it with a known-good version if one is available. Also address the likely entry point and review credentials before restoring public access. A backup’s age alone does not establish that it is safe.
What should I do if customer or employee information may have been exposed?
Preserve relevant records and involve appropriate internal decision-makers, qualified security professionals, and legal counsel. Treat the information exposure assessment as a separate workstream from technical website cleanup.
Make the go-live decision deliberately
Before reopening a hacked website, confirm that the issue has been investigated, the likely entry point addressed, access reviewed, and important pages tested. A homepage that looks normal is not enough to establish that every part of the site is clean. If your team needs help coordinating website security, access review, or recovery, Zevonix provides managed IT and cybersecurity services for businesses across the United States. You can contact the team at (904) 658-0777.