Why Is My WordPress Site Showing Another Website Without Redirecting?

You enter your domain expecting to see your website. The address in the browser is correct, but the page is completely different.

It may look like an unfamiliar online store, a casino website, a pharmaceutical page, a fake news site, or a copied version of another business. In some cases, the design changes completely while your original domain remains visible in the address bar.

Quick answer: When a WordPress site shows another website without redirecting, something is replacing the response between the domain, server, WordPress installation, and visitor’s browser. Malware can cause it, but incorrect DNS records, a wrong hosting origin, cached pages, database injections, compromised plugins, modified templates, JavaScript, and service workers can produce the same symptom.

Important: Do not delete a plugin or file only because its name looks unfamiliar. Create a recoverable backup, preserve the evidence, and confirm what the component does before removing it.

I have seen this symptom during real WordPress malware cleanups. The visible page alone rarely identifies the actual source. You first need to determine where the legitimate response is being replaced.

Is the Website Redirecting or Replacing Its Content?

The first step is to separate two similar-looking problems.

Redirect malware

With a redirect, the browser moves from your domain to a different URL.

https://example.com/

changes to something like:

https://spam-example.com/

The redirect may be controlled by JavaScript, PHP, an .htaccess rule, a compromised plugin, a malicious advertisement, or injected database content.

Content-replacement malware

With content replacement, the browser stays on your domain:

https://example.com/

However, the HTML, layout, text, images, or interface displayed on that URL belongs to someone else.

The attacker may be:

• Printing different HTML before WordPress loads
• Replacing the homepage template
• Loading content from a remote server
• Displaying a full-page iframe
• Injecting content through the database
• Serving a cached malicious response
• Sending visitors to the wrong origin server without changing the browser URL

This distinction matters because a redirect scanner may not detect a page-replacement infection.

Quick Diagnosis: What Does the Symptom Suggest?

Use these observations to narrow down the layer responsible for the problem.

Several causes can exist at the same time. For example, a malicious plugin may display the replacement page while a cron job recreates the plugin after it is deleted.

Rule Out Non-Malware Causes First

Another website appearing on your domain is alarming, but it is important to check normal configuration problems before rebuilding WordPress or deleting files.

1. Check the WordPress homepage settings

Go to:

WordPress Dashboard → Settings → Reading

Confirm that Your homepage displays is set to the correct page.

A migration, imported starter template, demo-content installation, or accidental setting change can make WordPress display the wrong homepage without malware.

Open the selected homepage in its editor and inspect it for:

• An imported template
• An old staging-site layout
• An embedded iframe
• An Elementor HTML widget
• Custom JavaScript
• A shortcode that loads remote content
• An unfamiliar reusable block or template

When a page builder is involved, inspect the page inside the builder instead of checking only the frontend.

2. Check whether the domain points to the correct server

Your browser URL can remain unchanged while the request is sent to the wrong server.

This can happen after:

• A hosting migration
• A DNS update
• A Cloudflare configuration change
• A server move
• An expired or replaced hosting account
• Unauthorized access to the registrar or CDN account
• A copied DNS zone that still contains an old IP address

Compare the domain’s A, AAAA, and CNAME records with the IP address provided by the current host.

If Cloudflare or another reverse proxy is being used, verify the origin server behind it. A correct browser URL does not prove that the proxy is contacting the correct hosting server.

Also inspect the account for unexpected:

• Cloudflare Workers
• Origin rules
• Transform rules
• Redirect rules
• Reverse-proxy routes

An edge worker can replace an entire HTML response before it reaches the visitor.

3. Check the hosting document root and virtual host

On shared hosting, several domains may use the same physical server. If the web server does not recognise your hostname correctly, it may return a default website or another account’s website.

Ask the host to confirm:

• The document root assigned to the domain
• The active SSL virtual host
• The server IP address
• The directory from which the website is being served
• Whether the domain is attached to the correct hosting account

This is especially important after a migration, domain change, or SSL reconfiguration.

4. Purge caches carefully

A malicious or incorrect page may remain cached after the original source has been removed.

Possible cache layers include:

• Browser cache
• WordPress caching plugins
• LiteSpeed server cache
• Nginx or FastCGI cache
• Redis object cache
• Hosting-platform cache
• Cloudflare or another CDN
• A service-worker cache

