Filthy redirects need WordPress website repair
A Dubai company checks its WordPress site on a desktop. Everything opens normally. Then a customer messages to say the site redirects to some grim spam page from Google on mobile. Not ideal. The owner clears the cache, tests again, sees nothing wrong and breathes out. That is usually where the fun starts.

A WordPress website redirecting to spam or unfamiliar pages should be treated as a repair incident, not a layout problem. Some malicious redirects are conditional, meaning they appear only for certain devices, countries, referrers, first-time visitors or search traffic. A clean test from the administrator does not prove the issue has gone. The sensible response is to capture evidence, restrict access, investigate files and database content, clean carefully, rotate credentials and monitor after recovery.
The scenario: Google mobile traffic gets the dirty version
Here is the pattern I would take seriously. A UAE service business appears normal when staff type the domain directly into Chrome on their office desktop. But visitors tapping the Google result on mobile are sent to an unfamiliar gambling, adult, fake prize or software download page.
That difference matters. Conditional redirects are often designed to avoid showing themselves to the same administrator on every visit. They may check the referrer, user agent, cookie, IP address or whether the visitor has been seen before.
So when someone says, I cleared the cache and it stopped, the honest answer is: maybe. Or maybe the redirect simply decided not to show itself to you again.
The false assumption: cache cleared means malware gone
Cache clearing can remove an old served copy of a page. It can also make the next test look cleaner than the last one. It does not prove that the database, theme files, plugins, uploads folder, cron tasks, rogue admin users or access credentials are clean.
The plugin might be guilty. It might also just be standing closest to the scene of the crime.
Before rebuilding your website, reinstalling random plugins or shouting at the hosting company, slow down. The first job is not to make the symptom disappear from your own screen. The first job is to understand what is triggering it and stop visitors being exposed while you investigate.
What to capture before everyone starts pressing buttons
Evidence gets lost quickly. A cache purge, plugin reinstall or database restore can remove the clues needed to understand the route in. That does not mean leaving a harmful site open. It means collecting the basics before making noisy changes.
- The exact URL visited and the URL it redirected to.
- Device type, browser, operating system and whether it was mobile data or office WiFi.
- How the visitor arrived, especially Google organic result, paid ad, social link or direct entry.
- Time and timezone of the incident.
- Screenshots or a short screen recording if safe to capture.
- Whether the redirect happens only on first visit or after cookies are cleared.
- Recent changes: plugin updates, theme edits, new users, hosting migration, DNS change or a developer login created in a hurry.
A boring specific one: check whether a staging copy or old subdomain is still indexed and redirecting oddly. I have seen businesses chase the live site while Google was sending mobile visitors to an abandoned copy with ancient plugins. Lovely.
Malicious redirect incident checklist
A proper WordPress website repair in Dubai should separate containment, investigation, cleaning and recovery. Mixing them together is how people delete useful evidence, miss the actual cause, then get reinfected a week later.
| Stage | What to do | What not to assume |
|---|---|---|
| Containment | Restrict admin access, consider a maintenance page, block public access if visitors are at risk, pause campaigns sending traffic to the affected page. | Do not assume one clean desktop test means customers are safe. |
| Investigation | Review server logs, recent file changes, database content, wp_options entries, redirects, user accounts, mu-plugins, uploads and theme files. | Do not blame the last plugin updated without evidence. |
| Cleaning | Remove injected code, replace altered core files from clean sources, clean database content carefully, remove rogue users and check scheduled tasks. | Do not wipe everything blindly if a clean backup and change history can explain the breach. |
| Recovery | Rotate passwords, salts, API keys and hosting credentials, update in a controlled order, test mobile and referrer behaviour, monitor for recurrence. | Do not put the same credentials and vulnerable setup straight back online. |
Backups help, but only if you know when they were clean
A backup is not automatically a rescue boat. If the backup was taken after the injection, restoring it just puts the problem back with a fresh coat of paint.
Look for restore points before the first known redirect, then compare file dates, database changes and user activity. If the oldest available backup is already compromised, you may still need to clean the current site rather than restore.
This is also where proper WordPress maintenance in Dubai earns its keep. Not because maintenance can promise nothing bad will ever happen. It cannot. But regular backups, update records and basic monitoring make repair less like archaeology with a blindfold on.
Access restriction is not panic, it is manners
If visitors are being sent to unsafe content, leaving the site fully open while ten people repeatedly refresh it is not clever. Containment can be proportionate. A small brochure site might go behind a temporary holding page. A WooCommerce store may need a more careful decision because orders, payments and customer messages are involved.
Either way, protect visitors first. Then protect evidence. Then repair.
Also rotate access properly. WordPress admin passwords are only part of it. Check hosting panel users, SFTP accounts, database access, deployment keys, API tokens, SMTP credentials and any old agency or freelancer logins. Rogue administrator accounts with friendly names are not rare. Neither are forgotten users created during a rushed campaign landing page build.
Cleaning is more than deleting a suspicious line
Redirect code can sit in theme files, plugin files, must-use plugins, .htaccess rules, JavaScript loaded from database content, widget areas, page builder templates or injected header fields. Some infections also reinsert themselves from another location after you remove the obvious bit.
Database work needs care. Search and replace tools can break serialized data if used badly. Editing live files in the WordPress theme editor during business hours is also a cracking way to turn a redirect problem into a white screen problem.
A clean repair route usually means working from server access, taking a fresh backup before changes, documenting what was found, then testing across the same conditions that produced the original complaint: Google result, mobile, first visit, cleared cookies, different network.
When is it safe to put the site back?
Safe is not a magic certificate. It is a practical decision based on what was found, what was cleaned, what access was rotated and whether the trigger conditions have been retested.
Before reopening properly, I would want to see:
- No redirect reproduced from the original device and referrer pattern.
- Suspicious users removed and legitimate users confirmed.
- Core, plugin and theme files checked against expected versions where possible.
- Database content reviewed for injected scripts or hidden redirects.
- Passwords, salts and relevant keys rotated.
- Updates planned and applied in a controlled order, preferably with a restore point.
- Monitoring in place for file changes, uptime, search warnings and repeated symptoms.
Do not declare victory after five minutes. Post-clean monitoring matters because reinfection often points to a missed access route, an old vulnerable component or a restore that brought the problem back.
FAQ
Why does my WordPress website redirect only on mobile?
Some redirects are conditional. They may trigger for mobile user agents, Google referrers, first-time visitors, certain countries or visitors without a previous cookie. That behaviour is meant to hide the problem from site owners and administrators. It needs controlled testing, not repeated casual refreshing from the same device.
Should I take my Dubai website offline if it redirects to spam?
If visitors are being sent to unsafe or fraudulent content, containment is sensible. That may mean a temporary maintenance page, access restriction or pausing campaigns while evidence is captured. The right level depends on the website type, traffic, checkout activity and business impact, but ignoring it because one desktop test looks fine is risky.
Can I fix a WordPress spam redirect by restoring a backup?
Sometimes, but only if the backup is known to be clean and the access route is closed. Restoring a compromised backup can bring the redirect back. Check when the first report happened, compare files and database changes, remove rogue users and rotate credentials before assuming a restore has solved the repair.
What credentials should be changed after WordPress website repair?
Change more than WordPress passwords. Review hosting panel access, SFTP or FTP users, database credentials, admin users, API keys, salts, deployment keys, SMTP logins and any old agency or freelancer accounts. If the same access remains open, a cleaned site can be compromised again.
How long should a repaired WordPress website be monitored?
At minimum, monitor through the same conditions that caused the original problem and keep checking after reopening. Look at file changes, admin users, search warnings, uptime, forms and mobile referral behaviour. The exact period depends on what was found, but a same-day clean test is not enough evidence on its own.
Treat the redirect like an incident, not a display bug
A spam redirect damages confidence quickly. Customers may not tell you politely. They may just leave, question the business, or avoid sending details through the site. For a service business, clinic, real estate firm or agency, that is more than a technical nuisance.
Preserve the evidence and contain the site before repeatedly refreshing or reinstalling random plugins. If you want a calm repair triage before more damage is done, message Standish Services on WhatsApp.