A hacked site can go from “something feels off” to real damage fast, spam pages in Google, stolen logins, malware warnings, and visitors put at risk. It’s not rare either, 2025 estimates put WordPress hacks at about 13,000 sites per day, and many break-ins start with an old plugin or a reused password.

If you need to Fix Hacked Website issues, don’t look for a one-click button. Recovery is a step-by-step job, you contain the damage, find how they got in, clean the site, then lock it down so it doesn’t happen again.

This guide gives you a clear checklist, from what to do in the first hour (to stop spam and protect users) to full recovery and long-term prevention. The steps work for WordPress, Joomla, custom PHP sites, and common hosted platforms, even if your setup is different.

How to Tell if Your Website Is Hacked (Common Signs You Can Spot Fast)

Website hacks are not always loud. Some are obvious (your homepage is replaced with a weird message), but many are quiet and meant to blend in, like hidden spam pages, sneaky redirects, or malware that only shows up on phones. The sooner you spot it, the easier it is to Fix Hacked Website damage before search rankings drop, customers get warned, or your server gets abused.

Here are the fast, real-world signs you can check in minutes.

Browser warnings, spam popups, and strange redirects

If you see a browser warning like “Deceptive site ahead” or “This site may harm your computer”, treat it as urgent. Google Safe Browsing and modern browsers block pages when they detect malware, phishing, or injected scripts. Even one infected page can trigger warnings across your whole domain.

Other common signs you can spot without logging in:

• Popups you didn’t add, especially fake “Your phone is infected” alerts or push notification prompts.
• Redirects to gambling, pharmacy, or adult pages, often happening only on certain URLs.
• Mobile-only redirects, where desktop looks fine but phones get sent elsewhere (attackers do this to hide from site owners who test on laptops).

A quick check that catches a lot:

1. Open your site in an incognito/private window (no extensions, no cached files).
2. Test your homepage and a few inner pages.
3. Test on a phone using mobile data (not your office Wi-Fi), because some hacks redirect by device type or IP.

If the weird behavior disappears when you’re logged in, that can still be a hack. Some attackers show clean pages to admins and infected pages to visitors.

New admin users, locked accounts, or changed content

When attackers get into your CMS (WordPress, Joomla, Shopify apps, custom admin panels), they often try to keep access. That usually means creating new users or taking over existing ones.

Watch for these account-level red flags:

• New admin users you don’t recognize (often with normal-looking names).
• Password reset emails you didn’t request.
• Locked accounts, changed email addresses, or “someone logged in from a new device” alerts.
• New posts or pages you didn’t publish, sometimes stuffed with links to spam offers.
• Defaced content, like homepage text changed to promote a scam, or random keywords inserted into titles and footers.

Do a quick audit in your CMS:

• Check the Users list (focus on Admin roles).
• Review recent posts/pages, including drafts.
• Look at your CMS activity or security logs if you have them.

If anything looks off, assume the attacker has credentials and move fast.

Slow site, server errors, or unusual traffic and emails

Some hacks don’t touch your visible pages at all. They turn your server into a worker for someone else, which usually shows up as performance trouble.

Common symptoms include:

• The site suddenly feels slow, even on simple pages.
• You see more 500 errors, timeouts, or “resource limit reached” messages.
• Your hosting dashboard shows high CPU usage, memory spikes, or disk space filling up fast.
• Analytics shows a traffic spike from odd locations or hits to random URLs that don’t match your content.
• You get complaints that your domain is sending spam emails, or your mailbox fills with bounce-backs.

Two examples that fit this pattern are spam mail scripts (your server sends bulk email) and crypto-mining malware (your CPU gets hammered). Even if your site still loads, the damage is happening in the background, and it can get your domain or server IP blocklisted.

First Hour Checklist to Fix a Hacked Website (Stop the Damage Before You Clean)

The first hour is about containment and evidence, not hero moves. Think of it like a fire in a kitchen, you turn off the gas and clear people out first. If you rush into reinstalling and deleting files, you can wipe the fingerprints you need to prove what happened and stop it from happening again. Use the steps below in order to stabilize the situation, protect visitors, and keep the trail intact so you can properly Fix Hacked Website damage after.

Put the site in maintenance mode or take it offline (without destroying proof)

Your first goal is to stop visitors from being exposed to malware, redirects, or phishing pages. The safest approach is a 503 Service Unavailable maintenance page. A 503 tells browsers and search engines the downtime is temporary, which is better than serving hacked pages or returning a blanket 404.

