Custom website development: the client says the official site redirects to another domain — shut it down or back it up first?

Bottom line first: When a website automatically redirects to an unknown site, the first moves are to preserve evidence and restrict access, not to shut the site down or delete code. Based on common handling experience in 2026, the usual order is: preserve evidence → restrict access → locate the entry point → remove backdoors → rotate credentials → verify and bring back online. Among redirect cases, weak admin passwords, components left unpatched for long periods, and overly permissive upload permissions account for most incidents; shutting the site down first loses the investigation timeline, while deleting code first often fails to clean it thoroughly.

Why “shut it down first” and “delete code first” are both poor opening moves

Taking the site offline stops the bleeding immediately, but it also shuts down the investigation scene: login records in access logs, timestamps of modified files, backdoor files in deep directories, and unknown admin accounts in the database can all disappear during a hasty reinstall. For a brochure-style website, a few hours of downtime usually does not affect business; but when the site is also catching paid traffic or inquiries, one day offline can reduce that day's leads, and this cost should be made clear to the client first.

A second misconception is “delete the malicious code first, and the pages just need to look normal.” A redirect is only a symptom; the real entry points are weak passwords, outdated components, upload directories that allow script execution, and database accounts with excessive privileges. If the entry point is not closed, the attacker can simply use the same entry point again. Pages that are restored and then redirect again two or three days later are not rare in projects.

• Taking the site offline: reduces the chance of further exploitation, but loses timeline evidence and disrupts any running campaigns;
• Deleting code: restores pages quickly, but there is no way to verify whether the entry point has been closed;
• Changing only passwords: blocks the weak-password path, but backdoor files can still be reused if they remain;
• A safer approach: take a read-only snapshot first (website files + database + the last 7 to 30 days of access logs), then touch anything else.

Handling order: a six-step containment method

The reason for this order is that each step provides the basis for judging the next: without evidence, you cannot locate the entry point; without a clear entry point, you cannot confirm whether backdoors have been fully removed. Note that this is a handling order, not an investigation order; when there are enough clues, locating the entry point and removing backdoors can proceed in parallel.

1. Preserve evidence: package website files, database, and access logs off-server; do not leave them only on the original server.
2. Restrict access: add an IP allowlist to admin login, temporarily disable uploads and online editing, and if needed replace suspicious pages with a maintenance page.
3. Locate the entry point: use the timeline to find abnormal files, unknown admin accounts, unusual cron jobs, and scheduled scripts.
4. Remove backdoors: compare files against a clean version, replace modified files, and delete files of unknown origin.
5. Rotate credentials: change passwords for admin, database, FTP/SSH, cloud accounts, and bound email addresses, and enable two-factor authentication.
6. Verify and bring back online: release gradually, watch logs for 24 to 72 hours, and only resume campaigns after confirming there is no second redirect.

The step most often skipped is credential rotation. A common situation is that only the website admin password is changed, while the database and cloud account passwords remain the same as those handed over originally; after cleanup, the same credentials are used to get back in. Treat the rotation scope as “anything that can modify the website counts,” and change more rather than fewer.

First determine which type of redirect it is; the handling differs greatly

A redirect on open can have different sources, and the response differs accordingly. To diagnose, test once on different networks and different devices, then check DNS records and the modification times of key files.

• Only some pages redirect, and titles in search results look normal: usually scripts injected into pages; focus on shared template files and third-party scripts loaded on the site;
• All visitors and all devices redirect, and DNS records have been changed: usually a DNS-layer compromise; first check A/CNAME records and login history for the domain account;
• Redirect only on the client's corporate network, while external networks are normal: possibly internal DNS or router poisoning, not necessarily a server issue;
• Redirect only in a certain mobile browser or a certain region: possibly carrier-level link hijacking, or analytics/ad scripts replaced.

Where entry points usually are: four common categories

Ranking entry points by frequency helps avoid detours during handling. Common mass scanning in 2026 mainly targets unpatched legacy components and admin panels with simple passwords; targeted intrusions are more often seen in scenarios with messy permission handovers.

• Admin passwords: multiple people sharing one account, accounts not revoked after departure, initial passwords unchanged;
• Component versions: CMS, frameworks, and plugins left unpatched for long periods, with known vulnerabilities exploited at scale;
• Upload directories: image or attachment directories allowing script execution, which is effectively opening another backdoor;
• Server permissions: cloud and database accounts with excessive privileges, and keys scattered across chat logs or documents.

