If your website was hacked—or you have good reason to think it was—document the symptom, stop further harm, contact the host and technical owner, preserve the current state, rotate exposed access from a clean device, remove both the malicious changes and the entry point, restore only from a known-clean source, test the real business journeys, and watch for reinfection. Do not start deleting random files or blindly restore the newest backup. Panic is understandable. Panic with administrator access is how one problem becomes three.
TL;DR: What to do when your website is hacked
- Record what happened. Capture screenshots, affected URLs, warnings, account changes, times, time zone, recent updates, and who noticed the problem.
- Protect people and operations. If the site is redirecting visitors, stealing credentials, serving malware, exposing personal information, or processing transactions unreliably, restrict public access or replace it with a clean temporary response.
- Call the right owners. Contact the hosting provider, website maintainer, domain and DNS owner, payment provider when relevant, and qualified security or legal help when data exposure may be involved.
- Preserve before you purge. Save logs, alerts, account lists, database and file copies, server details, and the compromised state before cleanup when it is safe to do so.
- Rotate access from a clean device. Change hosting, CMS, SFTP/SSH, database, domain, DNS, email, API, and integration credentials that may be exposed. Revoke sessions, unknown users, keys, and tokens.
- Find the entry point, not only the graffiti. Removing a spam page is not recovery if the stolen password, vulnerable plugin, malicious administrator, scheduled task, or backdoor still works.
- Restore carefully. A backup is useful only if it is complete, old enough to be clean, recent enough to be useful, and restored into an environment you can trust.
- Verify and monitor. Test forms, payments, logins, email, analytics, search visibility, mobile pages, permissions, updates, and security monitoring before declaring victory.
If customer, employee, payment, health, financial, or other sensitive information may have been exposed, stop treating this as a normal website repair. Bring in qualified incident-response and legal professionals, check cyber-insurance requirements, and determine the notification obligations that apply to the actual incident and jurisdiction.
In this recovery guide
How can you tell whether a website was hacked?
A hacked website does not always arrive wearing a skull-and-crossbones homepage. Sometimes it is obvious. Sometimes the public site looks perfectly normal while search engines see pharmacy spam, an attacker quietly receives form submissions, or an unauthorized administrator waits for the next opportunity.
The useful question is not “Does this look weird?” It is “What evidence suggests an unauthorized change, access, or use of the system?” The official WordPress hacked-site guidance calls these indicators of compromise. One indicator may be a technical failure or configuration mistake. Several related indicators—or one unambiguous unauthorized change—deserve immediate investigation.
Search engines or browsers show a security warning
Google Search, Chrome, other browsers, hosting companies, malware scanners, and security vendors may flag the site as dangerous, deceptive, hacked, or infected. Google Search Console’s Security Issues report can show detected issue types and example URLs. Treat the alert as evidence to investigate, not as a complete diagnosis of every affected file or account.
A warning can crush traffic because visitors are correctly being told not to trust the site. Do not request a review simply because someone deleted the most visible bad page. Clean the compromise, close the entry point, verify the site, and then request the appropriate review.
Visitors are redirected somewhere they did not choose
Unexpected redirects to gambling, counterfeit products, adult content, fake software updates, phishing pages, or another business are strong warning signs. Test from more than one device, browser, network, and entry source. Some malicious redirects trigger only on mobile, only for first-time visitors, only from search results, or only in certain locations so the site owner does not see the same behavior.
Strange pages, links, or search results appear
Search for the domain and review indexed pages, page titles, and descriptions. Unfamiliar language, pharmaceutical terms, casino pages, doorway pages, or hundreds of URLs the business never created may indicate injected content or SEO spam. Search engines may discover those pages before the owner does.
Do not assume every odd result is a hack. Old staging sites, abandoned imports, badly configured search pages, and legitimate but forgotten content can also create a mess. The difference is authorization and provenance: who created it, how, and whether the system was supposed to do that.
Unknown users, administrators, keys, or integrations appear
Review CMS users, hosting users, SFTP and SSH access, database users, domain and DNS access, API keys, application passwords, webhooks, payment integrations, email services, and deployment systems. An unfamiliar administrator or token is not “probably from an old plugin.” It is an access path until proven otherwise.
Also look for legitimate accounts with permissions they no longer need. Attackers do not always create a new identity; they may use a contractor’s old account, a reused password, or a mailbox that controls password resets.
Files, settings, templates, or scheduled jobs changed without authorization
Unexpected file modifications, unfamiliar plugins or themes, altered .htaccess or server rules, injected scripts, modified templates, rogue scheduled tasks, new cron jobs, disabled security controls, and unexplained configuration changes all deserve investigation. File timestamps help, but they are not proof by themselves because deployments, cache systems, backup tools, and attackers can change them.
Forms, email, payments, or business workflows behave differently
A compromise may show up as contact-form messages going to an unfamiliar address, orders changing destination, payment scripts loading from a new domain, password-reset emails nobody requested, legitimate mail suddenly being rejected, or customers receiving messages the business did not send.
These are not side effects to fix after the “website” is cleaned. They may be the business impact. Preserve records and involve the relevant providers before evidence or transaction history disappears.
The host reports malware, abuse, spam, or unusual resource use
Hosts may suspend a site, flag malicious files, report mass email, detect abusive outbound traffic, or show sharp CPU and storage changes. A traffic spike alone is not proof of a hack; a viral post, crawler, marketing campaign, denial-of-service attempt, or analytics bug can look similar. Correlate the host’s evidence with logs, files, users, requests, and recent changes.
The website becomes slow, broken, or unavailable
Slowness and downtime are symptoms, not verdicts. A bad update, exhausted hosting plan, database failure, cache problem, DNS error, expired domain, or broken integration can take down a site without an attacker touching it. Start with the incident facts. Do not diagnose a cyberattack because the spinner looked menacing.
The TRACE hacked-website recovery process
Scope Design uses a simple decision framework for the first response: TRACE—Triage, Restrict, Archive, Clean, Exercise. It keeps the business from confusing visible cleanup with verified recovery.
| TRACE stage | Immediate question | Evidence of completion |
|---|---|---|
| Triage the signal | What happened, when, where, and to whom? | Incident timeline, symptoms, affected URLs and systems, named response owner |
| Restrict further harm | What must stop now to protect people, data, money, and connected systems? | Safe containment decision, access restrictions, provider escalation, clean temporary service where appropriate |
| Archive evidence and current state | What will we need to understand scope, recover, make a claim, or meet an obligation? | Preserved logs, alerts, account state, file/database copy, transaction and communication records |
| Clean the compromise and close the entry point | What changed, how did access occur, and what persistence remains? | Malicious artifacts removed, access rotated, vulnerable path repaired, unauthorized accounts and tasks removed |
| Exercise recovery and watch for reinfection | Can the actual business safely operate, and will we notice if the attacker returns? | Tested journeys, verified monitoring, search review, clean scans, documented watch period and lessons |
T — Triage the signal
Start an incident record before changing the system. Include:
- the exact warning, behavior, or unauthorized change;
- affected URLs, accounts, forms, transactions, devices, and services;
- when it was first noticed, including time zone;
- who noticed it and how;
- recent plugin, theme, hosting, DNS, content, or account changes;
- alerts from Google Search Console, browsers, the host, payment services, email providers, or security tools;
- whether sensitive information or money may be involved;
- who owns the response and who can authorize containment.
This sounds bureaucratic until six people make changes in three dashboards and nobody can remember what the site looked like twenty minutes ago. WordPress makes documentation the first actionable step for good reason.
Triage also separates a compromise from an ordinary technical failure. Confirm the domain and hosting are paid, DNS resolves correctly, certificates are valid, the server is running, and recent deployments or updates did not cause the symptom. If the evidence still points to unauthorized behavior, proceed as an incident.
R — Restrict further harm
Containment is a business-risk decision, not an automatic “flip the whole internet off” rule. The right response depends on what the site is doing.
If visitors are being redirected to malware, credentials may be captured, payment pages are untrustworthy, personal information is publicly exposed, or the attacker is actively changing the system, public service may need to be restricted immediately. A clean temporary site or correctly configured 503 Service Unavailable response can be safer than leaving a compromised application online. Google’s hacked-site recovery guidance likewise recommends temporarily taking a compromised site offline while it is being fixed.
If the suspected problem affects one isolated function, the team may be able to disable that function while preserving safe parts of the business. Coordinate with the host and incident specialist before shutting down or rebooting evidence-sensitive systems. The FTC specifically warns businesses not to destroy forensic evidence during remediation.
Contain connected access too. Revoke suspicious sessions, disable unknown users, restrict compromised integrations, and rotate relevant credentials from a device believed to be clean. An infected laptop or compromised email account can hand the new password straight back to the attacker.
Prioritize accounts with the power to reset or rewrite everything else:
- primary email and identity accounts;
- domain registrar and DNS;
- hosting and cloud control panels;
- CMS administrators;
- SFTP, SSH, deployment, and database access;
- payment, ecommerce, CRM, email-delivery, analytics, and API credentials.
Use unique credentials and multifactor authentication where supported. Remove unknown accounts and revoke active sessions. Do not delete the records of those accounts before preserving what you may need to understand the incident.
A — Archive evidence and the current state
Before cleanup, preserve enough information to investigate and recover. That may include:
- screenshots and exact warning text;
- server, application, firewall, authentication, email, DNS, payment, and security logs;
- CMS user and role lists;
- active plugins, themes, integrations, keys, and scheduled tasks;
- a copy of files and database in their compromised state;
- file hashes, modification times, and detected malware paths;
- hosting and network details;
- orders, form submissions, exports, or other business records that may change during restoration;
- a timeline of every action the response team takes.
A compromised backup is not the one you restore into production, but it can still be valuable evidence and a reference for recent legitimate data. Store it safely with access limited to the response team.
If the incident may involve regulated or personal information, litigation, law enforcement, a cyber-insurance claim, or a contractual reporting duty, do not improvise evidence handling from a blog post. Contact the appropriate insurer, counsel, and incident-response professionals early. Insurance policies sometimes require prompt notice or approved vendors before work begins.
C — Clean the compromise and close the entry point
Cleanup has two jobs:
- remove the attacker’s code, content, accounts, jobs, and persistence; and
- remove or control the route that allowed the compromise.
Completing only the first job is digital whack-a-mole.
On WordPress, investigation may include core files, plugins, themes, uploads, must-use plugins, configuration files, server rules, scheduled tasks, database content, administrator accounts, application passwords, and hosting-level access. Compare WordPress core and repository-hosted extensions with trusted originals where possible. Replace compromised software from known-good sources instead of attempting to prettify malicious code line by line.
The entry point may be an outdated extension, abandoned component, stolen administrator credential, compromised email account, reused password, infected workstation, exposed key, vulnerable custom code, weak hosting isolation, or unauthorized vendor access. Sometimes the original evidence is incomplete and the exact route cannot be proven. Say that honestly, then close every plausible access path supported by the evidence.
Do not treat a remote scanner as a complete cleanup certificate. A public scanner sees what an outside visitor receives. It may catch warnings, injected scripts, and known malware behavior, but it usually cannot prove the database, server, user list, private files, scheduled tasks, or connected accounts are clean.
E — Exercise recovery and watch for reinfection
Recovery is not “the homepage loads.” It is the return of trustworthy business operation.
A clean backup can accelerate recovery, but answer four questions first:
- Complete: Does it include the necessary files, database, configuration, uploads, and business data?
- Clean: Was it created before the compromise, and has it been checked for malicious accounts, code, content, and persistence?
- Current enough: What orders, leads, content, users, or transactions would be lost by restoring it?
- Safe destination: Are you restoring into an environment with repaired access, updated software, and a closed entry point?
Blindly restoring yesterday’s backup can restore yesterday’s backdoor. Restoring a month-old backup can erase a month of business. A thoughtful recovery may rebuild application files from trusted sources, import carefully reviewed business data, and reconcile transactions created after the clean recovery point.
Before reopening, test the journeys that matter:
- public pages and navigation on mobile and desktop;
- administrator access and permissions;
- contact, quote, signup, and support forms;
- ecommerce cart, checkout, payment, tax, shipping, refunds, and transactional email;
- login, password reset, memberships, portals, and file access;
- analytics, advertising tags, consent controls, CRM, webhooks, and API integrations;
- site search, redirects, canonical tags, robots rules, sitemaps, and structured data;
- backups, monitoring, alerts, and the response contact path.
Then maintain heightened monitoring. Watch for new files, unexpected users, recurring spam URLs, redirects, authentication anomalies, outbound email, resource spikes, Search Console warnings, and the same indicators that triggered the response. Reinfection often means the entry point or persistence was missed—not that the attacker possesses supernatural keyboard powers.
How do you recover Google visibility after a website hack?
Open Google Search Console and review Security Issues, Manual Actions, indexed pages, sitemaps, and performance changes. Record example hacked URLs before cleanup. Search the domain for injected titles and pages, but remember that a normal search does not show everything Google knows.
After the site is clean and the vulnerability is closed:
- ensure malicious pages return the appropriate status or clean canonical content;
- restore legitimate pages and internal links;
- confirm robots rules and accidental
noindexsettings are not blocking recovery; - submit a current sitemap when appropriate;
- request a review through the relevant Search Console security workflow;
- monitor warnings, indexed spam URLs, crawl behavior, impressions, and branded results.
Google says its Security Issues report can provide the detected issue type and example URLs, and that site owners can request a review after cleaning the site and closing the security holes. A review request is not a substitute for cleanup, and repeatedly submitting one against a still-compromised site is not a strategy.
Search recovery can lag technical recovery because crawlers need to revisit pages and warning systems need to re-evaluate the site. Do not promise an exact clearance date. Document the request, monitor status, and keep the site stable and clean.
When does a hacked website become a data-breach problem?
A hacked website and a legally reportable data breach are not identical, but they can overlap. The incident deserves legal and forensic escalation when there is credible reason to believe an unauthorized party accessed, altered, exposed, or took personal, regulated, confidential, or payment-related information.
Examples include:
- a malicious checkout or payment script;
- exposed customer, employee, health, identity, or financial records;
- stolen form submissions or account credentials;
- unauthorized database access;
- public posting of private information;
- compromise of systems connected to the website;
- contractual or insurance requirements triggered by the incident.
The FTC’s data-breach response guide advises businesses to secure operations, stop additional data loss, preserve evidence, investigate the scope, fix vulnerabilities, develop a communication plan, and determine applicable notification requirements. The laws depend on the information, people, business, and jurisdiction. Scope Design can help coordinate website operations and technical ownership, but it does not replace breach counsel or a qualified forensic investigator.
Do not publish confident statements before the facts are understood. Do not hide material facts that affected people need to protect themselves. And do not let the marketing department write incident law because the homepage CMS was nearby.
What Scope Design can—and cannot—own
Scope Design’s practical role includes managed WordPress maintenance, controlled updates, backups, uptime and operational monitoring, compatibility checks, targeted rollback, website troubleshooting, and coordination across the website’s owners and providers. That work helps reduce risk and makes recovery less chaotic.
It is not a 24/7 security operations center, a forensic laboratory, penetration-testing practice, breach-law firm, insurer, or law-enforcement agency. Serious incidents may require several specialists. A trustworthy website partner should recognize that boundary early instead of cosplaying as the FBI because a malware plugin found a suspicious file.
The broader website security guide explains the ongoing LOCKED program for ownership, access, updates, monitoring, backups, and rehearsed response. The WordPress plugin update guide explains controlled updates and rollback. The website maintenance guide assigns the recurring operational work, while Scope Design’s WordPress maintenance services guide explains what managed support should actually include.
Hacked website recovery checklist
| Decision | Confirm before closing the incident |
|---|---|
| Scope | Affected sites, accounts, data, integrations, devices, and providers have been identified as far as the evidence allows |
| Containment | Harmful public behavior and unauthorized access have been restricted without casually destroying evidence |
| Access | Relevant credentials, sessions, keys, users, roles, and provider access have been reviewed and rotated |
| Cleanup | Malicious code, content, accounts, jobs, redirects, and database changes have been removed |
| Root cause | The confirmed or plausible entry path has been repaired, removed, patched, or tightly controlled |
| Recovery | The restored system comes from trusted sources and reconciles necessary current business data |
| Testing | Forms, payments, email, logins, permissions, integrations, mobile pages, analytics, and search controls work |
| Search | Security warnings, hacked URLs, sitemaps, indexing, and review requests have been handled |
| Obligations | Insurance, legal, regulatory, contractual, law-enforcement, and communication decisions have named owners |
| Monitoring | Reinfection indicators, access changes, file changes, uptime, backups, and business journeys are being watched |
| Learning | The inventory, maintenance plan, access policy, backups, monitoring, and incident procedure have been updated |
Frequently asked questions about hacked websites
What are the most common signs a website has been hacked?
Common signs include browser or search-engine warnings, unfamiliar redirects, injected pages or links, unknown administrators, unauthorized file or configuration changes, unexpected password resets, altered form or payment behavior, spam email from the domain, host malware alerts, and suspicious scheduled tasks. Slowness or downtime alone is not proof; correlate symptoms with logs and unauthorized changes.
What should I do first if my website is hacked?
Document the exact symptom and time, name the response owner, protect visitors and connected systems from further harm, contact the host and technical owner, and preserve relevant evidence before deleting or restoring anything. If sensitive data may be involved, notify qualified legal, forensic, security, and insurance contacts immediately.
Should I take a hacked website offline?
Restrict public access when the site may harm visitors, capture credentials or payments, expose personal information, distribute malware, or remain under active attacker control. A clean temporary response may preserve safe business communication. Coordinate evidence-sensitive shutdown decisions with the host and incident professionals; the right containment depends on the incident.
Can I check whether my website is hacked myself?
You can review Google Search Console, browser warnings, host alerts, users, recent changes, public pages, indexed URLs, file changes, and reputable remote scans. Those checks are useful but cannot prove the private server, database, accounts, tasks, and integrations are clean. Escalate when the evidence, data, or business risk exceeds your expertise.
Can a malware scanner prove my website is clean?
No single scan proves the whole system is clean. Remote scanners inspect public behavior; application scanners have access only to what their permissions and signatures reveal. Verification may require file and database comparison, account review, log analysis, scheduled-task inspection, configuration review, root-cause repair, business-journey testing, and continued monitoring.
Can I restore a hacked website from a backup?
Often, but the backup must be complete, clean enough, current enough, and restored into a trustworthy environment after the entry point is closed. A blind restore can reintroduce malware or erase recent orders and leads. Preserve current business data and reconcile it deliberately.
How do hackers get into WordPress websites?
Common routes include stolen or reused credentials, compromised email accounts or devices, outdated or abandoned plugins and themes, vulnerable custom code, excessive permissions, exposed keys, insecure hosting or deployment access, and forgotten vendor accounts. The specific cause must come from evidence; guessing “it was WordPress” is not a root-cause analysis.
Should I change passwords before or after cleaning the site?
Use a clean device to rotate credentials needed for immediate containment, revoke sessions, and stop unauthorized access. After cleanup, rotate them again where the incident plan calls for it, because credentials used while the system was still compromised may have been captured. Include hosting, CMS, domain, DNS, SFTP/SSH, database, email, API, and integration access as relevant.
How long does hacked website recovery take?
There is no honest universal estimate. A simple injected file with a known clean backup and confirmed entry point may be resolved quickly. A compromise involving multiple accounts, ecommerce, personal data, an unknown timeline, poor logs, or persistent backdoors can take far longer. Scope and evidence determine the work.
How do I remove Google’s hacked-site warning?
Use Google Search Console to review the Security Issues report and example URLs. Remove the compromise, close the vulnerability, verify the site, and then request a review through the appropriate workflow. Continue monitoring indexed spam URLs and search results while Google recrawls and re-evaluates the site.
Is a hacked website automatically a data breach?
Not automatically. A compromise becomes a potential data-breach matter when unauthorized access, acquisition, alteration, or exposure may involve protected or sensitive information. Because definitions and duties vary, preserve evidence and consult qualified counsel and incident professionals rather than making the legal determination from a generic checklist.
Will updating WordPress remove malware?
No. Updating supported software can close known vulnerabilities and replacing trusted core or extension files can remove some malicious changes, but an update does not necessarily remove database injections, unknown users, stolen credentials, scheduled tasks, backdoors, compromised devices, or malicious integrations. Cleanup and root-cause repair are separate jobs.
How do I prevent the website from being hacked again?
Close the incident’s entry point, remove unnecessary accounts and software, use unique credentials and multifactor authentication, keep supported components current, control changes, maintain separate restorable backups, monitor access and file changes, watch critical business journeys, document ownership, and rehearse the response. Perfect safety is fiction; reducing likelihood, blast radius, and recovery time is the real job.
The useful definition of recovered
A hacked website is not recovered because the ugly redirect disappeared. It is recovered when the harmful behavior has stopped, the unauthorized access and persistence have been removed, the entry path has been closed, the necessary business data is intact, the important journeys work, search warnings are being resolved, obligations have owners, and monitoring can catch a return.
That is less dramatic than “deploy AI-powered cyber defense.” It is also how grown-ups get the business safely back online.
