You're staring at a WordPress site that was fine yesterday and now every other click sends visitors somewhere they didn't ask to go. Maybe it only happens on mobile. Maybe only logged-out visitors see it. Maybe the same client opened a second ticket two weeks later from another site in the portfolio, and the pattern is starting to look less like a browser annoyance and more like a recurring incident.

That's the right instinct. Redirects on WordPress usually aren't a single toggle problem. They tend to live in one of three layers, browser settings, server or application rules, or malicious code, and the fix only sticks when you identify which layer is in charge. Google's 2015 guidance on unwanted mobile redirects treated the behavior as a search-quality and security issue, not just a nuisance, and it pointed operators toward checking mobile behavior directly, watching analytics for sudden drops in mobile time on site, and inspecting third-party scripts one by one when the site itself didn't look hacked Google Search Central guidance on unwanted mobile redirects.

Table of Contents

Why Redirects Keep Coming Back on WordPress Sites

A common agency pattern goes like this. A client reports spam landings, someone fixes the obvious issue, the ticket closes, and then another site in the portfolio starts sending visitors through the same kind of jump. The first fix addressed a symptom rather than tracing the redirect route through the stack.

Start by separating the three layers

Browser-level controls can block or limit some redirect behavior, and major browsers have made those settings easier to find over time. Microsoft's support path for Chrome points users to Privacy, search, and services > Site permissions > Pop-ups and redirects, and Mozilla's guidance has referenced redirection-limit controls and auto-refresh preferences. That matters because the browser gives you a local way to suppress a bad experience, but it does not tell you who created the redirect in the first place browser redirect controls.

Server and application rules are a different class entirely. Apache, Nginx, PHP, and WordPress plugins can all issue redirects before a page ever reaches the browser. If you only tweak the browser, you are changing the symptom on one device, not the behavior that affects everyone else.

Practical rule: if the redirect disappears only after you change a browser setting, you have probably only hidden a local trigger. If it survives a clean browser profile, a second device, and a different network, treat it like a server or security problem.

The useful mental model is simple. First, rule out browser-specific behavior. Second, inspect server and application configuration. Third, assume compromise if the first two layers are clean and the redirect still happens. That order saves time because it keeps you from ripping into WordPress files when the actual issue is a cached browser rule, and it keeps you from wasting time on a browser setting when the origin is a plugin, host rule, or malicious injection.

A flowchart diagram explaining why website redirects recur despite initial attempts to fix the underlying issue.

Why isolated fixes fail across a portfolio

The same weak point often exists on more than one site. Shared plugins, the same managed host, the same theme vendor, or the same maintenance habit can make a one-off ticket look solved while the next site in line is already carrying the same risk. That is why “how do I stop redirects” is really a triage question, not a single-site patch question.

A good diagnostic chain starts with a clean browser check, then moves to config and code, then ends at security review. If you jump straight to file cleanup every time, you will spend hours on the wrong layer. If you jump straight to browser settings, you will miss actual site compromise.

Before any deeper cleanup, make sure the affected site is serving the right certificate and the redirect target is not changing because of a broken HTTPS setup. A clean SSL certificate install check is part of that baseline, especially on client sites where the same host, CDN, or renewal process gets reused across the portfolio.

Quick Browser Checks to Rule Out the Obvious

Start with the fastest test you can trust. Open the affected page in a private or incognito window, then repeat it on a second browser profile if you have one. If the behavior changes, you're probably dealing with browser state, an extension, or a profile setting, not a server-side redirect.

Fast filters that save you from chasing ghosts

Disable extensions one at a time and retest. The reason is simple. Extensions can inject page rules, rewrite links, or interfere with navigation without changing the site itself. Then check the browser's homepage, startup pages, and search settings, because hijacked defaults can look exactly like a redirect problem when the browser launches or on the first search.

In Chrome, also inspect Site permissions for Pop-ups and redirects. That setting is useful when a site is behaving badly in that browser, but it won't fix a redirect being sent by WordPress, Nginx, or the host. If the problem disappears only after you relax a browser permission, you've learned something narrow, the issue is local to that browser profile.

A second device on a different network is a better signal than another click on the same machine. Cached redirects and some network-level interference show up there faster than they do on a browser you've already used for the site all week. If the redirect still happens on a clean device, in a clean profile, on a clean network, stop treating it like a browser issue.

For a broader site-health pass after you've confirmed the browser isn't the culprit, the WordPress SSL workflow at this guide is a useful reminder that transport and redirect behavior often get confused when teams are troubleshooting under pressure.

If the redirect survives private mode, extension removal, and a second network, the browser is no longer your main suspect.

The stop-or-continue decision

