Practical WordPress advice for website owners
WordPress Homepage Replaced With a Hacked Message? Recover a Defaced Business Website
In this guide
If your WordPress homepage has been replaced with a “hacked by” message, preserve the visible evidence and investigate what was changed before restoring the page. The replacement may live in page content, a template, a standalone file or routing configuration. Editing the visible text can restore appearances while leaving the attacker’s access intact.
Treat confirmed unauthorized replacement as a security incident. If visitors are being shown abusive content, false payment instructions or unsafe downloads, coordinate a temporary public restriction with your host while retaining access for investigation. Use the first-response checklist for the broader containment work.
Save what visitors actually saw
Record the affected URLs, screenshots, time and timezone, first customer report and last known correct appearance. Note whether the problem occurs while signed out, on mobile and on more than one connection. Preserve the page response where practical, but do not follow links or open downloads inserted by an intruder.
The WordPress hacked-site guidance identifies visible unauthorized changes as an incident indicator and emphasizes documenting symptoms. Keep a private record of recovery actions as well. A developer needs to distinguish the attacker’s edits from changes made during the response.
Ask the host to preserve relevant access and error logs before they rotate. Retain a secure copy of affected files and the database. Label it as an incident snapshot so nobody later mistakes it for a clean backup.
Find the layer that replaced the homepage
Use this sequence rather than rebuilding the page immediately:
- Check stored page content. Is the intended homepage still assigned, and does its editor contain the unwanted content? Compare available revisions without publishing unreviewed material.
- Check shared design elements. If several pages show the same message, review the active theme, templates, header, footer and reusable content used across those pages.
- Check the served file and routing. If the editor looks correct but the browser does not, have a developer inspect the active document root, front controller and redirect or rewrite configuration.
- Check caches after preserving origin evidence. A removed defacement can remain in a CDN or page cache, while a cached correct page can hide an ongoing origin change.
Do not identify a compromise path solely from which screen shows the damage. A stolen administrator session and a vulnerable file-writing component can both lead to visible page changes. Logs and access history are needed to support attribution.
Restore the intended content without losing newer records
If a page revision contains the trusted content, the WordPress revisions system can help compare and restore it. Review links, embedded content and business details before accepting the version. A revision restores supported content; it is not a malware scan or proof that server files are clean.
If templates or plugin files were altered, developers should replace affected code from trusted distributions or reviewed project sources. Do not overwrite legitimate custom functionality without preserving and examining it. For a heavily modified site, compare the last trusted deployment with the current installation before choosing a restoration strategy.
A full backup restore requires a separate decision about recent orders, bookings, enquiries and editorial changes. The WordPress backup documentation explains the distinction between files and database data. Use the safe post-incident restore guide to plan reconciliation instead of replacing all business records simply to recover a homepage.
When no trusted complete backup exists, recover approved copy and design assets from reliable business records and inspectable source material. Archived screenshots may help reconstruct appearance, but they cannot certify the security or functionality of the underlying code.
Check for quieter business tampering
A dramatic message draws attention away from changes that may be less visible. Compare phone numbers, contact email addresses, enquiry destinations, payment instructions, donation links and external booking URLs with records the business already trusts. Inspect the mobile header, footer and contact page as well as the homepage.
Review privileged users, recent access and configuration changes with the investigator. Remove unauthorized access through a coordinated recovery process, and rotate relevant credentials from trusted devices once the environment is ready. Owners should approve the correct business details; developers and hosts should handle code, account and server findings.
If checkout content or scripts changed, the checkout security incident guide provides the appropriate additional scope. Do not conclude that payment data was stolen from defacement alone, or conclude that it was safe merely because the main payment form still worked.
Verify the recovered website in public conditions
After the origin is corrected, clear the relevant caches deliberately and inspect signed-out pages on desktop and mobile. Verify the intended homepage assignment, navigation, metadata, contact links and any downloadable files. Submit a controlled enquiry and confirm the message arrives at the approved destination.
For transactional sites, use supported test workflows and reconcile the result with the administrative record. Review logs and monitored file changes for renewed tampering. Record the repaired layer, corrected access route where established, remaining uncertainty and who will review the next monitoring window.
Recovery is stronger when the business can demonstrate both the intended public content and the operation of its essential functions. A screenshot of the repaired homepage addresses only one of those requirements.
FAQs
Can I delete the hacked message and carry on?
You can remove public harm as part of containment, but the unauthorized access and other changes still need investigation. Preserve evidence before replacing content whenever practical.
Why is the WordPress editor correct while the homepage is defaced?
The replacement may be outside that page’s content, including a shared template, served file, routing rule or cache. Have a developer identify which layer produces the response.
Will restoring a revision undo the entire hack?
No. A revision can recover supported page or post content. It does not remove malicious files, revoke unauthorized access or validate other settings and business details.
Prepared for website owners by Nithu / Suthakaran Nithursan. Dated advisory facts link to primary sources. Examples are illustrative and are not client results or guarantees.