Visitors arriving from search are redirected while direct visits work. An infected .htaccess can test referrer, user agent, requested path or cookie before sending selected traffic elsewhere.
The file may also contain legitimate WordPress permalinks, HTTPS redirects, security controls and cache rules. Preserve and annotate it before replacement.
Capture the exact file and trigger
Copy .htaccess with metadata and hash. Record the visitor URL, referrer, user agent, time and redirect destination.
Check for .htaccess files in parent directories and nested upload/cache folders. Apache processes applicable rules along the directory path.
Do not visit the malicious destination. Preserve it as text.
Read conditions as a group
Rewrite rules depend on their preceding conditions. Look for tests involving HTTP_REFERER, HTTP_USER_AGENT, query strings, cookies and unfamiliar domains.
A suspicious example might target search referrers, but do not paste or deploy live malicious rules to test them. Analyse the logic offline and compare against known site requirements.
Encoded strings, very long lines and rules placed before standard WordPress markers deserve review, not automatic deletion.
Compare with the site’s legitimate baseline
Retrieve a known-good version from deployment history or backup. WordPress’s standard permalink block is short, but hosts, cache plugins and security tools add valid sections.
Identify an owner for each non-core block. Generated markers often state which plugin manages them.
Do not replace the file with only the generic WordPress block if the site needs language redirects, protected paths or server caching.
Test configuration before applying it
Use the host’s syntax checker or staging site where available. A malformed .htaccess can return 500 errors for the whole site.
Apply the clean file through a controlled method and keep an immediate rollback. Check permissions and ownership without making it world-writable.
On Nginx-only hosting, .htaccess may be ignored; investigate server configuration, CDN and PHP instead.
Find the rewriting process
If malicious rules return, correlate modification time with web requests, cron, plugin settings, SFTP and panel activity. Search quarantined code for the destination domain and writes to .htaccess.
Inspect root/backdoor PHP, must-use plugins, uploads and sibling sites. A cache or security plugin can rewrite legitimate sections during normal settings saves, so distinguish its output from the injected block.
Narrow file auditing can capture the writer on a VPS when authorised.
Check CDN and hosting redirects
Cloudflare Redirect Rules, Workers, hosting-panel redirects and DNS can reproduce the same symptom even after .htaccess is clean.
Export their configurations and review account users/sessions. Do not purge or delete every rule before preserving evidence.
Test the clean origin and public path separately, using secure authorised methods.
Also inspect server configuration inherited above the document root. On shared hosting, a parent .htaccess can affect several subdirectories; on a managed VPS, an Apache virtual-host include can apply rules that are invisible inside WordPress.
Ask the provider to preserve and review those layers if you cannot access them. Do not attempt to override an unknown parent rule with increasingly complex child directives.
Verify direct and search journeys
After removing malicious rules and closing the entry route, test a clean direct visit and an isolated search-referrer visit on mobile and desktop. Confirm expected canonical/HTTPS redirects still work.
Monitor .htaccess hash across plugin saves and scheduled events. Review server logs for continued requests to the former destination pattern.
When specialist cleanup is needed
Request help when rules reappear, several directory levels are involved or the host/CDN adds redirects too. Send the suspicious domain and redacted rule conditions as text, not account access.
The repair should preserve valid routing, remove selective redirection and identify who can still change the configuration.