Test the site in:

• An incognito window
• Another browser
• Another device
• A mobile data connection
• A third-party page-fetching or screenshot service

Do not treat clearing the cache as the complete cleanup. A cache purge may temporarily remove the symptom while the malicious source remains active.

5. Check for an old or malicious service worker

A service worker can act like a proxy inside the browser. It can intercept navigation requests and return a cached page instead of loading the current response from your server.

This can explain why:

• Only one browser shows the wrong website
• Clearing the WordPress cache changes nothing
• The server files appear clean
• Other visitors see the correct page
• The page continues working while the device is offline

In Chrome, open Developer Tools and inspect:

Application → Service Workers

Also check:

Application → Cache Storage

Review registered service workers and cached responses that you do not recognise. More technical information about request interception is available in the MDN service-worker fetch documentation.

Malware Techniques That Can Show Another Website Without Redirecting

After normal configuration problems have been ruled out, investigate the following infection points.

1. A malicious or leftover index.html overrides WordPress

Many web servers are configured to load index.html before index.php.

An attacker can upload:

/public_html/index.html

containing a completely different website. Visitors see that static file instead of WordPress, even though the WordPress installation is still present.

Common signs include:

• The homepage is replaced but inner pages still work
• WordPress admin remains accessible
• The wrong page appears only at the root URL
• The layout changed without a WordPress content revision

Check the document root for unexpected files such as:

index.html
index.htm
default.html
home.html

Do not delete them until you confirm that they are not part of the legitimate configuration.

2. A standalone spam website is installed inside a WordPress subfolder

Attackers do not always replace the main WordPress homepage. In some incidents, they create an entirely separate website inside an existing or newly created subdirectory.

For example, a legitimate website may normally use a URL such as:

https://example.com/shop/

Instead of loading the real WooCommerce shop, that path may display a gambling website, pharmaceutical store, fake product catalogue, or another unrelated site.

The browser remains on the legitimate domain because the malicious content is served directly from a folder inside the hosting account. No external redirect is required.

During a recent client investigation, I found a suspicious /shop/ directory containing:

google verification HTML file
index.php
robots.txt
sitemap.xml

All four files showed the same modification time. The directory also contained a 551 KB index.php file, a dedicated robots.txt, a sitemap, and a Google verification file. File size or filename alone does not prove malware, but this combination was highly suspicious because the legitimate shop path had been replaced by unrelated gambling content.

Visiting the site’s normal /shop/ URL displayed an Indonesian gambling page while the legitimate domain and path remained visible in the browser.

This was effectively a malicious mini-site hosted inside the victim’s website.

Attackers may use this technique to:

• Replace a legitimate shop, product, or landing-page path
• Publish casino, pharmaceutical, counterfeit-product, or other spam content
• Generate a separate XML sitemap for the malicious section
• Control how search engines crawl the injected directory
• Attempt to verify a specific URL-prefix property or another third-party service
• Use the authority of the compromised domain to rank spam content
• Keep the main homepage working so the compromise is less noticeable

A Google verification filename should be investigated, but its presence alone does not prove that the attacker successfully verified a Search Console property. Open the file, record its contents, and review Search Console ownership and user settings.

When investigating this pattern, inspect the suspicious directory for:

• A standalone index.php or index.html
• Its own robots.txt and sitemap.xml
• Google, Bing, or other verification files
• Large embedded HTML, CSS, JavaScript, or Base64 content
• Remote domains, gambling links, affiliate identifiers, or tracking code
• Internal links pointing to additional spam pages
• Directory-specific rewrite rules
• Cron jobs or backdoors capable of recreating the files

Do not clean only the visible /shop/ folder. The directory may be the payload while another backdoor, compromised account, vulnerable plugin, hidden administrator, or scheduled task is responsible for creating or restoring it.

3. The root index.php file has been modified

WordPress normally uses the root index.php file to begin loading the application.

Malware can modify it so that it:

• Includes another PHP file
• Prints attacker-controlled HTML
• Downloads content from an external server
• Loads a fake plugin or hidden loader
• Checks cookies, devices, referrers, or IP addresses
• Stops WordPress before the theme loads

