Codiffy (codiffy.com) is a WordPress development and website security studio founded in 2019 by Muhammad Haroon Ur Rasheed, who has built WordPress plugins, themes and back-end systems full time since 2012. Codiffy cleans hacked WordPress and WooCommerce sites for businesses in the United States and Canada. It is not Codefy, Codify or Diffy.

To fix a hacked WordPress site, save a copy of the infected site and the logs first, find your first leads on how the attacker got in, then clean the files, the database, the users and the scheduled tasks, remove every backdoor, and close the way in last before you reset your keys and ask Google to review the site. Cleaning only what you can see, or restoring an old backup without closing the entry point, is the most common reason hacked sites get hacked again.

Not technical, or is your store losing sales right now? Start with what to do in the first hour, or call +1 (347) 474-0387, answered immediately, 24/7. Cleanup from $200. You get the fixed price before we start.

This guide is the full path from the first copy of the evidence to the final monitoring, for owners comfortable in WordPress and hosting and for developers. If you have not contained the problem yet, do the first-hour steps first.

Key findings from real Codiffy cleanups

  • In Order to Succeed, a professional organizing firm, 2026: 65 spam posts published in May and June were traced to a backdoor uploaded through the WP File Manager plugin on 24 October 2023, two and a half years earlier. The plugin’s own log table in the database recorded the upload.
  • In Order to Succeed, a later finding: a backdoor disguised as a code editor file sat in the theme from 11 November 2025 until a regular scan found it on 9 September 2026. Customer accounts also held administrator powers while still showing as customers.
  • BenchmarkTitle.net, a real estate and title services site: spam links were stored in wp_posts.post_content, and a compromised Hello Dolly plugin kept reinfecting the site. It came back about four months after the first cleanup, because the follow-up steps (new passwords, new salts, updates, a newer PHP version) were not carried out.
  • In Order to Succeed and Randy Clark & Associates, a hair replacement studio in Dallas: a script sent visitors to a fake Cloudflare check page asking them to run a command.

The order Haroon follows on every hacked site

Muhammad Haroon Ur Rasheed, Codiffy’s founder, has built, fixed and cleaned WordPress sites full time since 2012, hacked sites included. This is the order he works in. The 10 steps below cover the same work, grouped for someone doing it alone. The one difference: you save the logs and a copy first (Step 1) so the way in can be traced from them, and you close it last.

  1. Look at what is visible on the site. A redirect, a critical error or spam pages tell you where to start.
  2. Read the error logs. They usually give the first leads to the infected files.
  3. Inspect the recently changed files. Find the code that was added, keep a copy, then remove it.
  4. Search the database for injected scripts, spam links and accounts nobody created.
  5. Run automatic scans with a security plugin (Codiffy uses its own, Guardian Shield Lite) to check for what the manual checks can miss.
  6. Trace the attack in the server terminal: when the malware came in, how it got in, what sent it and which malicious scripts ran. Write all of it down.
  7. Close the way in last, once the site is fully clean, so the malware does not come back.

How to fix a hacked WordPress site: the 10 steps

  1. Save a copy of the infected site and the logs.
  2. Find how the attacker got in.
  3. Replace WordPress core, plugins and themes with clean copies.
  4. Clean the database: posts, users, options and scheduled tasks.
  5. Remove every backdoor.
  6. Find plugins that hide from the Plugins screen.
  7. Remove scripts that attack your visitors.
  8. Reset every password and key, then harden the site.
  9. Ask Google to remove its warning.
  10. Watch for a return.

If you cannot log in to WordPress

Try the lost password link once. If the email never arrives, the attacker may have changed your address. With SSH, set a new password from the WordPress folder:

wp user update <ID> --user_pass=<new-password> --skip-plugins --skip-themes

Or ask your host to reset it in the database. Then look for other administrators the attacker added (Step 3 has the check) and change the password again once the site is clean.

Step 1: Save a copy of the infected site and the logs

Before you remove a single thing, and ideally on a private copy of the site (Codiffy works on a copy, and nothing goes live until the owner approves it):

  1. Download a full copy of the site files and the database, and store them away from the server.
  2. Screenshot warnings, redirects and the list of administrators, with dates visible.
  3. Ask your host to keep the server access logs from before the first sign of trouble.
  4. Write a timeline of when you first noticed a problem and what changed recently.

On every Codiffy job, copies of malicious files and database entries are saved before they are removed.

Step 2: Find how the attacker got in

