Start with evidence, not a verdict
If you think your WordPress site has been hacked, start by recording what changed, when you noticed it and who else can reproduce it. A slow page or failed login alone does not confirm a compromise. Unauthorised content, accounts or code give you something more specific to investigate.
A useful first check
Write down the affected URL, time, device and exact warning or behaviour. Save screenshots and contact your host through a known support route. If visitors are being exposed to harmful content, ask for help containing access immediately.
Use a trusted device for administration. Do not follow suspicious redirects or download files from a warning page. The checks below help you describe the problem; they are not a substitute for a full investigation.
1. Traffic changes you cannot explain
Compare unusual traffic with campaigns, tracking changes, seasonal demand and outages. An analytics drop may simply reflect a broken tracking script. A surge may be ordinary bots rather than a successful intrusion.
Look at affected pages, traffic sources and timing alongside hosting logs. If the same period includes newly created spam pages or unexpected redirects, preserve those examples for investigation. A chart on its own cannot tell you whether WordPress is hacked.
2. Unfamiliar administrators
Review WordPress users and roles, especially administrator accounts. Confirm unfamiliar names with the people who manage the site: a developer or integration may have created a legitimate account.
Record the username, email, role and available activity before making changes. A responder may need to revoke access quickly, but preserve the evidence first where practical. An ordinary user-list screen may not expose every way access has been retained.
3. Redirects or pop-ups you did not add
Does the redirect happen only when arriving from Google, using a phone or browsing while logged out? Note those conditions. Some malicious behaviour is selective, so a normal homepage visit from your own browser may miss it.
Unexpected redirects can also come from legitimate plugins, caching or routing faults. Our anonymised recovery investigation describes a redirect that needed a separate diagnosis after a compromise. Record the behaviour without assuming every redirect shares the same cause.
4. Browser or Google security warnings
Record the exact warning. A certificate warning, a Google Safe Browsing warning and a WordPress error describe different problems and need different checks.
If you have authorised Search Console access, inspect Security issues for reported problems and example URLs. Those examples are a starting point, not necessarily every affected page. A clear report does not prove the site is free from compromise; an issue may not yet have been detected.
Do not bypass a warning to continue normal use. Our Google warning recovery guidance explains the checks and review process after remediation.
5. Content you did not authorise
Check important pages for changed text, unexpected links, unfamiliar downloads and new content nobody recognises. Search results may show spam titles or pages that are difficult to find through the normal navigation.
Save the affected URLs and compare them with the intended content. Search results can also show an older version of a page, so establish what the live site serves before treating every unusual snippet as a current infection. Do not remove legitimate pages simply because their URLs look unfamiliar.
6. Files that do not belong
Ask your host or developer to compare WordPress core files with trusted checksums, and plugins and themes with known-good packages for their installed versions. Unexpected executable files in uploads, altered configuration and unexplained code changes warrant review.
A file date, filename or checksum mismatch is a lead to assess, not a verdict. Custom code and authorised modifications need context. Core checksums cover WordPress core; they do not establish that plugins, themes, uploads or database content are clean.
7. Unusual resource use
High CPU usage, background requests or a slow dashboard may involve abuse, but can also come from a plugin fault, scheduled job or overloaded hosting. Match the timing with logs, recent updates and normal business activity.
A useful investigation identifies the requests or processes responsible rather than repeatedly restarting the server. Where the evidence points to an ordinary application fault, Website Rescue may be the more appropriate next step.
8. Email activity you cannot account for
Unexpected sending alerts, messages or delivery failures deserve investigation. Bounces alone do not establish that your website sent spam: a sender address can be forged.
Compare the reports with transactional email and hosting logs. Check integrations and credentials using a secure support channel. Do not paste passwords, customer messages or access tokens into a public scanner or support forum.
9. Lost access to administration
Confirm the login address, recent password changes and whether your provider has introduced an access restriction. A failed login can come from a firewall rule, expired credentials or an application problem as well as an attacker.
Use the established recovery route with your host or developer. Avoid creating temporary public recovery scripts or giving an unverified helper administrator access. If an account has been taken over, access recovery needs to sit alongside investigation of the wider site.
10. Unexpected theme or plugin changes
Compare installed components and recent changes with the people authorised to maintain them. An unfamiliar plugin may be legitimate; a familiar plugin name does not guarantee its files are untouched.
Review inactive components, must-use plugins and scheduled work as part of the technical investigation. Deleting the first suspicious file can remove evidence while leaving another route back into the site.
Can a malware scanner tell me if WordPress is hacked?
A remote scanner sees what the website exposes to its requests. A scanner running within the installation can inspect other areas, depending on its access and coverage. Neither automatically examines every file, database record, account and conditional response.
Use scan results alongside file comparisons, account reviews, logs and observed behaviour. A clean result is useful evidence, not a guarantee. If a tool reports a finding, confirm what it detected before removing code or restoring a backup.
What to do if the checks raise concerns
- Contain harm. Ask your provider to restrict unsafe access or serve a safe maintenance page where needed.
- Preserve an incident copy. Keep affected files, the database and relevant logs separate from trusted backups.
- Agree a recovery plan. Establish the scope, responsibilities and a recovery route before replacing files or restoring data.
- Verify the result. Recheck affected pages, administration, enquiries and email, then document outstanding issues and ongoing care.
Our WordPress malware clean-up guide explains the recovery process. For hands-on investigation, talk to us about WordPress malware removal, including sites currently hosted elsewhere.
Further reading: WordPress.org: My site was hacked and Google: Security issues report.
Get help with your website
Tell us about your website and what you need. We can work through the options with you.
Explore the service ↗