Website redirects to a casino: how to find and remove it
If your site opens a casino or a betting page instead of your own, especially on mobile or when arriving from search, it is almost always a hack, not a virus on your computer. The code is planted so the owner never sees it: on a desktop everything looks fine, while visitors and Google get the redirect. Below: how to confirm the problem is the site, where exactly the code sits, and how to remove the redirect so it does not return.
Is it a hacked site or a virus in your browser
First work out where the problem is, because the fix differs:
- Open the site on a phone over mobile data and ask someone in another city. If it redirects for them too, the problem is the site.
- If many different sites redirect to a casino only for you, the problem is your browser or an extension.
- If only your site redirects, and only for some visitors, it is a hack.
The rest of this covers the case where the site itself is the problem, which is the usual one behind "my website redirects to a casino".
Check your site right now
The tool opens your site from the outside the way a search engine and a mobile visitor see it. They are usually the ones served the redirect. A mobile redirect, cloaking and an outdated CMS show up at once. No access to the site is required.
Why not everyone sees the redirect
The nastiest part of this hack is that the redirect fires selectively, so the owner is often sure everything is fine:
- Mobile only. On a desktop the site opens normally, while phones are sent to a casino.
- From search only. Type the address directly and there is no redirect; arrive from Google and there is.
- Once per device. It redirects only on the first visit, then sets a cookie and behaves.
- Cloaking. Googlebot sees a clean page, a real visitor gets the redirect.
So a single desktop visit proves nothing. You have to check the way real visitors arrive.
Where the code actually sits
The typical places the redirect code is planted:
.htaccessin the root or subfolders: aRewriteRuleconditioned on mobile or the referrer.index.phpand the active template files: injection is usually in the first lines, often viaeval(base64_decode(...))or base64.- The database: in WordPress
wp_optionsandwp_posts, in Joomla the template parameters in#__template_styles. - A third-party JS: a script pulled from a foreign domain that does the redirect in the browser.
This is why the hosting antivirus often stays silent: the code sits in the database or in .htaccess rules, while the files themselves are clean.
How to remove the redirect step by step
- Make a copy of the current state, even infected.
- Change every password: admin, FTP and SSH, database, hosting panel.
- Check
.htaccessin the root and subfolders, remove foreignRewriteRules. - Check
index.phpand the template files for injection in the first lines. - Check the database for foreign scripts and domains in template parameters and posts.
- Find and delete web shells: unknown .php files in uploads or media.
- Update the CMS and extensions, remove unused ones.
Why the redirect comes back after cleaning
The most common complaint: removed the code, and a day later the redirect is back. The reason is simple, the symptom was removed but not the way in:
- A web shell was left behind, and the code is re-uploaded through it.
- A cron job is running that restores the redirect on a schedule.
- The vulnerability used the first time was never closed.
Removing the redirect and closing the way in are two different jobs. Without the second, the site is hacked again the same way, often the same day.
If the site is on Joomla or WordPress
Joomla. Joomla 3 is especially exposed: no security updates since 17 August 2023. Attackers get in through extensions (JCE, SP Page Builder) or the Helix3 framework, and hide the redirect in template parameters in the database. Without moving to version 5 or 6 the site gets reinfected.
WordPress. Look at wp_options (the siteurl, home and custom records), wp_posts, the active theme functions.php, and the uploads folder: it must contain no .php files. The way in is usually a neglected plugin.
When to call a specialist
It is worth calling in a specialist if:
- you already cleaned the site and the redirect came back;
- the code is in the database or in
.htaccess, and the hosting antivirus stays silent; - it redirects only on mobile or only from search and you cannot catch the code;
- the host suspended the account for malware;
- there is no working clean backup.
I find and remove the casino redirect on any CMS and close the entry point so it does not return. Diagnostics are free. I work with site owners from Ukraine and Poland, and with Russian speakers across the EU. I do not work with legal entities registered in Russia: that is an EU sanctions restriction.
Details and requestFrequently asked questions
My site redirects to a casino only on mobile. Why?
That is a typical mobile redirect: the code checks the device and fires only on phones. On a desktop the site opens normally, so the owner does not notice for a long time while mobile traffic leaks to the casino.
I cleaned the site and the redirect came back. What went wrong?
You removed the symptom, not the way in. A web shell or a cron job was left behind and restores the code, or the vulnerability used to get in was never closed. You have to find the entry point, otherwise the redirect keeps returning.
How do I know it is not my browser?
Open the site from a different device and network, and ask someone in another city. If it redirects for them too, the problem is the site. If instead many sites redirect to a casino only for you, that is your browser or an extension.
The hosting antivirus says all clean. Why is there still a redirect?
Because the antivirus checks files against signatures, while the redirect code often sits in the database or in .htaccess rules. The files really are clean. A silent scanner does not mean the site is fine.
Can I just roll back to a backup?
Sometimes, but only if the backup is known-clean and you know the infection date. Often the backup already contains the code. And more importantly, a rollback does not close the vulnerability, so the site gets reinfected.