If your WordPress site is hacked, the first hour is for containment and evidence, not a rushed cleanup. Stop visitors from being harmed, save a complete copy of what exists now, notify your host, and rotate the accounts that could let an attacker stay in.
You do not need to solve every technical question immediately. A calm record of what you found, plus a preserved copy, makes the next cleanup far more reliable and helps prevent a second compromise.
Start by confirming the symptom without making it worse
The first task is to record what is happening. Take screenshots of warning pages, redirects, unfamiliar content, strange search results, host notices, and error messages. Note the affected URL, the date and time, the device and browser used, and whether you were logged in. If a redirect only happens after a search result or on a phone, record that too.
Use a private browser window to observe the public site. Do not enter passwords on a page that looks altered, and do not use the compromised WordPress dashboard for general browsing. A symptom that does not appear for you may be targeted to search visitors, first-time visitors, or a particular device.
Check for immediate risk: payment forms you do not recognize, browser malware warnings, phishing pages, unknown administrators, or reports from customers. These are reasons to contain the site promptly.
Contain the site in a reversible way
Containment limits further harm while keeping the evidence you need for recovery. If the site is serving malicious content or collecting information, place it in maintenance mode through your host, a known maintenance setting, or a trusted WordPress maintenance plugin. A host-level temporary page is often safer than editing theme files on a compromised installation.
If the site must stay available, at least disable affected pages, payment functions, or user registration until they can be reviewed. Tell staff not to log in from shared or potentially infected devices.
Lock accounts you do not recognize. In WordPress, review Users and identify every Administrator. Deactivate unknown accounts rather than deleting them in the first hour, and record the username, role, email address, and registration date first. Look for unfamiliar SFTP, SSH, hosting-panel, and email users too. An attacker may retain access outside WordPress.
Do not block all access so broadly that you cannot coordinate with your host or retain a copy. The goal is to reduce exposure, not to erase the scene.
Take a forensic copy before changing files
Take a complete copy of the WordPress files and database before cleanup. This snapshot preserves malware samples, timestamps, logs, user records, and configuration that may explain how the site was accessed. It also gives you something to compare with a later clean version.
Download the entire WordPress directory over SFTP or use your host's backup tool. Include hidden files such as .htaccess, plus wp-config.php, wp-content, any mu-plugins directory, and server logs available in the account. Export the whole database, not only posts and pages. WordPress settings, users, scheduled tasks, injected content, and attacker-created links can sit in database tables such as wp_options, wp_users, and wp_posts.
Keep the copy outside the hosting account if possible. Name it clearly with the site and date, restrict access to the people investigating, and do not upload it to a public folder. This is a preservation copy, not something to restore blindly.
Tell the hosting provider what you see
Your host can see account-level information that WordPress cannot. Open a support request and state the observed symptom, the approximate time it started, whether the site is in maintenance mode, and whether customers could have encountered malicious content. Ask them to preserve relevant access, error, malware-scan, and mail logs while the issue is investigated.
Ask whether they detected suspicious files, outgoing email, unusual CPU use, or activity under other sites in the same account. If they suspended the site, ask for the exact paths or scan results that led to the suspension. Save their responses with your incident notes.
Do not ask the host to delete every file as the first action. Their findings may identify the path that matters, and an account-wide deletion can remove logs and custom data that you need.
Rotate the most critical access from a clean device
Change credentials only from a device you trust and that has current operating-system and browser updates. If your usual computer may have stored or exposed the credentials, use a different device first. Use unique, long passwords and enable multi-factor authentication where the provider supports it.
Prioritize access in this order:
- The email account that receives hosting and WordPress reset messages.
- The hosting control panel and the account owner's credentials.
- All WordPress Administrator accounts, including API or integration users with admin-level access.
- SFTP, SSH, deployment, and source-control credentials that can change site files.
- Database credentials and third-party keys stored in
wp-config.phpor environment settings, when you can update the application configuration safely. - Domain registrar and DNS accounts, especially if you see unfamiliar redirects or DNS records.
Changing a password is not the same as removing access. Review recovery email addresses, active sessions, API tokens, SSH keys, and new administrator accounts. Regenerate WordPress salts during the full cleanup to invalidate existing WordPress login cookies, but first coordinate the update so legitimate users know they must sign in again.
Do not make these common first-hour mistakes
The instinct to clean everything immediately is understandable, but it can create a longer outage and make the cause impossible to find. Avoid these actions until you have a copy and a plan:
- Do not delete suspicious files one at a time just because their names look unusual. They may be backdoors, but they may also be part of a plugin or custom code that needs replacement in a controlled way.
- Do not overwrite the entire site with an old backup before you preserve the current state and check whether the backup predates the intrusion.
- Do not assume updating WordPress alone removes malware. Updates close known flaws, but they do not remove a backdoor or unknown administrator.
- Do not reset only one password. Attackers frequently use hosting, SFTP, database, email, or a second WordPress account to return.
- Do not announce a cause you have not verified. Tell affected people what you know, what you have contained, and when you will provide another update.
Move from containment to a complete cleanup
Once the site is contained and the copy is safe, begin a structured cleanup. This normally means identifying altered core files, plugins, themes, uploads, database content, accounts, scheduled tasks, and server configuration; replacing compromised files from trusted sources; removing unauthorized users; rotating every relevant credential; and closing the entry point.
Our detailed guide to fixing a hacked WordPress site lays out that sequence. If the symptom was an unfamiliar administrator, also review how to find hidden WordPress admin users, because an attacker can use accounts, database changes, or code to regain access.
After cleanup, confirm the public site from a private browser, test key forms and checkout flows, review logs, and keep monitoring for changed files and new accounts. The next few days matter as much as the first hour, because a recurring symptom often means an entry point was missed.
When to get help
Get help right away when the site takes payments, handles sensitive information, serves malware warnings, or you cannot confidently restore trusted access. Our WordPress malware removal service can assist with containment and cleanup, and WordPress hardening can address the controls that should follow recovery.