Site redirects to another website: how to find and remove a WordPress hack redirect

If mobile redirects to another website or visiting from Google opens a different site

These two symptoms account for most complaints and most often point to hacking or third-party advertising code added to the page. Google Search Central’s article on sneaky mobile redirects explains that a script added to show advertising can send mobile users to another website without the owner’s knowledge, and that hacked sites may show spam redirects only to mobile users. The same article recommends checking the site by visiting from Google search results on a smartphone.

If a customer reports being redirected on mobile, ask which browser they used and where they clicked through to the site. If a different site opens from Google but not when typing the address directly, a referrer condition is almost always involved. This information determines which of the following diagnostic steps to start with.

How to verify a redirect step by step

The purpose of verification is to document the conditions under which the redirect runs and how Google sees the page. Perform the steps in this order:

1. Incognito window: Open the homepage and a few internal pages in the browser’s incognito or private window without a WordPress session or cookies.
2. Phone using mobile data: View the same pages on a phone that is not logged in as an administrator, using mobile data instead of office Wi-Fi.
3. Click through from Google: Search for the brand name or a service on Google on the phone, then click the result; compare this with visiting by typing the address directly.
4. site: search: Enter site:alanadi.com in Google and check the index for pages with Japanese, pharmaceutical, or betting titles that do not belong to the site.
5. URL Inspection live test: In Search Console, use the URL Inspection tool to run “Test live URL”, then inspect the screenshot and raw HTML with “View tested page”. This shows the page received by Google’s crawler; spam text or scripts absent from the owner’s screen may appear here.
6. Security Issues report: The report under Security and Manual Actions in Search Console lists example URLs detected by Google.
7. Take notes: Record the time, device, browser, and destination address; this record is also used in the review request after cleanup.

For technical readers: requests with a different identity using curl

If you can use the command line, a single line shows what the server returns to visitors coming from a phone and Google:

curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://alanadi.com/

Here, -A makes the request look like an iPhone, -e adds a referrer as if arriving from Google, and -sI prints only response headers without progress output. If the response contains a Location: line pointing to another domain, the redirect is server-side, most likely in .htaccess or PHP. If headers are clean but the browser redirects, the code is running through JavaScript; in this case, remove -I and look in the page source for unfamiliar <script> tags.

Where do WordPress hack redirects most often hide?

The redirect code sits in server configuration, PHP files, or the database; in many cases, copies are left in multiple places. WordPress.org’s “My site was hacked” page states that .htaccess is one of the most frequently modified files, regardless of infection type. The following table matches symptoms with likely hiding places:

.htaccess redirect rules

On Apache servers, the .htaccess file in the root directory can redirect before the request reaches WordPress. Attackers add HTTP_USER_AGENT or HTTP_REFERER conditions with RewriteCond lines and then write a RewriteRule pointing to an external domain. WordPress.org reminds users that .htaccess can exist in directories beyond the root; copies under wp-content and uploads should also be opened and read.

wp-config.php, functions.php, and core files

Files executed on every page request are an attacker’s first choice. WordPress.org lists index.php, header.php, footer.php, and functions.php; wp-config.php is also a frequent target because it loads at the very beginning. Long single lines added at the beginning or end of a file and obscured with functions such as base64_decode, eval, and gzinflate are the most typical sign.

Database: wp_options and post content

