Recovering a hacked website involves two separate decisions: how to address the compromise, and how to recover any content that was lost. A verified usable backup may supply a native recovery source. If no suitable native copy survives, archive captures may help reconstruct public pages. Neither route, by itself, proves that the security problem has been removed.
Use this guide to decide which content source to assess and what evidence to give the responsible security specialist. It is not a malware-removal tutorial, a forensic investigation or a promise that an archived version is safe to deploy.
Confirm the symptoms without assuming the cause
A changed homepage, unexpected redirects or unfamiliar users deserve investigation. A blank screen alone does not establish a hack. Record the specific symptom, when you first noticed it and any provider or browser warning. Avoid repeatedly opening suspicious pages or asking customers to test them.
The official WordPress hacked-site guidance recommends documenting symptoms and retaining an environment snapshot before cleanup. Ask a qualified person to preserve relevant evidence safely. Do not execute files from an untrusted backup or restore a suspect copy into an ordinary live environment merely to see what happens.
Keep two questions distinct:
- Security question: What was compromised, and what must change before the environment can be used safely?
- Content question: Which legitimate pages, images or records are missing, and where do reliable copies survive?
That distinction prevents a design rebuild from being mistaken for security remediation. A restored homepage can look familiar while other parts of the system still require investigation.
Have the compromise assessed before choosing a recovery copy
The responsible security specialist should assess the affected application and environment, the likely entry point, access and the recovery plan. The owner should also agree who manages containment, credentials, software updates and any obligations arising from exposed information. Those responsibilities should not disappear inside a general “restore the website” request.
WordPress describes security as risk reduction rather than perfect risk elimination in its hardening documentation. It also illustrates why the date of detection can be later than the date of compromise. A backup from before you noticed the problem therefore needs review; its date alone is not proof that it is clean.
Preserve the distinction between evidence and a recovery source. A suspect backup can help an authorized specialist understand an incident without being suitable for live restoration. Label its provenance and date, keep access controlled and let the specialist decide how to inspect it.
Assess backup recovery first when a suitable copy exists
A native backup may retain information that a public archive cannot provide. Ask what it contains, when it was created and whether the corresponding files and database belong together. Also identify legitimate changes made after that recovery point.
For a store or membership website, recent business records need an application-specific recovery plan. An older copy may omit them. A public page that displays a product or login form is not a substitute for the underlying transaction or account data.
The review should answer these questions before approval:
- What evidence supports this copy as a suitable recovery source?
- Has the suspected compromise been considered when selecting its date?
- Which legitimate changes would a restore replace or omit?
- Where will the copy be tested without exposing visitors?
- Who verifies security separately from content completeness?
A tested recovery plan should state unresolved items openly. Do not replace “we found a backup” with “we can recover everything.”
Use archives for missing public content, not incident rollback
If no usable native copy exists, older captures may contain legitimate article text, public images and layout references. Compare the capture dates with the known incident timeline and inspect what each capture actually contains. A capture may show a defaced page, a malicious redirect or content from a period whose status is uncertain.
Treat captured material as evidence to review, not executable material to trust automatically. A reconstruction plan should identify the pages and assets selected, any suspicious or uncertain material excluded, and the gaps still requiring an owner-supplied source.
The Internet Archive explains that captures do not retain original functionality when elements depend on interaction with the originating host. Public captures therefore cannot provide the original private database, account access or a working checkout simply because those interfaces appear in a snapshot.
Our Wayback Machine restoration guide covers the public-page reconstruction process. Rebuilding captured content on an approved destination remains separate from verifying that the destination and its application are secure.
Create a content-source decision record
Use this original checklist to keep the content decision visible alongside, but separate from, the security investigation. It is not a case study or a security certificate.
| Decision | What to record |
|---|---|
| Incident timeline | First noticed date and any earlier compromise date supported by the specialist’s evidence. |
| Candidate source | Backup, export, surviving file or archive capture, with its date and provenance. |
| Legitimate content | Specific pages or assets that the owner recognizes and wants recovered. |
| Uncertainty | Suspicious material, unknown dates, missing pages and items needing further review. |
| Excluded data | Private records or functions that the selected public source cannot supply. |
| Separate approvals | Content acceptance by the owner and security release by the responsible specialist. |
For each important page, retain its original address and a known legitimate reference where available. Do not automatically create new URLs to escape an incident. URL decisions need their own evidence and approval.
Verify security warnings separately from the rebuild
If Search Console lists a security issue, the site’s authorized owner or specialist should follow the Security Issues report guidance. Google says example URLs are samples, not necessarily a complete list, and a review should be requested after the reported issues are fixed throughout the site.
Publishing rebuilt pages does not itself constitute that review, remove every warning or guarantee the return of rankings. Keep the security work, review status and content recovery results as separate records.
Wayback Restore’s website recovery assessment can evaluate available public content for reconstruction when native recovery is unavailable. Agree that public-content scope explicitly. Malware removal, incident forensics, private-data recovery and security clearance require separately defined specialist work, not assumptions based on a restoration service name.
Frequently asked questions
Is a backup from before I noticed the hack automatically safe?
No. Detection may occur after compromise. Have the responsible specialist review the recovery source and incident evidence before approving a restore.
Can an old Wayback capture contain hacked content?
It can show the page that was available when captured, which may include unauthorized changes. Check dates and visible content, and do not treat a capture as a security-certified copy.
Will archive reconstruction restore customer accounts and orders?
Public snapshots do not supply private account or transaction data. Recovering those records requires an appropriate native source and application-specific assessment.
