The Website Redirects to Foreign Sites

In short: If the website redirects to foreign sites, the cause lies in one of six layers: DNS, CDN or proxy, web server configuration, PHP code, database or included scripts. Because many redirects only trigger under certain conditions, test deliberately with different identifiers and referring pages. Protect visitors first, secure traces, and close the entry point once the redirect is removed.

When customers end up on prize draw pages

The report usually comes from outside. A customer writes that visiting your site took them to a prize draw or a questionable shop. You check on your own computer and everything looks normal. This is not a contradiction but intentional: redirects planted after a hack are built so that operators notice them as late as possible.

This is delicate for your company. Visitors lose trust, search engines and browsers may display warnings, and the target pages sometimes hold fraud or malware. A redirect is also almost never the only thing an attacker leaves behind.

After PHP2Shell, the vulnerabilities CVE-2026-109618 and CVE-2026-109619 with code execution without login, redirects are among the visible consequences that operators should take seriously. They are not a specific PHP2Shell indicator, as no confirmed indicators of compromise exist. But they show that someone was able to change content on your website.

Redirects often do not come alone. Anyone who redirects visitors frequently also creates spam pages for search engines to capture even more traffic. If Google already shows a notice about a hacked website, the guide Removing a Google warning describes the path to a review. The article SEO Spam and Foreign Pages in the Google Index covers foreign pages in the search index.

Why the website only redirects sometimes

Conditional redirects evaluate characteristics of the request. These are common:

• Origin: Only people arriving via a search result are redirected. Direct visits show the normal page.
• Device: Only mobile devices or certain browsers are affected.
• Repetition: The redirect triggers once per visitor, then sets a cookie and stays quiet.
• Login: Anyone logged in to the CMS never sees anything.
• Time or chance: The redirect triggers only for a share of the requests.

So do not test only at your workstation. A read-only request shows how the server responds to different requests:

# Normal request: status code and target of a possible redirect
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/

# Request as from a mobile device arriving from a search
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
  -e "https://www.google.com/" https://www.ihre-domain.de/

If a foreign target appears only on the second request, the redirect sits on the server. If both look normal, it may happen in the browser via JavaScript. In that case, look at the source of the delivered page or at the network view of the browser's developer tools, ideally in a private window.

Website redirects: checking the six layers

Work from the outside in. That way you avoid searching the code for hours while the cause lies in a DNS entry:

The outer layers are often skipped because they do not sit on your own server. That is exactly why they are dangerous: anyone who has taken over the account at the registrar or the CDN provider needs no access to the server. There, check not only the rules but also who has access and whether two-factor login is active.

For the web server layer, read-only searches for rules that react to origin or device are suitable:

# Redirect rules with conditions in all .htaccess files
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website

# Redirects in the server configuration (Apache and Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null

For the PHP layer, Comparing CMS core files with the original describes the procedure. For the database, the article Checking the database for injected code is worthwhile.

When the cause lies outside the server

Not every redirect means a compromised server. Third-party scripts that are included, for example for chat, statistics or advertising, run directly in the visitors' browsers. If such a provider is compromised, or a domain expires from which your page still loads a script, a redirect can arise without any file on your server having been changed.

A Content Security Policy limits the sources from which the browser may load scripts and makes such cases visible. Notes on this are found under Security headers for websites. Very rarely the cause lies with the visitor: adware or malware on their computer then redirects on other websites as well.

The right order after the discovery

1. Protect visitors: Put the website into maintenance mode or block the affected areas.
2. Secure traces: Copy suspicious rules, files and database content with a timestamp before you remove them.
3. Remove: Eliminate the redirect and replace core files from a clean source.
4. Close the entry point: Bring PHP to a fixed version, update the CMS and extensions, restart all workers, renew credentials.
5. Retest: Check again with all the variants from the second section and watch Search Console.

How does PHP SOS help?

• We reproduce the redirect with different identifiers and referring pages and narrow down the layer.
• We secure traces and remove redirects, malicious code and backdoors in files, configuration and database.
• In an acute infection, our emergency help for hacked websites takes over containment until the incident is closed and documented.
• We review included third-party scripts and recommend a suitable Content Security Policy.

Frequently asked questions

Sources

• Google Search Console Help
• Apache HTTP Server Documentation
• OWASP Cheat Sheets