A hacked website does not always show an obvious warning. Visitors may see spam, a fake login page, or an unexpected redirect—or they may notice nothing while an attacker quietly uses the site to access data or maintain control. Knowing what happens when a website gets hacked helps owners respond quickly without destroying evidence or restoring the problem along with the site.
This guide walks through common ways attackers gain access, what they may do afterward, and how to contain an incident, preserve evidence, rotate credentials, and recover safely.
Key takeaways
- A compromise may affect the website’s files, hosting account, database, administrator accounts, DNS, or connected services—not just the visible pages.
- Contain the incident and preserve useful evidence before making changes, when it is safe to do so.
- Rotate credentials and revoke active sessions from a trusted, clean device. Include hosting, email, database, and third-party service access.
- Restore from a known-clean backup only after addressing the likely entry point and checking that the backup is safe.
- Contact your host, relevant service providers, and qualified incident responders when the scope or impact is unclear.
What happens when a website gets hacked?
A website compromise is usually a sequence of events, not a single visible change. An attacker first gains some form of access, then may change the site, steal or alter data, create additional ways to get back in, or use the site to affect visitors. The activity can be brief or persist unnoticed.
The actual impact depends on the attacker’s access and the site’s architecture. A compromised content-management account may let someone publish unauthorized pages. Access to the hosting account can expose files and databases or allow changes across multiple sites. Access to DNS or a domain registrar can redirect visitors without changing the website’s files at all.
A defaced homepage is therefore only one possible sign. Other clues include unfamiliar administrator accounts, unexpected password-reset emails, modified files, new scheduled tasks, unexplained traffic, or reports that visitors are being sent elsewhere.
How attackers commonly gain initial access
Common entry points include:
- Stolen or reused credentials: Passwords exposed elsewhere, shared accounts, or missing multi-factor authentication can put administrative, hosting, or email accounts at risk.
- Unpatched software: A vulnerable content management system, plugin, theme, server component, or other dependency may provide an opening.
- Compromised devices or accounts: A developer’s workstation, email account, or deployment credential can provide access to site infrastructure.
- Misconfiguration: Excessive permissions, exposed secrets, or an incorrectly configured storage or administration service can make unauthorized access easier.
- Third-party access: A vendor or integration with access to the site may itself be compromised.
These are broad patterns, not a diagnosis. An unusual page or redirect does not prove which route was used. Confirming the entry point usually requires reviewing account activity, server and application logs, deployment records, and information from the hosting provider.
What an attacker may do after getting in
After gaining access, an attacker may make visible changes, such as inserting spam or replacing page content. They may also make less obvious changes: create an unauthorized account, alter site code, add a mechanism for later access, or change settings that affect users.
Depending on the permissions involved, an incident may also expose customer or business information, interfere with site availability, or affect connected services. For example, a compromised email account can be as important as a compromised web server because it may be used to reset other passwords.
Do not assume that removing the visible symptom removes the compromise. Deleting one suspicious file or restoring one page may leave other unauthorized changes, stolen credentials, or access through a different account.
What to do first: contain the incident and preserve evidence
Respond in a deliberate order. If the site is actively harming visitors or exposing sensitive information, reducing that harm is the priority. When feasible, preserve relevant records before making changes that could erase them.
- Use a trusted device and communication channel. Avoid investigating or changing credentials from a device you suspect may be compromised. Use a separate, trusted device and secure communications for incident coordination.
- Contact your hosting provider and relevant service providers. Ask for help restricting access, preserving logs, and identifying affected systems. If a developer, agency, or managed service operates the site, notify them through a verified channel.
- Limit access and exposure. Depending on the situation, this may mean taking the site offline, putting it into a maintenance mode, restricting administrative access, or asking the host to isolate the affected environment. Choose measures with your provider when possible; abrupt changes can affect evidence or business operations.
- Preserve evidence. Record when the issue was noticed and what was observed. Save relevant provider, web server, application, authentication, DNS, and deployment logs where available. Preserve a copy or snapshot of affected systems before cleanup if this can be done safely, and note who collected it and when.
- Keep a response log. Track actions, timestamps, decisions, people involved, and the systems changed. Use UTC consistently when comparing records from different services.
Logs may be incomplete, overwritten, or retained only briefly by a provider. Ask about retention promptly. Avoid publishing detailed incident evidence publicly while the investigation is ongoing, especially if it contains personal information, credentials, or sensitive infrastructure details.
Remove unauthorized access and rotate credentials
Once immediate containment and evidence preservation are addressed, reset access from a clean device. Prioritize accounts that can control the website or reset other accounts:
- Hosting, cloud, domain registrar, and DNS accounts
- Website administrator and database accounts
- Email accounts used for administration or password recovery
- Deployment, source-control, and continuous-integration accounts
- API keys, tokens, application passwords, and integration secrets
Use unique passwords and multi-factor authentication where available. Revoke active sessions, access tokens, and unrecognized application authorizations; changing a password alone may not invalidate every existing session or credential. Replace any secret that was stored on a potentially affected server or device, and update the systems that depend on it. Remove unfamiliar accounts only after documenting them and understanding their role in the investigation.
Coordinate these changes with your host or incident responder if you are unsure which credentials are affected. A rushed reset can lock out legitimate administrators or disrupt services, while changing credentials on a compromised device may expose the new ones.
Restore the site from a known-clean state
Restoration is not just a file upload. Before bringing the site back into service:
- Identify and address the likely entry point—for example, update vulnerable software, remove an unnecessary account, or correct a risky configuration.
- Choose a backup from before the compromise, and check that it does not contain the unauthorized change. A backup’s age alone does not establish that it is clean.
- Rebuild or restore the affected environment using trusted files and dependencies where practical. Have a qualified responder review the scope if you cannot determine which systems were touched.
- Apply security updates and restore only necessary data and configuration. Treat databases, uploaded files, and secrets as potentially affected until assessed.
- Test important functions before reopening the site, including sign-in, forms, checkout, email delivery, and integrations.
- Monitor logs and account activity after recovery for renewed suspicious behavior.
A backup can speed recovery, but it does not explain how access was gained. Restoring without fixing the entry point can lead to another compromise.
Check what visitors may be seeing
After unauthorized changes are removed, review the site’s pages and settings for injected content, altered links, and unexpected redirects. Check more than the homepage: inspect key landing pages, forms, and pages that receive traffic from email or advertising. Ask your hosting provider or incident responder to check the server-side configuration and logs as well.
A URL inspection tool can help you examine a link’s destination or redirect behavior during triage. For example, check a URL’s redirects to see where a particular link leads. This is only a way to inspect a URL; it cannot determine whether a server is compromised or replace a security review of your hosting environment.
Common mistakes that make recovery harder
- Deleting everything immediately: Cleanup before preserving available logs or snapshots can remove useful evidence. If urgent containment is necessary, prioritize safety, but document what you change.
- Fixing only what is visible: A defaced page or suspicious redirect may not be the only unauthorized change.
- Changing passwords from an untrusted device: A compromised device may capture replacement credentials.
- Restoring without fixing the cause: A clean-looking backup does not help if the vulnerable software or exposed account remains available.
- Assuming the host has investigated every part of the business: A hosting provider can assist with its own systems, but you may also need to investigate email, devices, DNS, source control, and third-party accounts.
- Sharing incident details too widely: Publicly posting logs or screenshots can reveal private data or operational details. Share evidence only with people who need it and through appropriate channels.
Preventing a repeat incident
No single control guarantees that a site cannot be compromised. These practices reduce common risks and make response easier:
- Keep the content management system, plugins, themes, server software, and dependencies maintained; remove components that are no longer needed.
- Use unique credentials, multi-factor authentication, and separate named accounts rather than shared administrator logins.
- Grant users and integrations only the access they need, and review permissions periodically.
- Protect administrator, hosting, email, DNS, and registrar accounts—not only the website login.
- Store secrets in an appropriate secrets-management system, restrict access, and rotate secrets when exposure is suspected.
- Maintain backups that are protected from routine modification, and test that you can restore them.
- Keep useful logs and know how to obtain them from your hosting and other service providers.
- Prepare a basic response plan with contact details, decision-makers, backup locations, and steps for taking the site offline safely.
For organizations handling sensitive information or facing a complex incident, engage qualified incident-response professionals. Legal, privacy, and regulatory notification obligations depend on the facts and jurisdiction; consult appropriate counsel rather than guessing.
Conclusion
When a website gets hacked, the visible page is only part of the story. The compromise may involve accounts, infrastructure, data, or connected services. A careful response prioritizes visitor safety, containment, evidence preservation, credential rotation, and restoration from a verified clean state. After recovery, address the likely entry point and improve monitoring and preparation so the next incident is easier to detect and manage.