You don't need twenty checks here. You need one clean yes or no.

  • If the redirect vanishes in private mode, focus on extensions, profile settings, or browser permissions.
  • If it stays on a second device, move to server and application sources.
  • If it only shows up on mobile, check the site itself and the request path before changing any browser setting again.
  • If it jumps across browsers, stop looking for a single-browser fix and inspect the stack.

That decision point keeps the work honest. A browser fix is the right answer when the problem is local. Everything else belongs on the server, in WordPress, or in security cleanup.

Tracing Server-Level Redirects in .htaccess, Nginx, and PHP

When the browser isn't the source, the next place to look is the code that sends the Location header. On WordPress sites, that usually means .htaccess on Apache, Nginx server blocks, custom PHP in a theme or plugin, or a host-level redirect rule sitting in front of the install. Those layers can override what WordPress is trying to do and make a clean admin screen look innocent.

The files that usually matter first

On Apache, open .htaccess and search for RewriteRule, Redirect 301, RedirectMatch, and any block comments added by a plugin. Plugin-generated rules are often wrapped in markers, so a manual edit can break canonical redirects, pagination, or login behavior. If you don't know who wrote the block, don't delete it blindly.

On Nginx, inspect the server block for return 301, rewrite, and try_files logic. A small rule in the wrong place can redirect a whole path tree before WordPress ever runs. PHP-based redirects are usually easier to miss because they hide inside functions.php, a mu-plugin, or a custom plugin and call header('Location: ...') or WordPress redirect functions during early hooks.

Practical rule: search the repository before you change the browser. If the redirect is server-driven, the browser never had a chance.

Database-backed redirects are also common when plugins persist rules in options tables or their own storage. A redirect might look like “plugin deactivated” from the dashboard while the actual rule still exists in the database and gets applied on every request. That's why server triage should include both config files and the stored application state.

What to grep and where to stop

