WordPress redirects to an unknown site: find the cause and secure the visit

Stop the visit before changing the site

You open your WordPress site and the browser ends up at an address you do not recognize. This could be a rule left over from a migration, a third-party tool or unauthorized access. The goal is to identify the first point sending visitors to this destination, then fix that cause without erasing evidence or disrupting other pages.

Do not enter any credentials at the unknown destination, download anything or accept notification requests. If a security warning appears, do not bypass it. Notify the site administrator and host through their usual contact details.

A redirect to a fraudulent page requires prompt containment, even if the cause is still unknown. The browsing comparisons described here apply when the destination is not clearly dangerous. For a page reported as infected, have the host perform the technical observation without reopening it in your usual browser.

Describe the observed scenario precisely

Record the starting address, final displayed address and time with time zone. Keep an already available screenshot instead of repeating the route. Distinguish the domain, which identifies the site, from the page path. An old page moved to a new section is a different problem from leaving for another domain.

Specify how the visit began: bookmark, search link, email link or direct entry. Indicate whether the move is immediate, happens after a few seconds or follows a click. These details guide diagnosis without automatically identifying the party responsible.

Record affected devices and accounts from the reports received. A logged-in administrator may not see what a logged-out visitor encounters. Do not ask readers to repeatedly test a suspicious page; collect circumstances already observed and have other variations examined in an appropriate environment.

Preserve evidence and identify who can intervene

Before making changes, have the state of affected files, database and settings preserved. Ask the host to retain available logs. Keep an earlier copy separate from the copy observed during the incident: the latter may contain useful data and the fault being investigated, without representing a clean state.

For rules in an intermediary service, retain a private screenshot of the condition, destination and execution order. Then record every change with its author and time. A global purge or immediate restoration can remove clues without closing the access method responsible.

Identify the available access: WordPress administration, hosting account, domain management and any CDN, a service positioned in front of the server. A WordPress administrator role does not automatically grant access to the other panels. Without authorization for the relevant layer, send observations to its administrator; do not try to bypass permissions.

Also record the WordPress version, hosting type and recently changed components from available screens or with the administrator.

Choose between three approaches

The first approach concerns behavior limited to one browser or device. It checks the actual starting point, browser extensions and local settings without changing WordPress. A single differing result remains a clue: the site may also restrict its behavior to certain visitors.

The second approach looks for a legitimate but misconfigured redirect. It fits problems following a migration, domain rule or identified component change. Compare the intended configuration with the one actually applied before making a targeted correction.

The third approach handles unauthorized or dangerous behavior. If nobody recognizes the destination, unknown accounts appear or changes return, involve the owner and host. The priority becomes limiting damage and establishing how the site was changed. Do not test all three routes while simultaneously changing every setting.

Approach 1: isolate the browser without erasing your reference points

If the behavior remains limited to your device and no malware warning requires you to stop, begin by checking the bookmark used. The stored address may already belong to an external service or old domain. Compare it with the owner’s documentation without replacing the bookmark with a destination merely assumed to be correct.

For an authorized comparison, use a separate, up-to-date browser profile without additional extensions. A private window does not necessarily eliminate every extension. First preserve unsaved text in work tabs. Do not clear all browser data as your first action.

If several unrelated sites show similar windows or redirects, have the device examined under your organization’s security procedure. A difference between profiles is not enough to declare WordPress clean. Stop testing as soon as a fraudulent destination or unexpected download appears; the technical administrator can continue without exposing your administrative session.

Read the first redirect rather than only the final destination

A technical administrator can examine the site’s first response without automatically following its destination. An HTTP redirect response uses a status such as 301, 302, 307 or 308 and a Location header specifying the target. HTML or JavaScript in a received page can also trigger a redirect, so the absence of a 3xx status does not rule one out.

If a network log from a completed visit is available in Chrome, open Network in developer tools and inspect the first document request. Preserve log keeps requests across navigations; it does not reconstruct a visit that was never recorded. Record the status, destination and time of the change without replaying the request.

Do not share a full network export publicly: it may contain cookies or private parameters. If no trace exists and the page is suspicious, ask the provider for a technical capture instead of reopening it to obtain a log.

For an authorized technician, curl can record the first response of a known public page. In a POSIX terminal, use the first line below; on Windows, use the second with curl.exe to avoid a PowerShell alias. Replace only votre-domaine.example with the known domain, without using the unknown destination.

The expected result is an HTTP status and, for a server redirect, Location. The -q option must remain first: it ignores a curl configuration file that could enable redirect following. -D - displays headers; -o discards the body and --max-time limits the wait to thirty seconds. No -L redirect-following option is added. A normal response does not necessarily reveal a JavaScript redirect or conditional behavior. This check requires neither login nor cookies; keep it private because headers may contain sensitive information. No rollback is required for this read-only check.

