WordPress incidents
Hacked WordPress website: investigation, cleanup and recovery planning
Unexpected redirects, added content or warnings need investigation before repair. Gloria reviews the incident, defines the possible work and plans the checks needed after the agreed recovery steps.
Diagnosis and repair are quoted after reviewing the incident, access and recovery options.
Your project in practice
Example recovery record
- Observed symptoms
- Document the unexpected behaviour and affected areas
- Work performed
- Record the agreed containment and recovery actions
- Checks
- Verify the restored journeys, access and identified issues
- After recovery
- List remaining actions and the agreed monitoring responsibilities
What it can change
Assess the incident, plan repairs and check access after recovery
Review symptoms, affected access and incident evidence
Symptoms, access and available evidence help establish the incident and the priorities for handling it.
Plan backups, cleanup, restoration and work on identified causes
The scope distinguishes backups, cleanup, possible restoration and work on identified causes.
Review access, updates and post-recovery checks
Access, updates and agreed checks help make the recovery more than a change in visible appearance.
In practice
Investigate a suspected hack or check a previous repair
Your website is behaving unexpectedly
Provide its address, the symptoms and when they appeared so the review and necessary access can be scoped.
An initial repair has already happened
We examine the work and available evidence to understand what may remain to be addressed or checked.
The scope
WordPress recovery scope, backups and access requirements
Open the sections below to explore the scope, deliverables and practical requirements.
Describe what you have seen
Report redirects, warnings, new pages, altered files or access problems. Include when they appeared and what has already been done, particularly by the hosting provider.
Keep the available evidence. If the website appears to expose data or carry out unwanted actions, the host can help consider temporary access restrictions while the situation is examined.
Agree access and the intervention
The initial scope identifies the WordPress installation, available backups, authorised access and any dependencies on the wider hosting account. Depending on the symptoms, the review may include core files, extensions, the theme and the database.
Availability and timing are confirmed before engagement. This is not a promise of round-the-clock incident response.
Address the cause as well as the visible symptom
- Record: preserve useful information and establish the initial state.
- Investigate: identify changes and the area that can be examined.
- Repair: clean or replace the agreed components and review affected access.
- Check: verify the pages, administration and critical functions in scope.
If the cause cannot be established within the original scope, we explain what remains uncertain before proceeding.
Plan what happens after the repair
The handover separates completed work from further measures. Updates, access, backups and maintenance responsibilities need a practical owner after the incident.
Related French resources cover prevention, extension choices and backups: Guide complet sécurisation WordPress 2025; Choisir la bonne extension sécurité; Sauvegardes WordPress : bonnes pratiques.
Define the completion checks
The proposal specifies what will be examined, repaired and verified. Removing a technical problem does not automatically remove a warning in Google or a security service; those services have their own review processes.
You receive the findings and recommendations needed to continue looking after the website.
Practical guide
Prepare an incident description that helps the investigation
Unexpected behaviour may affect only particular pages, devices or visitors. Record the affected address, what happens, when it was first noticed and what has already been attempted. Screenshots and hosting-provider messages can help. Do not place passwords, access tokens or customer information in a public description of the problem.
A succession of undocumented changes can make the incident harder to understand. Restoring backups, deleting components and changing settings may remove useful evidence or alter the symptoms. The initial task is to identify available access, preserve relevant information and consider how to reduce exposure while taking account of business operations.
Prepare the hosting contact, known backups and a list of people or suppliers with access. Mention whether the site takes payments or receives sensitive information. That affects recovery priorities and the checks required, but an unusual page alone does not establish whether data has been exposed. The investigation should separate confirmed observations from possibilities that still need examination.
Practical guide
Illustrative recovery decision: an older shop backup is available
A fictional shop begins redirecting some visitors to an unwanted site. The owner has an older backup and wants to restore it immediately. The copy may be useful, but its existence leaves two important questions unanswered: does it already contain the problem, and what recent orders or changes would be lost?
Swipe across the table to see every column.
| Area | Evidence to examine |
|---|---|
| Backup condition | Date, contents and evidence supporting its suitability |
| Recent information | Orders, accounts and content added since the copy |
| Underlying cause | Compromised access or an affected component that may remain |
| Return to service | Functions to test and the person authorised to accept recovery |
Restoring a copy without addressing the cause can leave the problem able to recur. Rebuilding everything can also discard useful information unnecessarily. This fictional scenario illustrates the choices to document; it is not a diagnosis or a universal recovery procedure.
Practical guide
Define recovery work and the handover afterwards
The scope depends on the incident's extent, available access, backup condition and business functions that must be restored. Separate investigation, cleanup or restoration, treatment of identified causes and any later monitoring. Ongoing maintenance, continuous surveillance or replacement of an abandoned component should not be assumed to be included in a one-off intervention.
A useful handover records what was examined, what changed, which checks were completed and what limitations remain. Temporary access should be addressed as part of closure, and responsibility for later updates should be clear. This is especially important where several suppliers share control of the website and hosting.
- Repeat the reported behaviour in the affected circumstances.
- Test important functions, including login, forms and checkout where relevant.
- Confirm agreed access changes and the availability of a usable backup.
- Record dependencies or components that still require a business decision.
A symptom disappearing is not, by itself, proof that every possible issue has been removed. Recovery should be assessed against the evidence and checks available. A responsible report explains what was verified and what remains uncertain, without promising that a website can never be compromised again or that every consequence of the incident is already known.
Questions about restoring a backup and sharing access securely
Will restoring a backup solve the problem?
It may help if the backup is suitable. The possible cause and affected access also need examination, otherwise the restored site may face the same problem again.
Should I send passwords with my first message?
No. Describe the situation first. The necessary access and how to provide it are agreed afterwards.
Describe the symptoms and timing of your WordPress incident
Share the website address, the symptoms, when they appeared and any action already taken.
Discuss your project