A good maintenance mode setup should do three things:

• Block public access to the site pages that might be infected.
• Allow admin access from your IP (or via a secret URL) so you can investigate.
• Stop harmful scripts from running for visitors.

If you can, put maintenance mode at the web server level (hosting panel, .htaccess, Nginx rule) because it kicks in before the CMS loads. CMS plugins can help too, but remember, a compromised plugin can be part of the problem.

Two warnings that save a lot of pain later:

• Don’t reinstall WordPress or wipe the server right away. That can erase backdoors, timestamps, and logs you need to trace entry.
• Don’t start deleting “weird” files on sight. Attackers often hide clues in places that look harmless.

If the hack involves payments, logins, or customer data, keep the site offline while you contain. A short outage is cheaper than a long cleanup plus angry customers.

Contact your hosting provider and isolate the account or server

Your host can see things you can’t, like server level processes, unusual resource spikes, and signs of cross account spread. Contact them early and ask for isolation so the infection can’t keep moving.

Here’s what to request in plain terms:

• Suspend risky processes: ask them to stop suspicious PHP workers, cron jobs, mail scripts, or unknown running processes tied to your account.
• Check if other sites are affected: if you have multiple domains on the same hosting account, ask them to scan all of them.
• Confirm your last known good backup points: ask what backups exist (daily, weekly, snapshots), and the exact timestamps available.
• Provide logs: request access to raw access logs and error logs for your domain (or have them export them for you).
• Quarantine options: ask if they can clone the site to a staging area for investigation while keeping the public site blocked.

Shared hosting deserves extra caution. One hacked site can sometimes be used to poke at other sites on the same account, especially if file permissions are loose or the attacker gets control of the account user. Isolation reduces the chance you clean one site and get reinfected from the neighbor site five minutes later.

Make a full backup for forensics, then reset all passwords

Before you clean anything, make a full snapshot backup. This is your evidence bag. It also gives you a rollback point if cleanup breaks something.

Back up these items, at minimum:

• All site files: web root, CMS folders, uploads, themes, plugins, and any hidden files.
• Database: full export of the site database.
• Config files: CMS config (for WordPress, wp-config.php), .env files, .htaccess, server config snippets.
• Scheduled tasks: cron job definitions in your hosting panel or server.
• Any custom scripts: especially anything tied to forms, email sending, or integrations.

Store the backup off-server (local drive and a cloud folder). If the server is still under attacker control, an on-server backup can get altered.

Once the backup is safe, start resetting credentials. Prioritize accounts that can restore access:

• Hosting control panel (cPanel, Plesk, custom dashboard)
• CMS admin users (reset passwords, remove unknown admin accounts)
• Database user password (then update the config file to match)
• Email accounts used by contact forms (and any SMTP accounts)
• FTP/SFTP accounts (disable FTP if possible, use SFTP)
• SSH keys (rotate keys, remove unknown keys, change passphrases)
• API keys and app tokens (payment gateways, maps, email services, CRMs, shipping tools)

Use a password manager and set long, unique passwords. If you reuse passwords anywhere, assume those are burned too.

Save and review logs and timelines (you will need them later)

Logs turn guesswork into facts. Even if you plan to hire help, saving logs now makes that help faster and cheaper. Copy them off the server before they rotate or get overwritten.

Try to preserve these log types:

• Web access logs (requests, IPs, user agents, unusual POST bursts)
• Web error logs (PHP errors, file include errors, permission issues)
• Auth logs (control panel logins, SSH login history)
• FTP/SFTP logs (file uploads, logins, unknown IPs)
• Mail logs (outbound spam attempts, mail script abuse)

Next, write a simple timeline in a text file. Keep it short and factual:

• When you first noticed something wrong (time and date)
• What you saw (redirects, new users, warnings, slow server)
• What changed recently (new plugin/theme, CMS update, hosting change)
• Any recent admin activity (new accounts, password resets, contractor access)

This timeline helps you pinpoint the entry point. It also helps you prove what happened if you need to report the incident, dispute fraud, or explain downtime to stakeholders.

Remove Malware and Backdoors (The Clean Up Step That Actually Fixes the Hack)

Containment buys you time, cleanup is what actually Fix Hacked Website problems. This step is about removing the attacker’s code and access paths, not just making the homepage look normal again. If you miss a backdoor, you will get reinfected, sometimes within hours.

