Contain active harm with the existing host, secure controlling accounts and preserve the affected state; choose checked restoration or qualified cleanup around the actual scope and data at risk.
If your WordPress site appears to be hacked, protect visitors and regain control before trying to make the homepage look normal. Contact the existing host through its official support channel, record the symptoms, restrict harmful activity and preserve a private copy before destructive cleanup. Choose restoration or specialist cleanup only after you understand the affected accounts and the data you could lose.
This guide is for a website you own or are authorized to administer. It is a researched triage workflow, not a report of a hack we cleaned or a promise of recovery. A store, membership service or site holding sensitive records needs its responsible business and technical people involved early. Do not install a collection of plugins or buy a new host as your first response.
First, choose the right response
| What you see | Do first | Avoid |
|---|---|---|
| Phishing, suspicious checkout code, malicious redirects or downloads | Ask the host to restrict affected public access promptly; involve the responsible payment or data provider where applicable | Leaving harmful pages available while waiting for a perfect backup |
| Only a broken page, slow site or failed login | Check the host’s status and recent authorized changes; collect details and investigate possible compromise | Treating a symptom alone as proof of a hack or deleting files to experiment |
| Unknown administrators, altered hosting access or several affected sites | Escalate to the host and a qualified incident handler; secure the wider account boundary | Assuming one WordPress password reset secures every service |
| Infection returns after a restore or scan | Keep the site contained and investigate surviving access or persistence | Repeating the same restore or declaring success from another empty scan |
| You cannot access the hosting account or recovery mailbox | Use the provider’s account-recovery process from a trusted device and reachable contact address | Changing DNS blindly or giving an unsolicited caller account access |
A screenshot of a warning, its address, the time and timezone, and an account-change alert are useful starting facts. A slow page alone is ambiguous. WordPress recommends recording concrete symptoms and actions so support can investigate the actual incident. Use the provider’s known website or saved contact details; do not follow a threatening email’s login link.
1. Contain active harm with the host
Tell support which site and account are affected, what visitors are experiencing and whether there are orders, sensitive forms or outgoing spam. Ask what they can restrict now, what remains running, and how to preserve the current state and available logs. Record who authorized the change and how access can be restored. If harm is active, contain it immediately; preservation and investigation can proceed alongside that work.
A maintenance page inside WordPress may rely on compromised code and is not a reliable account-isolation measure. Host-level web restrictions are one possible tool: Hostinger documents Password Protect Directories, and SiteGround documents Protected URLs. These are examples for their respective dashboards, not interchangeable instructions. Ask the host to verify the protected domain, paths and alternate addresses.
Restricting web requests does not establish that scheduled jobs, file access, other sites or a compromised hosting account have stopped. Explain any account-level symptoms to the host. If a CDN still serves affected content, include its cached copies in the containment discussion. A firewall or a hidden login URL alone does not remove an existing infection.
2. Keep evidence and recovery copies separate
Before replacing or deleting material, ask the host or incident handler to preserve a dated copy of the affected files, database and available access, error and account logs. Keep an action timeline as changes are made. Note the source account/site, capture time and timezone, available date range and who made the copy. If there is a dispute, suspected data theft or a formal investigation, ask the qualified responder how evidence should be captured and handled.
An infected copy is useful for investigating changes or recovering legitimate content; it is not a clean restore point. Store it privately outside the public website tree, limit access, and do not run its code on your everyday computer or upload its database to a public scanner or support forum. Configuration and database exports can contain credentials and personal records.
The WordPress file-backup documentation explains why downloading the website folder normally misses the database. Capture uploads, plugins, themes and relevant configuration, plus the separate database export using the host’s supported process. Do not guess the database name or overwrite another installation. Preserve account-level information with the host when the incident extends beyond WordPress.
Logs can disappear through rotation. For example, SiteGround’s dashboard shows the latest 300 access entries; support and archives may provide a different range. Ask your own host what exists and request it promptly. A short log window cannot prove when the compromise began.
3. Secure the accounts that control recovery
Identify the hosting owner, WordPress administrators, domain registrar, active DNS provider and recovery/business mailbox. These may belong to different services and people. If an attacker controls the mailbox receiving password resets, replacing only the WordPress password leaves a recovery problem. Use a known clean, updated device and the providers’ official recovery routes; involve the authorized owner when you lack the required access.
Rotate credentials suspected of exposure, remove unauthorized access and revoke active sessions through the relevant provider’s controls. Review hosting/SFTP/SSH access, privileged WordPress users and connected integrations with the responsible administrator. Preserve useful account-change evidence; do not remove a legitimate collaborator just because their username is unfamiliar. Set up supported multi-factor authentication and safe recovery methods after securing ownership.
Invalidate WordPress login cookies as well as changing passwords. Have the authorized administrator follow the WordPress hacked-site instructions to replace the authentication keys and salts in wp-config.php with fresh generated values. This logs out people using the old cookies, including you; confirm that legitimate administrators can sign in again. Use the host or specialist if you cannot safely edit the configuration. This does not revoke application passwords or access to separate services.
WordPress application passwords are separate integration credentials. Review and revoke exposed or unneeded ones; browser logout does not replace that check. Hosting API tokens, SSH keys and mail-provider access require their own review. Database-password changes need a coordinated configuration update; do not change one side and strand the site. Ask the host or specialist to handle a step you cannot safely complete.
Also check Search Console Settings → Users and permissions with the legitimate property owner. Remove unauthorized access and inspect Unused ownership tokens: a removed verified owner can regain access while their token remains. Follow the removal instructions for that token and preserve legitimate ownership. Tokens can also support other Google services, so identify their purpose before deleting a file, tag or DNS record.
Do the urgent access work early. After cleanup, reassess and replace credentials that may have been exposed while malicious code was still present. Record the access you revoked and confirm legitimate integrations again. Our domain-account ownership guide helps map control, while the domain and email guide explains why changing DNS can disrupt a separate mailbox. Do not transfer the domain or replace MX records as a generic malware fix.
4. Choose restoration or cleanup around the data at risk
| Situation | Useful route | Check before replacing anything |
|---|---|---|
| A plausible earlier backup exists | Inspect it and rehearse restoration in an isolated recovery environment | Its date, files/database coverage, infection indicators and the newer orders or content it omits |
| No trustworthy restore point or important newer records | Preserve the current state and use a competent cleanup/recovery operator | What can be repaired or selectively recovered without reintroducing infected material |
| The hosting account or multiple installations are affected | Coordinate broader recovery with the host and incident handler | Other sites, account access, scheduled tasks, email and the consequences of an account restore |
Yesterday’s backup may already contain an older infection. A date before you noticed the symptom is only a clue, not proof that it predates compromise. The WordPress backup handbook treats files and database as a matching recovery set. Use our restore-rehearsal guide to check recovered content and workflows rather than trusting a completed download.
Recover suspected material only in a suitably isolated environment arranged by the host or specialist, with its own storage and database. Keep real emails, payments, webhooks and scheduled tasks disabled. Password protection or noindex alone does not prevent copied malicious code from running or making outbound connections. A beginner should not launch an infected clone on an ordinary laptop to see what happens.
Namecheap’s cPanel incident guidance warns that a partial restore can miss malicious files or scheduled jobs elsewhere, while a full account restore can replace recent website data and email. That is a provider-specific reason to agree the scope and preserve newer legitimate records first. Reconcile recent orders with the responsible system or payment provider; do not replay real transactions as a restoration test.
5. Use free tools carefully; stop at your skill boundary
Start with the host’s included help and tools. A capable administrator may combine preserved copies, documented scans, file comparisons, account review and controlled restoration without buying another subscription. If you cannot distinguish an authorized customization from injected code, or cannot recover an accidental deletion, stop the destructive part and seek help.
Wordfence Free includes a scanner and firewall, with new rules and malware signatures delayed by 30 days compared with Premium. Neither that delay nor a paid license establishes whether this site is clean. Use the actual findings and coverage. Do not install several overlapping security plugins during an incident without a compatibility and rollback plan.
Wordfence’s repair action replaces eligible WordPress core or repository plugin/theme files with originals; it can remove legitimate customizations. Read each result, preserve the original and understand what will change. Do not bulk-delete all flagged files, remove the uploads folder or search-and-replace the whole database. A suspicious string or recent modification time is not sufficient evidence to delete something.
Ask the operator to review the affected scope: privileged users, database content/settings, core and components, must-use plugins, uploads, configuration, scheduled tasks, other installations and account access where relevant. WP-CLI core checksums can help an administrator compare the selected core version and locale; they do not clear the database, every plugin/theme or the hosting account. This article does not ask beginners to run shell commands.
Tools also have different boundaries. Hostinger explicitly documents that its Malware Scanner does not scan or clean the database. A clean file result cannot dismiss persistent redirects or unauthorized accounts. Ask what a scan checked, skipped and could not inspect.
6. Correct the entry point and verify recovery
Removing the visible spam page is insufficient if the exposed account or vulnerable component remains. Ask for a clear record of the likely entry route, what was corrected and any uncertainty that remains. If the cause is unknown, agree additional investigation and monitoring rather than inventing certainty. Replace affected software from trusted sources, remove unnecessary components and test supported updates with the responsible operator. WordPress’s hardening guidance treats server, application, device and access controls as connected responsibilities.
Before reopening, record checks of recovered pages, media, administrator access, forms and relevant commerce workflows using safe test procedures. Include previously affected URLs, redirects, accounts, logs and component integrity. Confirm that mail, DNS and other sites still operate as intended. An empty scan and a normal-looking homepage are only parts of that evidence.
After restoration, review exposed credentials and revoked integrations again, confirm the current patched configuration, and create a fresh recovery copy only after the recovered state has been assessed. Agree who receives alerts, what they inspect and when the next review occurs. Returning symptoms mean containment and investigation resume, not that the same restore should be repeated indefinitely.
Include authentication configuration in the restored-state check: a restored configuration can contain earlier keys and salts. Have the operator confirm the intended current configuration, invalidate old login cookies where needed and check legitimate sign-in again.
7. Resolve external warnings through the right channel
If Google reports security issues, use the verified site’s Search Console Security Issues report. Its example URLs are not a complete inventory. Address every reported issue type throughout the affected site, then request security review with the fixes described. A scanner cannot submit evidence of your whole recovery simply by displaying a green result.
Manual Actions needs its own review
Check the Manual Actions report separately. If it lists an action, follow that action’s scope and fix all affected pages before requesting review there. Explain the issue, changes and verification. A Security Issues review is a different process; neither a submitted request nor a clear report replaces checks of the recovered website.
Separate legitimate pages from attacker-created URLs
For an important legitimate page, use URL Inspection and its live test to inspect the current response, rendered page and index restrictions. Compare live information with the indexed version. A valid live result is not an indexing guarantee or a security clearance, and does not check Manual Actions or every possible indexing issue.
When the page is recovered and intended to be public, you can request indexing for a few important URLs, or submit a clean sitemap for many URLs. Repeated requests do not make a URL crawl faster. Monitor the relevant reports; a request does not guarantee inclusion, restored rankings or traffic.
For an attacker-only spam URL with no legitimate replacement, remove the injected content and have the server return an actual 404 or 410 status, as Google’s response guidance explains. Remove that URL from your sitemap. A normal-looking “not found” page returning 200 is insufficient; do not redirect unrelated spam URLs to the homepage. Preserve a legitimate page at its proper address instead of deleting it with the spam.
Temporary hiding is not cleanup
If an attacker-created URL needs urgent hiding from Google Search, an authorized owner can consider the Removals tool. Its temporary block lasts about six months and does not remove the content from the website. Check the exact URL or prefix carefully; avoid hiding the whole site or legitimate pages you want indexed. Complete the underlying removal or repair. Blocking with robots.txt alone is not permanent removal from Search.
Other host, browser or security-provider warnings have their own processes. Follow those providers’ instructions after remediation. Do not tell visitors to ignore warnings or promise a removal date, restored ranking or immediate traffic recovery. A clean Search Console report is not a universal security certificate.
When specialist help is worth paying for
Seek qualified help promptly for suspected customer/payment-data exposure, account takeover, recurring infection, multiple affected sites or recovery beyond your skills. Follow the affected providers’ incident procedures and obtain appropriate privacy, legal or payment-security advice about assessment and notifications. This guide cannot determine who must be notified or set a deadline for your circumstances.
Before paying, ask who performs the work, which account/sites and database are included, what access they need, how evidence and backups are handled, and what constitutes completion. Confirm current availability, exclusions, price and follow-up directly. Give scoped, revocable access through a secure channel; do not post credentials in public support threads.
Wordfence distinguishes its plugin from full recovery work. Our Wordfence versus Sucuri comparison helps separate firewall software from human cleanup scope. Compare that gap only if your existing host or administrator cannot meet it. For later prevention, read free versus paid WordPress security and hosting backups versus an independent backup. A second subscription is unnecessary when the documented, verified requirement is already covered.
Keep a short incident handover
Maintain a private record with: observed symptom and time/timezone; affected account/site; containment action and owner; evidence-copy location and access; chosen recovery point and data losses to reconcile; corrected access/component; checks and their results; outstanding warnings; and the next monitoring review. Leave unknown items explicitly open for the responder. Keep secrets and customer records out of the general checklist.
Copy the following fields into a private incident note. The bracketed fields are deliberately unfilled; they are a template, not a record of an incident we observed.
- Time and timezone: [date/time/zone]
- Observed symptom and affected site/account: [what happened; where]
- Action, authorization and owner: [what changed; who approved; who performed it]
- Preserved evidence location and scope: [private reference; files/database/log period; who can access]
- Verification result and limits: [check; observed result; what was not checked]
- Next action, responsible person and check time: [open item; owner; planned review]
The useful outcome is controlled access, an explained recovery decision and documented checks of the recovered service. Continue using the existing provider where it meets that need; purchase specialist work when there is a clear responsibility or capability gap.
Sources and verification
Editorial review 2026-10-10. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: FAQ My site was hackedChecked Document symptoms and timestamps, involve the host, renew access, replace authentication keys/salts to invalidate login cookies and change exposed passwords again after cleanup.
Limits: Broad incident guidance contains historical product names and example procedures; these are not copied as current universal instructions. - WordPress: Hardening WordPressChecked Security depends on host, application and administrator-device controls; trusted software sources, updates, logging and restricted access reduce risk.
Limits: No configuration, vulnerability or security effectiveness was tested. - WordPress: BackupsChecked A typical full restoration needs matching files and database; backup availability and recovery depend on the actual environment.
Limits: An existing archive is not established as clean or restorable by this documentation. - WordPress: Backing Up Your WordPress FilesChecked Files include uploads, plugins, themes and sensitive configuration; copying a website directory does not normally capture the database.
Limits: Do not execute preserved malicious files or publish configuration and backups. - WordPress: Backing Up Your DatabaseChecked Database export and restoration are separate operations requiring the correct database and environment.
Limits: This guide does not provide commands or test a MySQL/MariaDB restoration. - WordPress: Application PasswordsChecked Application passwords are separately manageable integration credentials; review and revoke suspected or unneeded credentials.
Limits: Browser-session logout alone is not a claim that these credentials or hosting API tokens are revoked. - WP-CLI: core verify-checksumsChecked Core checksum verification compares installed files with a specified WordPress version and locale and avoids loading WordPress.
Limits: It is not a whole-site, database, plugin, theme or hosting-account clearance; no command was executed. - Wordfence: If Your Site Is HackedChecked Scans and repair support differ from full incident restoration; avoid unchecked old backups and multiple security plugins; escalate beyond operator skill.
Limits: Vendor service descriptions are not independently observed cleanup, coverage or response guarantees. - Wordfence: Scan ResultsChecked Repair replaces eligible repository/core files with originals and can remove legitimate customizations; findings require interpretation and backups.
Limits: A matching original, completed scan or empty result list is not complete proof of recovery. - Wordfence: Free documentationChecked Free includes firewall/scanning and receives new rules and malware signatures 30 days after Premium.
Limits: No product installed or compared for detection effectiveness; vendor superiority language is not adopted. - Hostinger: Password Protect DirectoriesChecked The hosting dashboard provides reversible directory-level password protection for web access.
Limits: This is a product-specific example, not proof of stopping scheduled tasks, other access paths or a compromised host account. - SiteGround: Protected URLsChecked Site Tools Security offers Protected URLs with a selected domain/path and access users.
Limits: Check applicability, actual scope and removal procedure with the host; not a full account isolation procedure. - SiteGround: Raw Access LogsChecked The dashboard shows the latest 300 access entries; longer/current-day data may require support and archived logs have a limited period.
Limits: No universal log-retention assumption, complete incident timeline or actual access-log retrieval. - Namecheap: Hacked cPanel hosting accountChecked Scope can include other sites, email, accounts, DNS and scheduled jobs; partial recovery can miss persistence; full restore can replace recent data.
Limits: Namecheap/cPanel scope only; backup availability, exact affected components and an appropriate restore method require confirmation. - Hostinger: Malware Scanner limitationsChecked Its Malware Scanner scans/cleans files, not the database; persistence or compromised accounts can remain.
Limits: A product-specific scope statement, not a ranking or a claim that all scanners behave identically. - Google Search Console: Security issues reportChecked Security Issues provides issue details and non-exhaustive sample URLs; request security review after fixing all reported issue types throughout the site.
Limits: A report, scan or request does not guarantee immediate warning removal, complete security or restored ranking. - Google Search Console: Managing owners, users, and permissionsChecked Users/owners, retained verification tokens and token-specific removal; some tokens are also used by other Google services.
Limits: No property, owner or token was inspected or changed. Preserve legitimate access; a suspected owner also requires securing the underlying site. - Google Search Console: Manual actions reportChecked Manual-action scope, fixing affected pages and requesting review in that report with the issue, work and results described.
Limits: Separate from a Security Issues review; no action, request, account or ranking outcome was observed. - Google Search Console: URL Inspection toolChecked Indexed versus live information, rendered-page/response inspection, index restrictions and limits of a valid live test.
Limits: Live inspection does not check every indexing issue, Manual Actions or a complete security state; no actual property or URL was tested. - Google Search Central: Ask Google to recrawl your URLsChecked Individual indexing requests, larger sitemap discovery and the absence of guaranteed inclusion or benefit from repeated requests.
Limits: No Search Console request or sitemap submission was made; no reindexing, ranking or traffic recovery is promised. - Google Search Central: Troubleshoot crawling errorsChecked Actual 404/410 responses for removed pages without similar replacements, soft-404 problems and relevant replacement redirects.
Limits: Applying this response guidance to attacker-only URLs and excluding them from a clean sitemap is editorial recovery guidance; no server response was changed or tested. - Google Search Console: Removals and SafeSearch reports toolChecked Temporary removal for about six months, exact URL/prefix scope, avoiding whole-site hiding after hacking and permanent-removal requirements.
Limits: Temporary Search hiding is not removal from the website or malware cleanup. No removal request was submitted.