A hacked WordPress site can sometimes be recovered without a clean backup, but the work needs to be controlled. First limit harm, preserve the current state and find the entry point. Then rebuild or clean the site, secure access and verify that the compromise is gone before restoring normal traffic.

If the site handles payments, personal or health information, or is being used to attack visitors, contact the host and a qualified incident-response provider promptly. Follow your organisation’s security, privacy and reporting process. Do not publish a cleanup promise until the scope is understood.

Signs the site may be compromised

Possible indicators include unfamiliar administrator accounts, unexpected redirects, injected pages or links, browser warnings, unknown files, changed site settings, outbound spam, or a hosting provider’s abuse notice. Search Console’s Security Issues report may show problems Google has detected, but an empty report does not prove the site is clean.

Record affected URLs, error messages, dates, recent changes and notifications. Use a safe device and network. Do not log in through links in suspicious messages, and do not post credentials or private customer data in a public support forum.

First response: contain and preserve

  1. Contact the hosting provider. Ask about isolation options, server logs, backups, affected accounts and whether other sites in the same hosting account may be involved.
  2. Limit exposure. Depending on the risk, the host may restrict access, serve a maintenance notice or isolate the site. Preserve a clean contact or emergency page if safe and appropriate.
  3. Preserve a copy of the compromised state. Take a controlled snapshot of files, database and relevant logs before deleting or overwriting evidence. Store it with restricted access; it may contain malicious code or personal data.
  4. Coordinate access changes. From a trusted device, secure the hosting, domain, DNS, email, WordPress and third-party accounts. Revoke unfamiliar users and sessions. Rotate credentials after the attacker has been contained, and replace WordPress authentication salts so existing sessions are invalidated.
  5. Set a response owner. Record who can approve changes, communicate with affected parties and decide when the site can return to service.

Do not assume maintenance mode alone contains a compromise. A backdoor can continue running while the public page is hidden. Work with the host to choose a control that covers the affected files and services.

Investigate the entry point

Review access logs, file changes, new administrator accounts, scheduled tasks, plugin and theme versions, hosting alerts, DNS changes and recent deployments. Establish a timeline and identify whether email, payment, customer or other connected systems may also be affected.

Keep the investigation proportionate to the impact. If evidence may be needed for insurance, regulatory review or legal advice, consult the appropriate specialist before altering it. Do not make unsupported statements about who attacked the site or what data was accessed.

Clean or rebuild safely

There is no universal cleanup sequence for every incident. For a simple site, a qualified WordPress professional may be able to replace compromised software and review the database. For a serious or repeated compromise, use incident-response expertise and coordinate with the host.

  • Replace WordPress core files from a trusted distribution. Do not overwrite the preserved evidence copy.
  • Reinstall themes and plugins from their original trusted publishers. Remove abandoned, unauthorised or pirated software and confirm licences and current compatibility.
  • Review uploads and writable directories for unexpected executable files, while retaining legitimate business media.
  • Inspect administrator accounts, database content, configuration, scheduled tasks, must-use plugins, drop-ins and server-level rules for unauthorised changes.
  • Remove malicious redirects, spam pages and injected content. Check for additional access paths rather than deleting only visible symptoms.
  • Update supported software and restrict access according to the site’s actual needs. Do not apply blanket permission changes or unreviewed database commands.

If you cannot establish that the site is clean, rebuild from known-good content and software on a clean environment. Retain required business data only after it has been checked. A visual scan or single malware plugin is not proof that every backdoor has been removed.

Verify before returning to normal traffic

Test the rebuilt site on a controlled environment. Review file and account changes, repeat scans, inspect server logs, confirm redirects and test forms, checkout, email, analytics and integrations. Check that backups are created and can be restored.

If Google Search Console reports a Security Issue, use its current remediation instructions and request a review after the issue has been fixed. Google may take time to recrawl the site. A review request does not guarantee a particular search outcome.

Monitor for reinfection, new accounts, unexpected file changes and outbound activity. Keep the host involved during the observation period and document what was changed.

Reduce the chance of a repeat

Patch supported software through a tested process, remove components the site no longer needs, protect administrator accounts with unique credentials and multifactor authentication, restrict access, and keep off-site backups with scheduled restore tests. Review hosting, DNS, email and third-party access as part of the same security boundary.

When to bring in a specialist

Escalate if the compromise returns after cleanup, the attacker retains access, several sites or accounts are affected, sensitive information may be involved, or you cannot confidently identify the entry point. A provider should explain the evidence gathered, the remaining uncertainty, the work included and what will be independently checked.

Avoid anyone who guarantees a complete clean before inspecting the site, pressures you to hand over unrelated accounts, or treats a scanner result as proof of recovery.

Frequently asked questions

Can a hacked WordPress site be recovered without a clean backup?

Often it can, but the result depends on what was changed and what can be trusted. Preserve the compromised state, involve the host, replace software from trusted sources and verify the database and access paths. A clean rebuild may be safer than editing unknown files in place.

Should I change every password immediately?

Secure access from a trusted device and coordinate with the host. If the attacker still has access, password changes alone may not contain the incident. Revoke sessions and rotate credentials and authentication salts as part of the containment and recovery plan.

How long does recovery take?

There is no dependable standard duration. Scope, evidence, affected systems, data checks and review requirements all affect the work. Establish scope before agreeing an estimate.

Conclusion

Contain the compromise, preserve evidence, work with the host and rebuild from trusted software. Restore public traffic only after access, data, key functions and monitoring have been checked. If the site or data risk is uncertain, use qualified incident-response support.

Sources checked on 20 October 2026: WordPress guidance for hacked sites, Google’s Security Issues report guidance and Search Console security tools.