Quick answer
WordPress .htaccess malware uses rewrite rules, redirects, deny rules, or handler changes to send visitors to spam, block security tools, execute suspicious files, or break the site. Save a copy first, compare with normal WordPress rules, remove malicious lines, and check for the backdoor that edited the file.
.htaccess is powerful because it runs before WordPress handles the request. That makes it useful for legitimate permalink rules and dangerous when attackers modify it.
A small rewrite rule can redirect search visitors, hide malware from scanners, or trigger 500 errors. Because .htaccess is often edited by plugins, cleanup must be careful.
Why this matters
Server-level rules can affect every page. Malware in .htaccess can continue redirecting visitors even when WordPress files and posts look clean.
Broken .htaccess rules can also make the site unreachable, which turns a malware issue into an uptime emergency.
Warning signs to look for
- Visitors redirect before the page loads.
- The site shows sudden 500 or 403 errors.
- .htaccess contains unfamiliar domains.
- Rules target Googlebot, mobile devices, or referrers.
- The file changes again after cleanup.
If redirects happen before any WordPress theme output appears, .htaccess or server configuration should be checked early.
Where this usually hides
Malicious .htaccess rules can appear in the site root, uploads folders, plugin directories, or nested subfolders.
Attackers may mix malicious rules with legitimate WordPress, cache, or security plugin rules to make manual review harder.
Safe investigation steps
Back up the file before editing. Compare it with default WordPress permalink rules and known rules from cache or security plugins.
Search for external domains, suspicious RewriteCond patterns, unusual PHP handlers, and deny rules that block scanners or admins.
- Save a copy of every .htaccess file.
- Review root and nested directory rules.
- Search for external redirect domains.
- Check modification timestamps.
- Find what process keeps editing the file.
Cleanup priorities
Remove malicious rules while preserving legitimate WordPress and plugin rules. If unsure, regenerate permalinks after backing up the original file.
Then find the source. If a backdoor can write to .htaccess, the redirect can return.
- Back up .htaccess files.
- Remove malicious rewrite or handler rules.
- Regenerate legitimate WordPress rules.
- Delete backdoors that edit rules.
- Clear cache and retest affected URLs.
What to avoid
Do not overwrite .htaccess without saving it. The original file may contain both needed rules and evidence.
Do not assume the root .htaccess is the only one. Nested files can affect specific folders.
Prevention after cleanup
Limit file write access, monitor critical file changes, and review plugins that modify server rules.
Security hardening after cleanup can reduce the chance of unauthorized file edits.
Helpful resources
See redirect malware removal, hidden backdoor removal, and security hardening.
WordPress.org’s troubleshooting guide is useful when .htaccess causes 500 or permalink errors.
When to get expert help
Get help if .htaccess keeps changing, the site is down, or redirects affect only certain visitors.
How to confirm the cleanup worked
For WordPress .htaccess malware, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
How to confirm the cleanup worked
For WordPress .htaccess malware, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
FAQ
Can .htaccess redirect only Google visitors?
Yes. Rules can check referrers, user agents, and request patterns.
Is deleting .htaccess safe?
Not blindly. Back it up first and regenerate legitimate WordPress rules.
Can .htaccess exist in uploads?
Yes. Nested .htaccess files can affect specific directories.
Why does the file keep changing?
A plugin, cache tool, or malware backdoor may be rewriting it.