Hacked WordPress site: how to regain control and prevent a repeat incident

Hacked WordPress site: how to regain control and prevent a repeat incident

If your WordPress site has been hacked, limit visitors’ exposure, preserve a copy of the files, database and available logs, and regain control of your accounts with your hosting provider. Clean the site and fix the entry point before reopening. Restoring a backup without addressing the cause can bring the incident back.

A customer reports being sent to an unrelated website, yet your homepage looks normal. An unfamiliar administrator appears. Or Google displays a security warning before your shop. For a small business, the immediate question is who should act and what can be stopped without losing orders, enquiries or evidence. This guide sets out the decisions to make with your technical team, without blindly deleting the installation.

1. Record the symptoms without exposing more visitors

Save the affected URLs, discovery time, screenshots and warning messages. Note whether the issue appears on mobile, after clicking a Google result or only when logged out. Malicious redirects can be conditional: failing to reproduce one while signed in as an administrator does not rule out a compromise.

A slow page or a technical error alone does not prove a hack. A normal homepage does not exclude spam pages or a compromised account either. Send your observations to the hosting provider or incident handler instead of repeatedly opening suspicious links. Do not ask customers to visit a potentially harmful page to help you test it.

2. Contain the incident and preserve evidence

If visitors face malicious redirects, suspicious downloads or fraudulent data collection, ask your hosting provider to restrict access or serve a clean holding page. A maintenance plugin running inside compromised WordPress cannot guarantee that harmful content is inaccessible.

Before cleanup, request a timestamped copy of the files and database and retention of available logs. Store the copy outside the affected installation with restricted access. It may contain malware: it is evidence and a fallback, not a site ready to put back online. The official WordPress hacked-site FAQ recommends taking a snapshot before cleaning.

Appoint an incident owner and a business contact. The incident owner coordinates changes; the business contact confirms which functions must work, such as enquiries or checkout. This prevents one person’s restore from overwriting another person’s recovery work.

3. Recover control beyond the WordPress password

If you cannot sign in, contact your host through a trusted channel and establish ownership of the account. Do not hand credentials to someone who approaches you unsolicited after noticing the incident. From a trusted device, review access to hosting, domain management, recovery email, file transfer and WordPress.

Your incident handler should review administrator accounts, remove unauthorised access, revoke affected sessions and secrets, and enable multifactor authentication where available. Exposed passwords must be changed; credential rotation should also be checked after cleanup so usable secrets are not left in the compromised environment. Changing one administrator password does not remove malware already installed on the server.

4. Choose cleanup or restoration around the data you must retain

An available backup is not necessarily clean. Establish when it was made, compare that with the earliest evidence of compromise, and test restoration in an isolated environment. An infection discovered today may predate your latest daily backup.

Illustrative example: a shop has a backup from before the incident but has received orders since. Restoring the whole database would erase those sales. The team therefore needs to recover the relevant business records, check them and reintegrate them using a tested procedure. The decision depends on what is compromised and what can be verified, not simply on which restore button is quickest.

The cleanup scope should cover files, plugins, themes, accounts and database content, as well as redirect rules and scheduled tasks that could reintroduce malicious changes. Replacing components with trusted official copies may be necessary, but it does not remove the need to investigate added files or database changes. A scanner supports investigation; a clean scan alone does not establish that the whole environment is safe.

5. Address the cause before reopening

Ask what allowed the attacker in: a vulnerable component, stolen credentials, an overlooked account or another compromised site on the same hosting account, for example. If the logs cannot establish the cause, the report should say so and explain what was done despite that uncertainty.

Recovery must address affected components, unsupported software and excessive permissions. Test updates against business-critical functions. The official WordPress hardening guidance covers access controls, backups, logging and monitoring. Adding several security plugins without assigning someone to handle alerts does not replace that work.

6. Approve reopening against concrete checks

• Important pages work for logged-out visitors on both mobile and desktop.
• Forms, notifications and sales journeys are tested without exposing real payment data.
• Authorised accounts and access paths are inventoried; unwanted access has been removed.
• Technical checks, their limitations and applied fixes are recorded.
• A recent backup and tested restoration are available, and a named person receives and handles alerts.

If Google reports a security issue, inspect the Search Console Security Issues report. Request a review after fixing all identified problems. Google controls its warnings and their removal. A provider can prepare the review request, not guarantee Google’s decision or a search ranking.

7. Assess personal data and assign ongoing responsibility

A hacked website does not automatically require notification to a data protection authority. Establish whether personal data suffered a confidentiality, integrity or availability breach, then assess the risk to individuals. For organisations subject to French oversight, CNIL guidance requires notification of a breach presenting a risk without undue delay, where possible within 72 hours after becoming aware of it; delays must be explained. Additional information can follow. A high risk may also require informing affected individuals. Involve the data controller or DPO and document the assessment, including a decision not to notify.

After reopening, assign responsibility explicitly: who applies updates, checks backups, receives alerts and responds to another symptom? A cleanup report without these owners leaves the business to handle the next incident alone.

Get recovery support from SAY Digital

To scope an intervention, prepare your site address, symptoms, available access, known backups and business-critical functions. Do not include passwords in an initial message. Ask for a written scope distinguishing diagnosis, malware removal, data recovery and maintenance after the intervention.

SAY Digital provides maintenance, monitoring and incident management services and Cloud hosting. One-off cleanup and recurring hosting are separate services. Confirm their scope, price and applicable follow-up before committing. Hosting does not eliminate every security risk. The maintenance service page linked here is in French.

Book a call with SAY Digital to scope your WordPress site recovery.

Frequently asked questions

Should I delete the whole site and start again?

Not without a copy and an assessment. Deletion can destroy business records and evidence needed for investigation. Rebuilding may be appropriate, but it must preserve useful records and address compromised access.

Is restoring a backup enough?

Only if the backup has been checked and the cause addressed. Otherwise, you may restore an infection or leave the same entry point open.

Can a provider promise there will be no repeat incident?

Not as a blanket claim. Ask which problem was treated, which fixes were applied and what follow-up conditions and responsibilities apply. A warranty limited to a particular intervention is not protection against every future attack.

Explore your specific situation

• Visitors land on another site: diagnose a malicious WordPress redirect.
• Google displays a warning: prepare cleanup and a security review request.
• The compromise returns after intervention: investigate reinfection after cleanup.

Sources

This guide draws on the official WordPress “FAQ — My site was hacked” and “Hardening WordPress” documentation, Google Search Console’s “Security Issues report”, and CNIL’s personal data breach notification guidance. Links appear alongside the relevant recommendations. The guide helps organise a response; it does not replace a technical assessment of your installation or legal advice about a possible data breach.