The public website occupies an unusual position in most organizations. Its absence is embarrassing, visible and commercially disruptive, yet nothing internal may stop working when it goes down. It is often treated as less critical than line-of-business systems and has no named technical owner because an agency built it, handed it over and moved on.

At the same time, it is the most exposed system the organization owns. It must accept connections from anyone. It commonly runs a content management system shared with millions of other sites. Automated scanners test it continuously, whether or not anyone has chosen your company as a target. That combination of low attention and universal exposure is why a marketing site so often ends up in an incident queue.

We inherit many sites in this condition. The route from neglected project to recurring emergency is consistent, which means it can be interrupted with a relatively modest operating model.

How marketing sites are usually compromised

The attack is rarely clever or tailored to the organization. Most cases begin through one of four routes.

The first is a vulnerable plugin or theme. The core platform is generally well maintained and patched quickly, but the surrounding ecosystem is uneven. A plugin may be abandoned by its author. A theme may bundle a library frozen at the version available in 2019. An extension installed for one campaign may remain for years because nobody knows whether it is safe to remove. This is the majority of what we see. Public sites are scanned continuously for known flaws; mass exploitation commonly follows a plugin advisory within days, and one abandoned plugin can compromise an otherwise current site.

The second route is a weak or reused administrative credential. Public login pages are easy to find and are attacked continuously. A memorable password used elsewhere, combined with no second factor, turns another service’s breach into access to the website. Shared agency accounts make attribution and offboarding harder even when the password itself is strong.

The third is stale supporting infrastructure: an outdated PHP or other language runtime, a database port exposed to the internet, a hosting control panel left at permissive defaults, or a forgotten staging copy at a guessable subdomain. Staging is particularly dangerous when it runs last year’s code, contains production data and has weaker access control because somebody considered it non-production.

The fourth is the supplier chain. An agency may hold credentials for many customers, a developer workstation may be compromised, or an FTP account created for a contractor in 2021 may still work. The organization can maintain its own named accounts perfectly and still inherit risk through access it never reviews.

Why the consequence is larger than the website

If the site were completely isolated, a compromise would still be disruptive. Attackers use legitimate domains to serve malware, host phishing pages and inject content for search manipulation. The first sign may be a browser warning on the homepage, a customer’s mail filter blocking the domain, or a sharp fall in search traffic that takes months to recover. The lasting cost can be trust and discoverability rather than the value of the files on the server.

Poor isolation makes the event more serious. A marketing site that shares a server with an internal application, stores database credentials that work elsewhere, or runs from inside the corporate network turns a low-value internet target into a foothold. Backups mounted permanently with write access can be altered alongside production. A compromised sending configuration can also damage the reputation of domains used for legitimate email.

The single most valuable architectural decision is therefore isolation. Run the public site somewhere that touches nothing else. Give it credentials that work nowhere else. Separate production from staging, separate customer sites from one another, and keep backups outside the account that operates the live site. Treat any integration with CRM, payments, identity or internal APIs as a deliberately narrow trust boundary rather than a convenient shared credential.

Give the system an owner and an inventory

Maintenance fails first as an ownership problem. Name one role accountable for the site’s technical health, even when an outside provider performs the work. That owner should know where the domain is registered, who hosts DNS, where the application runs, which repository or deployment source is authoritative, where backups live, who can administer each layer and how renewals are paid.

Inventory every plugin, theme, integration, administrative account, domain, certificate and scheduled task. Record its purpose and owner. If nobody can justify an extension, remove it rather than merely deactivating it. Deactivated code can remain present on disk and may still be exploitable in some configurations. Fewer components mean fewer advisories, fewer update conflicts and fewer places to hide persistence.

The domain registrar and DNS provider deserve the same attention as the site. An attacker who controls DNS can redirect visitors, intercept some validation flows and defeat a perfectly patched application. Use unique named accounts, MFA, least privilege, protected recovery methods and renewal contacts that do not depend on one employee’s personal address.

A maintainable patching process

Set a defined cadence for updating the core platform, plugins and themes, and define an expedited path for actively exploited vulnerabilities. A calendar alone is not enough. Each cycle needs an inventory check, current backups, a staging update, functional verification, production deployment and observation afterward. Record what changed and whether anything required manual intervention.

Staging should be built from the same code and configuration pattern as production, while using sanitized or synthetic data wherever possible. Restrict access and prevent it from sending real customer email, charging payments or being indexed by search engines. A stale clone with real data is not a safety environment; it is a second, less-defended production system.

Testing must cover more than the homepage. Exercise representative page templates, navigation, search, forms, authentication, downloads, consent controls, analytics, caching and any purchase or lead path. Submit a real test form and confirm it arrives at the intended destination. Review application and server logs while doing so. A visually correct page can conceal a failed integration, a blocked background task or repeated errors.