curl -q -sS -D - -o /dev/null --max-time 30 https://votre-domaine.example/
curl.exe -q -sS -D - -o NUL --max-time 30 https://votre-domaine.example/

Approach 2: find an intended but incorrect rule

With authorized hosting panel access, open the domain’s redirect section. Check the selected domain, destination, conditions and any preserved paths. A rule intended for an old section may accidentally target the entire site. Ask who created it before removing it.

If Cloudflare is used, the administrator opens the domain’s redirect rules in its dashboard. They inspect individual rules and redirect lists, as well as their order. The first applicable rule may determine the destination; changing a lower rule therefore may not alter the result.

Preserve the original configuration and compare an affected address with one that must remain unchanged. The rule simulator, available to the account’s Administrator and Super Administrator roles, helps explain a condition without proving the origin server works. Do not disable the entire CDN or firewall for this check.

External example: disable an old Cloudflare Page Rule

This route applies only to an existing old Page Rule identified as the cause. Single Redirects and Bulk Redirects are different rule families: do not try to fix them on this screen or migrate rules during the incident.

1. With permission to manage the domain’s rules, open its Page Rules page in the Cloudflare dashboard.
2. For the relevant rule, preserve the URL pattern, destination, order and initial state in a private screenshot. Use Edit to correct only the approved value, or the on/off switch to disable this rule alone.
3. Record the first response again and check a neighboring path. The expected result is the intended route without an unknown detour.
4. If this result is not obtained, restore the recorded original value or state. Do not choose Delete or disable the domain’s proxy or protections to cancel this single redirect.

Check WordPress addresses and the relevant component

In self-hosted WordPress, a trusted administrator can open Settings, then General, and record the WordPress Address and Site Address. The first may contain a legitimate subdirectory. The two fields should therefore not be made identical by default. Values enforced in configuration can also make the fields uneditable.

Compare these addresses with the domain validated by the owner. If a value points to an unknown domain without a recognized intervention, preserve it and move to incident handling. Simply correcting the field does not explain how it changed.

Also examine redirect, maintenance or campaign settings in an already installed plugin, only when evidence points to it. The X-Redirect-By header may provide a clue, but its value can be changed: it does not identify the responsible component on its own. Do not install another manager to mask the destination without finding its origin.

Apply a limited correction and retain a rollback route

A rule recognized as legitimate can be corrected by its administrator. If the origin remains suspicious, preserve the settings and move to incident handling. The following example uses an already installed Redirection plugin without adding a plugin to mask the problem. This free plugin by John Godley currently states minimum requirements of WordPress 6.7 and PHP 7.4; version 5.10.1 is declared tested through WordPress 7.1.4.

The expected result is the approved destination for the affected path without changing neighboring routes. Prefer reversible deactivation over deleting the rule and creating an inverse redirect. If the WordPress addresses themselves must change, arrange backup hosting access before saving them.

1. Open Tools → Redirection, then Redirects. Search for the exact source path, for example /ancienne-page/, and check additional conditions and the destination.
2. Copy values and the active state into private notes. Use the plugin’s export feature to save redirects as JSON; this export may cover more than the affected rule, so keep it outside the public site.
3. For this rule only, open Edit and replace the target with the approved URL, then save. If the rule should no longer apply, use Disable instead of Delete.
4. Try the path while logged out, then a path that should remain unchanged. If the result is wrong, restore the original values or reactivate the disabled rule. Do not import the full export into production to undo one value.

Approach 3: contain unauthorized behavior

When the owner recognizes neither the destination nor the change, open an incident ticket from the usual hosting customer account. Provide the affected starting addresses and observed circumstances. Ask which measures can stop the dangerous behavior while preserving material needed for analysis.

Containment may require restricting administration, isolating the site or temporarily suspending certain functions. Its scope belongs to the environment administrator, especially on shared hosting. A maintenance page does not guarantee malicious code or technical access has stopped working.

Have access capable of changing the site examined: WordPress accounts, hosting, file transfers and integrations. An unknown account must be investigated without immediately deleting its content. Secret rotation and access closure must be coordinated from a trusted device; removing only the visible link does not necessarily close the entry point used.

Have files and components examined without blanket deletion

The host or maintainer compares the installation with trusted copies and documented changes. On Apache, a redirect may come from configuration or an .htaccess file; on Nginx, server configuration may contain return or rewrite rules. Replacing .htaccess does not fix an Nginx rule and may remove useful protections.

The behavior may also come from a theme, plugin, mandatory component or external resource. Have the source loading the redirect identified before a targeted intervention. Searching for suspicious code strings produces leads, not a list of files to delete.

A WordPress core integrity check compares relevant files with official references. It certifies neither the database, plugins nor the entire hosting environment. If a component must be restored, require a backup, the appropriate version and a check of customizations. An old restoration must not overwrite recent orders and content without preparation.