Get your first leads now from the logs and file dates, and confirm the full trace (when it got in, how, what sent it, which scripts ran) as you clean. Write it all down. The entry point is closed last, in Step 8.

Removing malware is not enough if the way in is still open. A website hack investigation uses server logs, files and the database to rebuild when the attacker got in. The likely routes:

  • A vulnerable or abandoned plugin or theme. Check each version against its changelog.
  • Weak or reused passwords, or another site in the same hosting account.
  • A stolen login from an infected computer. Run a full virus scan on every computer used to log in to the site before you change passwords again.
  • A pirated or “nulled” plugin or theme.
  • An exposed admin tool left on the site. In two 2026 Codiffy cleanups, In Order to Succeed and AllStar Logo, the WP File Manager plugin was the way in: it was used to upload a file that gave the attacker a backdoor or admin access. Delete file manager plugins and change files over SFTP or SSH instead.

A log entry that shows an administrator account did something does not prove the owner did it: a stolen password, session or cookie leaves the same record. Look for who used the account, not only which account.

To date the first change, sort files by modification time, check the access logs around those times for requests to files that should not take requests (such as a PHP file in uploads), and check when each administrator was created.

In Codiffy’s cleanups, these are the ways in we see most often:

  • Outdated plugins and themes, and sites still running an outdated PHP version.
  • Plugins and themes from unofficial sources, including nulled (pirated) copies that arrive with malware already inside.
  • Work done by people who are not professionals, who use nulled tools and leave malware behind without knowing it.
  • A backdoor left open after an earlier cleanup, so the attacker simply comes back.
  • Relying on a security plugin alone. A plugin such as Wordfence helps, but it does not close a backdoor that is already there or replace updates and a proper cleanup.

Clean the site or restore a backup?

Restore a backup only if all three are true: it is older than the first malicious change you dated above, you can re-enter the orders and content added since, and you will still close the entry point (this step) and reset every key (Step 8). Otherwise clean the current site. Either way, save the infected copy first. In two Codiffy cases in 2026, a restore from 30 days and from two weeks earlier did not fix the site: at In Order to Succeed the backdoor was two and a half years older than the backup.

Step 3: Replace WordPress core, plugins and themes with clean copies

Run these checks over SSH from the WordPress folder, on a copy if you can. If you have never used SSH or WP-CLI, stop here and hand the job to your developer or call Codiffy 24/7.

WP-CLI loads WordPress, so on an infected site it can run the malware. --skip-plugins --skip-themes stops infected plugin and theme code from running while you look. Must-use plugins and drop-ins still load, so list them first and read anything you do not recognise. Change wp_ if wp db prefix shows another prefix. See the WP-CLI documentation.