You have two main paths: restore a known clean backup, or rebuild from clean sources. Either way, work in a staged copy first, scan after every big change, and keep notes on what you removed.

Option A: Restore a known clean backup (fastest and usually safest)

If you have backups and you trust them, restoring is often the cleanest win. It replaces a lot of unknowns with a known working state, which is exactly what you want when time matters.

How to pick the right backup date

Choose a restore point from before the first sign of trouble, not just before you noticed it. Hacks often sit quietly.

Use clues to pick the date:

• The earliest spam page you can find in Google, Search Console, or your sitemap history.
• The first odd redirect or browser warning you saw.
• A traffic spike, CPU spike, or email spam burst in your host stats.
• Log entries showing new admin creation, unusual POST requests, or repeated login attempts.

A practical rule: if you noticed the hack on Tuesday, Monday’s backup might still be dirty. Go back further, then move forward carefully.

Test on staging first

Restore the backup to a staging copy (a host-provided staging site, a cloned folder, or a temporary subdomain). Then:

1. Scan the staging site for malware.
2. Browse key pages in incognito and on mobile data.
3. Check admin users, scheduled tasks, and redirects.
4. Only after it looks clean, repeat the restore on production.

Don’t restore without fixing the entry point

Restoring files and database does not stop the attacker from coming back through the same hole. Before you go live, close the common doors:

• Update the CMS, plugins, and themes.
• Remove unused plugins and themes.
• Rotate passwords and keys again (hosting, CMS, database, SFTP, email).
• Remove unknown admin users.

After the restore, scan again. Then clear caches (plugin, server, CDN) so you are not still serving infected pages.

Option B: Do a clean reinstall of your CMS, themes, and plugins (when backups are not clean)

If backups are missing, too recent, or already infected, a clean reinstall is usually safer than trying to scrub every file by hand. Think of it like replacing the locks and the doors, not just sweeping up broken glass.

Replace core files from the official source

For WordPress and similar CMS platforms, your core folders should be predictable. The safest approach is:

• Download a fresh copy from the official CMS site.
• Replace core folders and files on the server.
• Treat core directories as “no-edit zones” (for WordPress, wp-admin and wp-includes should not contain random extra files).

If you find unknown PHP files sitting in core folders, assume they are malicious until proven otherwise.

Reinstall only what you need

Start clean, then add parts back with intention:

• Install themes and plugins only from trusted sources (official repos, reputable vendors).
• Delete anything you do not use, even if it is inactive.
• Keep a short “must-have” list so you do not bring back old risk.

Never reuse unknown zip files or nulled themes

Don’t upload “that plugin zip you had on your laptop” unless you can confirm where it came from. And skip nulled themes and plugins completely. Pirated packages are a common way backdoors get reintroduced, even after a perfect cleanup.

Copy content carefully

Your content is usually safe, but it can carry injected scripts.

Move data in a controlled way:

• Copy uploads after scanning it (images should not contain PHP).
• Export and import posts and pages, then spot-check for strange scripts.
• Recreate config files manually instead of copying old ones blind.

When the rebuilt site works, scan again, then move it live.

Hunt and remove common malware patterns in files and folders

Even after a restore or reinstall, do a targeted search. Attackers hide small “return keys” that look harmless.

Common file-based malware and backdoor patterns include:

• Randomly named PHP files in places that normally hold media, like uploads, images, cache, or tmp.
• PHP inside uploads, for example invoice.php or image.php mixed with images.
• Obfuscated code using functions like eval, base64_decode, gzinflate, str_rot13, system, passthru, or shell_exec.
• Very long, unreadable strings that look encoded, often glued into the top or bottom of legitimate files.
• Reinfection triggers through cron jobs or scheduled tasks that pull code from remote URLs.

Also check your redirect controls:

• .htaccess rules that send visitors to spam sites.
• Server config entries (Nginx, Apache vhosts) that add hidden redirects.
• JavaScript files that load unknown third-party scripts.

After you remove or replace suspicious files, scan again, then re-check the same folders. Backdoors like to come in pairs.

Clean the database and user accounts (spam posts, injected scripts, hidden admins)

A site can look clean while the database keeps reinfecting it. Database cleanup is where spam pages, hidden redirects, and admin takeovers often live.

Before you touch anything, make a fresh database backup and store it off-server. If a cleanup breaks your site, that backup is your undo button.

Audit users and access first

