One Website Page Redirects to an Unfamiliar Domain: How to Trace It

A visitor reports that one WordPress article or page sends them to an unfamiliar domain. Other pages appear normal. This is different from a site-wide redirect, but it is not automatically safe: a narrow rule could be an old migration, a plugin configuration, custom code, or a compromise targeting only one path.

The short answer: do not immediately remove the redirect plugin, edit .htaccess, or open the destination. Record the starting URL, time, first status code, and Location header without following the redirect. Map the URL to its WordPress post or page, review per-page rules, plugins/themes, custom fields, server/CDN configuration, JavaScript, and approved campaigns. Change only the verified source, preserve a copy, and test the affected URL and nearby pages so the fix does not create a second outage.

If there are other signs—unknown accounts, changed files, or spam across multiple routes—treat this as an incident and use our guide to a hacked WordPress site. For baseline access controls after recovery, see our WordPress security guide for small businesses. This article stays focused on one URL, not a full site-wide investigation.

Verify the pattern before changing configuration

Record the full starting URL, including scheme, host, path, query string, trailing slash, and how the visitor arrived. Ask when it began, which device/browser they used, whether a new tab opened, the login state, and whether the URL was moved or used in a campaign. Do not ask for passwords, cookies, or repeated visits to a dangerous destination. Save timestamps with a known time zone and mask customer information.

Test the same URL and one normal control URL from an anonymous session. If possible, repeat on staging or a private copy. Change one variable per run: path, query, trailing slash, referrer, device, or login state. If several change at once, you will not know which condition matters. Also check whether it happens on HTTP and HTTPS, www and non-www, or only at one CDN edge. Record the status and headers for each test.

A redirect may be expected: an old page was moved, content was consolidated, a campaign ended, or checkout moved to a new URL. Compare the behavior with a migration document, business owner, SEO notes, and plugin history. If the destination is unfamiliar or points to unapproved phishing, malware, or gambling content, do not follow the link; preserve evidence and ask the host to reduce risk if visitors remain exposed.

Inspect the first response without opening the destination

Send a GET request to a URL you manage and do not use an option that follows redirects automatically. This example uses a documentation domain, not a production address:

curl -sS -D - -o /dev/null 'https://staging.example.test/page-under-test/'

If the first response is 301, 302, 303, 307, or 308, record Location, Cache-Control, and approved intermediary headers; do not copy cookies or tokens into a ticket. Standard curl does not follow a redirect unless you ask it to with an option such as -L, so leave that out while the destination is unverified. GET may behave differently from HEAD; do not rely only on curl -I if WordPress or a CDN handles the methods differently.

If the first status is 200 but the browser moves later, inspect the Network panel with Preserve log, Console, meta refresh, JavaScript, service workers, tag managers, and page-builder scripts. Curl does not execute JavaScript; therefore, “no Location on the first response” does not prove that no redirect occurred. Save the request chain and identify the script that initiated navigation, not just a screenshot of the final page.

Compare a direct visit with the reported incoming link, anonymous and signed-in sessions, and desktop/mobile only when the report indicates a difference. Mobile-specific behavior has its own variables; do not mix it into a page-only test. Keep the test order consistent so another operator can repeat it.

Map the URL to a WordPress post or page

If you have WP-CLI and authorized access, use its helper to find the ID from a URL, then inspect only the metadata you need:

wp post url-to-id 'https://example.test/page-under-test/'
wp post get <post-id> --fields=ID,post_type,post_status,post_title,post_name,post_date,post_modified

Replace the placeholder with a URL and ID in the correct environment. The official documentation covers wp post url-to-id and wp post commands. Match the ID with the dashboard, content type, status, author, revision, permalink, and modification time. If the URL is not a WordPress object, it may be handled by a rewrite, plugin, endpoint, or server; do not force a page lookup that has no match.

In WordPress, review redirect/SEO plugins, per-path redirect lists, custom fields, page builders, templates, menus, shortcodes, and scripts loaded on that page. Meta keys and storage vary by plugin; use the active plugin’s interface and documentation instead of guessing a query over all postmeta. Look for a rule matching the exact source path, destination, permanent/temporary status, login condition, parameter, or campaign end date.