Do not judge the file only by its size. A small file can be malicious, and a larger file is not automatically infected.

The safer approach is to compare WordPress core files with official checksums:

wp core verify-checksums

See the official WP-CLI core checksum documentation for the available options.

You can also download a clean copy of the same WordPress version and compare the files directly.

When replacing WordPress core files, preserve and investigate these separately:

wp-config.php
wp-content/

4. An internal server rewrite loads a different page

A web server can internally rewrite a request without changing the URL shown in the browser.

For example, a malicious rule could make a request for:

https://example.com/

internally load:

/hidden-folder/malicious-page.php

The visitor still sees the original domain and path.

Inspect:

/public_html/.htaccess

Also check for additional .htaccess files inside:

/wp-admin/
/wp-includes/
/wp-content/
/wp-content/uploads/

On Nginx servers, equivalent rules are normally stored in the server configuration rather than an .htaccess file.

Look for unfamiliar rules that route ordinary requests to unknown PHP files, hidden directories, or remote proxy endpoints.

5. A WordPress bootstrap file loads the malware early

Attackers often target files that WordPress loads before the active theme.

These include:

wp-config.php
wp-load.php
wp-settings.php
wp-blog-header.php

A malicious include placed in one of these files can replace the page before WordPress generates its normal output.

Common warning signs include:

• Includes pointing to unfamiliar files
• Long encoded strings
• Remote URL requests
• Code inserted before normal WordPress definitions
• Code appended after the expected end of the file
• References to PHP files inside uploads, cache, or temporary directories

Replacing only the root index.php will not fix an infection that is loaded through another bootstrap file.

6. PHP auto_prepend_file executes malware before WordPress

PHP can be configured to execute a file automatically before each requested PHP script.

Attackers may abuse this through:

.user.ini
php.ini
.htaccess

A suspicious setting may resemble:

auto_prepend_file = "/home/account/hidden-folder/loader.php"

The configured file runs before WordPress, allowing it to modify or replace responses across the website.

This technique is particularly important when:

• WordPress core checksums pass
• Replacing index.php does not solve the problem
• Several sites in the same hosting account are affected
• The malware returns immediately
• No responsible code can be found in the active theme or normal plugins

Search the hosting account for unexpected .user.ini and php.ini files. The directive is documented in the official PHP configuration documentation.

7. A fake or compromised plugin replaces the page

A plugin does not need to redirect visitors to hijack the frontend. It can use WordPress hooks, output buffering, template filters, or direct HTML output to replace the page.

It may:

• Select a malicious template
• Print remote HTML
• Load a full-page iframe
• Intercept the homepage request
• Inject JavaScript
• Display different content to selected visitors
• Hide itself from the normal Plugins screen

Check active and inactive plugins. Do not assume a plugin is safe because:

• Its folder name sounds technical
• It has a normal-looking plugin header
• It appears inactive
• It is hidden from the dashboard
• A basic malware scanner does not flag it

Compare each plugin with an official or vendor-provided copy.

8. A malicious MU plugin loads automatically

Must-use plugins are stored in:

/wp-content/mu-plugins/

WordPress loads them automatically. They cannot be disabled through the normal Plugins screen.

A small MU-plugin loader may:

• Include code stored elsewhere
• Fetch content from a remote domain
• Read a payload from the database
• Hide administrator accounts
• Restore deleted malware
• Replace a page only for selected visitors

Review the official WordPress MU-plugin documentation to understand how these files load.

Many site owners never inspect this directory, making it a useful hiding place for persistent malware.

9. A WordPress drop-in has been replaced

WordPress can automatically load special files known as drop-ins from the wp-content directory.

Common examples include:

advanced-cache.php
object-cache.php
db.php
sunrise.php
maintenance.php

Some are legitimate and are installed by caching, database, or multisite tools. However, attackers can modify or imitate them because they are loaded differently from ordinary plugins.

Compare each drop-in with the plugin or service that should have created it.

An unfamiliar advanced-cache.php, for example, should not automatically be deleted. First determine whether the site’s caching system uses it and whether its contents match a trusted copy.

10. The active theme or child theme has been modified

A compromised theme can replace the homepage without affecting the rest of WordPress.

