If your WordPress site hacked, here is what to do in the first hour: take the site offline, preserve a full snapshot of it as evidence, change every credential and force all sessions to log out, open an emergency ticket with your host, and establish your last known clean backup before you delete a single file.

At Survyc, hacked-site calls from partner agencies follow the same pattern. The damage from the hack itself is usually recoverable. The damage from the first panicked hour often is not. Site owners delete the files that showed how the attacker got in, restore a backup that is itself infected, and change the admin password while the attacker sits in an open session, still logged in.

So this guide is deliberately narrow. It is not a cleanup manual, and it does not repeat the signs your WordPress site is hacked, which we covered separately. It covers the 60 minutes after you know it is real, structured as a clock, because a panicking person can follow a clock. Nobody in a panic can follow twelve equally weighted bullet points.

What Is the One Rule When Your WordPress Site Hacked?

Preserve evidence before you delete or overwrite suspicious data.

Do not immediately remove unfamiliar files, spam pages, modified configuration files, or suspicious administrator accounts before you have documented the incident and captured a complete snapshot of the compromised environment.

Those artifacts may help establish when the compromise occurred, what the attacker changed, and how access was gained.

Once the evidence has been preserved, containment can continue. Unauthorized accounts can be disabled, sessions can be invalidated, credentials can be rotated, and malicious components can later be removed during the cleanup stage.

The important distinction is:

Preserve first. Contain second. Clean third.

What should you do in the first hour, minute by minute?

Work through the hour in five blocks: stop the bleeding, preserve the evidence, lock every door, bring in your host, then assess the damage. The order matters more than the speed. Each block below tells you what to do and why that step sits where it does.

Minutes 0 to 5: Isolate the Compromised Site

Your first goal is containment: stop visitors from interacting with a site that may be serving malicious code, redirects, phishing pages, or compromised forms.

If possible, isolate the site at the hosting, server, CDN, or firewall level rather than relying only on a WordPress maintenance-mode plugin. Ask your hosting provider to temporarily suspend public access while preserving administrator or support access needed for investigation.

For a business-critical site, another option is to serve a clean static maintenance page from your host or CDN while the compromised WordPress application remains isolated.

Do not rely on simply creating a blank .maintenance file in the WordPress root. WordPress uses that file as part of its temporary update process, and it is not a complete incident-containment mechanism.

If Google or your browser is already warning that the site contains malware, avoid repeatedly opening infected pages in your normal browser while investigating. Preserve screenshots and use your host, security tools, or Search Console data where possible.

The objective is simple: stop further visitor exposure without destroying the evidence you will need to understand and clean the incident.

Minutes 5 to 15: preserve the evidence

Before you change anything, capture the crime scene. Screenshot the defacement, the redirect, the Google warning, the spam pages, and anything else visible. Write down who found the problem, when, what the symptoms were, and anything anyone has already done.

Then take a complete backup of the site exactly as it is right now, files and database both. Label it clearly as infected. This copy is forensic evidence, not a restore point, and it must never be restored to a live server.

If your host can take a server-side snapshot, ask for one now. It captures details a WordPress-level backup misses. Our WordPress backup guide explains the difference between the two, and why it matters here.

Minutes 15 to 30: Lock Down Access and Revoke Exposed Credentials

Use a Trusted Device Before Rotating Credentials

Before entering new passwords, make sure the computer you are using is trustworthy.

If the original compromise involved stolen credentials, changing every password from an infected computer can expose the new credentials immediately.

Run an up-to-date malware or endpoint-security scan on the device you use to manage the website. If you have reason to suspect that device, use another trusted computer and secure network for emergency account changes.

Also secure the email account connected to your hosting and WordPress administrator accounts. An attacker who controls that inbox may be able to reset the credentials you are about to change.

After the compromised environment has been isolated and preserved, begin locking down the accounts that can control it.

From a trusted device, rotate credentials for your:

  • hosting control panel
  • WordPress administrator accounts
  • SFTP/FTP access
  • SSH access
  • administrator email accounts connected to password recovery

If API keys, payment credentials, CRM tokens, SMTP passwords, or other external secrets may have been exposed, revoke or rotate them at the external provider.

However, do not immediately place newly generated high-value secrets back into a WordPress installation that has not yet been cleaned. Keep the compromised application isolated and add replacement credentials only when the environment is trusted again.

Database credentials require additional care because changing them without updating WordPress configuration will break the site’s database connection. Coordinate that change with your host or incident-response process while the site is isolated.

Plan to rotate critical credentials again after the cleanup is complete. WordPress’s own hacked-site guidance recommends changing passwords again once the environment is clean.