• Remove any admin user you did not create.
• Check that admin emails are yours, not changed to a strange address.
• Review roles and capabilities for accounts that should not have them.

Look for injected scripts and spam content

Focus on:

• Posts and pages with hidden links, strange keywords, or blocks of JavaScript.
• Widgets, header/footer areas, and “custom HTML” sections.
• CMS options and settings fields that hold URLs, especially anything that controls site home URL, scripts, or analytics inserts.

If you find injected JavaScript, remove it and then check the same page in the editor and in the live HTML output. Some malware re-adds itself through scheduled tasks or a compromised plugin.

Once the database is cleaned, rotate database credentials (create a new database user and password, update the config), then scan again and watch for any new spam pages appearing.

Close the Hole: Find the Entry Point and Lock Down Your Site

Cleaning malware is only half the job. If the weak spot stays open, the attacker (or a bot) can walk right back in and undo your work. This is the hardening phase of any Fix Hacked Website recovery, you update what’s exposed, lock down file write access, tighten logins, then add a firewall and monitoring so you catch problems early.

Update everything and remove what you do not use

Most break-ins start with an old component. Updates close known holes, but only if you actually install them and remove the dead weight that never gets patched.

Focus on four areas:

• CMS core: Update WordPress, Joomla, Drupal, or your site framework to the latest stable version. If you can’t update, treat that as a risk you need to fix next.
• Plugins and extensions: Update all plugins, modules, and add-ons. Then delete anything inactive or unused. Inactive does not mean safe, the code is still on the server.
• Themes and templates: Update your active theme, then delete unused themes. Attackers love old default themes because they’re common targets.
• Server packages: Ask your host (or your sysadmin) to patch the stack, PHP, database server, web server (Apache/Nginx), control panel, and libraries. A patched CMS on an old server can still be a problem.

Also remove things attackers often abuse after the first entry:

• Abandoned extensions: If a plugin hasn’t been updated in a long time, replace it with a maintained option.
• Old backup files in public folders: Delete .zip, .tar, .sql, and “backup” directories inside public_html, www, or your document root. A forgotten backup.sql is a gift to an attacker.
• Extra install folders: Remove leftover setup scripts, old site copies, and staging folders that never got protected.

A simple rule helps: if you don’t need it to run the business, it doesn’t belong on the server.

Fix permissions and file access (stop attackers from writing files)

Even with clean files, bad permissions let attackers write new malware. Think of permissions like who has keys to which rooms. You want the web server to read what it needs, but you don’t want it to rewrite your site whenever it wants.

Start with these safe defaults (common on Linux hosting):

• Folders: 755
• Files: 644
• Avoid world-writable permissions like 777 (or any setup where “everyone” can write).

Then lock down your most sensitive files:

• WordPress: protect wp-config.php
• Other stacks: protect .env files and any config file holding database passwords or API keys

If your host supports it, add rules so these files can’t be fetched from the web, even by mistake.

Next, reduce the ways attackers sneak executable code onto your server:

• Restrict upload types: Only allow the file types you really use (for example, images and PDFs). Don’t allow uploads of .php, .phtml, or “double extension” tricks like image.jpg.php.
• Turn off PHP execution in uploads: Many hacks drop a backdoor into an uploads folder because it looks normal. If your server lets you, block PHP from running inside /wp-content/uploads/ (and similar media folders).

One more practical win for WordPress: disable the built-in theme and plugin file editor, so stolen admin access can’t edit files from the dashboard.

Add strong login security: MFA, least privilege, and safer admin URLs

If an attacker got in once, assume passwords or sessions might have been exposed. Tighten logins so one leaked password can’t take the whole site down again.

Do this in order:

1. Use strong, unique passwords everywhere: hosting panel, CMS admins, database, email, FTP/SFTP, and any third-party services. A password manager makes this realistic.
2. Turn on MFA for admins: Enable multi-factor authentication (app-based codes or security keys) for every admin account that supports it, especially WordPress admin and your hosting control panel.
3. Cut down admin accounts: Keep admin roles to the minimum. For day-to-day work, use editor or manager roles. Remove old contractor accounts and any user you can’t verify.
4. Stop shared logins: Shared admin credentials kill accountability. Give each person their own account so you can track actions and remove access fast.
5. Block brute-force attempts: Rate-limit failed logins and lock out repeat attempts. Add CAPTCHA where it fits, especially on login, password reset, and contact forms.