Use targeted searches, not blanket deletion.

  • Apache rules: look for RewriteRule, Redirect, and RewriteCond in .htaccess.
  • Nginx rules: inspect return, rewrite, and any location block that touches the affected path.
  • PHP headers: search for header('Location and redirect helpers inside theme and plugin files.
  • Application storage: check the options table and any plugin-specific redirect storage before assuming the file system is the whole story.

Host and cloud layers deserve the same respect. Managed redirectors, edge rules, and page rules can sit in front of WordPress and win every time. If the site looks clean but the browser still lands somewhere else, check the layer that answers before PHP does.

Cleaning Up WordPress Plugins, Themes, and Database Redirects

WordPress adds its own set of redirect sources, and these are the ones generic browser guides usually miss. A plugin can store a clean-looking 301 that survives deactivation, a theme can ship with redirect logic, and multisite domain mapping can send users exactly where the operator intended, just not where the operator now remembers intending.

Where WordPress hides redirect logic

The first place I check is the active plugin stack, especially SEO and redirect plugins that manage their own rules. Those tools often store redirects in the database, not only in the file system, so the rule can survive longer than the UI switch that created it. That's also why staging matters. If you remove a rule on production without seeing the dependency chain first, you can break legitimate SEO traffic.

Multisite and WooCommerce add another layer of confusion. Domain mapping and endpoint behavior can look like malicious forwarding when it's really config drift, an old site address, or an endpoint rule no one documented. Compare the redirect target with your known marketing URLs, checkout URLs, and account URLs before you call it an attack.

The safest sequence is boring but effective. Deactivate the suspected plugin on a staging clone, diff the database, then review any redirect tables or options records the plugin created. Only after that should you remove rules or clean stale entries on the live site.

Common WordPress Redirect Sources and Where They Live
Source Location First action
Redirection plugin rules Plugin database table or stored options Review rules on staging before deletion
SEO plugin redirects Plugin-specific redirect storage Compare against expected SEO URLs
Multisite domain mapping Network and site settings Verify the target domain is still intentional
WooCommerce endpoints Plugin settings and permalinks Confirm checkout, account, and cart behavior
Theme or mu-plugin code functions.php or custom plugin files Search for redirect hooks before editing

If you manage several client sites, the practical part is naming ownership. A redirect that belongs to a plugin should be handled as configuration. A redirect that appears without a clear owner should be treated like a defect until proven otherwise. The difference saves you from deleting a legitimate rule that protects rankings or checkout flow.

A broader plugin-maintenance workflow belongs in this practical guide for agencies and freelancers, especially when you're trying to figure out which extension introduced the behavior in the first place.

Spotting and Removing Malicious Redirects

Once browser checks come back clean and the server and plugin layers do not explain the behavior, treat the redirect as a security event. Infected WordPress sites often hide the first jump so it only appears under certain conditions, such as mobile user agents, logged-out visitors, or specific referrers. A site can look normal in your admin browser and still send visitors to spam pages in the wild.

What infection usually looks like

The usual patterns are ugly, not clever. Obfuscated JavaScript gets injected into a theme header or footer. Base64 payloads get tucked into options records or transient-like storage. Rogue cron jobs keep reintroducing the payload after you delete it. Compromised plugins and nulled themes can ship with redirect code already baked in.

That pattern is common in real cleanup work. Desktop looks normal. Mobile gets hijacked. The site owner often notices only after ads, organic traffic, or support tickets start to drift.

An infographic detailing common malicious redirect patterns, including obfuscated JavaScript, Base64 payloads, and backdoor access methods.

A cleanup sequence that does not make things worse

Start from a staging clone, not production. Diff it against a known-good WordPress core, then search the database for suspicious redirect strings, encoded payloads, and unexpected admin-like entries. Rotate credentials next, because a clean file tree does not help if the attacker still has a valid login or upload path.

Then reinstall core, plugins, and themes from known-good sources. Do not clean a nulled or untrusted package in place and assume it is safe. If the redirect was caused by injected code, deleting one file is often not enough, because the backdoor can live in a second file, a scheduled task, or a database record.

Practical rule: a redirect that returns after deletion indicates persistence, not a misconfiguration.

For a malware-oriented scan workflow, this scanner guide fits naturally after the triage step, because it helps confirm whether the redirect is part of a broader compromise.

Video walkthroughs can help when you are comparing infected and clean files side by side.

Verifying the Fix and Confirming Visitors Are Safe

A redirect isn't really fixed until you've proved the response chain is clean. The easiest mistake here is trusting one browser refresh from one machine. That can miss cached behavior, user-agent-specific redirects, or a server rule that only fires on certain paths.

Check the response, not just the page

Use curl with more than one user agent and compare the response headers. You're looking for surprise Location headers, any 30x hop you didn't expect, and a final status code that lands on the intended page. Browser dev tools can show the same thing in the Network tab, which is useful when you need to compare the server response with what the browser rendered.

Then retest from a private window on a clean device. If the site renders correctly there, the fix is probably holding. If mobile still behaves differently, keep testing the mobile response path separately instead of assuming the desktop result tells the full story.

Confirm search and retention signals

Search Console is the next checkpoint. Review the affected URLs and confirm they're responding normally, then watch for any lingering crawl or indexing issues on the pages that were previously hijacked. If the redirect was security-related, keep an eye on recurrence for the next month, because the original entry point may still be open even after the visible problem is gone.

Don't call a redirect solved until the headers, the browser, and Search Console all agree.

A short validation list keeps the process repeatable:

  • No unexpected 30x chain: the request reaches the correct page without detouring.
  • No stray Location header: the final response doesn't send the browser elsewhere.
  • Correct final status: the page ends where it should, with the right status code.
  • Clean mobile and desktop tests: both user paths behave the same in private mode.
  • No recurrence on a second device: the issue doesn't reappear off your usual browser profile.

That routine is fast enough to reuse on every ticket, and strict enough to keep you from closing incidents too early.

Triage Redirects Across a WordPress Portfolio

One redirect ticket is a site problem. Three tickets across different installs start to look like portfolio risk. If you manage 10, 20, or 50 WordPress sites, the useful question isn't just which site is broken. It's which site is most likely to become the next redirect incident, and which fix removes the most risk first.

Rank sites by exposure, not by inbox order

A sane Monday workflow starts with daily snapshots of core, plugins, themes, and PHP version across the portfolio. Then match installed software against known vulnerabilities and convert that into a simple risk band, like Safe, At Risk, and Critical. That doesn't replace hands-on cleanup, it tells you where to look first.

The operator benefit is obvious. Instead of opening every ticket in the order it arrived, you can move the most exposed installs to the top of the list and keep the lower-risk sites from distracting the team. That's the difference between chasing symptoms and managing a portfolio.

A good triage screen should show the top issues per install, the current risk band, and the next action in order. That gives you a repeatable way to decide whether the redirect ticket is an isolated cleanup, a plugin update, or a bigger security response. It also helps reduce alert fatigue, because you're not reacting to every signal the same way.

A simple prioritization rule for busy teams

If several sites flag at once, start with the one that combines the highest risk with the most business exposure, then move down the list. If two sites look similar, pick the one with the clearest exploit path or the oldest unpatched component. If the tooling keeps firing without changing the risk band, stop treating the alert as a task list and treat it as a queue that needs ranking.

WP Triage fits that portfolio model because it turns scattered site findings into a ranked sequence instead of another wall of notifications. If you're dealing with recurring redirects across multiple installs, visit WP Triage and use the portfolio view to decide which site needs attention first.