For authorized technical access, WP-CLI provides the check below from the relevant WordPress directory. It runs before WordPress loads, using a trusted WP-CLI. The technician must also check its configuration and environment: wp-cli.yml or wp-cli.local.yml files, including those in parent directories, can request PHP loading. On a compromised site, prefer an isolated copy examined by the provider; do not run the command unless this chain of trust is established. If the localized package or version differs from expected references, add --version and --locale with values from a trusted inventory. Dashboard → Updates can provide them on a site with a trusted administration area; do not log back into a suspicious installation solely to collect this information.

The expected result is either matching core files or anomalies to preserve for examination. The command repairs and deletes nothing. A match does not clean the database, uploads, themes or plugins. Do not use --insecure to force a check that fails TLS. Do not replace this check with wp option get on a suspicious installation: that other command loads WordPress.

wp core verify-checksums

Understand intermittent redirects or redirects affecting visitors only

A normal result for the administrator does not invalidate a precise report. Behavior may depend on the visit’s origin, device, cookie or an intermediary-service condition. Give these differences to the provider instead of provoking repeated visits to the destination.

Request a comparison of responses for the scenarios actually reported in a controlled technical environment. The destination visible in a search engine and the page currently served do not always describe the same moment. Example URLs in a security tool are not a complete inventory of affected pages either.

After a demonstrated fix, a cache may still retain an old response. Have only the affected entries invalidated at the identified level, then check again. Before this fix, a global purge may temporarily hide the behavior or erase clues. If the fault returns whenever the cache fills, investigate what recreates the incorrect response.

Adapt the investigation to WordPress.com and multisite

On WordPress.com, check with the owner whether Site Redirect was configured for the old .wordpress.com address. In the relevant site’s hosting dashboard, Settings then Site redirect lets you read its destination. A custom-domain redirect belongs to a different setting; do not purchase a service to diagnose an unexpected redirect.

Record the value and authorization before any correction. If the destination is unrecognized or the setting inaccessible, request support intervention. Do not cancel a subscription or domain simply to stop a route whose cause remains unknown.

In multisite, confirm the targeted subsite, its domain and the scope of network components. The network administrator must participate if the rule or code affects several sites. A local fix may be insufficient; conversely, network deactivation may affect unaffected sites. Have this scope and rollback documented before the operation.

Verify several routes after the correction

Checking starts after the identified correction and, for an incident, after the chosen security measures. Check the home page, a previously affected address and an internal page that should have remained intact. Compare reported scenarios, particularly direct visits and arrivals from search engines, without following any still-suspicious destination.

Check the status and target of expected redirects, not just the page’s final appearance. On a store, do not repeat a payment or order to reproduce the problem. Reserve routes that write data or send messages for an isolated copy with external effects disabled.

If Search Console reports a security issue, its reassessment is separate from the local fix. Review the report with the owner and request a review only once the listed problems have been addressed. A persistent warning does not justify bypassing the browser. Conversely, its disappearance does not guarantee that all other access has been removed.

Keep a resolution record and prevent recurrence

The final record states the initial scenario, responsible layer, corrected rule or component, times and checks performed. Retain old settings and preserved copies privately for the period defined by the administrator. Evidence must not be placed in the public media library to make sharing easier.

If the cause remains unknown, state that limit clearly: the symptom may have stopped without its origin being explained. Ask the provider for the next check, remaining available logs and monitoring criteria. Recurrence justifies reopening the investigation into access and other layers, not stacking new redirects.

Going forward, maintain a record of domain changes, CDN changes and important rules. Assign an owner to each integration and review its access at the end of an engagement. A useful redirect must have a recognized destination, understood scope and a documented way to remove it.

Have a custom redirect corrected in its source code

If the investigation identifies a legitimate function developed for the site, its maintainer must examine how the destination is built. A URL supplied through a request parameter must not be passed to a redirect without validation. For a destination that must remain local, WordPress provides wp_safe_redirect(), which checks the allowed host and supplies a fallback destination.

This function is not a general filter to add to block every outbound route from the site. It must replace the faulty call at the identified location after validating business parameters, then be followed by the appropriate termination of processing. Allowed-host filters and loaded plugins can influence its behavior; on a compromised installation, changing this function does not restore trust by itself.

The maintainer tests three cases on a copy: the intended local destination, an unauthorized external destination and a missing parameter. Each result must match the intended route and not expose data in the URL. They also check genuinely necessary external flows, such as provider authentication, without expanding default allowed hosts to every received value.

Keep the fix in the site-specific plugin or its repository, with the previous file available for rollback. The free Redirection plugin remains suitable for recognized editorial rules; it does not replace fixing this unvalidated input in custom code.