If your CMS allows it, protect admin access with a safer path or extra gate (like IP allowlisting or a second password prompt). It won’t replace MFA, but it cuts noise and slows bots down.

Use a firewall and security monitoring to block repeat attacks

A Web Application Firewall (WAF) is a bouncer for your website. It sits in front of your site and filters traffic, blocking known bad requests before they hit your CMS, plugins, or login page. This matters because many attacks are automated, bots scan the internet for the same old holes all day.

A solid WAF setup helps with:

• Blocking common attacks: SQL injection, cross-site scripting attempts, malicious bots, and known exploit patterns.
• Rate limiting: Slows down login brute-force attempts and spam floods.
• Bot protection: Challenges or blocks suspicious traffic, which reduces server load and form abuse.

Pair the firewall with basic monitoring so you see trouble early:

• File change alerts: Get notified when core files or plugin files change unexpectedly.
• Login alerts: Track new admin users, logins from new locations, and repeated failures.
• Malware scans: Run scheduled scans, then review results instead of ignoring them.

Hardening is what makes a Fix Hacked Website recovery stick. Without it, you’re just cleaning up the same mess on repeat.

Get Back on Google and Rebuild Trust After a Hack

Once you’ve cleaned the infection and locked down the entry point, the next job is getting your visibility and trust back. This is the part where a lot of site owners rush, bring the site online too soon, request reviews too early, or stay silent with customers. To truly Fix Hacked Website fallout, treat recovery like reopening a shop after a break-in: you re-check every door, restock the shelves, and put a clear sign up for customers.

Test in staging, scan again, then bring the site back online safely

Before you flip the switch on your live site, do a quick but complete test in staging (or a private URL). You’re looking for two things: nothing malicious is left, and nothing important is broken.

Use this simple test plan:

• Key pages: Homepage, top service/product pages, contact page, pricing, blog, and any landing pages you run ads to.
• Checkout and forms: Test add-to-cart, checkout, payment flow, and every form (contact, quote, sign-up). Confirm emails land in the right inbox.
• Admin login: Log in, change your password again, confirm MFA works, then check the user list for anything you don’t recognize.
• Redirects: Click menus and buttons, and manually test a few old URLs if you have them. Watch for odd redirects, especially on mobile.
• Search: Test on-site search, filter tools, and search result pages (attackers sometimes inject spam there).
• Mobile: Load pages on a phone using mobile data, not office Wi-Fi. Some infections trigger only on certain devices or IPs.

After it passes, run a final malware scan (files and database) and review your recent logs for fresh trouble:

• Spikes in POST requests to login pages or form endpoints
• Hits to strange .php files or paths that shouldn’t exist
• Repeated 404s to random plugin files (a sign bots are hunting holes)

If anything looks off, pause and re-check. Going live with one missed backdoor can put you right back at day one.

If your site was blacklisted, request a review after cleaning

Security warnings can stick around even after you clean up. In many cases, Google won’t lift them until you ask for a review in the right place.

Before you request anything, confirm these basics:

• The site no longer serves malware or spam content
• The entry point is fixed (patched software, removed weak plugins, rotated passwords)
• You can reproduce clean results in incognito and on mobile
• You’ve re-scanned and checked logs for new suspicious hits

Then, in Google Search Console, check the reports tied to hacked sites:

• Security Issues: If issues are listed, use the option to mark as fixed and request a review.
• Manual Actions: If you were hit with a manual penalty for spam or hacked content, clean it fully, then request a review there too.
• URL Inspection: For key pages, run a live test and use Request Indexing to speed up recrawling after cleanup.

If you request a review while anything is still infected, you can get rejected and lose time. Treat the review request like a final exam, submit only when you’re confident.

Tell customers what happened (only what they need) and what they should do

Silence makes people assume the worst. A short, calm update helps protect customers and rebuild trust without oversharing technical details that don’t help them.

Here’s a simple message structure you can adapt (email, banner, or status page):

• What happened: “We detected unauthorized access to our website on (date).”
• What might be affected: Keep it factual. For example, “Some pages may have shown spam links,” or “We’re investigating whether account details were accessed.”
• What you fixed: “We removed malicious code, restored clean files, and secured the system (password resets, updates, extra login protection).”
• What customers should do: Ask for clear actions:
• Change passwords (especially if they reused it elsewhere)
• Watch for suspicious emails or password reset messages
• Contact you if they notice unusual account activity
• Where to get help: A support email or phone number, plus your response hours