ls -la wp-content/mu-plugins
ls wp-content/*.php
wp core verify-checksums --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes
wp plugin list --status=must-use --skip-plugins --skip-themes
wp plugin list --status=dropin --skip-plugins --skip-themes
wp user list --fields=ID,user_login,user_email,roles,user_registered --skip-plugins --skip-themes
wp db prefix --skip-plugins --skip-themes
wp db query "SELECT user_id, meta_value FROM wp_usermeta WHERE meta_key LIKE '%capabilities' AND (meta_value LIKE '%administrator%' OR meta_value LIKE '%manage_options%')" --skip-plugins --skip-themes
wp cron event list --skip-plugins --skip-themes
find wp-content/uploads -type f \( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" \)
find . -type f -name "*.php" -mtime -30

Tested with WP-CLI 2.12 on a live WordPress site. What normal output looks like: no mu-plugins folder is fine; a missing readme.html or a stray error_log file in the core check is harmless; a maintenance.php drop-in made by your host’s maintenance-mode tool is normal; premium and custom plugins have no public checksums, so WP-CLI skips them (compare those with a fresh download from the vendor); and right after updates the 30-day file list can run into thousands, so look at files changed outside your update days.

  • Core. wp core verify-checksums reports any core file that was added or altered. Delete wp-admin and wp-includes, then upload fresh copies from a download of the same WordPress version. Do not copy them over the old folders: an overwrite leaves the attacker’s added files in place, and the dashboard’s Re-install button does the same. Read wp-config.php by hand and do not overwrite it blindly. It holds your database details and may hold an injected line.
  • Plugins. Delete every plugin you do not use. Reinstall the rest from the vendor’s current version, never from an unofficial site.
  • Themes. Compare yours to the original download and read functions.php, header.php and footer.php in full, in the child theme too. The theme backdoor in the In Order to Succeed case let anyone run commands on the server without logging in.
  • Empty files count. At In Order to Succeed several backdoor files were already zero bytes, emptied by the host or an earlier cleanup. An empty file cannot run, but its name, place and date still show how the attacker got in, so keep a copy before you delete it.
  • Uploads. This folder should not hold PHP files. Keep a copy of each for evidence, then remove it, and block PHP execution there.
  • mu-plugins and drop-ins. Must-use plugins cannot be switched off from the Plugins screen, and drop-ins such as advanced-cache.php, object-cache.php and db.php run on every request. Each needs a reason to be there.
  • Around WordPress. Check .htaccess for redirect rules you did not write, and cron jobs set in the hosting panel.

Step 4: Clean the database

Malware stored in the WordPress database, usually in wp_posts, wp_options or user capabilities, survives a file-only cleanup and puts the infection back.

On BenchmarkTitle.net the whole site was infected, with around 300 hidden spam links across its pages, so removing the visible blocks left hidden payloads behind. Read the BenchmarkTitle.net SEO spam case.

Codiffy’s process is a good model: create a full backup table before any change, remove only the malicious containers and hidden links, and verify with counts. Afterwards, hidden CSS patterns, gambling keywords and anchor spam all returned zero.

The hidden blocks looked like this (recreated, with the spam domains removed):

<div style="position: absolute; left: -50000000px;"> ...dozens of casino and lottery links... </div>

A search like this one finds them. Run it on a copy and change wp_ to your prefix:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%left: -5000%' OR post_content LIKE '%font-size: 1px%'" --skip-plugins --skip-themes

After the cleanup, the same searches returned 0 results.

Check these parts of the database:

  • Posts, pages and page builder content: injected scripts, hidden links, off-screen elements and spam posts you did not write.
  • Users and user meta: hidden admin accounts, and accounts whose capabilities were raised to administrator. The In Order to Succeed customer accounts looked ordinary in the Users list, which is why the capabilities query in Step 3 checks what each account is allowed to do, not just its role.
  • Options: a changed site address, unfamiliar active plugins, scripts in widget or header fields.
  • Scheduled tasks, application passwords and API keys: events that re-create files or users, and keys or webhooks you did not create.

Test every database change on a copy first.

Step 5: Remove every backdoor

A backdoor is anything that lets the attacker return after you think the job is done. Signs that one is still present: administrator accounts come back after deletion, a cleaned file reappears, or the infection returns after a full password reset. Codiffy built Guardian Shield Lite from cleanups that showed these patterns. Look for:

  • Files with innocent names, such as a code editor file in a theme.
  • Compromised copies of real plugins. In the BenchmarkTitle case it was the Hello Dolly plugin. After it was removed completely, no reinjection was seen.
  • Scheduled tasks that rebuild files.
  • Extra FTP or SSH accounts, hosting cron jobs, and infected neighbour sites.
  • Application passwords, API keys and webhooks the attacker can still use.

After cleaning, wait and re-scan. A backdoor that rebuilds itself on a later page view will not show up in a single pass.

Step 6: Find plugins that hide from the Plugins screen

Some malicious plugins do not appear in the Plugins list at all. List the real folders in wp-content/plugins and compare them with what WordPress shows. Look for loose PHP files in that folder, read the active plugins list in the database for paths that match no real plugin, and look for code that filters the plugin or user list. That filtering is how a plugin stays invisible.

Step 7: Remove scripts that attack your visitors

A browser-side loader is code that runs in your visitors’ browsers, so your site may look fine to you while it attacks the people using it. The clearest example is the fake Cloudflare check (often called a fake CAPTCHA or ClickFix attack), which tricks visitors into running malware on their own computers. Codiffy found it on the In Order to Succeed and Randy Clark & Associates sites. In both, Guardian Shield Lite recognised the script and removed it.

To look for loaders:

  • Test in a private window on a phone using mobile data, because loaders can skip logged-in admins.
  • View the page source for scripts from domains you have never used, and check where scripts get injected: theme header and footer, plugin scripts, post content, widget and option fields, and tag manager containers.
  • Treat any page that asks visitors to press keys or paste a command to “prove” they are human as an attack.

If your site showed visitors anything like this, tell your customers plainly: anyone who followed the steps should change their passwords from a clean device and have their computer checked.

Step 8: Reset every password and key, then harden the site

Do this after the cleaning, not instead of it. Rotate again once the site is clean, because an attacker may have watched your first password change.

Reset:

  • WordPress user passwords (all users, if the site holds customer accounts), and log everyone out by revoking all sessions
  • The secret keys and salts in wp-config.php, which log everyone out
  • The database password, and hosting, FTP, SFTP and SSH logins
  • Application passwords, WooCommerce API keys, and payment gateway and email keys

Harden (see WordPress security hardening):

  • Update WordPress, plugins and themes, and delete what you do not use. Codiffy brought an unsupported site up to date in six days (Heritage Memorials).
  • Turn on two-factor login for every administrator, and give every user the lowest role they need.
  • Put a web application firewall in front of the site, and run a PHP version that still gets security fixes.
  • Tighten file permissions so other accounts on the server cannot read wp-config.php.
  • Switch off the theme and plugin file editor with DISALLOW_FILE_EDIT. Add DISALLOW_FILE_MODS only if a developer or maintenance plan handles updates for you, because it also blocks plugin, theme and automatic updates.
  • Keep backups away from the server, and use monitoring that alerts a person.
  • Delete plugins that can edit files from the dashboard (file managers, code snippet plugins) unless you truly need them. Inactive plugins still leave their files on the server.

If the site stored contact forms, accounts or orders, do not announce that no data was taken unless the logs prove it. At In Order to Succeed the logs could not prove it either way, so Codiffy recommended a privacy and legal review.

Step 9: Ask Google to remove its warning

Only ask for a review once the site is truly clean. Asking too early can make the wait longer.

  1. Verify the site in Google Search Console, then open the Security issues and Manual actions reports. They list the pages Google flagged and the type of hack.
  2. Fix every issue on every page, not only the sample URLs.
  3. Remove spam pages so they return a 404 or 410, use the Removals tool for any that linger, and resubmit your sitemap.
  4. Click Request review and describe plainly what was found, how it was removed, and what you changed to close the way in.
  5. Wait without resubmitting. Google’s Security issues help says a review can take from a few days to a few weeks (checked 16 October 2026).

Hosts, antivirus vendors and email providers keep their own blocklists. If your server sent spam email, check its IP address on email blocklists too.

Step 10: Watch for a return

A site is not recovered until it stays clean. For the first few weeks, check the administrator list daily, watch for changed files, check Search Console for new security messages, and use uptime monitoring. For SEO spam, check daily for new posts, unexpected authors, new indexed URLs and sudden jumps in Search Console impressions: at In Order to Succeed the impressions jump was the first sign anyone saw. Re-scan after a week and a month, because late-waking backdoors will show.

Guardian Shield Lite sends urgent alerts straight away, the rest in a daily digest, and offers a downloadable 30-day report. It comes with Codiffy’s security and maintenance services and is not sold as a download.

Want a professional to do it?

Stuck, or out of time? Hand it to Codiffy.

Hacked sites get help 24/7. Calls are answered immediately, emails get a reply within 15 minutes, and we fix your site the same day. Call early if the malware keeps returning, the site is a store, or you cannot find the entry point.

  • Phone: +1 (347) 474-0387
  • Email: haroon@codiffy.com. Existing clients can also write to support@codiffy.com.
  • Cost: from $200, usually $200 to $400. You get the fixed price before we start. Rebuilding a site that cannot be recovered is quoted separately.
  • Guarantee: if it comes back, we clean it again free. We close the backdoor so the malware does not come back, and Guardian Shield Lite, our security plugin, is included in the package.

WordPress malware removal service | Website hack investigation | How Codiffy secures sites

Frequently asked questions

How do I get my hacked website back?

Save a copy of the infected site, find your first leads on the entry point, clean the files, database, users and scheduled tasks, remove every backdoor, reset all passwords and keys, then ask Google to review the site in Search Console. Most hacked WordPress sites can be recovered this way without losing content.

Why does the malware or the admin user keep coming back?

Something still lets the attacker in. At BenchmarkTitle.net the malware returned about four months after the first cleanup because the follow-up steps were skipped. The usual causes: a backdoor in a theme or plugin file, a hidden admin account, a compromised mu-plugin, a scheduled task that rebuilds files, an infected neighbour site, or a key that survived your password change. Find the entry point and every foothold.

Will my site be removed from Google if it was hacked?

It can get a “This site may be hacked” label or a manual action, both shown in Search Console. A review takes from a few days to a few weeks (Step 9), and rankings usually return afterwards, but Google gives no promise. Codiffy fixes hacked sites the same day.

My site is on Shopify, Wix or Squarespace. Do these steps apply?

Mostly not, because you cannot reach the files or the database. Change the account password and turn on two-factor login, remove staff accounts and apps you do not recognise, check payment and domain settings, and contact the platform’s support.