Stop traffic spikes from botnets: identify the exact malicious file, isolate it from the live server, and repair core integrity immediately. Remove the infection source before cleaning; cleaning without isolation leads to re-infection within 48 hours.
Security is not about one big wall. It is about thousands of small failures stacking up. In my years managing VPS servers, I’ve seen 7 out of 10 compromised sites trace back to the same three vectors. You need to know which one got you.
Scanners tell you *what* is wrong. They rarely tell you *where* it came from. Manual inspection is painful. It is also the only way to be sure. Start with your web server logs. Specifically, access.log and error.log. Look for 404 errors on wp-login.php coming from different IP addresses in the same minute. That’s a brute force. Filter by date. You want the days leading up to when the site first misbehaved.
Next, check your file system. Use an FTP client. Compare your /wp-content/plugins/ directory against a fresh download from the WordPress.org repository. Look for index.php files inside subfolders where they shouldn’t be. Look for PHP files with names like abc123.php. These are junk files. They are payload delivery systems. Delete them. Screenshot them first. Send the screenshot to your developer if you didn’t write that code.
Do not restore a full backup first. That’s the biggest mistake I see. If your backup includes the malicious files, you just re-installed the virus. The database usually gets injected with malicious posts or redirects. But the files are the vector. Clean files first. Then database. Then core.
wp-admin and wp-includes folders entirely. Upload fresh copies from wordpress.org. Never trust the existing files in those directories. They are prime injection targets for code obfuscation.Malware loves wp_posts and wp_users. It injects SEO spam links into content. It creates new administrator role users so the attacker can come back. You need to clean the database manually. Use phpMyAdmin. Search for common payloads: base64_decode, eval, gzinflate. These should not appear in your posts. They belong in PHP code execution, not in HTML content. Delete any rows containing them.
Check the wp_users table. Look for users with administrator role that you do not recognize. In one incident I handled, the attacker created a user named security_check_01. It looked harmless. It had full admin access. Change every admin password. Not just yours. Every admin. Force a password reset for all users. And rotate the DB_PASSWORD in your wp-config.php. If the attacker has file access, they can read that file. Changing the password in the cPanel database interface without updating the config file will break login. Do both simultaneously.
If you have a business owner relying on the site for revenue, yes. Manual removal misses hidden backdoors in 20-30% of cases. You need professional tools and time. For personal blogs, it’s a self-inflicted wound you can fix. But if the site makes money, pay the $200. It’s cheaper than losing a month of traffic.
No. Not unless you secured the vector that allowed the hack. If you restored a backup and left the vulnerable plugin active, you are hacked again within 24-48 hours. Patch the plugin. Change passwords. Then restore. The backup must be clean, but the environment must be harder too.
Fix the malware first. Submit a review request in Google Search Console *only* after you’ve confirmed no malicious files remain. If you submit while infected, the review is denied. You wait another 7 days. Use the WordPress.com security scanner or Wordfence to scan your entire site one last time before submitting.
Yes. If you are not using mobile apps that rely on it (like the official WordPress iOS/Android apps for login), disable it. Add this to your functions.php: add_filter('xmlrpc_enabled', '__return_false');. It eliminates a major brute-force vector. Most sites don’t need it. It’s a legacy protocol from 2003.