When your site opens another one
A customer clicks your name in the search results and lands on a pill shop, a fake tech support page, a betting site. They write to you, or they never come back. You open your own site in turn: everything's fine. You reload: still fine. The redirect is there all the same, and it's written to hide from you in particular.
Why you're the last to see it
A redirect built to last is conditional: it looks at where the request is coming from before deciding what to serve. The conditions stack, and they all serve the same purpose — fire for the stranger, stay silent for the owner. So what you see from your own machine tells you nothing about what your visitors are getting.
The visitor arrives from a search result
The redirect reads the referrer — the page the click came from. If it's a search engine, it acts; if it's the address bar or a bookmark, it stays silent. This is the most widespread condition, because it's the one that pays: search traffic is fresh traffic, with no reason to find the landing page strange.
The visitor is on a phone
The redirect reads the browser signature and only targets mobile. That's enough to make it invisible from the desktop computer you work on all day, and perfectly visible to half your visitors.
Once per address only
It drops a cookie in the browser, or remembers the address the request came from: the same visitor only gets redirected once. If you're trying ten times in a row from the same machine, you used up your one and only trigger on the first attempt — often before you even knew you were supposed to be looking.
You always arrive the same way
Through your bookmark, on your computer, from your network, already logged into the admin. Each of these habits ticks an exclusion box. The site owner is, quite precisely, the visitor profile the redirect avoids: the only one whose visit could lead to its removal.
Reproducing it deliberately, from home
The principle fits in one sentence: stop arriving the way you usually arrive. Each step below lifts one exclusion condition, and they're ordered that way because the first takes ten seconds and the last a quarter of an hour. A single observed trigger is enough — that's your answer, and you can stop there.
Open a private browsing window
It arrives with no cookie and no admin session: two exclusion conditions lifted at once. It's the test that costs ten seconds, and it already reveals the redirect in a good share of cases. Close it between attempts, otherwise the cookie dropped on the first try shields you from the next ones.
Arrive from a search result
Type site:yourdomain.com into Google, then CLICK a result instead of typing the address: the click passes the referrer the redirect is waiting for. Do it again from Bing and from your phone. A condition sometimes targets a single search engine, and you'd have drawn conclusions too fast by only trying the other one.
Change device AND network
A phone, Wi-Fi off, on mobile data: different browser, different signature, different address. Those three changes at once lift almost every remaining condition. Also ask the person who reported the redirect exactly what they were doing — their description is worth more than ten blind attempts.
Request the page the way a search engine requests it
Search Console's URL Inspection tool tests the live address and shows you the code actually served to the crawler, referrer included. Bing Webmaster Tools has its own. It's the only view that escapes your own browsing habits, and it's free.
Write everything down the second you see it
The full destination address, the date, the time, the device, the path followed, and a screenshot. That is what will serve you with your host, your client or your insurer — and it is what will allow you, once the removal has been carried out, to repeat the same request under the same conditions to prove that the response has changed.
Where the redirect sits
A redirect fits in a few lines, and those lines fit in four kinds of places. Three are on your side. The fourth is elsewhere, on a server belonging to someone else, and that is the one that makes a removal deceptive: the calling line is removed, the rest goes on existing beyond your reach.
The server configuration file
The .htaccess file runs before your content management system, on every request, and three lines are all it needs to set a condition based on the referrer or the browser. There is often one per folder, its name starts with a dot, and many FTP clients hide it unless you explicitly ask them to display hidden files.
A bootstrap file of the content management system
The file loaded on every page: the index, the configuration, a functions file from the active theme, an extension installed for the occasion. A line placed there runs on all your pages, including the ones you published yesterday, and it looks so much like its neighbours that you can read over it ten times without spotting it.
A database record
Here it is no longer a matter of a file: a value stored in a settings table, a block slipped in at the bottom of a piece of content, a page template stored in the database. A file comparison looks at files; what lives in the database has to be read back in the database — the export of the settings table can be read line by line, and it can be done in an evening.
A script called from a third-party domain
Your page loads a script hosted elsewhere: the redirect itself lives on a server that belongs to someone else, and its contents can change from one day to the next without anything changing on your end. What's on your end is the call line — and that's the part that pulls back.
A redirect removed in one place comes back if it stays written elsewhere
The move that fails most often is also the most natural one: you finally find the three lines in the .htaccess, you remove them, the site returns to normal — and three days later it starts again. Those lines were a copy. Whatever wrote them stayed somewhere, and rewrites them at the very next visit. As long as the exact list of modified files remains unknown, every removal is a gamble.
This is the point where the human eye reaches its limit: a living site carries tens of thousands of files, and the one that was added looks just like its neighbours. The question that can be answered, however, is the reverse one. Our analysis asks every file to justify its presence, by comparing it to the authentic code published by its publisher. What justifies itself is counted; the rest is named, one by one, with its date and its location — including the file that rewrites the others.
You receive the exact count, the list of files, the probable date of entry, and three signed documents: the report, the certificate of the state obtained, and the document you can hand to your host or your client. Each one can be verified with us, free of charge, by anyone and forever — that is what makes them enforceable.
There is no free scan here, and that is deliberate: a free scan would almost always answer that it found nothing — the expected good news, given without proof, to people who did not need it. We sell certainty, not worry. Record costs €99 per site; at €199, Restore additionally returns the publishers' files to their authentic version.
The reservation is written on every document, and it applies here: a fully accounted-for site is a site in which every file has accounted for itself — which is already a great deal, and remains something other than a secure site. A redirect tucked away in the database, or a password still known to someone else, stays beyond the reach of a file comparison, and that is why both are reviewed by hand.
Once it is gone
Make the request again under the exact conditions in which you saw the redirect: the same device, the same network, arriving from a search result, a fresh window. Then request a review of your site from the search engines, using the URL inspection tool, so that the reviewed page replaces the one they hold in memory.
Then certify the resulting state: that fingerprint is what will tell you, next month, whether the site is still the one you restored. Monitoring watches this certification and states precisely: when it breaks, it signals that this site differs from the one that was certified. Your own deployment breaks it in the same way — which is why you re-certify after every release, and why a break with no deployment deserves a close look. Watch costs €99 per site per year, as a single payment with no renewal, €199 with Restore.
Where exactly does the redirect start?
Every file on your site justifies its presence, or it is named — with its date, its location, and three signed documents that someone else can verify.