Why is my website redirecting to another website? Two questions sort it: where they landed, and who was sent away.

Someone asked for your site and ended up on a different one. Maybe it was you; maybe a visitor on a phone who came from a Google result; maybe one person who says it now happens on other sites as well. Those are different problems, and two questions tell them apart: where they landed, and who was sent away.

A redirect to another website lives in one of four places: the domain, the server, the page, or the visitor’s own browser. It is not always a hack: an expired or parked name, or an ad company’s script, can do the same, and each is fixed by someone different. On 1 October 2026 I tested the first three: eight redirects and a clean page planted in a copy of a small site on my computer, 1,500 .com names asked what their home page does, and Chrome’s own tools opened to see what they show.

Start with two questions: where they landed, and who

Ask the person who saw it, or answer for yourself:

• a phone or a computer;
• typed, tapped in a Google result, or followed from a link;
• once or every time;
• on other sites too, or only on yours.

Then read the address they landed on; ask for a screenshot if they can.

Where they landed comes first.

• Your own address with /lander on the end, a page saying the name has expired, or a parking page (a placeholder of ads or a for-sale offer): the domain, even when the site opens normally for you. The fix starts at the registrar, the company the name is registered and renewed through.
• Chrome’s red “Dangerous site” page: stop there. The hacked-site article has the checks from outside, none of which opens your pages.
• Your own site, just another page: a forward inside your site, and those have their own article.
• Someone else’s site: once the domain steps below rule it out, a rule on the server or code in the page, unless the second question points at one person’s browser.

Who was sent away then narrows it and names who fixes it.

• Only some visitors, from Google, on phones, on a first visit: a redirect that picks its visitors. It can look fine to you because you type the address, on a computer, and you have been there before; Google’s page on social engineering, dated 10 December 2025, adds a reason of its own: “clever hackers can disable their attacks if they think the visitor is a website owner”. For whoever looks after the site, with what Chrome shows you below.
• Everyone: still the server or the page. A script on every page, or a rule on the server, possibly a forward you set yourself.
• One person, on other sites too: look at that person’s browser first; the fix is theirs, with Chrome’s own steps.

If they land on “/lander” or a parked page: the domain

Three steps, none of them on your site.

1. Open lookup.icann.org, the public lookup run by ICANN, the body that coordinates domain names. Type the name and press Lookup; a link with the name in it opens an empty form. Under “Dates”, read “Registrar Expiration”; why, below.
2. If that date has passed, renew from the account where the name was registered, not from the parking page: on the three expired “/lander” names I opened, its one button led to a domain search, not to renewal.
3. If it is still ahead, ask whoever manages the name to compare its records, the settings that say which computer answers for the name, with what your host says they should be, and to remove any that nobody meant to add. The lookup’s “Nameservers:” line is the first of those settings, to set beside the name servers your host gave you.

Why the landing address points at the domain. On 1 October 2026 I asked 1,500 .com names made from common words what their home page answers, with a fetch that runs no code and, for thirteen of them, in Chrome 154 driven by a script that stopped every attempt to leave for another site. 1,011 were registered with an address to answer from; the sample leans to names held for resale, and the counts describe it on that day, nothing wider.

268 of the 1,011 answered with the same page, empty but for one line of script telling the browser to go to /lander on the same name: 114 bytes in 266 of them; the other two had an analytics tag added after it. No redirect in the server’s answer, so a checker that only follows it stops at a normal page and reports none. /lander then led to GoDaddy’s parking page for 90 names and its for-sale page for the other 178; the parking page I opened read “is parked free, courtesy of GoDaddy.com.” under the name.

The right reading is “pointed at GoDaddy’s parking”, not “registered at GoDaddy”: GoDaddy.com was the registrar for 184 of the 268, and other registrars, Namecheap among them, held the rest. 46 of them answered from the address pair 15.197.148.33 and 3.33.130.190, and all 46 names in the sample on that pair went to /lander. A 2024 staff answer on WordPress.com’s forums, in a thread about /lander, named the first of those as “an extra A record (15.197.148.33) that points to GoDaddy”: a record nobody meant to add, which is what step 3 looks for. Why a given name points there, my sample cannot say.