These can be turned into four standards: admin accounts map to specific people, component versions can be checked at any time, upload directories have no script execution permission, and cloud accounts are assigned least privilege. Meet all four, and most mass intrusions will be kept out; fail to meet them, and cleanup only buys time.

In a handling project, downtime is often what stalls progress

Based on project delivery experience, a typical constraint is: the website is running paid ads, the client has only one part-time ops person, downtime is not allowed during the day, and no one is available at night to confirm. Our approach is to first block visitors with a maintenance page, restrict admin access to fixed IPs, and let the campaign landing page use a separate domain to keep collecting leads; meanwhile, pull file and database snapshots off-server and do comparison and cleanup in a late-night window with no business traffic. As a result, the redirect was stopped that night, leads were not interrupted, and the cost was that investigation was split across two nights and the observation period extended to about 72 hours.

The experience range that can be summarized from such deliveries is: whether to take the site offline, and for how long, is mostly determined by whether the website is receiving paid traffic, not by technical difficulty. For sites with active campaigns, the typical range is to keep visible interruption to 0 to 4 hours where possible; for brochure sites without campaigns, accepting 1 to 2 days of maintenance status is usually fine. What really slows progress is often not removing backdoors, but being unable to find the person who can approve downtime.

Cleaning in place vs. rebuilding from scratch: how to choose

Neither route is inherently better; it depends on whether backups are trustworthy and whether backdoor locations can be identified clearly. Below are experience ranges based on common project situations; actual timeline and cost still depend on site complexity.

• Clean in place: suitable for sites with simple structure, a clean backup within the last 7 days, and changes concentrated in a few files. Experience range is about half a day to 2 days; cost is relatively low, residual risk is higher, and the observation period is longer.
• Rebuild from scratch: suitable when there is no trustworthy backup, backdoor locations cannot be fully identified, and the site itself is not complex. Experience range is about 1 to 5 days; the process is more controllable, at the cost of reconfiguring indexing, analytics, and some form workflows.
• Decision criteria: if anomalies persist after two or more cleanups, or the entry point still cannot be confirmed, prioritize a rebuild rather than repeatedly patching the same environment.

One more easy pitfall: several sites are hosted on the same server, but only the redirected one is cleaned. With shared databases, shared directories, or shared accounts, other sites may already have the same batch of backdoors; the handling scope is usually assessed for the server as a whole. This is also one reason many companies move their official website to separate hosting after a redesign.

Applicable scenarios and boundaries

You can try the above process yourself first if: it is a brochure-style website, there is no membership or online payment, there is a usable backup within the last 7 days, traffic is not high, and the client can accept 1 to 2 days of maintenance status. In this case, walking through the six steps yourself will in most cases restore access within two days.

Do not handle it yourself if: the system involves online payment, member data, orders, or external APIs, or it is a business site required to meet compliance retention rules. For these systems, prioritize the official processes of the cloud provider and security service provider. Whether reporting is required and whether users must be notified should be based on a check against relevant laws, regulations, and platform rules—not on impression. If there is suspicion that user data has been accessed, move the handling order even earlier: restrict access and verify data first, then discuss restoration.

FAQ

If my website is redirected, does changing the admin password first help?

It helps, but it is incomplete. Changing the password can block the weak-password entry point, but if backdoor files or unknown admin accounts remain, they can still be reused.

After recovery, how do I confirm the cleanup is complete?

Watch logs for 24 to 72 hours, look for unknown IPs accessing the admin panel and newly added unknown files, then retest the redirect from different networks.

Will other websites on the same server be affected?

When accounts, databases, or directories are shared, they often affect one another; the handling scope is usually assessed for the server as a whole, not just the redirected site.

Will a site that has been redirected lose search rankings?

If search engines detect a short-term redirect, ranking fluctuations or warnings may appear. After recovery, submit through the search resource platform; in most cases rankings recover gradually, subject to the platform's documentation.

Once a website redirect appears, finish preserving evidence and restricting access before discussing cleanup. If the site is simple and has a clean backup, you can go through the six steps; if it involves payment, member data, or external APIs, it is best to hand it directly to the cloud provider or security service provider. Based on project delivery habits, Xiyue Company usually hands over backup files, an account list, and emergency contacts together at acceptance, so that when problems arise there is someone to contact and evidence to check; specific handling actions should still follow official documentation and platform rules.