The WordPress Redirect
Hack: Removed.
Find It. Kill It. Lock It.
Someone clicks a link to your site and lands somewhere else entirely, usually a spam page, a fake shopping site, or something worse. Your admin dashboard looks completely normal, which is exactly why redirect hacks go unnoticed for weeks.
CV Infotech finds redirect injections at the file, database, and .htaccess level, closes the entry point, and verifies clean behaviour across desktop, mobile, and search-engine-referred traffic, since this hack often behaves differently depending on how the visitor arrived.
What The WordPress Redirect Hack Actually Is
The WordPress redirect hack is malicious code, most often injected into the .htaccess file, the wp-config.php file, or directly into the database, that sends some or all visitors to a destination the site owner never chose. It is one of the most profitable hacks for an attacker because it can run for months generating ad revenue or traffic for someone else's site without a single visible change to the site itself when viewed by the owner.
The defining trait of this hack is that it is usually conditional. It frequently checks whether the visitor arrived from a search engine, whether they are on mobile, and whether they are logged into wp-admin, then only triggers the redirect for visitors who match specific conditions, most often mobile users who clicked through from Google. This is precisely why the site owner, browsing on desktop while logged in, sees nothing wrong and only finds out when a customer complains.
Francisco Escobar's platform has run through 14 years of WordPress changes without a confirmed redirect compromise, in large part because our maintenance process checks .htaccess and wp-config integrity on every scheduled visit, not just when something is already reported broken. That same check is the first thing we run on any redirect hack engagement, detailed at /wordpress-maintenance-service/.
Conditional Redirects Found, Not Just Obvious Ones
We test as a search-engine-referred mobile visitor, not just as a logged-in admin on desktop, since that is exactly the condition most redirect hacks are built to hide from.
Three Injection Points Checked Every Time
.htaccess, wp-config.php, and the database are all checked, because a redirect hidden in one and missed in the others simply reappears days later.
Entry Point Closed, Not Just the Redirect Deleted
Deleting the redirect code without closing how it got there means it comes back. We identify and close the actual vulnerability.
Verified Across Real Visitor Conditions
We retest as mobile, desktop, logged-in, and search-referred traffic before calling the site clean, matching how the hack was actually built to behave.
How We Find And Remove The Redirect Hack
.htaccess Line-by-Line Audit
Redirect injections in .htaccess often sit among legitimate rewrite rules, disguised to look like normal WordPress permalink configuration. We compare against a known-clean baseline rather than scanning for obvious red flags alone.
wp-config.php Review
A less common but real injection point, since wp-config.php loads before almost anything else in WordPress, malicious code placed here can redirect before any plugin has a chance to intervene.
Database Scan for Injected Header Redirects
We search wp_options and wp_posts for injected header() or JavaScript redirect calls, which is where database-level redirect hacks most often hide, particularly inside theme option fields that are rarely reviewed manually.
Conditional Logic Testing
We test the site as a mobile visitor arriving from a Google search result specifically, since this is the visitor profile the hack is built to target and the one least likely to be caught by a site owner testing on desktop.
Backdoor Sweep
Redirect hacks are frequently paired with a backdoor that allows the attacker to reinstate the redirect after a superficial cleanup, so we check for this specifically rather than assuming the redirect was the only thing installed.
Written Entry-Point Report
You receive a plain-English explanation of exactly where the redirect was hiding and how it got there, so you understand what changed and why it will not simply reappear.
Redirect hacks are almost always found by accident, a customer mentions something strange, or a mobile user complains, rather than by the site owner noticing directly. That delay is normal and not a sign of negligence, since the entire design of this hack is to stay invisible to the person most likely to check for it.
What matters once it is found is testing under the actual conditions the hack targets, not just checking the obvious path. We test as the visitor profile most likely to be redirected, mobile, search-referred, not logged in, because that is the only way to confirm the hack is genuinely gone rather than simply not triggering during a superficial desktop check.
This service is not the right choice if:
- Your redirect issue is a simple, intentional 301 redirect you set up yourself and forgot about
- You have already confirmed the redirect is a plugin misconfiguration rather than malicious injection
- Your hosting provider's managed plan already includes this as a covered service
- You are comfortable auditing .htaccess and wp-config yourself and simply need a second opinion
We will confirm which of these applies during the triage call before billing anything.
USA
Compliance: CCPA · Hosting: AWS us-east-1 · Support: EST (UTC-5)
Site credentials and access during removal are handled in compliance with CCPA, processed on AWS us-east-1 infrastructure and deleted on completion. Full detail: /web-development-agency-usa/
UK
Compliance: UK GDPR · Hosting: AWS eu-west-2 London · Support: GMT (UTC+0)
UK GDPR governs how any personal or customer data encountered during the audit is handled. John Gowland's real estate platform build included the same .htaccess and wp-config integrity checks. Full detail: /hire-developers-uk/
Australia
Compliance: Privacy Act 1988 · Hosting: AWS ap-southeast-2 Sydney · Support: AEST (UTC+10)
Privacy Act 1988 obligations are factored into how Australian client data is handled during removal. Laura Maher's ongoing WordPress work runs on this same AEST-aligned model. Full detail: /app-development-company-australia/
Where Redirect Hacks Hide Most Often
Ranked by how often we actually find the injection in each location.
| # | Item | Why It Matters |
|---|---|---|
| 1 | .htaccess rewrite rules disguised as permalink config | Most common location, easiest to overlook since real rewrite rules live here too |
| 2 | wp_options table, theme_mods or widget option fields | Rarely reviewed manually, frequent target for database-level injection |
| 3 | functions.php of the active theme | Runs on every page load, common location for conditional redirect logic |
| 4 | wp-config.php, near the top before WP_DEBUG constants | Loads before almost anything else, less common but highly effective for the attacker |
| 5 | A disguised plugin posing as a caching or SEO tool | Entire plugin exists solely to inject the redirect, easy to miss in a plugin list |
| 6 | mu-plugins directory | Must-use plugins load automatically and are often overlooked because they do not appear in the standard plugin list |
| 7 | Cron jobs re-adding the redirect after removal | Explains why a redirect sometimes reappears days after apparent cleanup |
| 8 | JavaScript injected into footer.php | Client-side redirect that can behave differently depending on browser and device |
Tested As The Targeted Visitor, Not Just Admin
We check as mobile, search-referred, logged-out traffic, the exact profile most redirect hacks are built to target.
512 Verified 5.0 Reviews
512 reviews on Freelancer.com with a 5.0 rating, from real client engagements, not solicited testimonials.
Entry Point Documented In Writing
You keep a written record of exactly where the redirect was hiding, useful even if you manage the site yourself afterward.
Francisco Escobar, 14 Years, Zero Breaches
Client since 2012. His WordPress infrastructure has run 14 consecutive years without a confirmed redirect or malware compromise.
How We Remove The Redirect Hack
Six steps from triage under real visitor conditions to a verified clean written report.
We reproduce the redirect as a mobile, search-referred visitor specifically, since this is how the hack is confirmed rather than assumed.
We check .htaccess, wp-config.php, the database, and any disguised plugins in that order, based on how often each location actually holds the injection.
The redirect code is removed and we specifically check for a companion backdoor that could reinstate it.
Whatever let the attacker inject the code in the first place, usually an outdated plugin or weak credential, gets closed.
We retest as the exact visitor profile the hack targeted, not just a general scan, before calling it resolved.
You receive the exact injection location, the entry point, and the fix applied, in plain language.
Frequently Asked Questions
The clearest sign is visitors reporting they land somewhere unexpected after clicking a link to your site, while the site looks completely normal when you check it yourself, logged in on desktop. This mismatch is the defining trait of a conditional redirect hack.
Most redirect hacks are deliberately conditional, checking the visitor's device and referrer before triggering, specifically so the site owner testing on desktop while logged in never sees it. This is what makes the hack profitable for weeks or months before discovery.
Yes, easily. Malicious rewrite rules are often written to closely resemble normal WordPress permalink rules, which is exactly why a line-by-line audit against a known-clean baseline is necessary rather than a quick visual scan.
No. Clearing cache can occasionally make a redirect temporarily less visible if it was being served from a cached page, but it does not remove the underlying injected code, which will resume redirecting once the cache repopulates.
Yes, and often specifically through Google's own detection, since Google's crawlers frequently trigger the same conditions a real search-referred visitor would, causing the redirect to be flagged and the site penalised or removed from results entirely.
Most cases resolve within our standard 24-hour window once triaged, though the time to locate the specific injection varies depending on how well it is disguised, particularly if it is hidden in a database field rather than an obvious file.
Frequently, yes, if the entry point is not also closed and any companion backdoor is not detected, since the code that reinstates the redirect is often separate from the redirect code itself.
Our rate is $30 an hour. A straightforward single-location injection typically runs a small number of hours, and we provide an estimate after triage before any billed work begins.
Only if the original entry point is not closed. Our process always includes identifying and closing that specific vulnerability, not just removing the visible redirect code.
No, though they can occur together. A pharma hack specifically injects spam content and links into your pages and search listings, while a redirect hack sends visitors to an entirely different destination. See /wordpress-security/pharma-hack/ for that specific pattern.
Yes, browsing your site in an incognito window as if arriving from a Google search, and separately checking on a mobile device, will surface most conditional redirects without needing file-level access.
Yes. $30/hr. Contact us through the form above and we begin triage within 2 hours during business hours.
Visitors Landing Somewhere They Should Not? We Find Exactly Where It Is Hiding.
$30/hr. Tested under real visitor conditions, not just a desktop check.