Why would static sites suddenly redirect to spam pages?

Static only describes the site content. It does not rule out a compromised hosting account or server. Compare the deployed files with a known-good copy, especially the first lines of each index file, and inspect server configuration for unexpected rewrite rules or injected scripts. A redirect that depends on mobile devices, search referrals, or other request details can be easy to miss in a normal desktop visit.

Check access and system logs around when the changes appeared, and look for unexpected scheduled jobs, processes, or account activity. If files are being altered by a privileged account, treat the server as compromised rather than just deleting the visible script. Preserve useful logs, rebuild from trusted sources, and rotate credentials from a clean device.

First figure out what kind of redirect it is. In the browser's network panel, check whether the server returns a 301 or 302, or whether the page loads and then runs a script that changes location. Also compare the raw response from the server with the local, trusted copy of the site. Try more than one device and network, including a mobile browser, since conditional behavior can make the problem seem intermittent.

If the response is clean but the browser still goes elsewhere, check extensions, cached service workers, and the device itself. If the response contains the redirect or an unfamiliar external script, focus on the hosting environment and files.

Since the domains are on separate servers, check each layer independently rather than assuming one shared DNS problem. Verify the domains' DNS records and nameservers with more than one resolver, then compare what each hostname serves with what you get by connecting directly to the expected server while supplying the hostname. A domain can resolve correctly while the content on its server is compromised, and a server can serve the wrong site because of virtual-host configuration.

Run a recursive search through the deployed directories for unfamiliar script URLs, redirect code, and recently changed files. Compare hashes or file contents with your original exports or backups. A malware scanner missing something does not prove the files or server are clean, especially if the redirect is conditional or an attacker can rewrite files after a scan.

If the affected files keep changing, find and remove the mechanism doing the rewriting before trusting a cleanup. Otherwise the same injected code may come back.

If you confirm that a privileged account is modifying files, I would stop treating this as a one-page cleanup. Rebuild the affected servers from a trusted image or backup, patch them, review administrator and SSH access, and replace credentials and keys. Keep a copy of logs and the altered files first if you may need to work out how access happened. For a time-sensitive site, serving a known-clean copy from a fresh host is safer than leaving a questionable server online.