Keep the platform beneath the content manager current: language runtime, database, web server, operating system and hosting control panel. Hosting choice matters because inexpensive shared hosting may pin a site to an old runtime or offer little visibility into patching. If the platform cannot support a maintained version of a required component, migration is part of maintenance, not an optional redesign.

Control administrative and supplier access

Every person who can publish code, edit content, change DNS or enter the hosting console should have an individual account protected by MFA. Eliminate routine shared logins. Restrict administrator roles to people who need them, use lower-privilege editor roles for ordinary content work, and review access on a schedule and whenever a project or employment relationship ends.

For agencies and contractors, define how access is granted, where credentials are stored, whether file transfer is encrypted, and when access expires. Do not let convenience turn one supplier credential into permanent access across a portfolio. Deployment keys and automation accounts also need an owner, narrow scope and rotation plan; a non-human credential can outlive its original purpose even more quietly than a human account.

Put protection and detection around it

A web application firewall can block common exploit traffic and buy time between disclosure and a maintenance window. It does not replace patching, because a bypass, authenticated route or origin exposed around the firewall can still reach vulnerable code. Restrict direct access to the origin where the hosting model allows it, and test that the site remains available through the intended path.

Monitoring should check availability from outside the hosting environment, certificate validity, expected content, DNS resolution and file integrity against a known-good copy. It should also verify that the monitor is checking in. A green dashboard based on stale results is worse than an explicit unknown. Route actionable alerts to a queue with an owner and escalation path; do not rely on a mailbox nobody reads outside business hours.

Certificate expiry deserves its own design because it causes more public outages than compromise and is entirely preventable. Automate renewal, monitor the renewal job, and alert when renewal fails. Waiting to alert on the certificate’s expiration is a different event roughly thirty days later, and only the earlier signal gives the team useful time to respond. Also monitor domain and hosting renewals, payment failures and account notices.

Backups should be offsite, versioned and restore-tested. Keep enough history to reach a point before a compromise was discovered, because discovery often trails entry. Protect backup administration with separate credentials and MFA. Test recovery into an isolated location and document the time, dependencies and decisions required. A successful backup job shows that data was written; a restore test shows that the site can return.

Symptoms and first checks

Different visible symptoms suggest useful first questions, although none proves a single cause:

  • If browsers warn visitors, check for injected scripts and compare file integrity with a known-good source.
  • If the site becomes slow while server load rises, inspect running processes and outbound connections for cryptomining, spam or other abuse.
  • If search traffic collapses, compare the rendered source seen by search crawlers for hidden or conditional content.
  • If an unexpected administrator appears, preserve logs and review the user table, authentication history and recent plugin changes.
  • If the certificate expires, inspect renewal logs and validation failures rather than simply replacing the certificate and losing the cause.

These are first-response checks, not a cleanup procedure. Preserve evidence before changing the affected system when the consequence warrants investigation. Record the time of detection, known-good backup points, current DNS answers, active accounts and relevant logs. Change control during an incident matters because well-meant edits can erase the evidence needed to identify the entry route.

Recovery means rebuilding, not deleting what a scanner found

Once code execution is confirmed, removing malicious files and returning the site to service does not establish trust. The attacker had an opportunity to create additional administrators, modify core files, add scheduled tasks, inject database content and place web shells in quiet directories. A scanner reports what it recognizes, not everything that happened.

The defensible recovery is a rebuild: create a fresh platform installation; restore content from a backup that predates the compromise or from a reviewed export; reinstall plugins and themes from trusted source packages rather than copying the affected filesystem; rotate every relevant credential, including hosting and database access; and close the identified entry route before publishing the rebuilt site. Review DNS, administrator accounts, deployment credentials, API keys, mail configuration and connected services as part of the same boundary.

Identifying the route matters most. A clean rebuild that restores the same vulnerable plugin or reuses the compromised password is a scheduled repeat. If the route cannot be proven, remove or replace the most plausible exposures and increase monitoring while treating residual uncertainty honestly. Keep the old environment isolated for evidence, never as a fallback that can quietly return to production.

Keeping it out of the queue

A public website is a system, not a document. It runs code, accepts connections from the entire internet and decays without maintenance in a way a printed brochure does not. Its operating checks can be concise: all components supported, all privileged access named and protected, patches current, backups recent and restored, certificate renewal healthy, monitoring fresh, staging restricted, and no unexplained changes in files or administrators.

Organizations whose sites stay quiet are generally not using exotic defenses. They assigned an owner, reduced the component inventory, isolated the site from everything that matters, established patch and access routines, and arranged for a machine to report when those controls stop working. That standing cost is modest. It compares favorably with rebuilding under pressure while customers see a warning page and the marketing team asks each hour when the site will return.