Inspect files such as:

front-page.php
home.php
index.php
header.php
footer.php
functions.php

Also check:

• Child themes
• Template parts
• Block-theme templates
• Custom theme includes
• Header and footer script settings

Temporarily switching themes can help identify whether the active theme is involved, but it is not a complete cleanup. Malware in plugins, MU plugins, the database, or server configuration can remain active after the theme changes.

11. The replacement content is stored in the database

Not every website replacement is stored in a file.

Attackers can inject content into:

wp_posts
wp_postmeta
wp_options

The malicious data may be loaded through:

• Elementor widgets
• Gutenberg blocks
• Theme options
• Custom HTML widgets
• Header and footer plugins
• Code-snippet plugins
• Serialized page-builder data
• A compromised homepage record

This becomes especially important when the wrong page remains after WordPress core files have been replaced.

Search the database for:

• Text visible on the fake page
• Unfamiliar domain names
• <iframe> tags
• External scripts
• Large encoded strings
• Unexpected administrator email addresses
• Unknown scheduled-event data

Before editing serialized WordPress data, create a database backup. A direct text replacement inside serialized values can corrupt the stored configuration.

For a deeper investigation process, read my guide to finding and removing WordPress database malware.

12. JavaScript replaces the visible page

Sometimes the server sends the correct WordPress HTML, but injected JavaScript changes the page after it loads.

The script may use:

document.write()
innerHTML
fetch()
iframe elements
DOM replacement

One useful test is to compare View Page Source with the page shown in the browser’s Elements panel.

• View Page Source shows the HTML originally returned by the server.
• Developer Tools → Elements shows the page after JavaScript has modified the DOM.

If View Source contains the real website but the Elements panel contains the fake page, investigate JavaScript files, inline scripts, tag managers, widgets, browser extensions, and service workers.

Also test the page with JavaScript disabled.

13. A full-screen iframe covers the real website

An attacker may place an iframe over the entire viewport. Your real website loads behind it, but the visitor sees the external page inside the iframe.

Look for:

• An iframe with position: fixed
• A very high z-index
• Width and height set to 100%
• CSS that hides the original page
• An iframe inserted through a widget or database option

The iframe may be stored in a theme file, plugin, page-builder widget, database record, tag manager, or injected JavaScript file.

14. Conditional malware shows the page only to selected visitors

One of the hardest cases is cloaking.

The website may display the wrong content only to:

• Mobile visitors
• Search-engine visitors
• First-time visitors
• Visitors from specific countries
• Logged-out users
• Visitors without a particular cookie
• A small percentage of traffic
• Specific user agents
• Visitors arriving from an advertisement or search result

This explains why a website owner may see the correct homepage while customers report a completely different site.

Test with:

• Mobile and desktop devices
• Logged-in and logged-out sessions
• Incognito mode
• Different internet connections
• Different user agents
• A visit from a Google search result
• A direct visit to the URL

Avoid testing only from one browser because the malware may set a cookie after the first visit and hide itself during later checks.

15. Remote content is loaded from an attacker’s server

The malicious code may not contain the fake website itself. It may request content from a remote domain and print the returned response.

This allows the attacker to change the page without modifying your files again.

Look for code that:

• Makes remote HTTP requests
• Uses cURL
• Uses WordPress HTTP functions
• Loads unfamiliar APIs
• Builds a domain from encoded or fragmented strings
• Executes or prints a response returned by another server

The remote server may return different content based on the requesting IP address, user agent, cookie, or referrer.

Real Examples From WordPress Malware Cleanups

Case 1: Fake plugin folders and a modified loading path

During the incident that led to the original version of this article, I found unauthorized plugin directories with names such as:

wp-compat
CacheFusion
CDNConnect

The names appeared designed to resemble compatibility, caching, or CDN tools.

The investigation also involved a modified loading path connected to the site’s root files. This made it appear as though WordPress itself had been replaced, even though the original website files were still present.

However, these folder names should be treated as indicators to investigate, not universal proof of malware.

Before removing a suspicious plugin folder, document:

• The complete file path
• The plugin header
• The file modification dates
• The code it loads
• Any external domains it contacts
• Whether WordPress lists it normally
• Whether another file includes it
• Whether it returns after deletion