If payment details, IDs, health data, or other sensitive data may be involved, get legal advice early. You may have notice requirements depending on where your customers are and what data you collect.

Prevent the Next Hack: Simple Habits and a Maintenance Plan

After you Fix Hacked Website damage, the real win is staying clean. Most repeat hacks happen because the same weak spot stays open, or because no one notices the early signals. You don’t need to be technical to keep your site safer, you just need a simple routine, a place to store backups, and clear ownership (who does what, and when).

Set up reliable off-site backups and practice a restore

Backups are your reset button. Without them, every hack turns into a stressful rebuild.

Keep it simple:

• Back up daily if your site changes often (new orders, posts, bookings). If it’s mostly static, weekly can work, but daily is safer.
• Keep multiple versions (at least 7 to 30 days). Hacks can sit quietly, and yesterday’s backup might still be infected.
• Store backups off-server. If backups live on the same hosting account, an attacker can delete or poison them.

A good setup includes files + database (both matter). Then, practice a restore before an emergency. Do a test restore to a staging site or a temporary folder. If you can’t restore in under an hour, your backup plan isn’t ready.

Owner tip: Assign one person to check backup emails or logs weekly. “Auto-backups” that no one checks often fail silently.

Create an update routine and track changes

Updates close known holes. In 2025, most real-world issues still start with old plugins and themes, not secret hacker magic.

Use an easy schedule:

• Weekly (10 minutes): Log in, run updates for CMS core, plugins, and themes. Check for anything that looks unfamiliar.
• Monthly (30 to 60 minutes): Review your plugin list, remove what you don’t use, and replace anything abandoned.

Track changes so you can roll back safely. A simple note in a Google Doc is enough:

• Date
• What changed (plugin update, new theme, new user)
• Who did it
• Any odd behavior after

Be strict about plugins: delete inactive ones, and remove anything you no longer need. Old add-ons are like leaving spare keys under the doormat.

Monitor for early warning signs and run regular scans

You want alerts that tell you something’s wrong before customers do.

Start with these basics:

• Uptime alerts: Know when the site goes down.
• Login alerts: Notifications for admin logins, password resets, and failed login spikes.
• File change monitoring: Alerts when core files change (a common backdoor move).
• Regular malware and vulnerability scans: Weekly automated scans, plus a deeper check after big updates.

Also, build a quick habit of reviewing signals:

• Check for new admin users you didn’t create.
• Watch for sudden redirects, spam pages, or new pages you didn’t publish.
• Scan logs when possible (or ask your host), especially after spikes in traffic or email sending.

Know when to call a professional (and what to ask them)

Some situations need expert hands, and waiting can make the damage worse. Get help if you see:

• Repeated reinfection after you cleaned or restored
• Signs of a server-level compromise (unknown processes, other sites affected)
• Ecommerce, login accounts, or personal data involved
• No clean backups to restore from
• Serious business downtime (lost sales, blocked by browsers, blacklisted)

When you hire a provider, ask these questions upfront:

1. What exact cleanup steps will you take (files, database, users, cron jobs, redirects)?
2. Will you provide a root cause report (how they got in, and when)?
3. What hardening will you apply (MFA, firewall rules, permissions, plugin audit)?
4. What monitoring will be set up (alerts, scans, file integrity)?
5. Do you offer a warranty period against reinfection, and what’s covered?

Ongoing checklist (save this)

• Daily: Confirm backups ran and are stored off-site.
• Weekly: Run updates, review admin users, check security alerts.
• Monthly: Remove unused or abandoned plugins/themes, test a restore, review logs or host reports.
• After any big change: Run a full scan, then spot-check key pages on mobile and incognito.

Conclusion

Fix Hacked Website recovery works best when you follow a calm flow, confirm the hack, contain it fast, save a full backup for proof, clean files and the database, then close the entry point that let them in. After that, add a firewall, alerts, and a simple update and backup routine, so you spot trouble early and stop repeat hits. The goal is not just to get the homepage back, it’s to restore trust, protect users, and keep Google and browsers happy.

Most sites can recover, even after a messy breach. Speed matters, clean habits matter more, and the next week of monitoring is where you prove the fix will stick. If you want a second set of eyes, get expert help before you go live.

Quick wrap-up: Confirm signs, take the site offline (503), save logs and backups, clean or restore from a known good point, patch and remove risky add-ons, rotate every password and key, then monitor with scans and alerts.