Three names pointed at GoDaddy whose registrar expiry fell between 18 and 23 September 2026 went to /lander like the rest, and the page read “has expired and is parked free, courtesy of GoDaddy.com.” Its one button, “Get This Domain”, led to GoDaddy’s domain search; no renewal steps were on the page. One more name past its registrar’s expiry date still served an ordinary, working website.

Read “Registrar Expiration”, not “Registry Expiration”

The public record can show next year’s date for a lapsed name. For one of the three expired names, the lookup listed under “Dates” Registry Expiration: 2027-09-21 and Registrar Expiration: 2026-09-20: the registry’s date a year ahead, the registrar’s showing the lapse.

For generic domains such as .com, ICANN’s own pages back the steps. On renewal, its expired-registration policy, updated 21 February 2024, says “the registrar must restore the DNS resolution path set by the RAE immediately or as soon as is commercially reasonable”, the RAE being you, the registrant at expiration. For records that are not what you or your host set, ICANN’s blog for domain holders says that if “your account information was modified without your consent, immediately contact your registrar.”

ICANN also wrote, on 9 March 2026, that on parked domains “users can, under certain conditions, be redirected to different domains without any interaction on their part”. I saw it once: when my scripted Chrome called itself an iPhone, a for-sale page tried to send it on to another domain in 3 of 5 runs (my script stopped it there; the other 2 ended in an error); as a desktop, it stayed put in all 3. It looks like a page problem and is a domain one.

If they land on someone else’s site: the server or the page

Go the way the visitor went

Google’s guide on malware tells owners to avoid opening a suspect page in a browser, and the hacked-site article follows it. Here the question is where visitors are being sent, and Google’s own advice for that is to go the way they went: its post of 29 October 2015 on sneaky redirects says to check “by visiting your pages from Google search results with a smartphone”. On the page you land on, click nothing and download nothing; if Chrome shows its red page, stop and take the hacked-site route.

So: on a phone, your business searched for in Google and your result tapped; the address typed; and, for a rule that fires once per visitor, a fresh Incognito window after closing every other one, because Chrome’s help page on Incognito says “To end your Incognito session, you must close all Incognito windows”. Since ad networks may rotate the ads, Google’s page on social engineering adds, “you might need to refresh a page a few times”.

Why a browser and not a checker

On 1 October 2026 I put eight redirects and one clean page to compare against into a copy of a small site on my computer, with a second local site to be sent to and a third serving only a script. I asked each address with a plain fetch that runs no code, following redirects or not, and with a real browser driven by a script: Chromium 151, the open-source base of Chrome, a fresh profile each run, calling itself a desktop or an iPhone. This is my simulation, not a hacked site: a real one may combine conditions and hide in a database or a plugin, and nothing here says how common any case is.

Five of the eight returned a normal page to every check that reads only the server’s answer, and each of the eight sent the browser away under its own condition. That check can show code, a script tag, or code with no readable address, but it does not go, so a redirect checker that works that way can say “no redirect” for a page that sent the browser away in every run; I did not test which online checkers run code, so I name none. Nor is a script from another host, or the phrase window.location, a sign by itself: on 1 October my own clean sites, kovalseo.com and cryptowl.io, both loaded an analytics script from another host, and cryptowl.io’s page holds that phrase three times, each time only reading its own address.

Which file sent the visitor away

On a laptop, Chrome can show you. I checked these labels in Chrome 154 on 1 October 2026.

1. Open a new tab and press Cmd + Option + I on a Mac, or Ctrl + Shift + I (or F12) on Windows, the shortcuts in Chrome’s own guide. That opens DevTools, Chrome’s built-in panel for people who build pages; click Network. Do everything below in this same tab.
2. Tick “Keep log” in its toolbar, and pick “All” in the row of filters below it, or the page rows stay hidden. The tooltip on “Keep log” reads “Don’t clear log on page reload / navigation”. Without it the list is wiped when the page moves, and in my run without it nothing pointed to the script file. Chrome’s own DevTools guide, last updated in July 2024, and Google’s Ad Manager help still call it “Preserve log”, its older name.
3. Arrive the way the visitor did. From Google: search for your business in this tab and click your result. As a first visit: do it all in a new Incognito window with every other Incognito window closed. On a phone: a real phone is the surer check; Chrome’s guide describes a phone mode (the “Toggle device toolbar” icon, then a phone from the “Dimensions” list), which Google’s manual-actions page calls the “Chrome mobile emulator”; I did not test it against my phone-only rule.
4. Click the row for the page you landed on (the Name column shows only the end of an address; mine read “landing?case=f”) and open its Initiator tab: “Request call stack”, “Request initiator chain”, or “No initiator data”. Take a screenshot.