Changing credentials should be paired with explicit session invalidation so that existing authenticated sessions cannot remain useful.

If WP-CLI is available, you can destroy all sessions for a specific administrator with:

wp user session destroy USERNAME --all

For sites with multiple users, WP-CLI can also be used to destroy sessions across all WordPress accounts.

Another WordPress-supported approach is to regenerate the authentication keys and salts in wp-config.php. Changing those values invalidates existing WordPress authentication cookies and forces logged-in users to authenticate again.

Perform either change only after preserving the compromised environment, and record what you changed as part of the incident timeline.

While you are in there, run two persistence checks. Look for admin users you did not create, and look for extra SFTP or FTP accounts in your hosting panel. Review every account that can access the hosting environment, including WordPress administrators, SFTP/FTP users, SSH keys, hosting-panel users, and deployment credentials.

Do not assume that a second SFTP or SSH account is automatically malicious. Many legitimate hosting setups use separate developer, agency, or deployment accounts.

Instead, document each account and verify who owns it and why it exists. Disable or revoke accounts and keys that nobody can identify or that were created without authorization.

Minutes 30 to 45: bring in your host and get the logs

Open an emergency or priority support ticket with your host. Say the word “compromised” in the subject line. Do not send a casual email and wait.

Your host holds something you cannot get anywhere else: Your hosting provider may have logs that are unavailable inside WordPress and could help reconstruct the incident.

Ask them to preserve and, where possible, provide:

  • web access logs
  • server error logs
  • authentication or control-panel logs
  • WAF/security events
  • SFTP/SSH access records
  • relevant mail or outbound-connection logs

Request the period before and after the first known symptom. Do this quickly because log-retention windows vary between hosting providers.

Logs may help identify suspicious requests, login activity, changed files, or the approximate compromise window, but they do not always reveal the original entry point on their own. Combine them with file timestamps, database changes, administrator activity, and other evidence.

Reputable hosts run incident procedures daily and will move fast once you use the right words. If your host cannot produce logs or an incident process at all, note that for later. It belongs in your post-recovery hosting decision.

Minutes 45 to 60: assess the damage and find your last clean date

Spend the final quarter of the hour on assessment, not action. Three questions decide everything that happens after the hour ends.

What are customers exposed to right now? Check what a visitor could still do before you went offline: buy, book, submit a form, log in. This tells you the business severity, separate from the technical one.

Was payment or personal data involved? If yes, your obligations extend beyond fixing the site, which we cover below.

When was the site last known clean? Establish this date before anyone restores anything. Check your backup points against it. A “last known clean” date is a starting point, not proof that every earlier backup is safe.

Attackers sometimes maintain access quietly before the first visible redirect, defacement, spam page, or Google warning appears. A backup from the day before the visible incident can therefore still contain a backdoor.

Treat older backups as recovery candidates. Before restoring one to production, inspect or scan it, compare suspicious file changes where possible, and make sure the vulnerability that allowed the compromise has been corrected.

Restoring an older backup without closing the original entry point can simply restart the incident.

Finally, open Google Search Console and check the Security Issues report to see whether Google has flagged the site and what it found. Screenshot that too.

What should you not do in the first hour?

Five mistakes account for most failed recoveries, and all five happen in the first hour. Do not panic-delete files before understanding the incident. Do not clean the visible malware without finding the entry point. Do not restore a backup until you know your last clean date. Do not reset only the WordPress password while leaving hosting, FTP, and database credentials untouched. And do not fire off a Google review request before the site is actually clean.

Each of these feels productive in the moment. Each one either destroys evidence, leaves the attacker a way back in, or extends how long the warning stays on your site. The first hour rewards restraint, not activity. A hacked site that still “works” is not fine, and a fast reaction that skips the sequence is worse than a slow one that follows it.

What happens after the first hour?

After the first hour, the incident moves from containment to cleanup, and that is a different job with a different guide. The site is offline, the evidence is preserved, every credential is rotated, your host is engaged, and you know your last clean date. That is the full scope of this article, and it hands over here.

The cleanup itself, scanning, removing the malicious code, closing the entry point, and verifying the site is genuinely clean, is covered step by step in our WordPress malware removal guide. If the site matters to your revenue, do the cleanup on a copy rather than the live server instead of experimenting on the version your customers can see.

One symptom worth flagging at the hand-off: if the site keeps throwing errors after cleanup, a 403 or a white screen. If the site starts returning 403 errors, white screens, or other failures after cleanup, investigate them rather than assuming they are harmless. They may come from residual malicious changes, incomplete file replacement, permissions, server rules, plugin conflicts, or changes made during remediation.

Check Whether Anyone Else Must Be Contacted