If the page was moved, confirm the destination with the content owner and compare it with the migration plan and inbound links. Ensure the redirect is not part of an approved domain or URL migration. If the rule accepts a parameter such as redirect_to or a destination from a form, an unvalidated external value may create an open-redirect risk; review the implementation and allowlist instead of blaming the visitor’s URL alone. WordPress provides wp_safe_redirect() for validated local redirects; its documentation notes that it does not automatically call exit and does not handle every redirect from a server or CDN.

Trace other layers if the WordPress rule does not match

If the redirect header appears before the page renders, ask an administrator to review Apache/LiteSpeed .htaccess, Nginx configuration, virtual hosts, hosting-panel rules, CDN, workers, load balancer, and WAF. Look for rules matching one path, regex, query, host, cookie, referrer, or status. Nginx does not use .htaccess; do not make a change in a file the site stack does not read. Preserve a copy and involve the hosting owner for server-level changes.

If the first response is 200, inspect the HTML, tag manager, inline scripts, plugin header/footer output, service worker, theme, custom JavaScript, and cache behavior. Find the first request that changes location and the file/component that loads it. Do not add production debugging code that logs cookies or authorization headers. If a third-party script is involved, confirm its owner, version, and change history; ask the vendor to validate without sending them secrets.

For a WordPress page that changed without approval, review the user, revisions, plugin/theme, custom fields, cron, Application Passwords, and access logs. Compare the redirect start time with deployments, logins, and record changes. One affected URL does not rule out a payload targeting a specific path. If a rule returns after removal, find the process or configuration source instead of adding another redirect as camouflage.

Fix the cause without breaking legitimate redirects

Before changing anything, export the relevant plugin/configuration and database/file state according to your backup procedure. On staging, disable or edit one identified rule; test its status, destination, canonical URL, forms, approved tracking, and neighboring pages. Get business-owner approval for campaign or historical URL changes. Avoid globally disabling a plugin, deleting every redirect, or replacing .htaccess with a template from the internet; that can break login, checkout, canonical URLs, and hosting rules.

For an unauthorized rule, revoke the creator’s access, close the component or entry point, and inspect related files, database records, and accounts. Restore the page from a trusted backup or revision if content was injected. If visitors are at risk, ask the host for temporary containment on the affected path while the permanent fix is prepared. Record each action, approver, recovery copy, test result, and unresolved question.

After deployment, check the reported URL with anonymous sessions, relevant devices/networks, valid trailing-slash/query variants, and a control page. Confirm the destination or no-redirect behavior that the owner approved. Test headers and rendered output; clear caches after fixing the source, not just to make the administrator’s browser look normal. Review logs to ensure later requests do not create a new rule.

Google notes that hacked redirects can be implemented in server configuration or JavaScript, and Security Issues examples can help identify behavior limited to certain conditions. Check Security Issues and Manual Actions according to the notice; one report does not replace the other. If Google requests a review, send it after fixing all relevant findings and describe verifiable work.

Prevention and documentation

Keep an approved redirect inventory with source path, destination, status, owner, business purpose, start/end dates, and configuration location. Review plugin/CDN rule changes before deployment, limit who can publish rules, update supported components, and keep configuration backups outside the webroot. Monitor Location headers and customer reports for sensitive paths. Test campaign links after expiry so old destinations do not change without notice.

Maintain a baseline of theme/plugin versions and access logs that lets you compare changes. Ensure the help desk records the starting URL and time, not only a screenshot of the destination; ask the host to retain logs the application cannot overwrite. If the first audit finds multiple paths or unknown accounts, move from the single-page scope to a wider incident response using the hacked-site recovery guide.

Frequently asked questions

Does one redirecting page prove that the site was hacked? No. It could be an approved migration or campaign rule. An unapproved destination, rule without an owner, or change tied to unknown access should be investigated as a possible compromise.

What should I record before trying to fix it? The full URL, time/time zone, first status, Location header, session and device, relevant referrer, cache/CDN state, and evidence of changes. Do not store cookies, secrets, or customer data in a shared report.

Should I remove the redirect plugin if only one page is affected? Not automatically. Find the rule and owner matching the path, export its configuration, test it on staging, and change only the rule shown to cause the problem.

What if curl shows no redirect but the browser still moves? Inspect JavaScript, meta refresh, service workers, tag managers, and the browser Network/Console. Curl does not run JavaScript, so a 200 with no Location describes only the first HTTP response.

If one page still redirects visitors to an unfamiliar domain and no approved configuration explains it, request a website audit to trace the route, accounts, plugin, and hosting layer before disabling unrelated rules.