If the siteurl and home values in the wp_options table are changed, the entire site and administration panel redirect to another address. A subtler method inserts <script> into post and page content in wp_posts or widget settings; redirection continues while files look completely clean. Searching the database for the attacker’s domain and expressions such as <script and eval( reveals these records.

Nulled plugins and themes

An unlicensed distributed copy of a paid plugin often comes with a backdoor. WordPress’s security hardening documentation recommends avoiding plugins and themes from untrusted sources and using only the WordPress.org repository or known companies. If the cleaned site is rebuilt with the same nulled plugin, the redirect returns.

PHP files inside wp-content/uploads

The uploads folder is for images and documents; finding files with a .php extension there is a strong warning sign. These files are often backdoors allowing the attacker to return. WordPress.org also emphasizes that installers only overwrite existing files, whereas hacks frequently add new files.

WordPress redirect hack cleanup: in what order?

Cleanup is based on first recording the current state, then closing off the source; changing the order loses both evidence and the recovery route. The sequence based on WordPress.org’s steps is as follows:

1. Backup: Even if a clean backup exists, make another copy of the infected files and database. WordPress.org recommends keeping this copy as a reference in case things go wrong.
2. Find the source: Search files, .htaccess copies, and the database for the domain and conditions seen during diagnosis; examine recently changed files in date order.
3. Clean up: Replace the wp-admin and wp-includes folders through FTP/SFTP with the exact version used on the site. Reinstall plugins and themes from official sources, remove nulled copies, and clean PHP files from uploads and scripts from the database.
4. Passwords and salts: Change FTP/SFTP, WordPress administrator, hosting panel, and database passwords for all users; delete unfamiliar administrator accounts. Refresh the security keys in wp-config.php to terminate active sessions.
5. Update: Update WordPress, plugins, and the theme to their latest versions; change passwords once more after cleanup has been verified.
6. Review request: If a security issue appears in Search Console, request a review after repeating the diagnostic steps to confirm the redirect no longer runs.

WordPress.org recommends manually replacing files through FTP/SFTP instead of using the dashboard reinstall option. The broader recovery process, KVKK (Turkey’s Personal Data Protection Law) notification, and access renewal checklist are also explained on the recovering a hacked WordPress site page; this article focuses only on redirect infections.

How do you submit a review request in Search Console?

If there is a warning in the Security Issues report, select “Request a review” in the report after cleanup is finished and explain the work performed. According to Google’s Security Issues report page, a good request contains three things:

• Exactly what the issue on the site was
• The steps taken to fix the issue
• Documentation of the results of the work performed

Google states that reconsideration reviews may take from a few days to a few weeks. A request submitted before the issue is fully resolved may be rejected, so incognito, mobile, Google click-through, and URL Inspection tests must first return clean results. The notes taken during diagnosis form the backbone of this explanation.

False alarm? Redirects that are not hacks

Not every redirect is malicious; if the visitor goes to another address on the same site, it is often a legitimate setting. Google’s spam policy also lists moving a site to a new address, combining multiple pages into one, and sending a logged-in user to a page within the site as valid redirect examples. Rule out these situations before panicking:

• www and https redirects: Moving from http to https or from an address without www to one with www is normal, and the domain does not change.
• Redirect plugins: 301 rules set up for deleted pages move visitors to the new page on the same site.
• Language or country redirects: Multilingual sites may move visitors to a subdirectory such as /en/ based on browser language.
• Payment and login flows: Moving from a cart to a bank or payment page and returning to the site when the transaction finishes is expected behavior.
• Advertising network scripts: If the site displays ads, advertising code can send mobile users to another website, as Google also states; even if this is not a hack, the result for visitors is the same.

The distinguishing question is who owns the destination domain. If visitors go to another domain, especially a betting or advertising page, and the owner has not configured such a setting, treat the situation as a hack or unwanted third-party code.

Security plugin scanning or manual inspection?

A security plugin quickly detects known patterns but may not find all conditional redirects on its own; manual inspection catches what scanning misses. WordPress.org also states that a single solution is not the best approach and that combining in-application and remote scanners improves the chances. The differences between the two methods are as follows:

A plugin is valuable for the first cleanup step and subsequent ongoing monitoring. If the redirect returns after cleanup, the problem is often a backdoor beyond the scan’s reach or access credentials that remain exposed.

Common mistakes and the correct approach

The most common mistake is ignoring the issue because the site opens normally on your own computer; conditional redirects are designed precisely around this misconception. Other frequent mistakes and their correct alternatives are:

• Deleting only visible code: If the file, user account, or scheduled task rewriting the code is not located, the redirect returns.
• Blindly restoring a backup: The backup must have been taken before the infection began; otherwise, the problem is restored as well.
• Changing the password once before cleanup and leaving it: WordPress.org recommends changing passwords again after the site has been cleaned.
• Changing only the administrator password: FTP, hosting panel, and database access must also be renewed.
• Submitting the review request too early: A request sent before all tests are clean may prolong the process.

Brief measures to prevent recurrence

Preventing the redirect from returning depends on ongoing maintenance as much as cleanup itself. The key basic measures from WordPress’s hardening documentation are as follows:

• Regularly update WordPress core, plugins, and the theme; delete unused plugins.
• Obtain plugins and themes only from the WordPress.org repository or known companies.
• Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php to disable PHP file editing from the dashboard.
• Take regular backups, including the database, and store them off the server.
• Use long, unique passwords and two-step verification for administrator accounts.

For regular updates, backups, and monitoring, the annual WordPress maintenance and updates service is planned according to site size at 500–2,000 TL per month.

How does Onur Freelance handle redirect issues?

Onur Freelance is a web design and digital marketing studio based in Maltepe/İstanbul that has built and maintained WordPress sites since 2019. For redirect complaints, we first document the triggering conditions using the diagnostic steps above, then examine files, the database, and user accounts together. Because every hack has a different depth, the fee varies from 3,000–10,000 TL depending on the situation; the exact amount is provided in writing after the scope is examined.

The process is transparent: every change is noted, a pre-cleanup copy is kept, and the Search Console explanation is prepared from those notes. For WordPress errors unrelated to hacking, the WordPress troubleshooting service is used; where comprehensive recovery is needed, the hacked site recovery process is applied. No cleanup means a site can never be attacked again; regular maintenance is what reduces the risk.