For a business website, the hosting provider may not be the only party that needs to know.

Check whether your organization has:

  • cyber-insurance incident requirements
  • an internal IT or security provider
  • a managed service provider
  • payment-provider security obligations
  • contractual breach-notification requirements
  • legal or privacy counsel

Some insurance policies require the policyholder to use approved incident-response providers or notify the insurer before incurring remediation costs. Review your policy and contracts before making assumptions about coverage.

What if Google flagged your site as hacked?

If Google shows “This site may be hacked” or a red warning screen, you now have a business problem running in parallel with the technical one, and it has its own rules.

Confirm the flag in Search Console’s Security Issues report, and screenshot what Google found before you change anything. If the property is not verified in Search Console, verify it now. You cannot request a review without verification, and setting it up takes about ten minutes you do not want to spend later.

Then hold two lines of discipline. Request the review only after the site is genuinely clean, because a rejected review wastes days. And submit the request once. Request a security review only after the entire site has been cleaned and the vulnerability that caused the compromise has been addressed.

Google says reviews can take from a few days to a few weeks. After you submit a review, wait for Google’s decision before submitting another request.

Do not send repeated review requests while one is already pending. Google warns that requesting review before the issue is actually fixed can increase the turnaround time for later reviews and may cause the site to be treated as a repeat offender.

On timelines, be realistic. Google’s own documentation says a review can take from a few days to a few weeks. Some hosts claim flags usually lift within 24 to 72 hours, but that figure comes from commercial sources, not from Google, so do not build your plan on it. If rankings drop while the flag is up, our guide to fixing page indexing issues covers the recovery side once the site is clean.

Do You Need to Tell Customers About a WordPress Hack?

A hacked website does not automatically mean that customer data was breached, and a technical compromise does not automatically create the same notification obligation in every jurisdiction.

Your first job is to determine what information the attacker could access, whether personal data was actually or potentially exposed, and which privacy or breach-notification laws apply to your organization and customers.

For example, under UK GDPR rules, organizations must assess the likely risk to individuals. A reportable personal-data breach generally needs to be notified to the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Where the breach is likely to create a high risk to affected individuals, they may also need to be informed without undue delay.

US requirements vary by state, type of data, industry, and circumstances.

Keep a written incident record even if your assessment concludes that external notification is not required.

This article is not legal advice. If customer, employee, payment, health, identity, or other sensitive data may have been exposed, involve the appropriate privacy, legal, compliance, or insurance contacts as early as possible.

Conclusion

The first hour after a WordPress hack decides whether recovery is a clean handover or a repeating nightmare. Take the site offline, preserve a full snapshot before touching anything, rotate every credential and force all sessions out, get your host and their logs involved, and pin down your last known clean date before any restore. Delete nothing. The most expensive mistakes, panic-deleting evidence, restoring an infected backup, and locking the door with the attacker still logged in, all happen in this hour, and all of them are avoidable by following the sequence in order.

Frequently asked questions

What should I do first if my WordPress site is hacked?

Take the site offline first, using maintenance mode or a host-level suspension. This stops the hack from spreading malware to visitors while you work. Then preserve a full snapshot of the infected site, change every credential, force all sessions to log out, and open an emergency ticket with your host.

Should I delete the hacked files immediately?

No. Deleting files in the first hour destroys the evidence of how the attacker got in, which means the same route stays open for a repeat attack. Preserve a complete snapshot of the infected site first. Deletion belongs to the cleanup stage, after you understand the incident.

Should I take my website offline if it is hacked?

Yes. A site in maintenance mode loses some traffic for a few hours. A site left online can distribute malware to your visitors, expose customer data, and deepen the damage to your Google standing. If the site handles personal data or payments, taking it offline also limits your exposure.

Can I just restore a backup?

Not yet. Many backups were taken after the initial breach, so restoring one puts the malware straight back. First establish when the site was last known clean, then pick a backup older than that date. Even then, the vulnerability that let the attacker in still needs to be closed.

How long does Google take to remove the hacked warning?

Google says a security review can take from a few days to a few weeks. Submit the request only after every reported security issue has been fixed across the site, then wait for Google’s decision before submitting another request. Avoid relying on unofficial promises of 24- or 48-hour removal times.

Get the first hour handled for you

If you run an agency and a client’s site just went down with a warning screen, the first hour is exactly the window where a second pair of experienced hands earns its keep. Survyc is an AI-first digital agency, and we handle hacked-site response and recovery white label, as part of your team, so your client sees their site contained and cleaned under your name. We also run WordPress care plans that catch the next incident in minutes instead of weeks. Reach out at info@survyc.com and tell us what happened. Send the screenshots too; you preserved them for a reason.