Strange Domain in Your Site's Code? How to Check It Safely

By Glenn Lyvers · Updated September 28, 2026 · 7 min read

If you’ve found a domain in your site’s code that you don’t recognise, don’t open it in your browser. Look it up passively instead — VirusTotal, urlscan.io and a WHOIS lookup will tell you in a few minutes whether it’s a known bad host, how old it is, and what it serves — and then search your whole site for every other place it appears, because injected domains are almost never in only one spot.

I get sent a lot of these. Recent ones people have asked me about include scriptjshub.com, dbzy5.com, nirox.site, seika.one and whoushex.top. I’m not going to tell you what each of those is from a name alone — that’s the point of this guide. The method below is how I check any of them, and it works the same for whatever turned up in yours.

Where strange domains usually turn up

Most owners find the domain by accident: a browser console error, a slow-loading request in developer tools, a security plugin warning, or a <script src> in the page source that nobody remembers adding. The places it actually lives, in rough order of how often I find it there:

• Theme header and footer output — header.php, footer.php, functions.php, or a “header scripts” box in the theme or an insert-code plugin. See injected JavaScript in your header and footer.
• The database — wp_options (widget text, theme mods, plugin settings), wp_posts post content, and wp_postmeta, including page-builder data. Malware in the WordPress database covers each table.
• Existing JavaScript files — a line appended to the end of a legitimate jquery.min.js or a theme bundle, which loads the outside script at runtime.
• .htaccess and server config — not as a script, but as a redirect target. See .htaccess hacked.
• A tag manager container — if the domain isn’t in your files or database at all but still loads, check Google Tag Manager before anything else.

Look it up without visiting it

Malicious domains often fingerprint the visitor and serve different content to different people. Visiting from your own browser tells you little, and can hand the attacker your IP address or worse. Use tools that fetch it for you.

Check	What it tells you
VirusTotal (URL and domain tabs)	Which engines flag it, related files and URLs, and passive DNS history.
urlscan.io	A screenshot and the full list of requests the page makes, fetched from their infrastructure. Search their existing scans first.
WHOIS / RDAP (ICANN Lookup)	Registration date and registrar. A domain registered days before your infection started is a strong signal.
A plain web search for the domain in quotes	Whether other site owners and researchers have already written it up.

Clean results don’t clear it. New attack domains often have zero detections for days, which is exactly why attackers rotate them. The question isn’t “is it flagged?” but “did I put it there?” If nobody on your side added it, treat it as hostile.

Patterns that give it away

• Look-alike names that borrow from real infrastructure — words like jquery, cdn, analytics, js, static or api glued onto an unfamiliar domain. Real CDNs don’t need you to trust a brand-new hostname.
• Cheap or unusual TLDs and random-looking strings. The TLD alone proves nothing, but combined with a recent registration date it narrows things quickly.
• Obfuscated loading. The domain isn’t written out; it’s assembled with atob(), String.fromCharCode() or array joins. Legitimate vendors have no reason to hide their hostname. Reading obfuscated code shows how to decode it safely.
• Conditional behaviour. The script only fires for first-time visitors, mobile devices or search referrals. That’s the hallmark of families like Balada Injector and Sign1, and the reason owners so often can’t see what customers are complaining about — see redirects that only happen on mobile.

Find every place it’s referenced

Deleting the one line you spotted is how people end up doing this again next week. Search everything. Use a distinctive part of the domain, not the full URL, since injections are often split or encoded.

Files

From the site root over SSH:

grep -rIl "nirox" --include=*.php --include=*.js --include=*.html --include=.htaccess .

Repeat for any fragment you decoded from obfuscated code, and search wp-content/uploads without the --include filter — PHP in the uploads folder is a common companion.

Database

With WP-CLI, wp db search "nirox" --all-tables lists every table and column that contains it. Without WP-CLI, run the equivalent in phpMyAdmin:

SELECT option_name FROM wp_options WHERE option_value LIKE '%nirox%';
SELECT ID, post_type FROM wp_posts WHERE post_content LIKE '%nirox%';
SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%nirox%';

Adjust the wp_ prefix if yours differs. If you get hits in _elementor_data, read malware in Elementor data before editing — that field is escaped JSON and a careless edit breaks the page.

Removing it so it stays gone

Take a full backup of files and database first, even of an infected site; you may need it as evidence. Then remove the injection from every location you found, not just the first. Before you call it done, ask what put it there. Injected domains are a symptom: a backdoor, a vulnerable plugin, a stolen admin login or a scheduled task will re-add the script within hours if left in place. WordPress backdoor removal covers the persistence I check for on every job.

Finally, check whether the domain got you flagged. Scripts from known-bad hosts are a common reason for antivirus warnings like URL:Mal, so run a website blacklist check once the site is clean.

When it’s worth handing over

If the domain is in one theme file and you can see how it got there, this is a reasonable DIY job. If it’s in the database, in several files, or it came back after you removed it, you’re dealing with persistence, and the time goes into finding the thing that re-adds it rather than the script itself. That’s the work my malware removal service is built around: I trace every reference, find and close the entry point, and give you a written report of what was there.

Common questions

How do I check if a domain in my website code is malicious?

Look it up passively rather than visiting it: check it on VirusTotal and urlscan.io, and look up its registration date with WHOIS or ICANN Lookup. A recently registered domain that nobody on your team added is suspicious even with zero detections, because new attack domains often take days to be flagged.

Is it safe to visit a suspicious domain to see what it does?

Not from your normal browser. Malicious hosts fingerprint visitors, may try exploits, and often serve something harmless to anyone who looks like a researcher. Use urlscan.io or VirusTotal, which fetch it from their own infrastructure and show you the requests and screenshot.

I removed the script but it came back. Why?

Something is re-adding it: usually a backdoor file, a malicious scheduled task in WP-Cron, a rogue admin account, or a vulnerable plugin being exploited again. The injected domain is the symptom. Find and remove the persistence, then close the entry point, or the script will keep returning.

How do I search my WordPress database for a domain?

With WP-CLI, run wp db search followed by part of the domain and the --all-tables flag. Without it, use phpMyAdmin to run LIKE queries against wp_options option_value, wp_posts post_content and wp_postmeta meta_value. Search for a distinctive fragment, since injected domains are often split or encoded.

Can a script from another domain get my site blacklisted?

Yes. Antivirus web shields and Google Safe Browsing judge what your page loads, not just what is stored on your server. A script pulled from a known-bad domain is one of the most common reasons for warnings like URL:Mal, even when every file on your server looks clean.