Read the Initiator tab, not the Initiator column: for my scripts the column was blank or a “VM” number that changed between screenshots. What the tab showed for my cases, a reading, not proof of who wrote the code:

• The row just above it, your page, has Status 302 (or 301) and Type “document / Redirect”: the server, or a service in front of it, sent the visitor.
• The chain runs through a file on another company’s address, as mine read page → localhost:47803/widget.js → other site: that company’s script.
• The call stack names your own page with a line number: code inside your page, yours, a plugin’s, or slipped in by someone.
• “No initiator data”: ask whoever looks after the site to look for a “refresh” tag in the page’s code.

For a script, Google’s removal test, a job for whoever looks after the site: take the other companies’ scripts off that page one at a time and, after each, repeat the visitor’s route; when it stops, the last one removed was the cause. Send them the address the visitor landed on, the device, the route, the date, and that screenshot.

Other companies’ scripts: ads, chat, widgets

Google wrote this down in its 2015 post:

Google’s Search Central blog, 29 October 2015

A script/element installed to display ads and monetize content might be redirecting mobile users to a completely different site without the webmaster being aware of it.

The removal test is its fix, “Remove one by one the third-party scripts/elements you do not control from the redirecting page(s)”, and Google’s current help page on manual actions keeps it: “After removing each script or element, check your site behavior on a mobile device or in Chrome mobile emulator (or any other emulator) to see if the redirection stops.”

Chrome’s help page on pop-ups says “By default, Google Chrome blocks pop-ups from automatically showing up on your screen.”, but in my test in Chrome 154, with that on, none of the four in-page redirects I ran again (the script line, the refresh tag, the other host’s script, the encoded line) was stopped. Chrome did stop a frame from another site that tried to move the whole page, a rule the Chromium blog announced in 2017 for redirects “originating from third-party iframes” and, per its June 2018 update, set for Chrome 68, but a script loaded into the page itself was not stopped.

If it fires only from Google or on phones, and nothing in your page explains it

Google’s spam policies, updated 28 August 2026, describe it: “Hackers might inject malicious code to your website that redirects some users to harmful or spammy pages”. That is a job for whoever looks after the site; the hacked-site article’s outside checks are yours.

If one person is sent away: their own browser

Chrome’s help page on unwanted software lists, among the signs of something installed on the visitor’s own computer, “Your browsing is hijacked, and redirects to unfamiliar pages or ads”. It also says: “Before you reset your browser settings, check your computer for unwanted programs.” The Chrome Web Store’s page on extensions that change settings: ‘Look for a rectangular box that says “An extension, [extension name], is controlling this setting.”’ On Android: “One by one, remove recently downloaded apps.” The fourth question is the test: if it happens to that person on other sites too, look at that browser first. An extension runs in an Incognito window only if someone has allowed it to, and the window starts without what the browser has stored, so a redirect that stops there points at its extensions or at what it has stored.

How to know it is fixed

The route that showed it is the route that proves it.

For the domain: the lookup shows your name servers and a “Registrar Expiration” in the future, and the home page, typed, is yours again; after renewal ICANN’s policy gives the registrar “immediately or as soon as is commercially reasonable”, so allow for that.

For the server or the page, the same kind of device and the same arrival:

• on a phone, from a Google result;
• the address typed;
• a first visit, in a fresh Incognito window with every other one closed, since a rule that fires once per visitor hides from a second one;
• a few reloads;
• and, with Network open and “Keep log” ticked, no row for the other site.

A check that reads only the server’s answer can’t show that a script redirect is gone.

For one person: their browser no longer does it, on your site or any other.

Repeat each route that sent someone away until every one ends on your page.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.