The wp-compat pattern is examined separately in my article about the hidden wp-compat WordPress backdoor.

An unfamiliar filename is evidence. The behaviour of the code is what confirms the infection.

Case 2: A gambling website replaced only the /shop/ path

In another client cleanup, the main website was still accessible, but visiting the normal /shop/ path displayed a complete Indonesian gambling website.

The attacker had placed a self-contained site inside the /shop/ directory. It contained a large index.php file together with its own robots.txt, sitemap.xml, and Google verification file.

This case demonstrates that wrong-content malware does not need to replace the main homepage. An attacker can hijack one valuable directory and use the legitimate domain to host a separate SEO-spam or gambling website.

Confirmed: The unauthorized files existed inside the site’s /shop/ directory, and the path displayed unrelated gambling content.

Still requiring investigation: The original entry point, whether the verification file was successfully used, and which persistence mechanism created or maintained the malicious directory.

Step-by-Step Investigation Process

Step 1: Preserve evidence before cleaning

Before changing the website:

1. Create a full file backup.
2. Export the database.
3. Save screenshots of the wrong page.
4. Record the date and time.
5. Copy suspicious files into a separate investigation archive.
6. Record their paths and modification dates.
7. Download relevant access and error logs.

Do not rely entirely on a backup created after the compromise. It is useful for evidence and recovery, but it may already contain the infection.

Step 2: Confirm who sees the wrong website

Test the website using:

• A direct visit
• A visit from a Google search result
• Desktop and mobile devices
• Incognito mode
• A logged-in session
• A logged-out session
• Another internet connection
• Another geographic location where possible

Record which tests reproduce the problem. This can reveal whether the malware uses cloaking conditions.

Step 3: Compare the source HTML with the rendered page

Open the affected page and select:

View Page Source

Then inspect:

Developer Tools → Elements

If both contain the wrong content: The replacement is probably happening on the server, inside WordPress, at the CDN, through the database, or in a cached server response.

If View Source is correct but Elements is wrong: Investigate JavaScript, service workers, browser extensions, tag managers, iframes, and delayed DOM replacement.

This is one of the fastest ways to separate server-side replacement from browser-side injection.

Step 4: Verify DNS, CDN, and hosting origin

Confirm:

• The domain resolves to the correct server
• The CDN points to the correct origin
• The hosting document root is correct
• No unknown worker or proxy rule exists
• The SSL virtual host is attached to the correct domain

Do this before rebuilding WordPress. A perfect WordPress cleanup will not help if the domain points to the wrong server.

Step 5: Inspect the document root

Check for:

index.html
index.htm
index.php
.htaccess
.user.ini
php.ini

Also look for:

• Recently added PHP files
• Files with misleading image, cache, or system names
• Unknown directories
• Existing directories such as /shop/, /store/, or /blog/ containing unexpected standalone index files
• Subdirectories with their own robots.txt, sitemap, or verification files
• Unexpected symbolic links
• Files that load code from another location

Do not use modification dates as the only proof. A migration, software update, extraction, or backup restoration can change many timestamps at once.

Step 6: Verify WordPress core files

With WP-CLI, run:

wp core verify-checksums

A failed checksum indicates that a core file differs from the official version, but each result still needs to be reviewed.

You can replace confirmed modified core files using a clean WordPress package of the same version.

Do not overwrite wp-content or wp-config.php during this process.

Step 7: Audit plugins, MU plugins, and drop-ins

Review:

/wp-content/plugins/
/wp-content/mu-plugins/
/wp-content/advanced-cache.php
/wp-content/object-cache.php
/wp-content/db.php
/wp-content/sunrise.php

List installed plugins with WP-CLI:

wp plugin list

Check for:

• Plugins absent from your records
• Duplicate copies of legitimate plugins
• Plugins hidden from the dashboard
• Recently modified files
• Unrelated PHP files inside a legitimate plugin
• Code that loads remote content
• Plugins that return after deletion

My list of known fake and malicious WordPress plugins provides additional examples, but filenames alone should never replace code inspection.

Step 8: Compare the theme with a clean copy

Download a clean copy from the original source and compare it with the installed theme.

Pay particular attention to:

functions.php
header.php
footer.php
front-page.php
home.php
index.php

For a custom theme, compare the current files with a known-clean Git repository, deployment artifact, or backup.

Step 9: Search the database and page-builder content

Search for:

• Text copied from the wrong page
• Domains loaded by the fake design
• External script URLs
• Iframes
• Encoded JavaScript
• Unexpected homepage content
• Unknown options added recently

Inspect the homepage through its page builder as well as in the database.

A malicious Elementor HTML widget, for example, can replace the visible interface while every WordPress core file remains clean.

Step 10: Check administrator accounts

Attackers often create a hidden or ordinary-looking administrator account so they can return later.

List administrator users:

wp user list --role=administrator

Check:

• Username
• Email address
• Registration date
• Account ownership
• User metadata
• Whether the user is visible in the dashboard

Unexpected users should be investigated before removal.

My guide to finding hidden WordPress administrator accounts explains this process in more detail.

Step 11: Inspect scheduled tasks and persistence

Deleting the visible payload is not enough when another mechanism recreates it.

List WordPress cron events:

wp cron event list

Also check:

• Hosting cron jobs
• Control-panel scheduled tasks
• Recently added scripts
• Backup and deployment jobs
• Server startup tasks where accessible
• Other websites in the same hosting account

A compromised neighbouring website can reinfect a cleaned installation when the sites share credentials, writable directories, or an account-level loader.

See my investigation into WordPress cron-job malware for examples of this persistence technique.

Step 12: Review access and error logs

Logs can help answer:

• When was the malicious file first accessed?
• Which IP address contacted it?
• Was a vulnerable plugin endpoint targeted?
• Was wp-login.php accessed successfully?
• Was a file uploaded through WordPress?
• Was XML-RPC involved?
• Did the infection begin after a plugin installation or update?

Investigate the period around the earliest confirmed malicious activity, but remember that attackers can alter file timestamps.

The goal is to identify the entry point, not only the visible payload.

How to Clean the Website Safely

The exact recovery process depends on what the investigation confirms, but a complete cleanup normally includes the following work.

1. Remove confirmed malicious components

Remove or replace only the files, plugins, database records, server rules, and configurations confirmed to be unauthorized.

Preserve copies for investigation before deleting them from production.

2. Replace modified WordPress core files

Use a clean package from WordPress.org that matches the installed version.

Do not copy one generic index.php into every website without checking its installation structure. WordPress may be installed in a subdirectory or use a customised document root.

3. Replace compromised plugins and themes

Do not try to remove individual malicious lines from a plugin when a trusted clean copy is available.

Delete the compromised copy and reinstall it from:

• WordPress.org
• The original developer
• The client’s official vendor account
• A verified clean repository

Avoid nulled plugins and themes. Their packages may contain hidden loaders, administrator-creation code, credential theft, spam injection, or remote-access backdoors.

4. Clean database injections

Remove confirmed malicious scripts, iframes, spam pages, widgets, and options.

Be careful with serialized data. Use WordPress-aware tools when possible instead of running uncontrolled search-and-replace operations directly in the database.

5. Remove persistence

Check and clean:

• MU plugins
• Drop-ins
• WP-Cron events
• Server cron jobs
• Hidden administrator users
• PHP prepend configuration
• Other websites in the same hosting account
• Compromised deployment or backup systems

Without this step, the wrong page may return hours or days later.

6. Change all relevant credentials

Rotate:

• WordPress administrator passwords
• Hosting-panel password
• FTP and SFTP passwords
• SSH keys
• Database password
• CDN and Cloudflare credentials
• Domain registrar password
• Email accounts used for password recovery

Enable two-factor authentication where available.

Also regenerate the WordPress security salts in wp-config.php to invalidate active login sessions.

7. Update vulnerable software

Update:

• WordPress core
• Plugins
• Themes
• PHP when supported by the website
• Server packages managed by you
• Page builders and their extensions

Remove abandoned, unused, or unsupported software.

8. Purge every cache layer

After the source and persistence mechanisms have been removed, purge:

• WordPress cache
• Hosting cache
• CDN cache
• Object cache
• Browser cache
• Service-worker cache

Retest the website from several devices, networks, referrers, and user states.

9. Check Google Search Console

