You open your homepage and see a message you didn’t write. The logo is gone, strange links are everywhere, or visitors are being sent somewhere else.
That’s a website defacement attack, and if you’re dealing with one right now, don’t panic or start deleting things at random.
It can look like a simple visual problem, but it may point to a wider WordPress compromise your visitors can’t see. This guide will help you understand what you’re dealing with, avoid mistakes that make recovery harder, and work out when you can handle the incident yourself or need expert help.
TL;DR: Put the site into maintenance mode, save evidence, contact your host, and and scan the complete WordPress installation for malware. Then restore from a trusted backup, change every related password, fix the weakness, and monitor the site for signs of another attack.
Your homepage has been defaced. What now?
Take the site out of public view before trying to remove the attacker’s message.
Put WordPress into maintenance mode or ask your host to temporarily isolate the site. This protects visitors from malicious redirects, fake login forms, harmful downloads, and injected scripts. Before changing anything, save:
- Screenshots of the affected pages
- The page URLs and redirect destinations
- The time you discovered the attack
- Relevant login, hosting, and error logs
- Details of unfamiliar users, files, or changes
This is the mistake I see most often: someone replaces the defaced homepage, sees that the site looks normal, and assumes the problem is over. The visible message is only evidence of the compromise, not the entire compromise.
Contact your hosting provider and ask them to check for unusual logins, changed files, new users, and suspicious activity on the hosting account. Also review your domain registrar, DNS provider, CDN, and deployment tools. The attacker may have changed something outside WordPress.
📝 Note: If your site handles payments, health information, or customer data, involve the person responsible for security and privacy response. Reporting duties depend on your location, industry, contracts, and the type of data involved.
What is a website defacement attack?
You don’t need to know the technical definition to respond correctly, but it helps to understand what the visible damage is telling you.
A website defacement attack occurs when someone changes your website without permission. They may replace content, add unwanted links, change images, inject code, or redirect visitors to another site.
Some attacks are obvious, whereas others only affect mobile visitors, search traffic, or specific pages. The attacker may also create a hidden administrator account, install a backdoor, or alter the database while leaving most of the site looking normal.
That’s why a defacement should be treated as a wider security incident until you know how the attacker got in and what they changed.
How did the attacker get access?
Find the entry point before restoring the site, or the attacker may return. Common WordPress security issues that can lead to unauthorized access include:
- Stolen or reused passwords
- Outdated plugins or themes
- Vulnerable custom code
- Compromised administrator accounts
- Unsafe file uploads
- Excessive user permissions
- Compromised hosting, FTP, SSH, DNS, or deployment accounts
Start with WordPress users and roles. Look for unfamiliar administrators, changed email addresses, unexpected role changes, unknown application passwords, and suspicious password resets.
Then review WordPress core, plugins, themes, custom code, upload folders, and server rules. Pay particular attention to software that is outdated, abandoned, or no longer needed. The database matters too since attackers can store redirects, scripts, spam links, and new user records in posts, pages, widgets, menus, options, and custom tables. Finally, check connected services such as:
- Hosting-panel accounts
- FTP and SFTP users
- SSH keys
- Database users
- DNS records
- CDN settings
- Email accounts
- Deployment tools
- API keys
A malware scanner will help find suspicious files and database changes. We recommend scanning and cleaning the entire site rather than treating the changed page as an isolated problem. Its scanner and cleanup service may be useful after you contain the attack. Check the current features and plan details before relying on it.
Should you clean the site or restore a backup?
Use a known-clean backup when possible, but don’t assume the newest backup is safe.
The attacker may have entered before your latest backup was created. If so, restoring that backup could bring the malicious code or unauthorized account back with it. Before restoring, check:
- When the backup was created
- When the defacement first appeared
- Whether the backup predates suspicious activity
- Whether it contains unfamiliar users or changed files
- Whether it passes a malware scan
Restore the backup to staging and validate it first if you can. If you can’t identify when the compromise began, rebuilding may be safer. Reinstall WordPress and trusted plugins from official sources, then restore reviewed content and media. Reapply custom code from a known-good source instead of copying the entire compromised installation.
If you clean the existing site, search for backdoors, hidden users, malicious scheduled tasks, injected scripts, altered server rules, suspicious upload files, and database redirects.
📝 Note: Clearing the cache or replacing the homepage doesn’t remove malware. If you can’t explain why the files, database, and accounts are clean, ask a qualified WordPress security professional for help.
How do you know the site is clean?
A normal-looking homepage isn’t proof that the recovery worked.
Test the site as both a visitor and an administrator. Check the homepage, important pages, login, password reset, forms, search, media, checkout, payments, email, and redirects. Use a clean browser or device, look at the final destination after redirects, and check the page source for unfamiliar scripts, frames, downloads, and external domains.
Then change every credential connected to the site:
- WordPress administrator passwords
- Hosting and domain passwords
- FTP and SFTP credentials
- SSH keys
- Database passwords
- DNS and CDN credentials
- Email passwords
- API keys and deployment tokens
Enable two-factor authentication for WordPress accounts and multi-factor authentication on connected services wherever possible. Remove unknown users, keys, sessions, and application passwords, then rotate the WordPress salts and security keys to invalidate active login sessions. Reduce administrator access so each person has only the permissions they need. Keep an eye on the site after recovery, look for new users, unexpected file changes, redirects, failed logins, server errors, and unusual outbound requests.
How can you prevent another defacement?
Use several layers of protection because no single security tool covers every attack.
- Keep WordPress, plugins, themes, server software, and custom dependencies updated.Follow a controlled process for applying WordPress security updates so known vulnerabilities are patched without creating avoidable downtime. Remove unused plugins, themes, accounts, and integrations because anything left installed can become another attack path.
- Protect WordPress, hosting, DNS, FTP, SSH, deployment, and email accounts with unique passwords and multi-factor authentication. Review administrator access regularly.
- Limit who can upload files or edit code. Harden the WordPress
wp-config.phpfile, validate uploaded files, and prevent executable files from running in upload directories where appropriate. - Keep backups away from the live server and test that they can be restored. Backups help you recover, while updates, malware scanning, WordPress firewalls, access controls, and monitoring help prevent or detect attacks.
- HTTPS is still important because it encrypts traffic between visitors and your site. It does not prevent stolen passwords, vulnerable plugins, malware, compromised hosting, or DNS changes.
📝 Note: An online store needs faster detection and recovery than a simple blog, but every WordPress site should have protected accounts, updated software, independent backups, and a tested recovery plan.
FAQs
Is a defaced website hacked?
Treat it as compromised until you investigate it. Defacement proves that someone changed the site without permission, but it doesn’t show whether they also installed malware, created accounts, or accessed data.
Can a backup remove a website defacement?
A clean, validated backup can restore the site, but it doesn’t replace an investigation. Scan the backup, review its users and settings, and change related credentials before restoring it publicly.
Is website defacement a data breach?
Not necessarily. Defacement means that website content or code was changed. A data breach involves unauthorized access to data. Both can happen in the same attack, so review logs and connected systems.
Does HTTPS prevent website defacement?
No. HTTPS protects data in transit, but it doesn’t prevent vulnerable software, stolen passwords, malicious uploads, compromised hosting, or DNS changes.
How can I prevent a website defacement attack?
Keep software updated, remove unused components, use unique passwords and multi-factor authentication, limit permissions, secure uploads, monitor changes, scan for malware, and keep tested off-site backups.
Conclusion
A website defacement attack is a warning that someone gained unauthorized access to your site. Contain the damage, preserve evidence, investigate WordPress, hosting, DNS, files, databases, and user accounts, then restore only from a backup you can validate. After recovery, fix the entry point, rotate credentials, enable stronger account security, and monitor for repeat activity.
Start with a full malware scan and a complete review of your credentials, then keep monitoring the site after it comes back online. A homepage that looks normal isn’t the finish line; a website you can trust is.
