WordPress is redirecting to another site. That is an active hack.

What this usually is

Redirects get planted in .htaccess, in JavaScript in the header or a widget, in a compromised plugin, or in PHP that inspects the user-agent and only fires for Googlebot or mobile. That is why the owner “cannot reproduce it” on the office desktop while logged in. Clearing the cache without removing the rule is a fifteen-minute holiday.

What you are probably seeing

• Only mobile visitors are redirected
• Only people arriving from Google are redirected
• You cannot see it while logged into wp-admin
• .htaccess has rewrite rules you did not write
• A JavaScript snippet in the header or footer loads a third-party domain

What not to do

• Do not only restore a default .htaccess. If a plugin or mu-plugin is writing it, the redirect returns on the next request.
• Do not change the WordPress Address (URL) and Site Address as the fix. You will break logins and leave the malware.
• Do not assume Cloudflare or the host cache is “the problem.” Cache can hide a redirect; it does not invent one to a sportsbook.

What we actually do

We reproduce the redirect the way a visitor or Googlebot would see it, find the rule or script, remove it, and close the account or file that put it there. Same published packages as any other WordPress incident. If the redirect is only the front door of a larger business compromise (365, ransomware), that is the emergency IR page — say so on the call.

Published rates live on the WordPress incident-response packages page: Phase A from $2,500, Phase B from $2,000, combined from $4,200. Remote nationwide. Onsite in the Tri-Cities and Western North Carolina if you want someone in the room. If the WordPress site is the front door to a larger business compromise, start at emergency incident response instead.