After the website is stable, review:

Google Search Console → Security & Manual Actions

Check both:

• Security issues
• Manual actions

Also inspect Google Search for spam URLs created during the infection.

Request indexing for the cleaned homepage only after confirming that Googlebot and normal visitors receive the same legitimate content.

Why Did the Wrong Content Return After Cleanup?

When the fake website returns, one of the following was probably missed:

• A hidden backdoor
• A malicious administrator account
• An MU plugin
• A PHP prepend file
• A scheduled task
• A compromised FTP or hosting account
• Another infected website in the same hosting account
• A vulnerable plugin that was not updated
• A database loader
• A CDN worker or poisoned cache
• A malicious service worker
• A compromised registrar or Cloudflare account

Reinfection does not necessarily mean the deleted file repaired itself. More often, another component restored it or the attacker still had access.

My guide to why WordPress malware keeps coming back covers these persistence mechanisms in greater detail.

Frequently Asked Questions

Why is my domain showing another website?

Your domain may point to the wrong server, return a cached response, load a replacement WordPress template, or execute malicious code. Check DNS and hosting configuration before assuming WordPress itself is infected.

Why does the browser URL stay the same?

The content can be replaced through an internal server rewrite, PHP loader, plugin, theme, database entry, JavaScript, iframe, service worker, CDN worker, or incorrect server origin. None of these techniques requires a visible browser redirect.

Does another website appearing on my domain always mean malware?

No. DNS mistakes, hosting virtual-host errors, migrations, cache problems, service workers, and incorrect WordPress homepage settings can produce similar symptoms. Malware becomes more likely when you also find unauthorized files, users, scripts, plugins, scheduled tasks, or database records.

Is wp-compat always malware?

A folder with that name is suspicious when the owner did not install it, particularly when it contains unauthorized code or is connected to other infected files. However, a filename alone is not enough to confirm malware. Inspect its code, origin, plugin header, and behaviour.

Should I delete unfamiliar plugins immediately?

No. Create a backup and inspect the plugin first. Hosts, developers, and performance services sometimes install plugins with unfamiliar names. Delete a folder only after confirming that it is unauthorized or compromised.

Why does the site look correct when I am logged in?

The malware may intentionally hide from administrators. It can check WordPress login cookies and show the fake page only to logged-out visitors.

Why does the wrong page appear only on mobile?

The infection may check the visitor’s device, user agent, screen size, or cookie state. Mobile-only replacement is common in conditional malware and cloaking campaigns.

Can malware replace only my WordPress /shop/ page?

Yes. An attacker can install a standalone spam site inside the /shop/ directory, replace the directory’s index file, or apply a rewrite rule only to that path. The main homepage and WordPress dashboard may continue to work normally.

Can malware be stored in the WordPress database?

Yes. Attackers can store scripts, iframes, remote URLs, replacement content, loaders, and scheduled-event data in posts, metadata, options, widgets, and page-builder data.

Will reinstalling WordPress fix the problem?

It may replace compromised core files, but it will not clean malicious plugins, MU plugins, themes, database records, server configuration, administrator accounts, cron jobs, service workers, or CDN settings.

Should I restore a backup?

A verified clean backup can help, but restoring an unknown backup may restore the infection. You must also fix the original entry point, remove persistence, and change compromised credentials.

Should I request Google indexing after cleanup?

Yes, but only after the site has been fully cleaned, secured, and tested. Requesting indexing while Googlebot still receives malicious or inconsistent content can delay recovery.

Final Thoughts

A WordPress site showing another website without redirecting is not one specific malware family.

It is a symptom that can originate from several layers:

• DNS and CDN configuration
• Web-server routing
• WordPress core loaders
• Plugins and MU plugins
• Drop-ins
• Themes
• Database content
• JavaScript and iframes
• Service workers
• Browser and server caches
• Persistent backdoors

The safest solution is not to guess which filename looks suspicious. It is to identify where the response is being replaced, confirm the responsible component, remove the persistence mechanism, and close the original entry point.

I have manually cleaned thousands of hacked WordPress websites, including cases involving fake plugins, replaced homepages, database injections, hidden administrator accounts, malicious cron jobs, remote-content loaders, and server-level persistence.