What to do if your WordPress site gets hacked

Unexpected redirects, unfamiliar administrators or malicious files can indicate compromise. A broken update or a legitimate DNS change can also explain some symptoms. Record what you observe before making destructive changes; do not assume a scanner result tells the whole story.

1. Use a trusted contact and record the timeline

Use an unaffected device and account to contact your hosting provider or incident support. Record when symptoms began, affected services and actions already taken. Ask for relevant access, error and account logs to be preserved before they expire. Do not send credentials or raw evidence through a public enquiry form.

If personal data, insurance requirements or legal proceedings may be involved, bring in appropriate advice early. Technical recovery does not settle notification obligations or replace formal forensics.

2. Contain access without casually destroying evidence

Ask your provider to help restrict traffic or isolate the affected service if it is harming visitors or exposing data. A maintenance page can reduce visitor exposure but does not stop attacker access, malicious scheduled tasks or outbound activity.

Preserve protected copies of relevant files, the database and available logs before cleanup where safe and feasible. Treat these as potentially malicious and sensitive: do not open or upload them casually. Do not wipe or rebuild the original system before considering evidence and recovery needs.

3. Review and revoke compromised access

From a trusted environment, review hosting, registrar, DNS, WordPress and recovery-email access. Reset affected credentials, revoke sessions and app passwords, and review API keys and connected apps. Coordinate database and application-secret changes so dependent services do not silently break. Password changes alone may not remove persistence on an infected server.

4. Understand the scope and choose a recovery route

Look for vulnerable components, unauthorised accounts, changed files, scheduled tasks and other persistence within the access available. The database, uploads and neighbouring sites may also be affected. A file timestamp is a clue, not proof of an entry point.

Recover from a backup checked to predate the compromise, or rebuild in an isolated environment using trusted core, theme and plugin sources. Inspect restored content, uploads and database records; copying them blindly can carry malicious changes forward. Keep the original evidence separate from the recovery copy.

5. Address the entry route and test before reopening

Patch the affected components and remove unused ones. Review permissions, privileged accounts, sign-in protection and administrative access. Rotate relevant secrets through a trusted route and invalidate old sessions. Changing the WordPress database prefix is not a meaningful substitute for these controls.

Check public pages, logins, password resets, forms, email and any orders or memberships. Review for signs of recurrence before restoring normal traffic. Reconcile data created during the incident rather than overwriting it blindly with an older backup.

6. Document and follow up

Record what was verified, what was changed and what remains uncertain. Request a Google Search Console security review once the flagged issue is resolved; its processing time is outside your control. Restore-test off-site backups and agree who owns updates, account review and future escalation.

Need help?

The urgent help path within Web & Infrastructure Security Assurance covers compromised websites, web apps and hosting environments, not just WordPress. Tell us what is affected, when you noticed it and the safest way to contact you.